El auge de las herramientas de desarrollo agentico, que delegan a agentes de IA la preparación de modificaciones de código, plantea la cuestión de la auditabilidad de los flujos de trabajo. En los sectores regulados, saber quién aprobó una modificación ya no basta: es necesario poder reconstituir el contexto, los controles y las decisiones que la produjeron.
Dentro de una gran institución financiera que utiliza un agente en su flujo de trabajo de desarrollo, el equipo de auditoría interna y cumplimiento se planteó una pregunta precisa. Para una merge request (una solicitud de fusión de código) abierta por un agente para actualizar una dependencia de un servicio de pago, ¿se podía indicar quién la había aprobado, qué datos de entrada y qué prompts había utilizado el agente, qué controles de política se habían evaluado y cómo reproducir o deshacer esta tarea? El equipo no tenía respuesta. El sistema de entrega no consideraba el trabajo del agente como una transacción delimitada y auditable.
Un diff validado por la CI (la integración continua, que prueba automáticamente el código) y aprobado prueba que ha ocurrido una modificación. Sin embargo, no prueba el contexto utilizado por el agente, las decisiones de política evaluadas antes de crear la merge request, ni la posibilidad de reproducir el resultado en una ejecución posterior. Ahora bien, en entornos regulados, el « cómo » y el « por qué » son esenciales. Esta situación se repite en todas las plataformas y en las organizaciones DevSecOps: el presupuesto para las herramientas agenticas se aprueba en pocas semanas, mientras que el de los registros de ejecución, la vinculación de identidad y las herramientas de reejecución nunca aparece o se trata como un simple costo de cumplimiento.
Cuatro excepciones recurrentes
En cuanto los agentes abren merge requests en un entorno CI/CD regulado, aparecen cuatro tipos de excepciones de cumplimiento. La primera es la procedencia faltante: nadie puede decir qué datos utilizó el agente, ya sean las especificaciones, el contexto recuperado, las llamadas a herramientas o el estado del repositorio. La segunda es la atribución de identidad incierta, dado que el agente actuó bajo un token de servicio compartido, sin un responsable humano designado. La tercera es una cadena de decisión no reconstruible, ya que el razonamiento solo se capturó de forma efímera. La cuarta es el retroceso no delimitado: al estar acopladas las modificaciones del agente, cualquier deshacer se convierte en un trabajo manual a través de los commits y los repositorios.
La reconstrucción a posteriori consiste en examinar los registros de conversación, las salidas parciales de la CI y las trazas del agente aún disponibles. En la mayoría de las organizaciones, nadie contabiliza las horas dedicadas cada semana a esta tarea, lo que explica que su costo permanezca invisible. La fuente propone una prueba simple: ¿es capaz un equipo de producir en menos de una hora un dossier de pruebas que reúna las especificaciones de la tarea, el estado del repositorio, los controles evaluados y el responsable humano que originó la acción?
« Entregar primero » y sus límites
La estrategia « Entregar primero, gobernar después » puede funcionar cuando los agentes se limitan a perímetros restringidos, como la generación de pruebas, pequeñas refactorizaciones o la actualización de documentación, con una revisión humana sólida. Sin embargo, se fractura cuando los equipos se liberan de estas restricciones, las bibliotecas de prompts se multiplican con un registro inconsistente y los tokens compartidos hacen imposible la atribución a escala del portafolio. El artículo también cita el caso de una gran empresa que quiso construir una base de flujo de trabajo antes de generalizar los agentes: el proyecto de plataforma se extendió varios trimestres y los equipos terminaron por sortearlo.
El artículo subraya que « la presión competitiva recompensa la velocidad, mientras que los reguladores recompensan la capacidad de reconstitución ». Describe el costo de esta brecha: pruebas faltantes descubiertas durante un control, remediación de varias semanas y un radio de impacto que se amplía con cada acción de agente mal registrada. Cita a este respecto a Crédit Agricole CIB, que pilota, según el texto, una entrega que reúne a miles de desarrolladores distribuidos en decenas de países en una sola plataforma DevSecOps, condición requerida para auditar el trabajo agentico.
Nombrar y medir el trabajo
La fuente recomienda tratar este proyecto como un producto en sí mismo, denominado « Ejecución registrada para el CI/CD agentico », con recursos que reúnan ingeniería de plataforma, seguridad, auditoría y experiencia del desarrollador. Sus entregables cubren un esquema de registro que captura datos de entrada, salidas, llamadas a herramientas y versión del modelo, una vinculación de identidad que asocia cada acción a un responsable humano, registros de decisiones de política, así como mecanismos de reejecución y retroceso. El seguimiento puede basarse en la profundidad de la cola de excepciones, el tiempo medio para obtener pruebas, la tasa de éxito de las reejecuciones y la tasa de reapertura de excepciones.
Si solo debe darse un paso, el texto aconseja comenzar por los casos de mayor riesgo, como los cambios de dependencias, las modificaciones de Infrastructure as Code y la configuración de seguridad. La última prueba propuesta consiste en pedir a un equipo que deshaga limpiamente una modificación fusionada redactada por un agente, basándose únicamente en artefactos registrados.
