Los agentes ya escriben cambios en producción. Su gestión del cambio es ahora su gobernanza de agentes

Si se observa lo que han lanzado los agentes empresariales en la última semana, aparece un patrón que tiene poco que ver con el chat. Autonomous Engineer, de ServiceNow, planifica, construye y prueba cambios de flujos de trabajo. El agente de EKS a GKE de Google traduce manifiestos de Kubernetes y los propone mediante GitOps. El diseño de migración de AWS genera código de infraestructura a partir de módulos aprobados. En los tres casos, el resultado del agente es el mismo tipo de objeto: un cambio en un sistema en producción.

Eso importa porque las empresas ya tienen un control maduro para los cambios en producción. Es antiguo, poco vistoso y se audita cada año. Nuestra lectura, y es una opinión, no un hecho, es que la gestión del cambio va a convertirse en el lugar principal donde se gobierna la autonomía de los agentes, y que la mayoría de las empresas llegará antes ampliando ese proceso que inventando uno específico para la IA.

Las señales

• Cambios de flujos de trabajo. AI Workflow Factory de ServiceNow une process mining, construcción por agentes y despliegue en un ciclo, con Autonomous Engineer (en Early Access) programando sin supervisión.
• Cambios de infraestructura. El agente de migración de EKS a GKE de Google (en Public Preview) sitúa puntos de aprobación y GitOps entre el agente y el clúster. La arquitectura de migración de AWS tiene un agente que compone código de infraestructura con módulos aprobados.
• Cambios en el propio agente. Cambiar de modelo altera el comportamiento sin tocar el código, y por eso dijimos que retirar un modelo es la nueva obsolescencia de API.
• Aplicaciones que nadie programó a mano. Plataformas como Copilot Managed Runtime ejecutan aplicaciones generadas a partir de lenguaje natural, que siguen necesitando un proceso de publicación.

Qué cambia cuando el autor es un agente

Los procesos de cambio se diseñaron para autores escasos. Un equipo producía un número manejable de cambios y un comité de cambios podía revisar los arriesgados. Los agentes eliminan la escasez. Cuando un agente puede proponer veinte mejoras de flujos a la semana, se rompen tres cosas:

1. El volumen. Revisar a mano cada cambio no escala, y aprobar por inercia es peor que no revisar.
2. La atribución. “Autor: svc-automatizacion” no dice qué agente, qué versión, qué modelo ni quién lo pidió.
3. La segregación de funciones. Si el agente de una misma plataforma escribe, prueba y promueve el cambio, el control que separa autor y aprobador ha desaparecido sin que nadie lo note.

Un registro de cambio para el trabajo de agentes

1. Autor: ID del agente, versión, modelo
2. Promotor: la persona que lo pidió
3. Alcance: sistemas y datos afectados
4. Evidencia: pruebas y controles
5. Aprobador: otra identidad
6. Rollback: plan y disparador

Lo registra la plataformaPersonas con nombre

Después, use las categorías de cambio que ya conoce su área de sistemas para decidir dónde cabe la autonomía:

• Cambios estándar: preaprobados, de bajo riesgo y repetibles. Aquí un agente puede actuar solo cuando tiene historial, por ejemplo aplicando una plantilla ya probada al flujo de un área nueva. La escalera de nuestro marco para que el agente se gane la autonomía se aplica tal cual: una clase de cambio solo pasa a “estándar” para un agente con evidencia.
• Cambios normales: requieren evaluación y aprobación. Los agentes pueden ser autores, pero la evidencia (pruebas, controles de políticas, análisis de impacto) debe salir del pipeline, no de la descripción del agente, y el aprobador debe ser otra identidad, persona o motor de políticas.
• Cambios de emergencia: siguen siendo humanos. El agente puede diagnosticar y proponer, pero saltarse la aprobación normal es una decisión de una persona que responde por ella.

La respuesta al volumen no es un comité más grande. Es llevar la evidencia al pipeline (pruebas automatizadas, políticas como código, ejecuciones comparativas) para que las personas revisen la decisión, no el diff.

Por qué el supervisor llegará primero

Para bancos, aseguradoras y otras entidades financieras de España y del resto de la UE esto ya es una obligación con nombre. El artículo 9 de DORA exige políticas y procedimientos documentados para que todo cambio en sistemas TIC se registre, pruebe, evalúe, apruebe, implante y verifique de forma controlada, y la norma técnica que lo desarrolla (artículo 17 del Reglamento Delegado 2024/1774) concreta funciones y responsabilidades, documentación, procedimientos de marcha atrás y tratamiento de cambios de emergencia. Nada de eso distingue si el autor es una persona o un agente. Un inspector que muestree cambios en un flujo crítico preguntará quién lo escribió, quién lo aprobó y qué prueba respaldó la aprobación. “Lo hizo el agente” no es una respuesta que el marco reconozca. Nuestra expectativa es que, en un año, la autoría por agente sea un campo habitual en las muestras de auditoría y supervisión.

Qué hacer ahora

1. Añada campos de autoría de agentes a los registros de cambio: identidad, versión y modelo, y la persona promotora.
2. Exija una identidad aprobadora distinta en todo cambio normal escrito por un agente.
3. Defina qué clases de cambio puede tratar un agente como estándar, con evidencia para cada una.
4. Lleve la evidencia al pipeline para que la aprobación revise resultados, no descripciones.
5. Trate las actualizaciones de modelo y de prompt como cambios en el propio agente, con el mismo registro.
6. Informe por separado durante seis meses de los cambios hechos por agentes, con tasas de fallo y de rollback, antes de conceder más autonomía.

En resumen

La pregunta de gobernanza para agentes que escriben cambios en producción tiene una respuesta antigua: la gestión del cambio. Amplíela con la autoría de agentes, mantenga separados autor y aprobador, y deje que la evidencia del pipeline decida qué tipos de cambio puede hacer un agente por su cuenta.