Gobernanza de agentes de código: decidir antes de automatizar
Define responsables, límites y pruebas para agentes que modifican software. La política debe orientar el trabajo cotidiano.
Un agente puede ser capaz de ejecutar una acción sin que esta forme parte de su tarea. Esa diferencia inicia la gobernanza. El objetivo no es aprobar manualmente cada lectura, sino definir qué efectos se permiten, en qué entorno y bajo la responsabilidad de quién.
El AI Risk Management Framework del NIST ofrece una referencia voluntaria de gestión de riesgos. La OWASP describe la autonomía excesiva relacionada con funciones, permisos y libertad de actuación. Estas referencias ayudan a formular preguntas; no certifican automáticamente la configuración de un equipo.
Describe los límites mediante sus efectos
“Se permite usar IA en el proyecto” resulta demasiado amplio para orientar una integración. Especifica si el agente puede leer código, modificar una copia de trabajo, preparar una propuesta, publicar una aplicación o cambiar datos. Son acciones con consecuencias distintas y no necesitan la misma autorización.
Identifica también el entorno. Una credencial de pruebas no debería apuntar silenciosamente a producción. Usa nombres comprensibles, permisos adecuados y una forma de verificar el destino antes de actuar. La persona responsable debe saber qué sistema se verá afectado sin depender de la interpretación de una conexión ambigua.
Haz que las herramientas respeten la política
Si la tarea consiste en consultar el estado de una entrega, puede bastar una herramienta de lectura. Exponer una función administrativa genérica amplía innecesariamente los efectos posibles. Describe entradas, consecuencias y errores para evitar que el agente adivine el significado de identificadores o parámetros.
Imagina un agente que investiga fallos de registro. Recibe logs reducidos y acceso a validación. Modificar permisos de clientes o borrar registros no pertenece a esa investigación. Si la corrección exige alguno de esos efectos, la tarea debe mostrar la operación concreta y el motivo antes de ejecutarla.
Asigna responsabilidad sobre el resultado
Cada automatización necesita una persona que revise cambios de configuración, siga los fallos y decida cuándo suspender el flujo. La responsabilidad no desaparece porque la herramienta prometa revisar su propia salida. El registro debe identificar quién recibe el problema y qué información necesita para investigarlo.
Conserva identificador de tarea, entorno, acciones relevantes, resultados y decisiones de aprobación. Evita guardar secretos en los logs. La finalidad es reconstruir lo ocurrido, no acumular todo el contenido al que puede acceder el agente. Los datos de observabilidad también necesitan propósito y acceso definidos, además de personas capaces de interpretarlos.
Ensaya los fallos antes de ampliar el uso
Prueba una herramienta indisponible, una respuesta ambigua, un límite alcanzado y un cambio rechazado en revisión. Observa si el agente se detiene correctamente, conserva el trabajo válido y explica lo pendiente. Una automatización que solo funciona por el camino ideal deja sin respuesta incidentes previsibles.
Repite los casos relevantes tras cambiar modelo o conector. La diferencia entre ingeniería de prompts y de agentes explica por qué las instrucciones son una capa. El checklist de adopción empresarial organiza el paso de ensayo a uso recurrente. Una gobernanza útil aparece en decisiones que personas y herramientas pueden ejecutar cada día, con responsabilidades claras también cuando algo falla.
Sobre el autor
Tiago F SantiagoComentarios
Todavía no hay comentarios
Comparte una pregunta o una experiencia relacionada con el artículo.
Artículos relacionados
