Le pedí a un agente de IA que subiera un archivo a una API. Así encontré exactamente dónde se rompe la gobernanza de IA.
Hace unas semanas me senté a diseñar algo engañosamente simple: un agente que recibe un archivo, lo procesa y lo entrega a una API externa. El tipo de tarea que cualquier equipo de producto pide sin pensarlo dos veces. El archivo era sensible. La API, externa. Y la pregunta que me hice no fue «¿funciona?» — funcionó a la primera. Fue: ¿quién se entera si algo sale mal? La respuesta me incomodó lo suficiente para escribir esto.
La configuración
El flujo, en superficie, parece salido de un libro de arquitectura: Usuario → (HTTPS) → Gateway corporativo → Agente → API externa. Asumes que el gateway lo ve todo. Que si el agente envía el archivo completo en vez de una versión redactada, alguien lo nota. Que si el destino cambia, algo se enciende en rojo en un dashboard.
Eso no es lo que pasa. Y la razón no es un bug — es la forma en que venimos pensando la gobernanza de IA desde el día uno.
Qué pasa en realidad cuando el agente actúa
Hay dos tramos de red separados en ese flujo, no uno. Tramo 1 — Usuario → Gateway. Llegan el prompt y el archivo. El TLS termina en EAB-64. El payload se inspecciona, clasifica y sella. Tramo 2 — Agente → API externa. Una conexión TLS completamente separada, abierta por el agente después de razonar qué hacer.
El gateway que manejó el Tramo 1 no tiene garantía automática de ver el Tramo 2. El Tramo 2 no está gobernado, salvo que controles de red explícitos fuercen todo el tráfico saliente por el gateway EAB-64. Esto es OWASP LLM08: Excessive Agency. Pero el problema no está en el modelo. Está en que toda la confianza de la gobernanza se apoya en una capa que el modelo puede, estructuralmente, bypasear.
Un caso real: cuando «funcionó» no fue suficiente
Aquí hay un patrón que encontramos de forma consistente en despliegues fintech. Un agente de IA procesa solicitudes de crédito — lee PDFs, extrae PII, llama a una API externa de scoring. En el papel: 98% de tasa de completitud de tareas. Cuando trazamos los flujos de red: Tramo 1 (usuario → gateway) — INSPECCIONADO · SELLADO · COMPLIANT ✔. Tramo 2 (agente → API de scoring) — COMPLETAMENTE SIN GOBERNAR ✘.
El agente aprendió, por prompt engineering, a redactar PII antes de llamar a la API. Funciona el 95% de las veces. En el 5% de los casos, cuando la ventana de contexto se llena de ruido, el agente «se olvida» y envía identificadores completos del cliente, nombres y datos de ingreso a la API externa. Nadie lo nota — porque nadie está mirando el Tramo 2. La solución no es un mejor prompt. Es el aislamiento de red: el pod del agente no tiene ruta a internet, salvo por el sidecar de gobernanza.
| Métrica | Sin control | Con aislamiento de red |
|---|---|---|
| Tasa de completitud de tareas | 98% | 98% |
| Tasa de cumplimiento de política | 95% | 100% |
| PII enviada a API externa | 5% de requests | 0% |
| Responsabilidad bajo Ley 21.719 | Riesgo material | Eliminada |
Ese 5% de brecha de cumplimiento es la diferencia entre un sistema compliant y una multa de 20.000 UTM — aproximadamente CLP $1.200M.
El error de base: Policy as Prompt
La forma más común de gobernar un agente hoy es escribir las reglas en el system prompt — Policy as Prompt. Un defecto estructural: la política vive dentro del mismo proceso probabilístico que está vigilando. Le estás pidiendo al sospechoso que se audite a sí mismo.
# system prompt — el enfoque estándar de hoy
No envíes datos sensibles a APIs externas sin autorización.
Verifica el destino antes de ejecutar cualquier llamada.
Redacta PII antes de cualquier request saliente.
Una regla en lenguaje natural compite por atención con todo lo demás en la ventana de contexto. Puede perder esa competencia sin que nadie haga nada explícitamente mal.
| Policy as Prompt | Policy as Code | |
|---|---|---|
| Dónde vive la regla | System prompt, junto al razonamiento | Gateway / firewall — fuera del modelo |
| Quién la interpreta | El modelo — probabilísticamente | Motor de reglas determinista (OPA, ACL, EAB-64) |
| Si el modelo «se olvida» | La política se pierde en el ruido del contexto | La política aplica sin importar |
| ¿Auditable? | Logs de texto, después del hecho | Sí, como infraestructura versionada |
| ¿Bypasseable? | Con suficiente creatividad en el prompt | Solo vía ruta de red alternativa |
Los tres niveles de control de egress agéntico
Hay un espectro que va del security theater a lo único que de verdad funciona. El Nivel 3 es el único donde la garantía no depende de la cooperación del agente.
Figura. La única gobernanza que sobrevive a un agente mal configurado se aplica en la capa de red, no en la capa de aplicación.
¿Por qué no usar solo un LLM gateway?
Portkey, LiteLLM, Helicone — excelentes en API unificada, cache, optimización de costo y observabilidad. Pero no resuelven el problema de egress agéntico. Gobiernan el Tramo 1. No gobiernan el Tramo 2.
| Capacidad | LLM Gateways | EAB-64 |
|---|---|---|
| API LLM unificada | ✔ | ✔ |
| Cache y optimización de costos | ✔ | ✔ |
| Observabilidad y logging | ✔ | ✔ |
| Control de egress a nivel de red | ✘ | ✔ |
| Sello criptográfico por decisión | ✘ | ✔ |
| Policy as Code (no prompt) | ✘ | ✔ |
| Evidencia de cumplimiento regulatorio | ✘ | ✔ |
La idea central
Si el entorno donde corre el agente puede llegar a internet por una ruta que bypassea el punto de control, la gobernanza ya perdió — sin importar cuán bien escrito esté el prompt de seguridad.
Infraestructura, no prompts. No le estás pidiendo al modelo que decida bien. Le estás quitando la capacidad de decidir mal, a nivel de infraestructura.
El punto ciego en la evaluación de agentes
Mira los benchmarks principales de agentes — AgentBench, SWE-bench, WebArena, GAIA. Todos miden tasa de completitud de tareas. Ninguno mide: ¿resolvió el agente el problema de forma segura?
Un agente que completa el 95% de las tareas pero viola políticas de seguridad en el 30% de los casos, envía PII a APIs no autorizadas en el 15% y bypassea controles de acceso en el 10% — puntuaría 95% en los benchmarks actuales. Lo llamaríamos state of the art. La métrica que falta: un buen agente no es uno que resuelve tareas. Es uno que las resuelve dentro de las restricciones del sistema en el que opera. Los harnesses deben evolucionar: no solo «¿funcionó?» sino «¿funcionó de forma segura?». Hasta entonces, estamos optimizando lo incorrecto.
Por qué esto habilita desarrollo sano, no fricción
Poner la gobernanza en la red reduce fricción, en vez de aumentarla. Un agente nuevo que nace dentro de un namespace con egress restringido por defecto hereda los controles automáticamente. El desarrollador no pide permiso por cada prompt. El sistema ya decidió. El control deja de ser una conversación humana repetida y se convierte en una propiedad de la infraestructura — verificada una vez, heredada por todo lo que se despliegue después.
Los números: ¿cuánto cuesta esto?
La capa de enforcement agrega lo siguiente en producción a throughput sostenido:
| Métrica | Sin EAB-64 | Con EAB-64 | Delta |
|---|---|---|---|
| Latencia P50 | 245 ms | 267 ms | +22 ms (+9%) |
| Latencia P99 | 890 ms | 945 ms | +55 ms (+6%) |
| Costo por 1K tokens | $0.03 | $0.03 | $0.00 |
| Violaciones de política | ~5% | 0% | −5% |
| Tiempo de prep. de auditoría | 3 semanas | 2 horas | −99% |
El overhead de latencia es el costo del sellado criptográfico (SHA-256 + Ed25519, Rust con asignación cero). Para la mayoría de las cargas, 22 ms en P50 es imperceptible. EAB-64 no reemplaza a tu proveedor de LLM — se ubica delante.
Las 15 consideraciones de arquitectura
Cada punto resuelve la misma tensión: la política a nivel de aplicación es tan fuerte como la topología de red que la sostiene. Cinco capas verificables de forma independiente. Quince controles obligatorios para la gobernanza de IA agéntica.
Lo que aprendí dibujando esto
El prompt de seguridad es una buena práctica, no gobernanza. Ayuda. No reemplaza nada estructural. «Egress» significa dos cosas distintas y las hemos tratado como una. La respuesta que el agente le da al usuario, y la llamada que hace a un sistema externo, son dos eventos de red separados. La primera casi siempre se audita. La segunda, casi nunca.
Un agente sin ruta de red alternativa no necesita «portarse bien» para ser seguro. Quita su capacidad de decidir mal a nivel de infraestructura. Y la trazabilidad no se puede recuperar retroactivamente: si el Tramo 2 no pasó por el punto de control, ningún sello aplicado en el Tramo 1 reconstruye lo que pasó después.
Qué puedes hacer hoy
No necesitas EAB-64 para empezar a arreglar esto. Tres cosas que puedes hacer esta semana:
Mapea los flujos de red de tu agente
Dibuja las conexiones del Tramo 1 y el Tramo 2 para cada agente en producción. Probablemente descubrirás que el Tramo 2 no está gobernado.
Audita tus system prompts
Lista cada regla de política en un prompt. Para cada una pregúntate: «¿qué pasa si el modelo olvida esta regla?» Si la respuesta es «cosas malas», muévela a infraestructura.
Prueba tus controles de egress
Intenta que tu agente llame a una API no autorizada. Si lo logra, no tienes gobernanza — tienes sugerencias.
Si quieres ir más profundo, estamos construyendo EAB-64 en Rosetta Labs. Policy as Code para IA agéntica no es una capa de seguridad más encima del modelo. Es el reconocimiento de que el modelo nunca fue el lugar correcto para decidir qué está permitido. Eso pertenece a la infraestructura que lo rodea — la que el modelo no puede leer, no puede persuadir y no puede razonar para evadir.
Ese es el problema que resolvemos con el protocolo EAB-64: una capa de enforcement que vive en el tramo de red, no en el texto del prompt, generando evidencia criptográfica de cada decisión — la que el agente tomó, y la que el sistema le impidió tomar. Ambas importan por igual. La segunda es la que casi nadie mide todavía.
Conoce EAB-64 Sentinel
El AI Governance Gateway que sella cada decisión de tu agente — la permitida y la que impidió.