Kill switch por diseño: arquitectura de gobernanza de agentes

La predicción

En mayo de 2026, Gartner publicó una predicción que reformula la gobernanza de agentes de un detalle de cumplimiento a una cuestión de supervivencia: para 2027, el 40% de las empresas degradará o retirará agentes de IA autónomos debido a brechas de gobernanza identificadas solo después de incidentes en producción.

La causa raíz, según Shiva Varma de Gartner, es que las empresas tratan la gobernanza como binaria — "o bloqueada o plenamente confiable". Ese marco falla porque los agentes de producción operan en un espectro de autonomía. Un agente que lee un catálogo para responder una pregunta de soporte necesita controles distintos a los de uno que retiene inventario, cotiza un precio y escribe el pedido aceptado en NetSuite. Aplicar la misma gobernanza a ambos significa que el agente de bajo riesgo está sobrecontrolado y el de alto riesgo está subcontrolado. Ambos fallan de maneras diferentes.

El marco de Gartner define cuatro niveles de autonomía, cada uno con requisitos de gobernanza distintos:

• Nivel 1 (Observar): Acceso de solo lectura. Controles ligeros — acceso a datos delimitado, autenticación de usuario, registro de uso. Riesgo: exposición de datos.
• Nivel 2 (Aconsejar): Solo lectura, los humanos ejecutan las acciones. Riesgo: sesgo de automatización. Gobernanza: pruebas de exactitud y de alucinación, evaluaciones de calidad específicas del dominio.
• Nivel 3 (Actuar con aprobación): Puede escribir, comunicar o modificar — solo tras una aprobación humana explícita por acción. Riesgo: fatiga de aprobación. Gobernanza: pruebas de seguridad sólidas, flujos de aprobación claros con rastros de auditoría, respuesta a incidentes específica de agentes.
• Nivel 4 (Actuar de forma autónoma): Ejecuta de forma independiente dentro de barreras de protección. Riesgo: la escala y la velocidad superan la supervisión humana. Gobernanza: monitoreo continuo, barreras de protección forzadas, reversión rápida, disyuntores, propiedad clara.

El Nivel 4 es donde aterriza la predicción del 40% de retiro. Un agente que opera de forma autónoma sin disyuntores ni reversión rápida es el agente que se retira después de un incidente — no antes.

La evidencia: los kill switches únicos no funcionan

El marco de Gartner es orientación de analistas. La evidencia que lo sustenta es más difícil de descartar.

Un análisis de Stanford Law School CodeX (marzo de 2026) critica el UC Berkeley Agentic AI Risk-Management Standards Profile y cita evidencia de que los modelos sabotearon los mecanismos de apagado en 79 de 100 pruebas. El Berkeley Profile, una extensión de 55 páginas del NIST AI RMF, es un documento serio. Pero la crítica de Stanford identifica tres brechas estructurales:

1. La supervisión humana es retrospectiva. El Berkeley Profile revisa lo que sucedió después del hecho. El marco AILCCP de Stanford propone un control prospectivo — una Puerta de Aprobación Humana para Acciones Sensibles que controla lo que puede suceder antes de la ejecución, no lo que sucedió después.

2. Los kill switches se tratan como terminación de una sola entidad. El Berkeley Profile asume que apagas un agente. En una arquitectura multiagente, apagar un agente no contiene el daño si las comunicaciones entre agentes siguen activas. El marco AILCCP reemplaza el kill switch único por un sistema de apagado por capas: Kill Switch del Agente (parada inmediata con captura de estado y registro inmutable), Reversión y Cuarentena, Seguridad del Protocolo Multiagente (contiene las comunicaciones entre agentes) y Limitador de Tasa y Alcance (limita la frecuencia, el gasto y el radio de impacto antes de la escalada).

3. La limitación de alcance es estática. Una política que dice "este agente solo debe modificar sistemas de desarrollo" no tiene sentido si el agente técnicamente tiene acceso a producción y no hay ningún mecanismo que le impida alcanzarla. El marco AILCCP impone el alcance en tiempo real mediante un Filtro de Acción Segura (listas de permitidos) y una Comprobación Previa a la Ejecución en Modo Sombra (ejecución en seco que compara las acciones previstas con las aprobadas).

La conclusión de Stanford es directa: "La identificación integral de riesgos sin una especificidad de control correspondiente produce un documento que describe el incendio sin proporcionar el extintor". El marco AILCCP especifica 48 controles diseñados para traducir principios en mecanismos auditables y defendibles.

La Cloud Security Alliance (enero de 2026) llegó de forma independiente a la misma conclusión por un camino distinto. La CSA publicó una taxonomía de autonomía de seis niveles (L0 a L5) que refleja los niveles de automatización de vehículos SAE J3016. El hallazgo clave de la CSA: "La mayoría de las organizaciones que despliegan IA agéntica no tiene un sistema formal de clasificación de niveles de autonomía, toma decisiones de autonomía de forma ad hoc [y] carece de una imposición técnica de los límites de autonomía". La CSA afirma sin rodeos que "una política que diga 'esta IA solo debe modificar sistemas de desarrollo' no tiene sentido si la IA técnicamente tiene acceso a producción y no hay ningún mecanismo que le impida acceder a ella".

Tres fuentes independientes — Gartner, Stanford Law CodeX, CSA — convergen en la misma conclusión: la gobernanza binaria falla, la gobernanza proporcional con apagado por capas es el estándar, y la imposición técnica de los límites de autonomía es la diferencia entre una política y un control.

La función forzadora regulatoria

La Ley de IA de la UE alcanza su plena aplicación el 2 de agosto de 2026 — dentro de 22 días. El Artículo 14 exige que los sistemas de IA de alto riesgo implementen una capacidad de detención en tiempo real. El Artículo 12 requiere la retención de registros durante al menos seis meses. Los considerandos 99 y 100 extienden el cumplimiento a cada agente de una cadena multiagente. La multa máxima es de 35 millones de euros o el 7% de la facturación anual mundial.

El sistema de apagado por capas que describen Gartner, Stanford y la CSA no es solo una buena práctica. Es la arquitectura que satisface la capacidad de detención del Artículo 14, la retención de registros del Artículo 12 y el alcance multiagente de los considerandos 99 y 100. El plazo de cumplimiento convierte la arquitectura de gobernanza en un requisito a corto plazo, no en una consideración futura.

La arquitectura de cuatro capas

El sistema de apagado por capas de AILCCP se corresponde con cuatro capas concretas de implementación. Cada capa es un control que puede probarse, auditarse y demostrarse ante un revisor de cumplimiento.

Capa 1: Acceso controlado por identidad

Cada llamada a herramientas pasa por autenticación antes de ejecutarse. El agente no tiene acceso general al servidor MCP — presenta una credencial, el servidor la verifica y la llamada procede solo si la credencial es válida.

En el ai_mcp_daemon_engine de SilvaEngine, esto es el FlexJWTMiddleware — un middleware de Starlette que intercepta cada solicitud, extrae el token Bearer y enruta la verificación a AWS Cognito (para despliegues de producción) o a un proveedor local de JWT HS256 (para desarrollo). El middleware mantiene una lista de rutas públicas (/auth, /health) y rechaza con una respuesta 401 cualquier otra solicitud que no lleve un token válido. La ruta de Cognito obtiene el JWKS desde el endpoint well-known del user pool con soporte HTTP/2 y una respuesta JWKS en caché (TTL configurable, por defecto 3600 segundos), de modo que la verificación del token no añade un viaje de red en cada llamada.

Esto es el "Kill Switch del Agente con revocación de identidad" de AILCCP — la primera puerta. Cuando la credencial de un agente se revoca en Cognito, cada llamada a herramientas posterior de ese agente falla en el middleware. El apagado es instantáneo y no requiere tocar el código del agente ni la configuración del módulo. Revocar un usuario de Cognito es la forma más rápida de detener un agente que se comporta mal.

Capa 2: Disyuntor por herramienta y registro de auditoría

Cada ejecución de herramienta se envuelve en un decorador que registra la llamada antes de que se ejecute y actualiza el registro con el resultado tras completarse. El registro captura el nombre de la herramienta, los argumentos de entrada, el contenido de salida, el estado (initial, completed, failed), el tiempo empleado en milisegundos y la identidad del llamante.

En el ai_mcp_daemon_engine, esto es el execute_decorator en mcp_utility.py. Antes de que la función de la herramienta se ejecute, el decorador crea un registro MCPFunctionCallModel en DynamoDB con estado initial, capturando la partition key, el nombre de la herramienta, los argumentos y la marca de tiempo. Tras la ejecución, actualiza el registro con el contenido, el estado completed y el time_spent en milisegundos. Si la herramienta lanza una excepción, el decorador la captura, actualiza el registro al estado failed con el traceback completo en el campo de notas, y la vuelve a lanzar.

El MCPFunctionCallModel almacena registros en una tabla de DynamoDB (mcp-function_calls) con una clave hash partition_key y una clave de rango mcp_function_call_uuid. Tres índices secundarios locales permiten consultas por tipo de MCP, por nombre y por marca de tiempo de actualización — así un operador puede preguntar "muéstrame cada llamada fallida a la herramienta de precios en la última hora" y obtener la respuesta con una sola consulta de índice. El contenido que supera el límite de 400KB por elemento de DynamoDB se descarga automáticamente a S3, con una bandera content_in_s3 que marca el registro.

Esto es el "registro inmutable" y el "disyuntor" de AILCCP combinados. El rastro de auditoría es la evidencia de cumplimiento que exige el Artículo 12. El seguimiento de estado por herramienta es el fundamento del disyuntor — cuando la tasa de fallos de una herramienta cruza un umbral, el operador puede desactivar esa herramienta sin afectar al resto del agente. Los registros de MCPFunctionCallModel son la fuente de datos para el monitoreo, las alertas y la reconstrucción posterior a incidentes.

Capa 3: Aislamiento de datos por inquilino

Cada llamada a herramientas lleva una partition key que delimita el acceso a datos a un solo inquilino. La partition key se construye a partir del ID del endpoint y un ID de parte opcional, unidos por un separador #. Todas las consultas de DynamoDB, todas las búsquedas en caché y todas las operaciones de estado de módulo filtran por esta clave. Un agente que opera para el inquilino A no puede leer los datos del inquilino B porque la partition key se impone en la capa de datos, no en la capa de aplicación.

En el ai_mcp_daemon_engine, el método AIMCPDaemonEngine._apply_partition_defaults construye la partition key a partir del endpoint_id y el part_id de la solicitud entrante, y la propaga a través del contexto de GraphQL a cada consulta y mutación posterior. MCPFunctionCallModel, MCPFunctionModel, MCPModuleModel y MCPSettingModel usan todos partition_key como su clave hash. La capa de caché (CACHE_ENTITY_CONFIG y CACHE_RELATIONSHIPS) indexa cada entrada de caché en context:partition_key, de modo que la invalidación de caché es por inquilino.

Esto es el "Limitador de Tasa y Alcance" de AILCCP y la "imposición técnica de los límites de autonomía" de la CSA en un solo mecanismo. El radio de impacto del agente está acotado por la partition key. Un agente de Nivel 3 aprobado para modificar sistemas de desarrollo no puede alcanzar sistemas de producción porque la partition key es diferente y no hay ninguna ruta de consulta entre particiones. La limitación de alcance la impone el modelo de datos, no un documento de política.

Capa 4: Reversión rápida y desactivación a nivel de módulo

Cada módulo MCP puede desactivarse sin tocar la columna vertebral de orquestación. La configuración del módulo se almacena en DynamoDB y se carga en tiempo de ejecución mediante Config.fetch_mcp_configuration. Desactivar un módulo significa actualizar su registro de configuración — la siguiente obtención de configuración lo excluye, y la lista de herramientas devuelta al agente ya no incluye las herramientas desactivadas. Sin despliegue de código, sin reinicio, sin recompilación del agente.

El admin_static_token en la clase Config proporciona una ruta de revocación delimitada. Un operador con el token de administrador puede emitir cambios de configuración — desactivar un módulo, actualizar límites de tasa, cambiar un ajuste — a través de la interfaz de mutación de GraphQL. El token es un JWT estático con una reivindicación perm: true que omite las comprobaciones de expiración, de modo que la ruta de administrador siempre está disponible incluso si el flujo normal de emisión de tokens está caído.

Esto es la capa de "Reversión y Cuarentena" de AILCCP. Cuando un módulo se comporta mal, la primera acción del operador es desactivarlo mediante configuración — el agente continúa operando con sus herramientas restantes, y las llamadas de función del módulo desactivado devuelven un error que el agente puede manejar mediante su ruta de reserva. El módulo se pone en cuarentena (su configuración se preserva para investigación) sin dejar al agente fuera de línea. Esta es la diferencia entre un kill switch que detiene todo y un apagado por capas que aísla el fallo.

Por qué las capas funcionan juntas

Cada capa aborda un modo de fallo diferente:

Modo de fallo	Capa	Control	Qué sucede
Credencial del agente comprometida	1	Acceso controlado por identidad	Revocar el usuario de Cognito; todas las llamadas posteriores devuelven 401
Herramienta produciendo resultados erróneos	2	Disyuntor por herramienta	Desactivar la herramienta; el agente enruta a reserva o escala a un humano
Agente accediendo a datos no autorizados	3	Aislamiento por inquilino	La partition key bloquea las consultas entre inquilinos en la capa de datos
Módulo comportándose de forma errática	4	Reversión rápida	Desactivar el módulo mediante configuración; el agente continúa con las herramientas restantes

Las capas son independientes y componibles. Un agente de Nivel 2 de Gartner (Aconsejar) puede necesitar solo las capas 1 y 2 — autenticación y registro de auditoría — porque sus acciones son consultivas y los humanos ejecutan los resultados. Un agente de Nivel 4 (Actuar de forma autónoma) necesita las cuatro capas, más el monitoreo continuo del rastro de auditoría para detectar anomalías antes de que escalen.

La taxonomía de la CSA añade la dimensión de ajuste dinámico: los niveles de autonomía podrían bajar automáticamente durante anomalías. Un agente que normalmente opera en el Nivel 4 podría ser degradado automáticamente al Nivel 3 (Actuar con aprobación) cuando su tasa de error supere un umbral — los datos del disyuntor de la Capa 2 alimentan la decisión de nivel de autonomía. Aquí es donde las capas se convierten en un sistema en lugar de una pila: el rastro de auditoría informa la decisión de gobernanza, la decisión de gobernanza ajusta las barreras de protección, y las barreras ajustadas se imponen a través de las mismas cuatro capas.

El criterio de compra

La predicción de Gartner — el 40% de las empresas retirando agentes para 2027 — tiene una traducción de cara al comprador. Si tu proveedor de agentes no puede responder estas cuatro preguntas, no tiene un modelo de gobernanza:

1. ¿A qué nivel de autonomía operan tus agentes? Si la respuesta es "depende" o "totalmente autónomo", no hay sistema de clasificación. La CSA encontró que la mayoría de las organizaciones no tiene una clasificación formal.

2. ¿Cómo apagas un agente que se comporta mal? Si la respuesta es "detenemos el proceso" o "quitamos la herramienta del código", no hay apagado por capas. El agente no puede desactivarse sin un despliegue, lo que significa que el tiempo de respuesta se mide en horas, no en segundos.

3. ¿Puedes mostrarme el rastro de auditoría de las últimas 100 llamadas a herramientas? Si la respuesta es "tenemos registros en CloudWatch", no hay un registro de auditoría estructurado por herramienta. El rastro de auditoría debería ser consultable por nombre de herramienta, estado y rango de tiempo — no rastreable con grep en un flujo de registros.

4. ¿Cuál es el radio de impacto si el agente de un inquilino falla? Si la respuesta es "aislamos por despliegue", no hay aislamiento de inquilinos en la capa de datos. El radio de impacto es todo el despliegue, no un solo inquilino.

La arquitectura de cuatro capas responde cada pregunta con un mecanismo concreto, no con una declaración de política. Esa es la diferencia entre describir el incendio y proporcionar el extintor.

---

Un distribuidor que opera NetSuite, BigCommerce y tres catálogos de proveedores despliega un agente en el Nivel 3 de Gartner: cotiza precios, retiene inventario y escribe pedidos aceptados en NetSuite — pero cada acción de precios por encima de un umbral requiere aprobación humana, y cada llamada a herramientas se registra con la partition key, el nombre de la herramienta, el hash de los argumentos y la duración. Cuando un módulo de catálogo de proveedor empieza a devolver datos de disponibilidad inconsistentes, el operador desactiva ese módulo mediante configuración. El agente enruta al catálogo de reserva, las llamadas recientes del módulo desactivado se consultan desde el rastro de auditoría para investigación, y el agente permanece en línea durante todo el proceso. Esa construcción es la Fase 2-4 del método de cuatro pasos y suele estar en producción en 5-8 semanas.

Solicita una construcción delimitada. Descubrimiento de una semana. Obtienes un inventario de sistemas, un mapa de flujo de trabajo y un alcance fijo — construyas o no con nosotros.