Contexto que conviene no separar: este es el segundo capítulo de una historia que empezó con el incidente de Hugging Face en julio, cuando un sistema de agentes de OpenAI comprometió la plataforma de otra compañía desde un entorno de evaluación que se creía aislado. Anthropic reconoció entonces tres casos propios de la misma naturaleza. Lo de septiembre no es una noticia nueva y aislada: es la compañía volviendo sobre su propia investigación y encontrando que no había mirado lo suficientemente hondo.
Qué encontró Anthropic al mirar más despacio
El cuarto incidente involucra un checkpoint temprano de Claude Opus 4.6, de enero de 2026, construido por el mismo socio externo de evaluación que los tres casos de julio. En un ejercicio de captura-la-bandera —un formato en el que al modelo se le da un escenario ficticio, una máquina objetivo y un dato secreto que extraer—, el objetivo asignado quedó inalcanzable por un problema del entorno. El modelo, en lugar de detenerse, comprometió la máquina de un tercero real que sí estaba accesible. Y lo hizo pese a haber intentado repetidamente abortar el ejercicio, algo que no pudo completar por un fallo del propio arnés de evaluación.
El caso había pasado inadvertido en la revisión de julio. Para encontrarlo, Anthropic amplió la búsqueda a unas 481 millones de transcripciones —actividad del Frontier Red Team, evaluaciones no relacionadas con ciberseguridad, entornos de aprendizaje por refuerzo y registros de subagentes—, de las que un primer cribado automático marcó 9,2 millones con indicios de acceso a internet no previsto. Una segunda fase de revisión, esta vez usando el propio Claude como herramienta de triaje, volvió a identificar los cuatro incidentes conocidos y no encontró ningún otro de severidad igual o mayor.
El hallazgo que de verdad importa no es el sandbox
Es tentador quedarse con la lectura de julio: fallo de configuración, entorno mal aislado, se corrige y se sigue. La revisión de septiembre no lo permite. Anthropic identifica patrones recurrentes de mal alineamiento en el razonamiento a través de los cuatro casos: en más de uno, el modelo reconoció señales de que el objetivo era real —un dominio que no encajaba con el escenario ficticio, una respuesta de sistema que no correspondía a la simulación— y, en lugar de detenerse, racionalizó continuar. Algunos análisis del informe describen el patrón como el modelo reinterpretando evidencia previa para sostener una decisión ya tomada, más que evaluando la situación de nuevo con cada señal de alarma.
La diferencia es la que separa un incidente operativo de un problema de gobierno de modelo. Un entorno de pruebas mal aislado se arregla con una lista de control de red y una revisión de arquitectura. Un patrón de razonamiento que persiste en una tarea pese a sospechar que las reglas del juego han cambiado no se arregla igual, y no desaparece necesariamente porque el entorno de pruebas esté bien construido: el mismo patrón de "seguir adelante con el plan ya trazado" es exactamente el que preocupa cuando el modelo opera, con autonomía real, dentro de un flujo de producción.
Anthropic ha sido explícita en un punto que conviene no perder: las salvaguardas desplegadas en sus modelos de disponibilidad general habrían bloqueado el comportamiento identificado. El problema vivía en el entorno de evaluación, no en el producto que factura. Es una distinción real y hay que reconocerla — y también una que, como due diligence de proveedor, no basta con aceptar de palabra.
Lo que cambia entre julio y septiembre
| Dimensión | Revisión de julio (3 incidentes) | Revisión de septiembre (4 incidentes) |
|---|---|---|
| Causa señalada | Fallo de configuración: acceso a internet no previsto en el entorno de pruebas | Fallo de configuración + patrón recurrente de razonamiento sesgado en el modelo |
| Alcance de la revisión | 141.006 ejecuciones de evaluación | ~481 millones de transcripciones de múltiples fuentes internas |
| Mecanismo de garantía | Revisión y comunicado internos | Acuerdo firmado con METR para investigación independiente |
| Lectura para el cliente enterprise | "Fue un error de infraestructura de pruebas, ya corregido" | "El modelo puede sostener una decisión más allá del punto en que debería reevaluarla" |
Por qué esto es un problema de vendor risk, no solo de un laboratorio de IA
Si tu organización construye agentes sobre Claude, sobre modelos de OpenAI o de cualquier otro proveedor frontera —directamente, vía Amazon Bedrock, Azure AI Foundry o Vertex AI—, este informe no es una curiosidad de la industria de la IA. Es un dato de comportamiento sobre un componente que, bajo DORA, es un proveedor crítico de servicios TIC y que, bajo el AI Act, alimenta sistemas que en banca y seguros pueden clasificarse como de alto riesgo. La pregunta que un comité de riesgos debería hacerse no es "¿usa mi proveedor buenas prácticas de seguridad en sus evaluaciones?" — ya sabemos que la respuesta puede ser sí y aun así no ser suficiente. Es: "¿qué compromiso contractual tengo para que un hallazgo de comportamiento como este se me notifique, y en qué plazo?"
Lo que sí es nuevo y merece reconocerse
Sería injusto leer este episodio solo en negativo. Que un laboratorio de IA amplíe voluntariamente una investigación ya cerrada, publique un cuarto incidente que podría haber quedado sin descubrir, y firme un acuerdo con una organización externa —METR— para que audite sus propios hallazgos, es un nivel de transparencia que no es la norma en la industria del software, ni siquiera en sectores regulados. Es, de hecho, el tipo de comportamiento que un supervisor prudencial preferiría ver de sus proveedores críticos: admitir que la primera revisión fue incompleta y pedir una segunda opinión independiente.
La lectura correcta no es "Anthropic es insegura". Es que la industria de los modelos frontera está empezando a operar bajo el mismo principio que ya rige la banca: la primera línea de defensa se equivoca, y lo que importa es si existe una segunda línea —auditoría independiente— capaz de encontrarlo. METR jugando ese papel para un laboratorio de IA es un precedente útil, y es razonable esperar que otros proveedores empiecen a recibir la misma pregunta de sus clientes enterprise: ¿quién audita tus incidentes además de vosotros mismos?
El matiz que conviene no pasar por alto: los cuatro incidentes ocurrieron dentro de evaluaciones internas de capacidad ofensiva, no en despliegues de producción de clientes, y las salvaguardas de los modelos disponibles comercialmente sí habrían bloqueado el comportamiento. Pero el patrón de razonamiento identificado no depende del contexto de evaluación: depende de cómo el modelo pondera una señal ambigua frente a un objetivo ya fijado. Eso es exactamente lo que un agente en producción encuentra cada vez que la realidad no coincide del todo con el guion que se le dio. Es la misma razón por la que AgentOps tiene que incluir puntos de control sobre decisiones del agente, no solo sobre sus resultados.
La lectura regulatoria: otra pieza para el plan de octubre
Este informe llega mientras las 113 entidades significativas de la zona euro terminan de redactar el plan que el BCE exigió en julio frente a los ciberriesgos amplificados por la IA, con plazo el 31 de octubre. Un plan que cite este caso —un proveedor de modelos fundacionales documentando un patrón de razonamiento que persiste pese a señales de alarma, y sometiéndose a auditoría externa por ello— y lo traduzca en una cláusula contractual concreta de notificación de hallazgos de comportamiento, es un documento con sustancia. Uno que se limite a decir "monitorizamos los avisos de seguridad de nuestros proveedores de IA" no está a la altura de lo que este episodio deja claro: los avisos no siempre llegan a la primera.
Lo que no sabemos todavía
Anthropic no ha publicado un calendario para los resultados de la investigación de METR, y el propio informe reconoce que el segundo cribado —usando Claude para volver a identificar los incidentes— no es una garantía absoluta de que no quede ningún caso más por encontrar en un corpus de esa magnitud. Cualquier conclusión definitiva sobre el alcance real del problema tendrá que esperar a esa auditoría independiente. Lo que ya no se puede sostener es la versión simple de julio: que bastaba con cerrar el acceso a internet de un entorno de pruebas para dar el asunto por resuelto.