La mayoría de los equipos tratan la gobernanza de la IA como algo que se observa: un panel, una puntuación de calidad, una auditoría al cierre del trimestre. La observación importa, pero ocurre después de que la acción ya se ejecutó. Para entonces el dinero se ha movido y el registro ya está escrito. La gobernanza real tiene que ocurrir antes — en la ruta de ejecución, como una puerta que la acción debe superar para continuar.
En Cortex, toda acción de un agente recorre la misma canalización de ocho puertas fail-closed. Fail-closed significa que denegar es lo predeterminado: si una puerta no puede aprobar afirmativamente una acción, la acción se detiene. Nada llega al modelo ni a la herramienta hasta que toda la secuencia queda superada. Esta es la canalización, en orden.
La canalización
- 1 — Identidad. ¿Es esta una identidad de agente gobernada, activa y no caducada? Una identidad caducada o suspendida se rechaza con 403 IDENTITY_EXPIRED antes de que se ejecute nada más.
- 2 — Presupuesto. ¿Queda gasto disponible bajo los límites del tenant y por agente? Un límite superado devuelve 402 — la ejecución nunca arranca.
- 3 — Guardrails. Cribado de DLP y de seguridad sobre el prompt y las entradas antes de que el modelo o cualquier herramienta los vea. Una entrada bloqueada nunca llega al modelo.
- 4 — Registro. ¿Está la habilidad, la herramienta o el modelo registrado, permitido y — para publicar — por encima del umbral de fiabilidad? Una publicación por debajo del umbral se rechaza con 409 RELIABILITY_TOO_LOW.
- 5 — Control Tower. ¿Está el agente o la herramienta en pausa, contenido o bajo un kill switch? Un sujeto en pausa se detiene aquí.
- 6 — Ejecutar. La llamada gobernada al modelo y a las herramientas se ejecuta de verdad — la única puerta cuyo camino feliz es un 200.
- 7 — Guardia de salida. Cribado de DLP y de seguridad sobre el artefacto generado antes de entregarlo a una persona o a un sistema posterior.
- 8 — Auditoría. El resultado se sella en el Trust Ledger con detección de manipulación mediante un recibo firmado — de modo que la ejecución es demostrable, no solo afirmada.
Cada casilla de la canalización es una puerta de gobernanza que se puede ver y controlar. Si alguna puerta deniega, la ejecución nunca llega al modelo ni a la herramienta. Denegar es lo predeterminado.
La política y la supervisión se superponen
Las ocho puertas son el suelo estructural. Sobre ellas se apoyan dos capas configurables que solo pueden hacer una decisión más estricta, nunca más laxa. Policy-as-Code evalúa sus reglas por orden de prioridad y resuelve al efecto más restrictivo — deny gana a require_approval, que gana a allow. Una acción de alto valor activa una regla require_approval y queda pendiente en lugar de ejecutarse:
Los Oversight Modes deciden cuánta autonomía tiene un agente — desde suggest_only, donde toda acción queda pendiente, pasando por execute_low_risk, hasta autonomous, donde solo queda pendiente el piso de riesgo propio de la acción. Y algo crucial: la supervisión es una capa que endurece; el piso de riesgo alto de la acción siempre se respeta y la supervisión solo puede añadir fricción, nunca quitarla.
Por qué una denegación es una función, no un fallo
Un código de estado real en una acción denegada es lo más útil que produce un runtime gobernado. Un 402, un 403, un 409 o un 451 es un veredicto honesto y legible por máquina: esta acción se detuvo, este es exactamente el motivo y este es el registro que lo demuestra. Lo que mete en problemas a las empresas son las aprobaciones silenciosas — la acción que se ejecutó cuando no debía, sin nada que lo respalde.
Cuando toda ejecución supera las mismas ocho puertas y todo veredicto acaba en el ledger, la gobernanza deja de ser una auditoría trimestral y pasa a ser una propiedad del sistema. No se espera que un agente se haya comportado. Se puede demostrar, puerta por puerta, que no tenía otra opción.