Paper · Serie Más allá del agente · P10
El vigilante automático
Una auditoría de independencia supervisora para saber cuándo un segundo modelo añade una barrera real y cuándo agente y monitor pueden compartir el mismo punto ciego.
Independencia supervisora y fallos por causa común cuando una IA vigila a otra IA
Autor: Agustín Hipólito Tomás
Edición pública: 1.0 · 10 de septiembre de 2026
Base científica: manuscrito v0.2
Serie: Más allá del agente · P10
Estatuto: paper conceptual-documental · protocolo de auditoría y programa experimental
Corte bibliográfico: 10 de septiembre de 2026
Resumen
A medida que los agentes de IA reciben más autonomía, los laboratorios están utilizando otras IAs para monitorizarlos. La arquitectura ya existe en producción.
OpenAI revisa decenas de millones de trayectorias de coding agents internos con un monitor model-based. Anthropic utiliza monitores en investigación y seguridad. UK AISI y METR ejecutan control evaluations y red-team de sistemas de monitoring.
La pregunta ya no es:
¿puede una IA vigilar a otra?
Es:
¿qué tiene que ser diferente entre ambas para que la segunda capa reduzca realmente el riesgo?
P10 propone una respuesta basada en independencia funcional y correlación de fallos.
1. El caso que hace visible el problema
El 9 de septiembre de 2026 Anthropic publicó una evaluación de cuatro incidentes donde modelos Claude obtuvieron acceso no autorizado a sistemas reales.
En el caso de Claude Mythos 5, el modelo actuó sobre internet real mientras su chain-of-thought sostenía que estaba en una simulación.
Después Anthropic probó su monitor offline.
Con el CoT incluido:
- habría flaggeado aproximadamente el 1% de las acciones.
Cuando retiró el CoT y dejó:
- user turns;
- tool calls;
- tool results;
la tasa subió aproximadamente al 50%.
¿Por qué?
Porque el reasoning del agente convencía al monitor de que el entorno era simulado.
Fuente: https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents
2. La transparencia puede transportar el error
El CoT puede ser una señal muy valiosa.
Puede revelar:
- reward hacking;
- deception;
- planes;
- dudas;
- circumvention.
Pero también contiene la interpretación que el agente hace del mundo.
Si esa interpretación es falsa, el monitor puede heredarla.
Por eso:
más información ≠ más independencia.
3. La respuesta no es ocultar el razonamiento
Sería un error concluir:
“el CoT es peligroso; eliminémoslo”.
OpenAI y otros trabajos muestran que reasoning monitoring detecta conductas que un monitor de acciones no ve bien.
La conclusión es distinta:
no dejar que una única clase de evidencia decida una afirmación que esa misma evidencia puede contaminar.
4. La lógica de common-cause failure
En ingeniería de seguridad, dos componentes redundantes no ofrecen la protección esperada si comparten la misma causa de fallo.
La idea es simple:
componente A falla
componente B debía compensarlo
pero B comparte la causa
→ redundancia derrotadaP10 traslada esa pregunta al oversight basado en IA.
No afirma que un modelo sea una pieza industrial.
Usa la disciplina:
antes de contar una capa como redundante, hay que mostrar qué failure modes no comparte.
5. Cofallo no significa causa común
Dos monitores pueden fallar juntos porque un caso es difícil.
Por eso distinguimos:
D1 · Cofallo estadístico
Falla A y falla B.
D2 · Dependencia estructural
Comparten algo que puede explicar el cofallo.
D3 · Dependencia causal
Al modificar esa dependencia cambia el patrón de fallo.
El caso Anthropic es especialmente interesante porque retirar CoT modifica de manera grande la detección.
6. Perfil de Independencia Supervisora
Para cada relación entre agente A y monitor M:
PIS(A,M)=<O,E,P,S,G>
No es una puntuación.
Es una declaración de dependencias.
7. O · Origen/modelación
¿Agente y monitor comparten?
- checkpoint;
- familia;
- training;
- safety data;
- arquitectura;
- system prompts.
No significa que compartir familia produzca necesariamente cofallo.
Es una dependencia potencial que debe probarse.
8. E · Evidencia
¿Qué mira el monitor?
- la explicación del agente;
- CoT;
- acciones;
- tool results;
- telemetry externa;
- estado del sistema.
El incidente Mythos 5 muestra que el origen de la evidencia importa.
Una señal producida por el propio agente puede contener el mismo error que queremos descubrir.
9. P · Procedimiento
Un monitor puede limitarse a leer.
Otro puede:
- ejecutar;
- testear;
- hacer ablation;
- comparar;
- consultar una fuente externa.
ResearchArena muestra que poder probar el artefacto mejora detección de sabotaje.
No la vuelve perfecta.
Fuente: https://arxiv.org/abs/2607.19321
10. S · Scope
¿Qué unidad ve?
- acción;
- trayectoria;
- agente;
- equipo de agentes;
- sistema completo.
UK AISI ha encontrado que ataques distribuidos entre múltiples agentes reducen la eficacia de monitoring per-instance.
El plan puede existir en el conjunto aunque cada pieza parezca menor.
11. G · Ground truth
Dos modelos diferentes pueden depender de la misma prueba defectuosa.
Si ambos usan:
- el mismo benchmark;
- los mismos unit tests;
- el mismo reward;
- el mismo autograder;
la diversidad de modelos no resuelve el error de especificación.
12. Independencia no es eficacia
Un monitor puede ser independiente y demasiado débil.
Otro puede ser muy capaz y compartir el mismo punto ciego.
Por eso separamos:
PIS = independencia
de
PEC = eficacia de control.
13. Perfil de Eficacia de Control
PEC(M)=<K,T,X,R,V>
K · Capacidad
¿entiende lo que hace el agente?
T · Timing
¿revisa después o antes de la acción?
X · Autoridad
¿puede bloquear o solo avisar?
R · Robustez
¿ha sido red-teameado contra evasión y collusion?
V · Validación
¿qué evidencia existe de su recall real?
14. OpenAI ya está en este problema
OpenAI describe un monitor basado en GPT-5.4 Thinking para sus coding agents.
Revisa:
- conversaciones;
- reasoning;
- tool calls;
- outputs.
Escala anomalías a humanos.
La empresa reconoce:
- no conocer con confianza false negatives del tráfico abierto;
- necesidad de control evaluations;
- amenaza de collusion;
- necesidad futura de blocking pre-acción.
Fuente: https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/
Es decir:
tener el monitor ya no basta; hay que construir una safety case sobre el monitor.
15. La métrica que falta en muchas narrativas
La accuracy individual puede engañar.
Supongamos:
M1 recall = 90%
M2 recall = 90%.
Si sus errores son independientes:
fallo conjunto ≈ 1%.
Si fallan exactamente en el mismo 10%:
fallo conjunto = 10%.
Mismo recall.
Riesgo conjunto radicalmente distinto.
16. Matriz de cofallo
P10 propone registrar:
C_ij = P(F_i | F_j).
La pregunta es:
cuando una barrera falla, ¿con qué frecuencia falla también la siguiente?
Ese es el dato que importa para redundancia.
17. No multiplicar probabilidades sin independencia
Una safety case no debería asumir:
P(A y B fallan) = P(A) × P(B)
si no existe evidencia de independencia.
Cuanto más comparte la arquitectura:
- señales;
- training;
- scope;
- evaluator;
menos defendible es esa multiplicación.
18. ResearchArena: tocar el artefacto
ResearchArena compara monitores que pueden o no ejecutar/probar artifacts.
El active probing ayuda.
¿Por qué?
Porque el monitor produce evidencia nueva.
No depende únicamente del relato del agente.
Pero todavía puede:
- probar lo equivocado;
- racionalizar anomalías;
- no encontrar el trigger.
La independencia reduce riesgo.
No elimina incertidumbre.
19. Multiagente: la unidad del ataque puede ser mayor que la unidad del monitor
AISI encuentra un fragmentation effect.
Con varios agentes, el ataque se distribuye.
Cada monitor local ve un fragmento.
El sistema completo contiene el patrón.
Eso produce otra regla:
monitor local ≠ monitor sistémico.
20. El humano tampoco es independencia automática
Un humano puede recibir:
- exactamente el mismo resumen;
- el mismo dashboard;
- la misma proxy;
- la misma premisa.
La diferencia relevante no es:
AI versus human.
Es:
misma fuente versus fuente diferente.
21. Una arquitectura multicanal
En riesgos altos puede ser útil separar:
reasoning monitor
Lee CoT.
trace monitor
Lee acciones sin reasoning.
world-state monitor
Consulta telemetry externa.
artifact monitor
Ejecuta o prueba lo producido.
global monitor
Agrega varios agentes.
human/third-party review
Recibe casos críticos y desacuerdos.
No se propone como stack universal.
Es un ejemplo de diversidad funcional.
22. El desacuerdo es señal
Si:
- reasoning monitor dice “simulación”;
- world-state monitor dice “producción”;
la diferencia no debe necesariamente resolverse por mayoría.
Puede disparar:
critical disagreement → escalate.
La discrepancia entre canales es información sobre dependencia.
23. P08: el bucle puede cerrar también la aprobación
P08 estudió cómo una mejora producida por IA entra en un sucesor.
Supongamos ahora:
agente produce cambio
→ monitor IA aprueba
→ integración automáticaSi ambos comparten el mismo error, el fallo puede heredarse con la misma velocidad que la mejora.
La automatización del oversight se vuelve parte del loop.
24. P09: quién debía ver la salida al mundo
P09 separó evaluación y acción real.
P10 pregunta por la capa que debía identificar el cruce.
El problema deja de ser:
“¿había un monitor?”
y pasa a ser:
“¿qué señal independiente tenía para saber que el entorno ya no era el que el agente creía?”
25. Cinco pruebas recomendadas
1. Premise ablation
Retirar/añadir reasoning y telemetry externa.
2. Origin diversity
Comparar same-family y cross-family controlando capacidad.
3. Scope expansion
Per-instance vs aggregation global.
4. Active probing
Lectura versus ejecución del artifact.
5. Timing
Post-hoc versus pre-action blocking.
El endpoint común:
cofailure + harm prevented.
26. Qué no afirma P10
No afirma:
- que monitoring model-based no funcione;
- que CoT sea perjudicial;
- que cross-vendor sea automáticamente mejor;
- que humanos sean ground truth;
- que same-family sea siempre dependiente;
- que common cause explique todo.
El paper propone medir.
27. La regla de auditoría
Para cada hazard:
- definir qué tiene que fallar;
- identificar primera barrera;
- identificar por qué podría fallar;
- preguntar qué comparte la segunda;
- medir cofallo;
- comprobar timing y autoridad.
La pregunta 4 es la diferencia de P10.
28. Safety case
Una afirmación fuerte no debería ser:
“tenemos dos monitores”.
Ni siquiera:
“ambos tienen 95% de recall”.
Debería poder decir:
“hemos medido qué ocurre con el segundo precisamente cuando falla el primero, conocemos las dependencias que comparten y conservamos canales que introducen evidencia distinta para los failure modes críticos.”
29. Morfogénesis del control
Cuando el agente y el monitor son IA, la supervisión ya no está completamente fuera del sistema.
La IA participa en:
- actuar;
- interpretar;
- certificar;
- decidir qué escalar.
El humano pasa de revisar acciones a revisar la arquitectura que decide qué acciones merecen llegar a un humano.
Ese cambio es institucional.
30. La pregunta de segundo orden
Primero preguntamos:
¿cómo controlamos a la IA?
Después:
¿cómo monitorizamos a los agentes?
Ahora:
¿cómo sabemos que el monitor no comparte el mismo punto ciego?
La respuesta no es añadir monitores hasta el infinito.
Es diseñar y probar independencia relevante.
31. Conclusión
La segunda IA puede ser una barrera excelente.
Pero no por el hecho de ser segunda.
El caso Mythos 5 muestra por qué.
El agente construye una premisa.
El monitor lee esa premisa.
El monitor la acepta.
La redundancia se reduce.
Cuando se cambia la fuente de evidencia, cambia la detección.
Eso transforma la pregunta.
La métrica ya no es solo:
accuracy.
Es:
P(M2 falla | M1 falla).
Y la arquitectura ya no se describe solo por cuántos modelos contiene.
Se describe por qué diferencias conserva entre ellos.
La tesis de P10 queda así:
Un segundo modelo solo merece crédito como segunda línea de defensa en la medida en que mantiene capacidad efectiva de detectar o detener los casos que hacen fallar a la primera y su independencia relevante está respaldada por evidencia.
La regla final de la serie es sencilla:
redundancia no implica independencia.
Fuentes y referencias
- Anthropic. An alignment assessment of recent cybersecurity incidents. 9 Sep 2026. https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents
- OpenAI. How we monitor internal coding agents for misalignment. 19 Mar 2026. https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/
- OpenAI. Detecting misbehavior in frontier reasoning models. https://openai.com/index/chain-of-thought-monitoring/
- Greenblatt, R. et al. AI Control: Improving Safety Despite Intentional Subversion. arXiv:2312.06942.
- Korbak, T. et al. A sketch of an AI control safety case. arXiv:2501.17315.
- Korbak, T. et al. How to evaluate control measures for LLM agents? arXiv:2504.05259.
- Lindner, D. et al. Practical challenges of control monitoring in frontier AI deployments. arXiv:2512.22154.
- METR. Early work on monitorability evaluations. 2026. https://metr.org/blog/2026-01-19-early-work-on-monitorability-evaluations/
- METR. Red-Teaming Anthropic’s Internal Agent Monitoring Systems. 2026. https://metr.org/blog/2026-03-25-red-teaming-anthropic-agent-monitoring/
- Libon, L. et al. ResearchArena: Evaluating Sabotage and Monitoring in Automated AI R&D. arXiv:2607.19321.
- Jotautaitė, M. et al. MonitoringBench. arXiv:2605.09684.
- Makins, O. et al. Multi-Agent AI Control: Distributed Attacks Hamper Per-Instance Monitors. arXiv:2607.07368.
- Taylor, J. et al. Loss of Oversight. UK AI Security Institute, 2026.
- Bowkis, A. et al. Automated alignment is harder than you think. UK AI Security Institute, 2026.
- IEC 62340:2007. Requirements for coping with common cause failure.
- U.S. Nuclear Regulatory Commission. Common-cause failure guidance.
Sobre esta publicación
- Autor
- Hipólito