---
title: "Supervisor de agentes"
subtitle: "Más inteligencia en el operador. Menos poder en quien autoriza."
kind: "PLAYBOOK"
number: "07"
updated: 2026-10-06
families: [ai-agent-governance, soc-response, identity-access]
tags: [Agentes, Gobernanza, Autonomía, Policy Engine]
lang: es
source: https://iaxia.rodrigojorge.me/es/cases/supervisor-agentes
author: Rodrigo Jorge
project: IA × IA
---

# 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.

- Tipo: PLAYBOOK
- Métrica de referencia: 3 capas (investigar, autorizar y ejecutar)
- Familias de desafío: Gobernanza de IA y agentes, SOC y respuesta, Identidad y accesos
- Actualizado el: 2026-10-06

## 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

1. **Agente operador**: El modelo más capaz. Investiga, correlaciona, construye la hipótesis, reúne evidencias y solicita una acción.
2. **Agente supervisor**: Recibe únicamente el contexto necesario para una decisión específica. Aprueba, niega o escala.
3. **Policy Engine**: Aplica reglas determinísticas: allow y deny list, autoridad, activo, identidad, reversibilidad, TTL, schema y kill switch.
4. **Acción**: Ejecuta 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.

```json
{
  "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

```json
{
  "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 1 | Bloquear una IP maliciosa por 30 minutos |
| Supervisor | APPROVE |
| Policy Engine | Acción temporal, reversible y dentro de la autoridad delegada |
| Resultado | Ejecuta automáticamente |
| Solicitud 2 | Deshabilitar la cuenta del CFO |
| Supervisor | Puede considerar que la evidencia es suficiente |
| Policy Engine | Identidad privilegiada y acción de alto impacto |
| Resultado | HUMAN 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 clase.** Enriquecer, 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 independiente.** La 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ón.** Una divergencia por encima del umbral degrada la clase automáticamente. La degradación la ejecuta la plataforma, fuera del modelo.
- **Acciones en vuelo.** El 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 estrecha.** El supervisor no recibe la misión abierta de investigar el incidente entero. Evalúa una solicitud específica.
- **Contexto mínimo.** Recibe solo los datos necesarios para decidir, lo que reduce la superficie de interpretación.
- **Menor autoridad.** No obtiene acceso libre al entorno ni ejecuta directamente la acción solicitada.
- **Independencia.** Objetivo, contexto y contrato deben evitar que simplemente repita la misma cadena de razonamiento del operador.
- **Control determinístico.** Las políticas objetivas se quedan fuera del LLM siempre que puedan expresarse como regla.
- **Humano según impacto.** El 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. **1. Cataloga las acciones**: Lista lo que tus agentes pueden pedir: consultar, bloquear, revocar, aislar, cambiar o eliminar.
2. **2. Clasifica el impacto**: Define reversibilidad, criticidad, blast radius e identidades o activos protegidos.
3. **3. Define la autoridad**: Asocia cada acción a automático, supervisor o aprobación humana.
4. **4. Crea contratos**: Estandariza request y response con schema validable y evidencia obligatoria.
5. **5. Saca las reglas del LLM**: Allow list, límites, TTL, alcance, identidad privilegiada y kill switch quedan en código o en el policy engine.
6. **6. Registra todo**: Solicitud, 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.

---

Fuente: https://iaxia.rodrigojorge.me/es/cases/supervisor-agentes · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno.