Gobernanza de agentes de IA: el marco de control que tu empresa necesita antes del primer incidente

Los agentes de IA ya no solo redactan texto: crean archivos, ejecutan comandos, llaman APIs y borran recursos. Esta guía define un marco de gobernanza operativo —seis controles aplicables con cualquier stack— para que puedas darles acceso a sistemas reales sin perder el control ni la evidencia.

Qué es la gobernanza de agentes de IA (y qué no es)

La gobernanza de agentes de IA es el conjunto de controles técnicos y operativos que determinan qué puede hacer un agente, con qué identidad, bajo qué políticas, con qué supervisión humana y con qué evidencia. Es una disciplina de ingeniería, no de discurso: si el control no puede impedir una acción concreta o probar que ocurrió, no es un control.

Conviene despejar tres confusiones frecuentes:

• No es ética de IA. Los principios de IA responsable son valiosos, pero operan a nivel de intención. La gobernanza de agentes opera a nivel de ejecución: decide si esta llamada a esta API con estos parámetros procede o no.
• No es un comité. Un comité puede definir el apetito de riesgo, pero no revisar cada acción de un agente que ejecuta cientos de operaciones por hora. El comité gobierna las reglas; la decisión por acción tiene que estar automatizada y auditada.
• No es una política en PDF. Un documento que dice "los agentes no deben acceder a datos de producción" no detiene a un agente que tiene las credenciales para hacerlo.

Definida así, la gobernanza responde cuatro preguntas para cada acción de cada agente: ¿quién la pide?, ¿está permitida?, ¿qué riesgo tiene?, ¿quedó registrada? Si hoy no podés responder las cuatro, tenés una brecha, no un matiz.

Por qué los agentes cambian el problema

Con un LLM conversacional, el peor caso es una mala respuesta: texto incorrecto que un humano lee y descarta. El humano sigue siendo el actuador; el modelo solo propone.

Un agente rompe ese supuesto: es un modelo con herramientas que crea y modifica archivos, ejecuta comandos en servidores, llama APIs internas y externas, dispara deploys, envía correos o borra recursos en la nube. La combinación de autonomía más acceso a sistemas genera una superficie de riesgo que no existía:

• Prompt injection con consecuencias físicas en tus sistemas. Si el agente procesa contenido externo —un mail, un ticket, una página web— ese contenido puede incluir instrucciones. En un chat, eso produce una respuesta rara; en un agente, un rm -rf, una exfiltración o una transferencia que nadie pidió.
• Credenciales compartidas y sin atribución. El antipatrón más común: el agente corre con la service account del equipo o con el token personal de un desarrollador, con permisos amplios heredados. Cuando algo sale mal, el log dice que "alguien" lo hizo, y no podés distinguir al agente del humano.
• No determinismo. El mismo prompt puede producir acciones distintas en dos corridas. No podés certificarlo por testing exhaustivo como al código tradicional; solo podés acotar lo que sus acciones tocan.
• Velocidad y encadenamiento. Un agente ejecuta en segundos una secuencia que a un humano le tomaría una tarde. Un error de criterio no produce un incidente: produce veinte, encadenados, antes de que alguien mire un dashboard.

La conclusión práctica: no podés gobernar al modelo, pero sí sus acciones. Ese es el objeto del marco que sigue.

Los 6 controles de un marco de gobernanza de agentes

Estos seis controles son agnósticos: podés implementarlos con cualquier stack —IAM de tu nube, un policy engine como OPA, colas de aprobación, un log inmutable— o con una plataforma dedicada. Lo que no es opcional es la función que cumple cada uno.

1. Identidad propia por agente

Cada agente necesita una identidad distinta de la de cualquier humano y de cualquier otro agente, con credenciales propias, de corta vida y revocables. Sin identidad no hay atribución, y sin atribución la auditoría es teatro.

2. Política explícita

Qué acciones están permitidas, para qué agente, en qué contexto y con qué límites — escrito como reglas evaluables por una máquina antes de ejecutar, no como prosa. Policy-as-code: versionada, revisable, testeable. Y el default correcto es denegar: lo no contemplado se bloquea.

3. Permisos mínimos

El agente solo puede invocar las capacidades que su tarea requiere, con el alcance más chico posible. No "acceso a la base de datos" sino "SELECT sobre estas tablas"; no "acceso al repositorio" sino "abrir pull requests, nunca pushear a main". Los permisos amplios heredados de un rol humano son el error de diseño más caro en agentes.

4. Clasificación de riesgo por reversibilidad

No todas las acciones pesan igual, y la dimensión que mejor ordena es la reversibilidad: read-only (leer un log, consultar una API), reversible (crear un archivo, abrir un ticket, escalar un pod) e irreversible (borrar datos, enviar un correo a un cliente, ejecutar un pago). La clase de riesgo determina cuánta fricción aplica el resto del marco: lo read-only fluye, lo irreversible se frena.

5. Aprobación humana

Para las acciones irreversibles o fuera de política, un humano con contexto aprueba o rechaza antes de la ejecución, y esa decisión queda registrada. El diseño fino —a quién se enruta, con qué contexto, con qué timeout— lo tratamos en la sección 5.

6. Auditoría íntegra

Cada acción —permitida, denegada o aprobada— queda en un registro append-only con protección de integridad, atribuible a una identidad y con la decisión de cada control anterior. Es el control que convierte a los otros cinco en evidencia demostrable ante un auditor o durante un incidente.

Así lo implementa NexusOS

Este marco es exactamente lo que NexusOS ejecuta como plataforma: cada acción que un agente propone atraviesa un pipeline de gates —identidad → capability → contrato → política → permisos → riesgo → aprobación → punto de enforcement (PEP) → ejecución → auditoría— antes de tocar un sistema real. Las acciones se modelan como governed capabilities (102 en el core), el riesgo se clasifica por reversibilidad y el audit trail es append-only con cadena de hashes y HMAC-SHA256. El principio de diseño: la IA propone, NexusOS decide. Podés verlo evaluar acciones reales en la demo interactiva.

Gobernanza en runtime vs. gobernanza de papel

La mayoría de las organizaciones ya tiene "gobernanza de IA": una política de uso aceptable, un comité, quizás un registro de casos de uso. Todo eso es gobernanza de papel, y tiene una limitación estructural: un documento no puede interceptar una llamada. El PDF que prohíbe borrar datos de producción no está en el camino entre el agente y esa API.

La gobernanza de papel opera antes del despliegue (aprobación del caso de uso) y después del incidente (el post-mortem). En el medio —el runtime, donde el agente efectivamente actúa— no hay nada. Con humanos ese hueco lo cubren el criterio profesional y el miedo a las consecuencias; un agente no tiene ninguna de las dos cosas.

Gobernanza en runtime significa que los seis controles se evalúan en el camino de ejecución: un punto de enforcement (PEP) por el que pasa cada acción y que puede permitirla, frenarla o escalarla en el momento. La prueba ácida: si mañana un agente intenta una acción prohibida, ¿tu control la bloquea o solo la lamenta? Profundizamos en control de ejecución para agentes de IA.

Human-in-the-loop: cuándo un humano debe aprobar

El instinto inicial es pedir aprobación humana para todo. Es el peor diseño posible: genera approval fatigue. Si un operador recibe cuarenta pedidos por día y treinta y nueve son triviales, al tercer día aprueba sin leer — y el control queda formalmente presente y materialmente muerto.

El criterio correcto es enrutar por riesgo, apoyándose en la clasificación por reversibilidad:

• Read-only: ejecución automática. Registrar, no preguntar.
• Reversible: automática dentro de política, con límites de tasa y monitoreo.
• Irreversible o fuera de política: aprobación humana previa, siempre.

Para que la aprobación sea real y no ceremonial, el aprobador necesita contexto accionable (qué acción, sobre qué recurso, con qué parámetros, por qué el agente la propone), tiene que ser alguien con criterio sobre ese dominio —no un buzón genérico—, y el pedido debe expirar: si nadie aprueba en el plazo definido, la acción se deniega.

Bien calibrado, el human-in-the-loop es un dial, no un interruptor: un agente nuevo arranca con supervisión densa y la va perdiendo a medida que acumula historial limpio. El diseño detallado está en human-in-the-loop para agentes de IA.

Evidencia y auditoría: qué registrar para ISO 42001 y el EU AI Act

Cuando un auditor —o tu propio equipo durante un incidente— pregunte qué hizo un agente, la respuesta tiene que salir de un registro, no de una reconstrucción. El registro mínimo útil, por cada acción:

• Quién: identidad del agente y principal humano responsable de esa sesión o tarea.
• Qué: capacidad invocada y parámetros concretos (qué archivo, qué endpoint, qué monto).
• Cuándo: timestamp confiable.
• La decisión: qué evaluó cada control —política aplicada, clase de riesgo, quién aprobó o por qué se denegó—.
• El resultado: qué devolvió el sistema, incluidos los errores.

Tan importante como el contenido es la integridad: un log que el propio agente —o un atacante con sus credenciales— puede editar no prueba nada. El estándar razonable es un registro append-only con verificación de integridad: cada entrada encadenada a la anterior por hash (al estilo prevHash) y firmada, por ejemplo con HMAC-SHA256, para que cualquier alteración u omisión sea detectable.

Esta evidencia es la materia prima de los tres marcos que hoy importan. ISO/IEC 42001:2023 define un sistema de gestión de IA (AIMS) certificable: hay que demostrar control operativo sobre el ciclo de vida de los sistemas de IA, y sin registros de ejecución esa demostración no existe. El EU AI Act (Reglamento 2024/1689) exige para sistemas de alto riesgo registro automático de eventos (art. 12) y supervisión humana efectiva (art. 14) — un pipeline con gates de aprobación y audit trail responde a ambos por diseño. El NIST AI RMF, voluntario, organiza el problema en Govern, Map, Measure y Manage; Measure y Manage presuponen telemetría real de lo que los sistemas hacen. Ninguna herramienta te "certifica" por sí sola —la certificación evalúa a tu organización—, pero sin esta evidencia el proceso ni empieza. El detalle de qué pedir y cómo prepararlo está en auditoría técnica de agentes de IA.

Cómo empezar: checklist de 8 puntos

No necesitás el marco completo el primer día. Esta secuencia hace que cada paso reduzca riesgo real aunque nunca hagas el siguiente:

1. Inventariá tus agentes. Todos: los oficiales, los pilotos y el script con un LLM que alguien dejó corriendo en un cron. Si no está en la lista, no está gobernado.
2. Auditá sus credenciales. ¿Con qué identidad corre cada uno? ¿A qué llega hoy? Cualquier agente con token personal de un humano o service account compartida es tu primera prioridad.
3. Asignale identidad propia a cada agente, con credenciales de corta vida y revocación inmediata.
4. Listá las acciones posibles de cada agente como capacidades concretas: no "usa AWS" sino qué operaciones, sobre qué recursos.
5. Clasificá cada capacidad por reversibilidad: read-only, reversible, irreversible. Una planilla alcanza para arrancar.
6. Definí política deny-by-default y habilitá explícitamente solo lo que cada tarea requiere.
7. Poné aprobación humana obligatoria a lo irreversible, con contexto para el aprobador y denegación por timeout.
8. Activá registro append-only con integridad verificable y ensayá una pregunta de auditoría real: "¿qué hizo el agente X el martes?". Si la respuesta tarda más de cinco minutos, ajustá.

Los puntos 1 a 5 se resuelven con disciplina y herramientas que ya tenés. Los puntos 6 a 8 son donde una plataforma de ejecución gobernada como NexusOS ahorra meses de ingeniería propia. Y si preferís arrancar con una mirada externa, nuestros servicios incluyen un diagnóstico express que en 72 horas te dice dónde están las brechas y en qué orden cerrarlas.

Preguntas frecuentes

¿La gobernanza de IA frena la adopción de agentes?

Al revés: la habilita. Sin controles, cada despliegue de un agente con acceso a producción es una decisión de riesgo que alguien tiene que frenar a mano. Con identidad, permisos acotados, clasificación de riesgo y auditoría, podés autorizar agentes en sistemas reales porque sabés exactamente qué pueden hacer y tenés evidencia de qué hicieron. La gobernanza convierte "no, es muy riesgoso" en "sí, bajo estas condiciones". Lo que sí frena la adopción es el primer incidente sin trazabilidad.

¿Qué diferencia hay entre guardrails y gobernanza?

Los guardrails operan sobre el contenido: filtran prompts y salidas del modelo (toxicidad, PII, jailbreaks). Útiles, pero actúan sobre texto, no sobre acciones. La gobernanza opera sobre la ejecución: decide si una acción concreta —borrar un recurso, llamar una API, ejecutar un comando— está permitida para esa identidad, bajo esa política, con ese nivel de riesgo, y deja evidencia auditable. Un guardrail puede dejar pasar una instrucción inyectada que suena inocente; un control de ejecución bloquea la acción resultante aunque el texto haya parecido legítimo. Se complementan, no se reemplazan.

¿Sirve un framework de prompts como control de gobernanza?

Como control primario, no. Un system prompt es una instrucción, no un límite técnico: el modelo puede ignorarla por error, ambigüedad o prompt injection. Ningún auditor acepta "le pedimos al modelo que no lo haga" como evidencia de control. Los prompts sirven para orientar el comportamiento y reducir la frecuencia de acciones indeseadas. Pero el control que cuenta es el que actúa fuera del modelo: permisos que la acción no puede exceder, políticas evaluadas antes de ejecutar y registro de lo que efectivamente pasó.

¿Qué pide el EU AI Act para agentes de IA?

El Reglamento (UE) 2024/1689 no regula "agentes" como categoría propia: las obligaciones dependen del caso de uso y su nivel de riesgo. Si un sistema con agentes cae en alto riesgo (decisiones de empleo, crédito, infraestructura crítica), aplican requisitos de gestión de riesgos, registro automático de eventos (art. 12), supervisión humana efectiva (art. 14), documentación técnica, y exactitud, robustez y ciberseguridad (art. 15). Aun fuera del alto riesgo, esos requisitos son la referencia razonable para agentes con acceso a sistemas: trazabilidad, supervisión y control demostrables.

¿Por dónde empiezo si ya tengo agentes en producción?

Por el inventario y las credenciales: qué agentes existen, con qué identidad corren y a qué llegan hoy. Es el paso más barato y el que más sorpresas revela; casi siempre aparece un agente con credenciales compartidas o permisos heredados de un humano. Después clasificá las acciones por reversibilidad y ponele aprobación humana a lo irreversible: con eso ya bajaste el riesgo de la peor pérdida. Si querés una evaluación externa de ese punto de partida, un diagnóstico corto ordena las prioridades.