El stack de 10 capas ya era el más profundo de la categoría
Cuando lanzamos nuestro stack de gobernanza el mes pasado, ya era el más completo en la categoría de automatización de IA. Diez capas cubriendo identidad, protección de datos, supervisión humana, cumplimiento y observabilidad. Ningún competidor tenía algo comparable.
Pero un stack de 10 capas tiene una brecha. Puede controlar quién ejecuta un flujo de trabajo. Puede controlar qué datos accede el flujo de trabajo. Puede requerir aprobación humana antes de que se ejecute el flujo de trabajo. Lo que no podía controlar era qué herramientas específicas invoca un agente durante la ejecución.
La brecha: gobernanza a nivel de herramientas
Considere un flujo de trabajo que usa servidores MCP para Slack, Gmail y Salesforce. El flujo de trabajo está aprobado para ejecutarse. El agente tiene los permisos correctos. Pero, ¿debería ese agente poder enviar un correo electrónico vía Gmail sin aprobación explícita? ¿Debería actualizar un registro de Salesforce de forma autónoma?
n8n reconoció esta brecha y añadió humano en el circuito a nivel de llamada de herramienta individual. Su implementación permite a usuarios individuales aprobar llamadas de herramientas durante la ejecución. Pero está controlado por el usuario, no por el administrador. No hay una capa de política organizacional.
Nosotros tomamos un enfoque diferente.
Puertas de aprobación de herramientas: la capa 10
Las puertas de aprobación de herramientas otorgan a los administradores control granular sobre qué herramientas requieren aprobación humana antes de la ejecución. Esto no es una pausa a nivel de flujo de trabajo. Es una puerta a nivel de herramienta.
Así es como funciona:
- El administrador configura las herramientas que requieren aprobación en la configuración de ACL de MCP. Cualquier herramienta en el catálogo de servidores MCP de la cuenta puede ser marcada.
- Durante la ejecución del flujo de trabajo, cuando el agente intenta invocar una herramienta marcada, la ejecución se pausa.
- Se crea una solicitud de aprobación mostrando el nombre de la herramienta, los parámetros de entrada que el agente quiere enviar y el contexto de identidad del agente.
- Un aprobador revisa y decide — aprobar para continuar, denegar para omitir, o dejar que el tiempo de espera auto-deniegue.
- La ejecución se reanuda con la decisión registrada en la pista de auditoría.
La diferencia clave respecto al enfoque de n8n: las políticas de aprobación son establecidas por administradores, no por usuarios individuales. El aprobador puede configurarse como el patrocinador del agente, cualquier usuario con un rol mínimo, o usuarios específicos nombrados. La configuración de tiempo de espera y notificaciones es política organizacional, no preferencia por usuario.
El stack completo de 10 capas
Esto es lo que hace cada capa:
| # | Capa | Qué gobierna |
|---|---|---|
| 1 | Control de acceso basado en roles | Quién puede hacer qué (6 roles, 24 permisos, alcance departamental) |
| 2 | Identidad del agente | Permisos por agente, límites de velocidad y propagación de contexto de auditoría |
| 3 | Registro de auditoría | Más de 280 tipos de acciones con evidencia inmutable y exportable |
| 4 | Detección de PII + tokenización | Detección automática y tokenización reversible de datos sensibles |
| 5 | Autonomía graduada | 4 niveles de confianza (manual a completamente automático) con escalamiento impulsado por políticas |
| 6 | Puertas de aprobación de herramientas | Aprobación controlada por administrador por herramienta antes de la ejecución |
| 7 | Controles de residencia de datos | Presets de cumplimiento para HIPAA, GDPR, PCI-DSS, SOX, FedRAMP |
| 8 | Cifrado de clave envolvente | AES-256-GCM con derivación de clave HKDF-SHA256 para BYOK |
| 9 | Panel de cumplimiento + SOC 2 | 21 políticas, 17 controles TSC, exportación de evidencia, integración con Vanta |
| 10 | Motor de cumplimiento EU AI Act | Mapeo de 10 artículos (Art. 9-17, 52), clasificación de riesgo, generación de evidencia |
| 10 | Evaluación de preparación de gobernanza | Puntuación de autoservicio en todas las capas de gobernanza con recomendaciones |
Cada capa opera de forma independiente pero se integra con las demás. La identidad del agente (capa 2) se propaga a través de las puertas de aprobación de herramientas (capa 6) para que los aprobadores vean exactamente qué agente está solicitando acceso a herramientas. El registro de auditoría (capa 3) registra cada decisión de aprobación. El panel de cumplimiento (capa 9) rastrea el cumplimiento de aprobación de herramientas en toda la organización.
Por qué la profundidad importa más que la amplitud
Microsoft, OpenAI y Anthropic están invirtiendo en gobernanza. El Agent Framework de Microsoft añade asignación básica de roles. OpenAI Frontier tiene identidad por agente. Anthropic ofrece controles de administración empresarial.
Estos son primeros pasos importantes. Pero la profundidad de gobernanza se mide en capas, no en funcionalidades. Una plataforma con control de acceso basado en roles pero sin detección de PII tiene una brecha de gobernanza. Una plataforma con registro de auditoría pero sin controles a nivel de herramientas tiene una brecha de gobernanza. Una plataforma con presets de cumplimiento pero sin mapeo de EU AI Act tiene una brecha de gobernanza.
10 capas significa que 10 puntos potenciales de fallo están cubiertos. No porque elegimos 10 como número, sino porque las implementaciones empresariales de IA tienen al menos 10 requisitos de gobernanza distintos.
Qué sigue
La carrera armamentista de gobernanza se está acelerando. Cada plataforma importante está lanzando funcionalidades de gobernanza. La pregunta ya no es si gobernar los agentes de IA, sino con qué profundidad.
Seguiremos añadiendo capas a medida que surjan nuevos requisitos de gobernanza. El stack está diseñado para crecer.
Explore el stack de gobernanza | Pruebe la evaluación de preparación de gobernanza