Coordinador D2D: planificación de misiones y cuándo llamar a una persona

El nodo coordinador es donde los sistemas agénticos D2D viven o mueren. Si lo haces mal, tienes un bucle caro que alucina planes. Si lo haces bien, tienes un sistema que se degrada con elegancia ante los fallos y sabe exactamente cuándo parar y preguntar a una persona.

Descomposición de la misión

Cuando llega un objetivo de alto nivel (por ejemplo, «investiga el pico de eventos de autenticación fallida desde el rango de IP 203.0.113.0/24 en las dos últimas horas»), el primer trabajo del coordinador es descomponerlo en un grafo acíclico dirigido (DAG) de subtareas:

mission: investigate-auth-spike
tasks:
  - id: t1
    type: query_siem
    params: { query: "failed_auth src_ip:203.0.113.0/24 last:2h", limit: 500 }
  - id: t2
    type: enrich_ip
    params: { ip_range: "203.0.113.0/24" }
    depends_on: []
  - id: t3
    type: correlate_events
    params: {}
    depends_on: [t1, t2]
  - id: t4
    type: assess_threat
    params: {}
    depends_on: [t3]
  - id: t5
    type: notify_slack
    params: { channel: "#soc-alerts", severity_threshold: "high" }
    depends_on: [t4]

t1 y t2 se ejecutan en paralelo (sin dependencias). t3 espera a ambas. t4 espera a t3. t5 solo se dispara si t4 evalúa la amenaza como alta o crítica. Es un patrón estándar de ejecución de DAG, nada exótico.

Gestión de los fallos parciales

Los sistemas D2D reales fallan parcialmente todo el tiempo. La NVD está caída. La consulta al SIEM agota el tiempo. Un servicio de enriquecimiento de IP devuelve un error por límite de tasa. El coordinador necesita una política de replanificación:

1. Reintentar con espera: ante fallos transitorios (límites de tasa, tiempos agotados), reintentar hasta max_retries con espera exponencial
2. Sustituir por un resultado degradado: si un worker de enriquecimiento falla, el coordinador puede seguir con un enriquecimiento nulo y marcar el hueco en la salida
3. Replanificar el DAG: si falla una tarea del camino crítico, el coordinador vuelve a descomponer: ¿se puede lograr el objetivo con otro enfoque?
4. Escalar a una persona: si la replanificación falla o la misión requiere una decisión que el coordinador no está autorizado a tomar (por ejemplo, «¿bloqueo este rango de IP en el cortafuegos?»), se detiene y avisa a la persona

La restricción clave: el coordinador nunca debe adivinar para sortear un fallo. Un coordinador que fabrica datos de enriquecimiento porque la API estaba caída es peor que uno que dice «no he podido completar este paso».

Cuándo llamar a una persona

Es la decisión de diseño más difícil de cualquier sistema agéntico. El coordinador debería escalar cuando:

• Una acción sería irreversible (bloquear un rango de red, borrar una cuenta, enviar una notificación externa)
• La confianza en la evaluación está por debajo de un umbral definido (por ejemplo, confianza en la amenaza < 0,7)
• La misión ha superado su presupuesto de tiempo o de tokens sin completarse
• Un worker ha sido terminado varias veces y no existe una vía alternativa
• La tarea requiere una autorización que el coordinador no tiene (soberanía de los datos, retención legal)

Escalar no es fracasar: es el coordinador haciendo bien su trabajo. Un mensaje de escalado bien diseñado incluye qué se ha logrado, qué falló y por qué, qué decisión hace falta y qué recomendaría el coordinador si tuviera que adivinar.

La máquina de estados de la misión

states:
  PLANNING → EXECUTING → COMPLETED
                       → PARTIAL_SUCCESS (with gaps flagged)
                       → REPLANNING → EXECUTING
                       → ESCALATED (human decision required)
                       → FAILED (unrecoverable)

Cada transición se registra con un motivo. Un análisis posterior a un incidente puede trazar el historial completo de estados de una misión: qué workers se ejecutaron, cuáles fallaron, qué decidió el coordinador en cada encrucijada y cuál fue la salida final.

Implicaciones de seguridad para los CISO

Para un CISO que despliega sistemas agénticos D2D, la política de escalado del coordinador es un documento de gobierno. Define:

• Qué puede hacer el sistema de forma autónoma y qué requiere aprobación humana
• Cuál es el radio de impacto si el sistema se comporta mal
• Cómo es la pista de auditoría a efectos regulatorios

Antes de desplegar cualquier sistema D2D en producción, las reglas de escalado del coordinador y los manifiestos de los workers deberían pasar por el mismo proceso de revisión que cualquier otro cambio en los controles de seguridad de producción.

Siguiente: desplegar D2D para un equipo real de operaciones de seguridad, incluida la integración con PagerDuty, la cola de revisión humana y las lecciones de ponerlo a funcionar de verdad.