IA × IA / PLAYBOOK
PLAYBOOK · Nº 07

Supervisor de agentes

Más inteligencia en el operador. Menos poder en quien autoriza.
Un agente operador investiga con contexto amplio y propone una acción. Un supervisor deliberadamente limitado evalúa la solicitud. Un Policy Engine aplica las reglas objetivas antes de cualquier ejecución.
3 capasinvestigar, autorizar y ejecutar
AgentesGobernanzaAutonomíaPolicy Engine
Actualizado el 6 oct 2026

El problema

Un agente autónomo puede consultar SIEM, EDR, IAM, WAF y cloud, correlacionar señales y llegar a una buena hipótesis. El riesgo aparece cuando la misma entidad que investiga también decide por su cuenta hasta dónde puede actuar.

La propuesta es separar funciones y autoridad. El operador sigue siendo poderoso para investigar. La autorización pasa por una capa con un objetivo mucho más estrecho, menos contexto, menos herramientas y menor autoridad.

Arquitectura

Agente operadorEl modelo más capaz. Investiga, correlaciona, construye la hipótesis, reúne evidencias y solicita una acción.
Agente supervisorRecibe únicamente el contexto necesario para una decisión específica. Aprueba, niega o escala.
Policy EngineAplica reglas determinísticas: allow y deny list, autoridad, activo, identidad, reversibilidad, TTL, schema y kill switch.
AcciónEjecuta solo dentro de la autoridad delegada. Fuera de ella, exige humano.
El supervisor no necesita investigar mejor que el operador. Necesita decidir algo mucho más estrecho.

Contrato entre operador y supervisor

El operador no le entrega una conversación entera al supervisor. Le entrega una solicitud estructurada con acción, objetivo, evidencias, confianza y reversibilidad.

{
  "action": "revoke_session",
  "target": "user_8271",
  "evidence": {
    "credential_leak": "confirmed",
    "impossible_travel": true,
    "active_sessions": 3
  },
  "operator_confidence": 94,
  "reversible": true
}

La respuesta también es un contrato

{
  "decision": "APPROVE",
  "policy": "IAM-07",
  "scope": "user_8271",
  "ttl": "15m",
  "requires_human": false
}
El texto libre puede explicar. La autorización que pasa a la siguiente capa tiene que respetar un schema validable.

Mismo incidente. Autoridades distintas.

Ejemplo operativo
Solicitud 1Bloquear una IP maliciosa por 30 minutos
SupervisorAPPROVE
Policy EngineAcción temporal, reversible y dentro de la autoridad delegada
ResultadoEjecuta automáticamente
Solicitud 2Deshabilitar la cuenta del CFO
SupervisorPuede considerar que la evidencia es suficiente
Policy EngineIdentidad privilegiada y acción de alto impacto
ResultadoHUMAN APPROVAL REQUIRED

La matriz de autoridad

Se puede automatizar

  • Enriquecer y correlacionar alertas.
  • Crear la línea de tiempo y reunir evidencias.
  • Bloquear temporalmente una IP dentro de la política.
  • Revocar una sesión cuando identidad, alcance y reversibilidad estén dentro de la regla.

Requiere supervisión

  • Deshabilitar una cuenta privilegiada.
  • Cambiar una configuración crítica.
  • Ejecutar una acción de gran blast radius.
  • Cualquier acción irreversible o crítica.

Autoridad que se gana y se pierde

La autoridad para actuar sin aprobación no es un nivel único del agente ni es permanente. Se concede por clase de acción, después de comparar las decisiones del agente en esa clase con la revisión humana en una muestra definida. Quien mide la precisión no es el propio agente.

Cuando los veredictos empiezan a divergir de la revisión independiente por encima de un umbral, la clase vuelve al modo anterior. El umbral, la ventana de observación y quién revisa son parte del contrato, no quedan implícitos.

Concesión por claseEnriquecer, bloquear una IP por tiempo limitado y revocar una sesión son clases distintas. Cada una sube de nivel por su cuenta, con su propia evidencia.
Evaluación independienteLa muestra de decisiones la revisa alguien que no es ni el operador ni el supervisor. El agente no califica su propio examen.
Disparador de reducciónUna divergencia por encima del umbral degrada la clase automáticamente. La degradación la ejecuta la plataforma, fuera del modelo.
Acciones en vueloEl contrato dice qué pasa con lo que ya se ejecutó cuando la clase baja de nivel: reversión, compensación o solo registro. Que expire la autorización no deshace lo que ya se hizo.

El carnet del agente

Qué declara el carnet

  • Identidad del agente y responsable humano.
  • Contexto que puede consultar y accesos que tiene.
  • Acciones autorizadas, por clase, con el nivel actual de cada una.
  • Supervisión exigida, evidencia obligatoria y vigencia con fecha de expiración.

Qué queda fuera del carnet

  • El kill switch. El agente no controla su propio apagado.
  • La degradación de clase. Quien la ejecuta es la plataforma.
  • La medición de precisión. Viene de la revisión independiente.
  • Un agente sin identidad ni autoridad delimitada es una cuenta de servicio con demasiado poder.

Lo que de verdad reduce el riesgo

Función estrechaEl supervisor no recibe la misión abierta de investigar el incidente entero. Evalúa una solicitud específica.
Contexto mínimoRecibe solo los datos necesarios para decidir, lo que reduce la superficie de interpretación.
Menor autoridadNo obtiene acceso libre al entorno ni ejecuta directamente la acción solicitada.
IndependenciaObjetivo, contexto y contrato deben evitar que simplemente repita la misma cadena de razonamiento del operador.
Control determinísticoLas políticas objetivas se quedan fuera del LLM siempre que puedan expresarse como regla.
Humano según impactoEl humano entra por excepción, por política o por impacto. Lo irreversible o crítico exige aprobación humana.

Modelo más pequeño no significa modelo más seguro

Un modelo más pequeño puede servir como supervisor porque la tarea es estrecha, pero el tamaño no garantiza seguridad. El control viene de la arquitectura: función limitada, contexto mínimo, contrato rígido, menor autoridad, independencia y validaciones determinísticas.

Una segunda instancia idéntica tampoco resuelve el problema por sí sola. Si operador y supervisor comparten los mismos supuestos, el mismo contexto y la misma forma de decidir, la segunda capa puede repetir la misma falla.

Cómo implementarlo

1. Cataloga las accionesLista lo que tus agentes pueden pedir: consultar, bloquear, revocar, aislar, cambiar o eliminar.
2. Clasifica el impactoDefine reversibilidad, criticidad, blast radius e identidades o activos protegidos.
3. Define la autoridadAsocia cada acción a automático, supervisor o aprobación humana.
4. Crea contratosEstandariza request y response con schema validable y evidencia obligatoria.
5. Saca las reglas del LLMAllow list, límites, TTL, alcance, identidad privilegiada y kill switch quedan en código o en el policy engine.
6. Registra todoSolicitud, evidencia, decisión, política aplicada, ejecución, resultado y eventual intervención humana.
Para llevar: No estamos poniendo a una IA a confiar en otra IA. Estamos separando autoridad.
Llévate este playbook

En Markdown para pegar en tu IA, o como punto de partida de tu propio playbook.

Abrir este playbook en tu IAChatGPTClaudePerplexityCopilotGrok