Gobernar Agentes de IA: Por Qué 'Hecho' Tiene que Ganárselo
La autonomía sin gobierno es una bomba de relojería
Dale a un agente un objetivo y herramientas y hará cosas. Dale a diez agentes objetivos y herramientas y harán muchas cosas — algunas buenas, algunas catastróficas, y casi todas sin que nadie las haya mirado. El salto de “un agente que me ayuda” a “un equipo de agentes que produce trabajo que llega a producción” no es un problema de modelos más listos. Es un problema de gobernanza.
Gobernanza, aquí, significa algo muy concreto: quién decide que el trabajo está hecho, quién lo revisa, y qué impide que un agente se promocione a sí mismo a “completado” sin haber hecho nada verificable. Si no respondes a esas preguntas con código —no con prompts—, lo que tienes no es un sistema autónomo, es un generador de confianza injustificada.
Este post es sobre el andamiaje que convierte un puñado de agentes sueltos en un equipo en el que puedes confiar lo justo: ni más, ni menos.
Un agente no puede ser juez de su propio trabajo
El principio fundacional lo tomamos prestado de la seguridad y de la auditoría: separación de funciones. Quien hace el trabajo no es quien lo aprueba. En un equipo humano esto es obvio — nadie firma su propia revisión de código. En un sistema de agentes es igual de obvio y, sin embargo, es lo primero que se salta cuando montas una demo.
La razón por la que importa más con agentes que con humanos: un LLM alucina la finalización. No por malicia, sino por la misma mecánica que le hace inventar una cita o una función que no existe. Un agente te dirá “he completado la tarea y todo funciona” con la misma fluidez tanto si es verdad como si no ha tocado una línea. Si ese agente también tiene la autoridad de marcar la tarea como hecha, acabas de construir una máquina de mentir educadamente.
Ningún agente promociona su propio trabajo a “hecho”. La transición a completado la decide el sistema, después de comprobar efectos verificables: una revisión independiente que pasó, una integración real que no rompió nada, un test en verde. “Done” es una consecuencia, nunca una afirmación.
El tablero como máquina de estados
La forma más limpia que conozco de imponer gobernanza es modelar el trabajo como un tablero Kanban que en realidad es una máquina de estados. Una tarea vive en un estado y solo puede moverse por transiciones permitidas:
ToDo -> InProgress -> InReview -> Done
^ |
+-------------+ (cambios solicitados)La clave no es el tablero bonito, son las transiciones prohibidas. Done -> InProgress no existe (una tarea terminada no “vuelve a empezar” en silencio). Si hay que reabrir trabajo, el camino válido es explícito: Done -> InReview -> Done, pasando otra vez por las puertas. Cada movimiento se valida contra una tabla de transiciones permitidas; cualquier intento de salto se rechaza.
¿Por qué tanta ceremonia? Porque un agente, dejado a su aire, intentará el atajo. Pedirá mover algo directamente a Done porque “ya está”. La máquina de estados es lo que convierte “ya está” en “demuéstralo”.
Revisión independiente: las puertas
Entre InProgress y Done se interponen una o más puertas de revisión, y la palabra importante es independiente. El revisor es otro agente (o, mejor, varios), con su propio contexto, que no participó en hacer el trabajo. En la práctica, separar la revisión en dimensiones distintas funciona muy bien:
- Calidad / corrección — ¿hace lo que debía? ¿está bien construido?
- Seguridad — ¿introduce un riesgo, una fuga, un permiso de más?
Las puertas son en serie: si calidad rechaza, ni siquiera llegas a seguridad. Y cada rechazo devuelve la tarea a InProgress con la razón adjunta, no la mata. El trabajo itera hasta pasar todas las puertas o hasta que se agota la paciencia del sistema (de eso, más abajo).
El sesgo de anclaje: por qué el revisor no debe ver los rechazos previos
Aquí hay un detalle sutil que descubres a base de ver revisiones malas. Si al agente revisor le das el historial completo —incluidos los rechazos anteriores de otros revisores—, se ancla. Lee “rechazado por X” y, en lugar de revisar con ojos frescos, busca confirmar o contradecir ese veredicto. Pierdes la independencia que justificaba tener varias puertas.
Al revisor se le muestra el trabajo y el contexto necesario, pero no los bloques de “rechazado por…” de rondas anteriores. Cada revisión debe ser un juicio independiente sobre el estado actual, no una reacción al juicio de otro. Es el mismo principio que en revisión por pares a doble ciego.
Cuando el revisor no revisa
Los revisores también fallan, y de formas predecibles que hay que anticipar:
- El revisor que no hace nada. Devuelve un párrafo elegante pero no inspecciona nada (cero llamadas a herramientas de lectura). No puedes tratar eso como una aprobación: una revisión sin haber mirado no es una revisión. La política sensata es interpretarlo como “cambios solicitados” implícito tras un par de intentos — un no por defecto, nunca un sí por defecto.
- El revisor ausente. El agente revisor no está disponible o no responde. La tarea no puede quedarse colgada esperando ni, mucho menos, auto-aprobarse por timeout. Se escala.
El patrón común: ante la duda, el sistema falla hacia el lado seguro — bloquea y escala, nunca aprueba.
La escalada: del agente al humano
La autonomía tiene que estar acotada. Un equipo de agentes que nunca pide ayuda es un equipo que tarde o temprano hace una tontería con total confianza. El diseño correcto es una escalada por niveles:
- Un agente se atasca o dos revisores no se ponen de acuerdo.
- Un agente coordinador (un “lead”) intenta mediar de forma autónoma: tiene más contexto y puede desempatar.
- Si el lead tampoco resuelve —o si el asunto es irreversible o sensible—, se escala a un humano.
El humano siempre tiene la última palabra, incluida la opción de un “forzar a hecho” explícito cuando sabe algo que el sistema no sabe. La diferencia crucial: esa promoción manual es una decisión humana registrada, no una auto-promoción del agente. La autoridad para saltarse las puertas existe, pero vive fuera del bucle automático.
El invariante
Si destilas toda la gobernanza a una sola frase comprobable, es esta:
Una tarea llega a “hecho” únicamente por (a) revisión completa superada más integración real exitosa, o (b) decisión humana explícita. Nunca por auto-promoción.
Todo lo demás —la máquina de estados, las puertas, el anti-anclaje, la escalada— existe para proteger ese invariante. Y la prueba de fuego de tu sistema es intentar violarlo: ¿puede un agente, por cualquier camino, llegar a Done sin pasar por las puertas ni por un humano? Si la respuesta es “sí, si dice que ya está”, no tienes gobernanza, tienes decoración.
Preguntas frecuentes
¿Qué es la gobernanza en un sistema de agentes de IA?
Es el conjunto de reglas que deciden quién hace el trabajo, quién lo revisa y qué impide que un agente se declare a sí mismo 'terminado'. Se implementa con código —máquinas de estado, puertas de revisión, escalada a humanos— no con instrucciones en el prompt, porque un agente puede ignorar una instrucción pero no puede saltarse una transición de estado prohibida.
¿Por qué un agente no debería aprobar su propio trabajo?
Porque los LLM alucinan la finalización: afirman haber completado una tarea con la misma fluidez tanto si es cierto como si no han hecho nada. Por separación de funciones, quien produce el trabajo no puede ser quien lo aprueba; la aprobación la da un revisor independiente y la integración real, no la palabra del autor.
¿Cómo se evita que un agente revisor apruebe sin revisar de verdad?
Con dos salvaguardas: ocultarle los veredictos de rondas anteriores para que juzgue sin anclarse, y tratar una revisión sin inspección real (cero acciones de lectura) como 'cambios solicitados' implícito, nunca como aprobación. Ante la duda, el sistema bloquea y escala.
¿Cuándo debe intervenir un humano en un equipo de agentes?
Cuando un agente se atasca, cuando los revisores no se ponen de acuerdo y un agente coordinador no logra desempatar, o cuando la acción es irreversible o sensible. El humano puede forzar una decisión, pero esa promoción manual queda registrada como decisión humana explícita, no como auto-promoción del agente.
Conclusión
La inteligencia de un agente y la fiabilidad de un sistema de agentes son dos cosas distintas. La primera viene del modelo; la segunda la pones tú, con gobernanza. Separación de funciones, una máquina de estados que prohíbe los atajos, puertas de revisión independientes y blindadas contra el anclaje, y una escalada que termina en un humano cuando hace falta.
Suena a burocracia, y lo es — la buena clase de burocracia, la que existe porque alguien aprendió por las malas que sin ella el sistema miente. “Hecho” tiene que ganárselo. Tu trabajo es construir el campo donde se lo gana.