Gobernanza de agentes de IA en el SDLC

Gobernanza de agentes de IA en el SDLC: trazabilidad, control y evidencia

Cuando un agente de IA puede consultar un repositorio, generar cambios y ejecutar pruebas, revisar el código al final cubre solo una parte del control. La organización también necesita saber qué información recibió, qué herramientas utilizó, qué estaba autorizado a hacer y quién permitió que el trabajo avanzara.

Estas preguntas tienen consecuencias concretas. Ante un defecto, un cambio inesperado o una revisión de seguridad, el equipo debe poder reconstruir la ejecución y entender bajo qué condiciones se produjo el resultado.

La gobernanza de agentes de IA en el SDLC consiste en diseñar ese control desde el inicio: delimitar su autonomía, asignar responsables, establecer validaciones y conservar evidencia suficiente para explicar cada entrega.

El desafío aparece cuando la IA empieza a participar en un flujo de trabajo compartido. Como abordamos en nuestra guía sobre desarrollo de software con IA, integrar agentes exige coordinar requerimientos, arquitectura, desarrollo, calidad y seguridad. Este artículo profundiza en la arquitectura de control que necesita esa coordinación.

¿Qué significa gobernar agentes de IA dentro del SDLC?

Gobernar agentes de IA significa establecer reglas y responsabilidades sobre su actuación durante el ciclo de vida del software: qué propósito tienen, qué contexto reciben, a qué sistemas acceden, qué acciones pueden ejecutar y qué condiciones deben cumplir para continuar.

Ese gobierno debe expresarse en el funcionamiento del proceso. Una política que exige aprobación humana tiene que traducirse en una compuerta efectiva. Un límite de acceso debe restringir las acciones disponibles. Una exigencia de trazabilidad debe producir registros que puedan consultarse después.

Leonel Hernández, Deputy CTO de ACL powered by DataArt, resume la diferencia entre una ayuda puntual y una capacidad integrada:

“Usar IA puede significar apoyar una tarea específica. Gobernar IA dentro del SDLC implica integrarla al flujo completo”.

En las respuestas entregadas para este artículo, esa integración comprende agentes especializados, evidencia auditable, métricas y aprobación humana en etapas clave.

La autonomía cambia el modelo de control

Un agente que consulta documentación y uno que modifica un repositorio pueden utilizar el mismo modelo, pero sus consecuencias operativas son diferentes.

El primero necesita fuentes pertinentes y acceso autorizado. El segundo requiere, además, un entorno de trabajo delimitado, revisión de los cambios y condiciones claras para incorporarlos.

NIST aborda esta diferencia en su publicación sobre uso de herramientas en sistemas de agentes. Allí distingue herramientas de solo lectura, escritura restringida y escritura, considerando también si actúan en entornos confiables o no confiables. La publicación presenta enfoques para analizar capacidades y restricciones; no una clasificación universal de riesgo.

Los siguientes criterios propone criterios de evaluación para el SDLC. Es un modelo editorial, no una taxonomía oficial de NIST ni una descripción de los niveles de SPIREX®.

Consultar documentación: fuentes autorizadas y registro de consultas.
Proponer historias o código: criterios de aceptación y revisión.
Ejecutar pruebas en un entorno acotado: límites de ejecución y evidencia.
Modificar una rama: permisos definidos, diferencias verificables y aprobación para incorporar cambios.
Intervenir en una entrega: condiciones de autorización, responsables y mecanismos de recuperación.

El control depende también del entorno. Ejecutar una prueba que crea datos en un ambiente aislado tiene implicaciones distintas de hacerlo sobre un sistema utilizado por clientes.

Por eso, antes de habilitar una herramienta, conviene preguntar qué puede modificar, qué consecuencias tendría un error y cómo se detendría o corregiría la acción. El análisis debe considerar la combinación de agente, herramienta, permisos y entorno.

Trazabilidad: qué debe poder reconstruir una organización

La trazabilidad permite conectar una acción con las condiciones bajo las cuales ocurrió.

Guardar la respuesta final del agente ayuda a conocer el resultado. Para investigar una ejecución, también hace falta vincularla con el requerimiento, el contexto utilizado, los cambios realizados y las validaciones recibidas.

Una organización puede usar estas preguntas para evaluar su capacidad de reconstrucción:

Una ejecución debería permitir responder:

Identidad: ¿qué agente intervino y con qué propósito?
Modelo: ¿qué modelo y configuración utilizó?
Contexto: ¿qué información y versiones recibió?
Herramientas: ¿qué sistemas podía consultar o modificar?
Acción: ¿qué ejecutó concretamente?
Resultado: ¿qué produjo o cambió?
Validación: ¿qué controles se realizaron y qué encontraron?
Decisión humana: ¿quién autorizó continuar y bajo qué condiciones?
Evidencia: ¿qué registros permiten comprobarlo?

Estas preguntas funcionan como una guía de evaluación. Su implementación debe ajustarse al riesgo del proceso y a las políticas de acceso, conservación y protección de información de la organización.

Registrar indiscriminadamente todo el contenido puede introducir otro problema: almacenar información sensible sin una necesidad definida. El diseño debe resolver qué evidencia se conserva, durante cuánto tiempo y quién puede consultarla.

Con SPIREX®, la documentación describe un inventario de agentes con propósito, tipos de datos y nivel de riesgo; identificación de los modelos efectivamente utilizados; y un registro de aprobaciones humanas con autor, momento y contexto. Ese conjunto puede exportarse como un paquete para revisión de auditoría.

La utilidad de estos registros depende de que puedan relacionarse con el trabajo entregado. Una aprobación aislada dice poco si no es posible identificar qué versión del resultado fue aprobada.

Del resultado a la evidencia verificable

Cuando un agente informa que una prueba pasó, el equipo necesita conocer qué prueba ejecutó, sobre qué versión, en qué ambiente y con qué resultado.

La evidencia debe permitir verificar el alcance de la validación. Esto puede incluir registros de ejecución, capturas, hallazgos reproducibles y resultados asociados al cambio.

Escenario ilustrativo: un agente modifica una validación en un formulario. La ejecución muestra que el flujo principal funciona, pero la revisión detecta que faltan casos de entradas inválidas y permisos insuficientes. Tener evidencia permite identificar ese vacío; una afirmación general de “pruebas exitosas” podría ocultarlo.

En SPIREX®, el módulo de Evidencia y Pruebas ejecuta una suite en un entorno aislado y entrega capturas, video, hallazgos con severidad y pasos de reproducción. También contempla un modo de exploración con límites sobre cantidad de pasos, direcciones permitidas y capacidad de escritura o solo lectura.

Estos elementos ayudan a revisar lo que ocurrió. Su alcance sigue estando determinado por las pruebas y condiciones de ejecución: demostrar que un conjunto de casos pasó no garantiza la ausencia de defectos fuera de ese conjunto.

La evidencia debe acompañar una afirmación precisa. “Se validaron estos comportamientos en este ambiente” es una conclusión que el equipo puede comprobar y utilizar para decidir.

Quién configura, ejecuta, valida y responde

Un proceso gobernado necesita responsables para definir las reglas y resolver las excepciones.

Conviene distinguir cuatro funciones:

Configuración: definir agentes, modelos, herramientas y condiciones del flujo.
Ejecución: realizar las tareas dentro de los límites autorizados.
Validación: revisar resultados y decidir si cumplen los criterios para avanzar.
Responsabilidad: responder por la incorporación del resultado al producto o proceso.

Una misma persona puede asumir varias funciones en un equipo pequeño. Lo relevante es que la asignación sea explícita y que los cambios en las reglas también tengan control.

Por ejemplo, quien valida una entrega debería saber si el agente utilizó una nueva instrucción, un modelo diferente o una integración que antes no estaba disponible. Esas modificaciones pueden alterar las condiciones bajo las cuales se produjo el trabajo.

También deben definirse las excepciones: qué ocurre si falla una integración, si aparece una instrucción contradictoria o si la ejecución supera el alcance previsto. El flujo necesita una condición de detención y un responsable al cual escalar.

Con SPIREX®, la documentación contempla cuentas con roles y validación de permisos en el servidor. Esa capacidad describe el acceso de usuarios a la plataforma; los límites de actuación de agentes y herramientas deben evaluarse específicamente para cada flujo.

Human-in-the-Middle: decisiones humanas con información suficiente

SPIREX® utiliza el concepto Human-in-the-Middle para describir la intervención humana en momentos clave del recorrido.

Leonel lo explica así:

“la IA puede ejecutar, proponer y acelerar, pero las decisiones críticas siguen pasando por una persona”.

En sus respuestas menciona la revisión de historias y el gate de entrega como ejemplos de esa intervención.

Una aprobación aporta control cuando la persona puede evaluar lo que está autorizando. Para ello necesita ver el alcance, los cambios, los resultados de las pruebas y los hallazgos pendientes.

La pregunta de diseño es dónde hace falta criterio humano. Resolver una ambigüedad de negocio, aceptar una excepción de seguridad o aprobar una entrega requiere información y autoridad diferentes de las necesarias para ejecutar una tarea repetitiva.

También debe quedar claro qué sucede después de la decisión. Si cambian el alcance o el resultado aprobado, el proceso debería determinar si hace falta una nueva revisión.

Concentrar la intervención humana en decisiones definidas permite organizar el trabajo de revisión. El objetivo es que cada aprobación tenga un propósito y una consecuencia concreta.

Gobernar el contexto que reciben los agentes

El comportamiento de un agente depende del modelo y de la información disponible durante la ejecución: documentación, código, instrucciones, convenciones y resultados anteriores.

Por eso, el contexto también necesita gobierno.

Una instrucción desactualizada puede hacer que el agente aplique un patrón que el equipo ya abandonó. Una documentación incompleta puede omitir una dependencia relevante. Una fuente accesible puede contener información que el agente no debería utilizar para esa tarea.

El equipo debe definir quién mantiene ese conocimiento, cómo se revisan los cambios y qué versión se utiliza en cada ejecución.

SPIREX® aborda parte de este trabajo mediante Contexto de Proyectos y la gestión de skills. La documentación describe análisis previo del repositorio, construcción de un grafo de dependencias e incorporación de documentos de negocio y normativa. Las skills contienen instrucciones de trabajo y sus cambios se presentan como propuestas revisables, con versionamiento separado del código de la plataforma.

Esto permite tratar las instrucciones como activos sujetos a revisión. Si una skill cambia, conviene evaluar qué agentes la utilizarán, qué comportamientos podría afectar y cómo se verificará el resultado.

El contexto debe ser pertinente y estar autorizado. Tener más información disponible no resuelve por sí solo esas dos condiciones.

Observabilidad y auditoría: operar y reconstruir

Observabilidad y auditoría se apoyan en registros, pero responden a necesidades distintas.

La observabilidad ayuda a comprender la ejecución y detectar problemas durante la operación. La auditoría permite reconstruir posteriormente acciones, condiciones y decisiones.

Seguimiento operativo: identificar el estado del trabajo, incluidas detenciones y esperas por aprobación.
Diagnóstico: entender problemas como errores de integración o fallos de pruebas.
Auditoría: reconstruir acciones, cambios y decisiones humanas.
Verificación: comprobar qué evidencia respalda la versión entregada.

Con SPIREX®, Control Tower presenta operación, actividad y salud de los servicios. La capa de gobernanza registra información sobre agentes, modelos y aprobaciones humanas para su consulta y exportación.

Una ejecución puede terminar correctamente y tener evidencia insuficiente para una revisión posterior. También puede producir numerosos registros sin ofrecer una explicación clara de un incidente. El diseño necesita cubrir ambas situaciones: información útil para actuar durante la ejecución y registros suficientes para explicar lo ocurrido después.

Cómo gobernar sin frenar el delivery

La gobernanza puede convertirse en un cuello de botella cuando exige revisiones sin definir qué riesgo resuelven o qué información necesita el revisor.

Para evitarlo, cada control debe responder a una condición concreta: qué acción lo activa, qué comprueba, quién resuelve un hallazgo y cuándo puede continuar el trabajo.

Una validación repetitiva puede automatizarse si tiene criterios definidos y resultados comprobables. Una decisión ambigua de negocio requiere intervención de quien conoce el alcance. Una acción con consecuencias difíciles de revertir puede necesitar una autorización más estricta.

La política debería convertirse en reglas ejecutables:

Limitar las herramientas y ambientes disponibles;
Detener el flujo ante hallazgos que impidan continuar;
Presentar evidencia al responsable de revisión;
Registrar la decisión y el resultado aprobado;
Escalar las excepciones a una persona definida.

Estas reglas deben probarse junto con el flujo. Si un control existe en el documento, pero la ejecución puede omitirlo, su capacidad de gobierno es limitada.

También conviene medir la espera por revisión. Un agente puede reducir el tiempo de preparación y dejar todo el trabajo acumulado frente a una persona sin capacidad para validarlo. En ese caso, el tiempo total de entrega no mejorará en la misma proporción.

Cómo empezar antes de ampliar la autonomía

Un punto de partida útil es un caso acotado, con un problema observable y resultados que el equipo pueda verificar.

Las respuestas de Leonel proponen ejemplos como transformar requerimientos en historias, reducir retrabajo en QA, mejorar documentación o acelerar validaciones repetitivas. La recomendación es establecer una línea base, comparar antes y después y decidir con evidencia antes de escalar.

Para evaluar un piloto, conviene medir:

Flujo: tiempo desde el requerimiento hasta el resultado aceptado.
Calidad: retrabajo y defectos posteriores a la incorporación.
Revisión: tiempo de revisión activa y espera por aprobación.
Trazabilidad: proporción de ejecuciones con los registros exigidos completos.
Evidencia: proporción de entregas con validaciones verificables.
Costo: consumo de IA y esfuerzo humano por resultado aceptado.

Son indicadores propuestos para evaluar una implementación, no resultados prometidos ni capacidades atribuidas automáticamente a SPIREX®.

Leonel plantea el criterio central:

“La pregunta no es solo si la IA produjo más, sino si ayudó a desarrollar mejor”.

Ampliar autonomía debería depender de esos resultados y de la capacidad del equipo para manejar excepciones. Cada nueva herramienta, permiso o entorno añade condiciones que necesitan evaluación.

SPIREX®: llevar la gobernanza al flujo de desarrollo

SPIREX® es un framework de IA para el ciclo de vida del software. Su documentación describe agentes especializados que reciben requerimientos, trabajan con contexto del proyecto, refinan historias, diseñan soluciones, generan pruebas y código, y producen evidencia con aprobación humana en etapas clave.

Para el problema de gobernanza, sus piezas aportan funciones concretas: el pipeline declara fases y puertas de aprobación; la revisión de código presenta diferencias y hallazgos; Evidencia y Pruebas conserva resultados de ejecución; y Gobernanza registra agentes, modelos y decisiones humanas.

Estas capacidades permiten organizar el control alrededor del trabajo. Su aplicación requiere definir el alcance de cada flujo, los responsables, las condiciones de aceptación y la evidencia necesaria.

Antes de incorporar más agentes al SDLC, una organización debería poder responder tres preguntas: qué pueden hacer, quién autoriza las decisiones relevantes y cómo se verificará lo entregado.

Conoce SPIREX® y conversa con ACL powered by DataArt sobre cómo evaluar un flujo de desarrollo, definir sus controles y medir sus resultados antes de ampliar la autonomía.

Preguntas frecuentes

¿Qué diferencia hay entre gobernanza de IA y gobernanza de agentes de IA?

La gobernanza de IA abarca reglas y responsabilidades sobre sistemas de inteligencia artificial. En los agentes, también debe controlar su capacidad de actuar mediante herramientas: qué pueden consultar o modificar, en qué entornos y con qué autorización.

¿Se necesita una aprobación humana después de cada acción?

La frecuencia debe definirse según el riesgo y las consecuencias de la acción. Las tareas acotadas pueden operar con reglas y validaciones automáticas; las decisiones críticas requieren un responsable con información suficiente para autorizar el avance.

¿Qué debe registrarse para auditar un agente dentro del SDLC?

Según el riesgo del flujo, conviene vincular requerimiento, agente, modelo, contexto, herramientas, acciones, resultados, validaciones y decisiones humanas. También deben definirse acceso, conservación y protección de esos registros.

¿Tener logs significa que una ejecución es auditable?

Los logs aportan información, pero deben permitir relacionar acciones, versiones, validaciones y decisiones. Su utilidad depende de la integridad, accesibilidad y contexto de los registros.

¿Cómo evaluar si los agentes generan valor sin perder control?

Hay que comparar una línea base con resultados aceptados: tiempo total de ciclo, calidad, retrabajo, esfuerzo de revisión y costo. También debe verificarse que las ejecuciones mantengan la trazabilidad y evidencia exigidas.