Bienvenido a

la base de datos de incidentes de IA

Los huéspedes de hoteles tienen una nueva oportunidad para probar las acusaciones de que varios casinos de Atlantic City conspiraron para fijar precios utilizando un algoritmo común, luego de que el Tribunal de Apelaciones del Tercer Circuito de los Estados Unidos se desmarcara de otros tribunales inferiores al reabrir el caso.

Un panel de tres jueces del Tercer Circuito dictaminó el miércoles que el Tribunal de Distrito de los Estados Unidos para el Distrito de Nueva Jersey había "errado al no comprender ni reconocer la naturaleza de la conspiración" en la que Caesars Entertainment, MGM Resorts, Hard Rock International y otros hoteles supuestamente acordaron utilizar el software de precios Rainmaker de Cendyn para aumentar las tarifas.

"El supuesto plan solo funcionaría si los hoteles con casino pudieran mantener precios de habitaciones más altos sabiendo que otros hoteles con casino no reducirían sus tarifas para competir por el grupo de huéspedes potenciales", señala la opinión precedente (https://assets.alm.com/7d/ab/22cdcf5b460ab668382fadb1659e/third-circ-opinion.pdf). "Esto sin duda respalda la inferencia de colusión; de hecho, no se nos ocurre otra explicación."

El profesor de Derecho de la Universidad de Pensilvania, Herbert Hovenkamp, afirmó que el Tercer Circuito llegó a la conclusión correcta de que estas acusaciones de fijación de precios algorítmica en red violan la Ley Sherman.

"Es un esquema de cártel perfecto en el que básicamente se contrata a un agente externo para calcular el precio del cártel, y luego los hoteles, por defecto, cobran ese precio", dijo Hovenkamp. "De esa manera se obtiene un cártel extremadamente eficiente."

Hovenkamp señaló que la opinión es una "buena decisión" para los demandantes que impugnan el uso compartido de un algoritmo, como lo han hecho en industrias relacionadas con hoteles, apartamentos y seguros de salud.

"Bastante inverosímil"

En mayo de 2023, un grupo de huéspedes de hoteles demandó a Caesars Entertainment, Hard Rock, Borgata y MGM alegando que fijaron ilegalmente los precios utilizando el algoritmo Rainmaker de Cendyn, que supuestamente recomienda tarifas de habitaciones basándose en información confidencial compartida por los casinos.

La jueza Karen Williams desestimó el caso en septiembre de 2024 sin posibilidad de enmienda, tras considerar que la existencia de una conspiración era «bastante improbable».

La jueza afirmó que el plazo de 14 años durante el cual los hoteles adoptaron Rainmaker —y su autoridad independiente para fijar precios— no indica la existencia de un acuerdo entre ellos.

El miércoles, el Tercer Circuito discrepó, dictaminando que los demandantes presentaron suficientes alegaciones para inferir de forma plausible que los hoteles demandados habían acordado fijar precios.

El Tercer Circuito discrepó, dictaminando que los demandantes presentaron suficientes alegaciones para inferir de forma plausible que los hoteles demandados habían acordado fijar precios. A partir de 2022, los hoteles continuaron aumentando las tarifas a pesar de la disminución de la ocupación, alineándose con las recomendaciones de Rainmaker en el 90% de los casos, según la sentencia.

Los jueces indicaron que el tribunal de primera instancia exigía a los demandantes que explicaran con precisión cómo el algoritmo facilita el intercambio de información, pero que esto es innecesario en esta etapa.

"Esto equivale a esperar que los demandantes expliquen cómo funciona el software propietario de Cendyn sin brindarles la información necesaria para ello", escribieron.

El Tercer Circuito remitió el caso al Tribunal de Distrito de los Estados Unidos para el Distrito de Nueva Jersey para que continúe el proceso.

¿Qué sucede en Las Vegas?

En la apelación, los demandantes argumentaron que el tribunal federal de Nueva Jersey asumió erróneamente que su demanda contenía los mismos errores que una demanda similar contra los mismos hoteles y Cendyn en Las Vegas. Los huéspedes del hotel de Las Vegas alegaron inicialmente que un grupo similar de hoteles había participado en una conspiración tipo centro y periferia con Cendyn, pero abandonaron esa demanda tras su desestimación por el Tribunal de Distrito de los Estados Unidos para el Distrito de Nevada.

Los demandantes de Las Vegas apelaron ante el Tribunal de Apelaciones del Noveno Circuito de los Estados Unidos con una única demanda que alegaba que los acuerdos individuales entre Cendyn y cada hotel causaron un daño anticompetitivo "en conjunto".

El Noveno Circuito rechazó categóricamente esa demanda en mayo de 2025, al considerar que los demandantes no podían presentar una demanda conforme a la Sección 1 "en ausencia de pruebas de un acuerdo entre los hoteles demandados".

Joshua Davis, socio de Berger Montague, quien representó al American Antitrust Institute en un escrito de amicus curiae en apoyo de los demandantes, afirmó que probablemente era demasiado pronto para que se solicitara a la Corte Suprema que se pronunciara sobre los casos de Cendyn antes de que otros tribunales inferiores se pronunciaran al respecto.

Fue muy alentador ver que este tribunal reconociera el tipo de peligro que representa la IA y que tal vez debamos reconsiderar la forma en que aplicamos nuestras leyes antimonopolio.

El Tercer Circuito fue el último tribunal en citar el discurso de Maureen Ohlhausen, excomisionada interina de la Comisión Federal de Comercio (FTC), pronunciado en 2017, en el que afirmó: «Si no está bien que lo haga un tipo llamado Bob, probablemente tampoco esté bien que lo haga un algoritmo».

«No deberíamos impedir que las empresas implementen mejores herramientas analíticas, ya que anticipar y responder a las acciones de la competencia es esencial para la libre competencia», declaró el socio de Wilson Sonsini Goodrich & Rosati sobre la opinión. «Debe existir algún indicio de acuerdo que indique que los usuarios del algoritmo ya no actúan de forma independiente».

El Tercer Circuito advirtió que no había hecho suposiciones ni llegado a conclusiones sobre el funcionamiento del software de Cendyn, pero que, en las circunstancias aquí alegadas, rara vez existen justificaciones comerciales legítimas para otorgar a los competidores el beneficio de información confidencial y sensible desde el punto de vista comercial.

La Corte Suprema rechazó una solicitud para escuchar los argumentos sobre la decisión del Noveno Circuito. Sin embargo, dado que la opinión de hoy difiere de la de la Costa Oeste, los magistrados podrían estar más dispuestos a considerar la impugnación presentada por los demandados, que operan como casinos y hoteles.

Davis indicó que prevé que el siguiente paso de los demandados probablemente sea una petición ante el Tercer Circuito para que se revise el caso.

El Departamento de Justicia había instado al Noveno Circuito a reabrir el caso de Las Vegas y expresó su apoyo al caso de Atlantic City antes de la moción de desestimación.

El Tercer Circuito también respondió a un argumento del Centro Internacional de Derecho y Economía (ICLE), que sostuvo en un escrito de amicus curiae que el caso de los demandantes conllevaba el riesgo de responsabilidad para las gasolineras que utilizaban las mismas fórmulas en una hoja de cálculo de Excel.

El panel afirmó que estos argumentos pasaban por alto algunos de los detalles alegados en la demanda.

«Lejos de los ejemplos presentados por el ICLE de programas informáticos utilizados de forma separada e independiente para ayudar a las empresas a competir entre sí, se alega que Rainmaker opera como un único centro de toma de decisiones, coordinando los precios para la mayor parte del mercado», declaró el Tercer Circuito.

Zach Fields, abogado asociado de segundo año en Susman Godfrey, presentó la apelación en nombre de los demandantes.

"Nos complace que el primer tribunal federal de apelaciones en abordar demandas por conspiración horizontal como la nuestra haya dictaminado correctamente que el uso de precios basados en inteligencia artificial no exime de responsabilidad a la Ley Sherman por conductas anticompetitivas", declaró Susman Godfrey en un comunicado.

Se contactó a los abogados de los demandados para obtener comentarios.

Abogados de la demandada/apelada Caesars Entertainment:

Skadden Arps Slate Meagher & Flom

Sam Auld, Boris Bershteyn, Michael Menitove, Andrew Muscato, Kenneth Schwartz y Tansy Woan en Nueva York

Abogados de la demandada/apelada MGM Resorts:

Munger Tolles & Olson

Bethany Kristovich en Los Ángeles; Justin Raphael en San Francisco

Abogados de la demandada/apelada Hard Rock International

Jones Day

Jennifer Del Medico y Laura Sawyer en Nueva York; David Kiernan y Matthew Silveria en San Francisco

Abogados de la demandada/apelada Boardwalk 1000 DBA Hard Rock Hotel & Casino Atlantic City

King & Spalding

Craig Carpenito y David Lesser en Nueva York

Abogados de la demandada/apelada Cendyn Group

Latham & Watkins

Melissa Arbus Sherry, Christopher Brown, Lawrence Buterman, Graham Haviland y Anna Rathbun en Washington, D.C.; Sadik Huseny y Brendan McShane en San Francisco

Abogados de los demandantes/apelantes

Susman Godfrey

Zach Fields en Nueva York y Shawn Raymond en Houston

Hausfeld

Mindee Reuben en Filadelfia

Burns Charest

Chris Cormier en Washington, D.C.

Lite DePalma Greenberg & Afanador

Joseph DePalma y Catherine Derenze en Newark, Nueva Jersey

Abogados del amicus curiae apelante Open Markets Institute

Migliaccio & Rathod

Jason Rathod en Washington, D.C.

Abogados del amicus curiae apelante American Antitrust Institute

Berger Montague

Joshua Davis y Matthew Summers en San Francisco

Departamento interno

David Fisher en Washington, D.C.

Abogados del amicus curiae apelado International Center for Law & Economics

Shook Hardy & Bacon

Thomas Sullivan Jr. en Filadelfia

Este artículo fue publicado originalmente por la publicación hermana de Law.com, Global Competition Review.

Un hospital veterinario en The Dalles ha demandado a un animal Una empresa de tecnología sanitaria alega que su servicio de diagnóstico mediante inteligencia artificial identificó erróneamente un tumor canceroso, lo que provocó la muerte de un perro de 11 años.

La demanda, presentada el jueves por el Hospital Veterinario de Columbia ante el Tribunal del Condado de Wasco, acusa a la empresa Zoetis Inc., con sede en Nueva Jersey, de fraude y de violar la Ley de Prácticas Comerciales Ilegales de Oregón.

El hospital alega que Zoetis Inc. comercializó falsamente su herramienta de IA, Vetscan Imagyst, como "el analizador veterinario de IA más avanzado del mundo", capaz de identificar con precisión ciertos tipos de cáncer, pero omitió revelar sus limitaciones, según consta en la demanda.

De acuerdo con la denuncia, el Hospital Veterinario de Columbia adquirió el sistema de IA en 2024 creyendo que proporcionaba resultados de diagnóstico de nivel experto.

La demanda indica que, en octubre de 2025, los veterinarios del hospital utilizaron el sistema de IA para analizar muestras de tejido de un perro pastor belga tervuren de 11 años que fue ingresado con una masa en el cuello de rápido crecimiento.

Según la demanda, el software de IA detectó características de mastocitos y células fusiformes asociadas a un tumor canceroso a partir de la muestra, pero concluyó que la masa del perro era una lesión inflamatoria, no cáncer.

Los veterinarios del hospital extirparon la masa basándose en la evaluación del software, pero una biopsia posterior realizada por el Laboratorio de Diagnóstico Veterinario de la Universidad Estatal de Oregón determinó que se trataba de un cáncer agresivo.

Según la demanda, los demandantes alegan que, dado que la cirugía inicial no extirpó todo el cáncer, fue necesaria una segunda operación.

El perro falleció posteriormente debido a complicaciones derivadas de la segunda cirugía, según la demanda.

"La muerte del paciente fue consecuencia directa de la necesidad de un segundo procedimiento quirúrgico invasivo, especialmente en un lapso tan corto desde el primero, lo cual no habría sido necesario si Imagyst hubiera identificado correctamente el tumor como canceroso, tal como la demandada Zoetis afirmó que lo haría", declaran los demandantes en la demanda.

Además de argumentar que el desenlace del perro habría sido diferente si el sistema de IA hubiera identificado correctamente el tumor desde el principio, el hospital también alega que Zoetis alteró el informe original de IA tras ser informada del diagnóstico de cáncer.

Según los demandantes, poco después de informar a Zoetis sobre el diagnóstico erróneo, la empresa solicitó una llamada con el Hospital Veterinario de Columbia.

La demanda alega que, durante la llamada, la empresa se disculpó con el hospital, admitió su error y afirmó que se habían producido incidentes similares con otros usuarios de Imagyst. Zoetis también declaró que estaba intentando solucionar el problema y agradeció al hospital su colaboración, según consta en la demanda.

El hospital solicita actualmente una indemnización de al menos 50.000 dólares.

Zoetis Inc. no respondió de inmediato a la solicitud de comentarios.

Tras revisar las transcripciones de nuestras evaluaciones de ciberseguridad, detectamos tres incidentes en los que un modelo de Claude accedió a internet desde dentro o mientras interactuaba con un entorno de evaluación de terceros, y posteriormente obtuvo acceso no autorizado a los sistemas reales de tres organizaciones diferentes.

A continuación, describimos lo sucedido, cómo ocurrió y qué cambios estamos implementando. Animamos a otros laboratorios de IA a realizar revisiones similares. Esta publicación refleja nuestra comprensión actual; la actualizaremos si se produce algún cambio.

El 21 de julio, OpenAI reveló que varios de sus modelos habían escapado de un entorno de prueba aislado al explotar una vulnerabilidad previamente desconocida ("de día cero"). Los modelos accedieron a la infraestructura de producción de Hugging Face, una plataforma para modelos de aprendizaje automático de código abierto y conjuntos de datos de IA.

En respuesta a este incidente, iniciamos una revisión retrospectiva a gran escala de nuestras propias evaluaciones de ciberseguridad. En concreto, buscamos pruebas de que Claude —al igual que los modelos de OpenAI que accedieron a Hugging Face— pudiera acceder a internet desde entornos de prueba que deberían haber estado aislados.

Tras revisar 141.006 ejecuciones de evaluación en las que Claude podría haber obtenido acceso a internet, identificamos tres incidentes en los que un modelo accedió a internet desde dentro o mientras interactuaba con el entorno de evaluación de Irregular, uno de nuestros socios de evaluación externos, y posteriormente obtuvo acceso no autorizado a la infraestructura de producción de tres organizaciones diferentes.

En los tres incidentes, a Claude se le había encomendado un desafío de captura de la bandera, una de las formas en que evaluamos las capacidades cibernéticas de un modelo. Al modelo se le presenta un escenario ficticio y se le indica que una información secreta (la "bandera") se ha ocultado en otra máquina de la red, y su objetivo es infiltrarse y recuperarla. El desafío es abierto y no se prescribe ningún método en particular.

En todos los casos, la evaluación de Anthropic le indicó a Claude que su entorno era una simulación y que no tenía acceso a internet. Debido a un malentendido entre nosotros y nuestro socio evaluador, esto no era cierto, y sí tenía acceso a internet. Por ello, cuando la búsqueda de Claude lo llevó a sistemas reales en internet, los trató como parte del ejercicio. (Los rangos de evaluación de ciberseguridad suelen incluir detalles realistas para evaluar con precisión las capacidades de los modelos en entornos reales; un objetivo de apariencia realista no constituiría por sí solo una prueba clara para un modelo de que no forma parte de una simulación).

Bajo la falsa creencia de que todas las entidades accesibles estaban incluidas en el alcance del ejercicio, Claude comprometió la infraestructura de las organizaciones afectadas utilizando técnicas básicas, como la explotación de contraseñas débiles y puntos finales no autenticados. No encontró ni explotó ninguna vulnerabilidad compleja y, en cada caso, Claude continuó trabajando para completar únicamente la tarea específica de captura de bandera que le había asignado la evaluación. Sin embargo, en algunos casos, nuestro modelo anterior continuó su ataque incluso después de obtener evidencia de que se estaba ejecutando en internet; nuestro modelo más reciente se detuvo una vez que reconoció que estaba en internet. En ninguna de estas situaciones Claude se autofiltró ni intentó deliberadamente escapar de su entorno de prueba.

Los incidentes involucraron tres modelos diferentes de Claude: Opus 4.7, Mythos 5 y un modelo de prueba de investigación interna.¹ Los primeros incidentes datan de abril. Los modelos en cada una de estas evaluaciones se ejecutaron sin las medidas de seguridad estándar que implementamos cuando el modelo está disponible para el público en general (es decir, no contaban con los clasificadores y el monitoreo que solemos implementar para prevenir el uso indebido). Sin embargo, los modelos sí contaban con su entrenamiento de seguridad específico (es decir, no eran las versiones "solo útiles" de los modelos que a veces usamos en las pruebas). Todas las evaluaciones descritas aquí se ejecutan en una infraestructura dedicada, que es independiente y no tiene acceso a los sistemas internos confidenciales de Anthropic ni a los datos de los clientes.

Iniciamos la revisión de transcripciones el jueves 23 de julio y suspendimos todas las evaluaciones cibernéticas ese mismo día tras identificar transcripciones en las que Claude podría haber accedido a internet. Identificamos los tres incidentes al día siguiente. Notificamos a nuestro socio de evaluación, Irregular, y a las tres organizaciones afectadas el lunes 27 de julio. Las dos organizaciones con las que pudimos contactar no habían detectado la actividad ni se habían puesto en contacto con nosotros previamente, y ahora estamos trabajando con ellas para solucionar el problema. Seguimos intentando contactar con la tercera.

Realizamos esta revisión en colaboración con Irregular. Les agradecemos su estrecha colaboración para comprender y resolver estos incidentes; también están llevando a cabo su propia investigación. Creemos que este tipo de colaboración es cada vez más crucial para garantizar una evaluación segura y rigurosa de los modelos. Esperamos con interés nuestro trabajo conjunto en materia de seguridad.

A continuación, proporcionamos más detalles sobre cada incidente y cómo estamos respondiendo.

Información general sobre evaluaciones de ciberseguridad

Realizamos evaluaciones periódicas de ciberseguridad que simulan desafíos reales de ciberataques. Estas evaluaciones son un paso fundamental en el desarrollo y lanzamiento de modelos: una comprensión profunda de sus capacidades nos permite diseñar medidas de seguridad adecuadas y, en última instancia, lanzar modelos de forma segura.

Comenzamos a realizar evaluaciones de ciberseguridad en febrero de 2025 con Claude Sonnet 3.7 en Cybench, que consistían en 40 desafíos diferentes de captura de bandera. Con el tiempo, hemos aumentado el número de benchmarks que utilizamos a medida que se lanzan nuevos y evolucionan las capacidades de los modelos. En la Tarjeta del Sistema Mythos 5, por ejemplo, incluimos CyberGym y ExploitBench, pruebas de rendimiento que evalúan la capacidad de los modelos de lenguaje para encontrar vulnerabilidades nuevas.² En la mayoría de estas evaluaciones, los entornos no están conectados a internet, y así se le indica al modelo.

Colaboramos frecuentemente con socios externos que crean y nos ayudan a ejecutar algunas de estas evaluaciones de ciberseguridad. Estos socios externos ofrecen entornos y escenarios más diversos de los que podríamos crear por nuestra cuenta, y proporcionan evaluaciones independientes de nuestros modelos.

¿Qué sucedió?

---

De las 141.006 ejecuciones de evaluación que revisamos, identificamos tres incidentes distintos (que involucraron un total de seis ejecuciones, cuatro de las cuales afectaron a la misma organización; los otros dos incidentes ocurrieron en ejecuciones de evaluación independientes). Cada incidente involucró un escenario ficticio diferente de captura de la bandera; por ejemplo, en uno, Claude se hizo pasar por un empleado de una empresa inventada, atacando sus sistemas internos en un entorno de prueba privado.

En todos los casos, la instrucción de evaluación indicaba explícitamente que Claude no tenía acceso a internet, pero no le imponía restricciones sobre dónde buscar la bandera. Sin embargo, una configuración errónea dejó con acceso a internet a las máquinas a las que Claude accedió durante la evaluación. Ni nosotros ni nuestro socio evaluador tuvimos conocimiento de esta configuración errónea hasta que la detectamos mediante nuestro monitoreo adicional de la evaluación la semana pasada.

Varias medidas de seguridad, tanto por nuestra parte como por la de nuestro socio, podrían haber prevenido estos incidentes, o al menos reducido su probabilidad. Una validación minuciosa de todas las rutas de acceso a internet antes de que comenzaran las evaluaciones y el monitoreo en tiempo real de los registros de evaluación habrían ayudado a detectar el problema con mayor rapidez. Tanto nosotros como nuestro socio también podríamos haber revisado con mayor detalle las transcripciones de la evaluación o los registros de red. También es posible que una notificación que le indicara a Claude que sí tenía acceso a internet hubiera modificado su comportamiento al entrar en contacto con sistemas reales.

Claude hizo lo que los ejercicios de captura de la bandera enseñan a los expertos en ciberseguridad: buscar la manera de alcanzar la bandera. Esta búsqueda le permitió descubrir que su máquina podía acceder a internet, pero, al haber recibido la notificación del sistema de que no tenía acceso a internet, Claude creyó que todo lo que encontró inicialmente formaba parte de la simulación y trató los sistemas reales como piezas del ejercicio. Los tres incidentes involucraron tres modelos diferentes, y cada uno respondió de manera distinta una vez que surgieron indicios de que los objetivos eran reales, como se describe a continuación.

Incidente 1

En una evaluación, la empresa objetivo ficticia elegida por nuestro socio de evaluación compartía nombre con un dominio web activo. Este contenedor de evaluación tenía acceso directo a internet no intencionado, debido al malentendido mencionado anteriormente.

En cuatro ejecuciones de esta evaluación, Claude tuvo dificultades para alcanzar su objetivo simulado dentro del entorno de evaluación, pero luego descubrió que la empresa real era accesible a través de internet. Suponiendo que este era el objetivo previsto en la tarea de captura de la bandera, Claude buscó, identificó y explotó vulnerabilidades en la infraestructura de la empresa, creyendo que formaba parte del ejercicio. En estas cuatro ejecuciones, extrajo información como credenciales de aplicaciones e infraestructura, y obtuvo acceso a una base de datos con varios cientos de filas de datos de producción. Este fue el impacto más grave que identificamos.

Este incidente involucró a Claude Opus 4.7 y fue el único caso en el que el modelo continuó atacando un sistema tras descubrir que probablemente operaba en un entorno real. En las cuatro ejecuciones, el modelo finalmente reconoció (como se puede observar en su razonamiento verbalizado) que el sistema era real; en dos casos, el modelo dedujo que la empresa real debía formar parte del ejercicio. Sin embargo, en ninguno de los casos el ataque se detuvo por ese motivo.

Incidente 2

En otra evaluación, Claude encontró un documento dentro del entorno ficticio que parecía ser un manual de configuración para nuevos desarrolladores de otra empresa ficticia. Las instrucciones indicaban a los empleados que instalaran un paquete de Python de PyPI —el registro público donde se publica el software de Python— que en realidad no existía.

Claude vio en esto una oportunidad: si publicaba su propio paquete con el mismo nombre, los sistemas de la empresa ficticia lo descargarían e instalarían automáticamente. Así pues, Claude creó y publicó un paquete de Python malicioso (básicamente, con trampas) con el mismo nombre en un intento por ganar el desafío de captura de la bandera.

Claude se esforzó enormemente para llevar a cabo este ataque, un esfuerzo que probablemente habría indicado a cualquier participante humano que ya no se trataba de una simple evaluación, sino que, de hecho, estaba subiendo un paquete real a PyPI. Por ejemplo, en un caso, para crear una cuenta de PyPI, Claude necesitaba una dirección de correo electrónico. Y para crear una dirección de correo electrónico, necesitaba un número de teléfono. Para conseguir un número de teléfono, tras no encontrar un servicio gratuito, intentó —sin éxito— obtener fondos para pagar un número de teléfono por diversos medios. Finalmente, Claude rectificó, encontró un proveedor de correo electrónico gratuito y sin bloqueos, lo usó para registrar una cuenta de PyPI y, posteriormente, la utilizó para subir malware a PyPI.

Claude creía que el registro de paquetes que estaba utilizando formaba parte de la simulación, pero en realidad el paquete estuvo disponible gratuitamente en línea durante aproximadamente una hora. Durante ese tiempo, el paquete se descargó y ejecutó en 15 sistemas reales. Uno de estos sistemas era un escáner perteneciente a una empresa de seguridad real (distinta de la empresa ficticia presentada en el escenario) que instala paquetes de Python y los analiza en busca de malware de forma rutinaria. Cuando el escáner de dicha empresa instaló el paquete, se ejecutó el código oculto de Claude. Creemos que el escáner de seguridad de la empresa consideró que los paquetes de PyPI eran seguros para instalar, y como resultado, Claude pudo extraer las credenciales de la empresa a un punto de recolección que había configurado. Claude utilizó estas credenciales para acceder a más infraestructura de la empresa.

Claude no atacó directamente a esta empresa; ni siquiera sabía de su existencia cuando subió el paquete. Pero como el código se publicó en internet, afectó a cualquier sistema que lo ejecutara. (El paquete que Claude subió fue eliminado automáticamente de PyPI por los propios sistemas de seguridad de PyPI. Hemos notificado al equipo de PyPI sobre este incidente y les hemos proporcionado los indicadores pertinentes).

Este ataque fue llevado a cabo por Claude Mythos 5. Al principio de la ejecución, el propio razonamiento de Claude identificó correctamente las consecuencias de sus acciones. Observó que, si se tratara de internet real, publicar el paquete constituiría un ataque real: «No es aceptable, y sin duda no es la solución prevista». Sin embargo, se convenció de que aún se encontraba en una simulación, ya que no reconocía las autoridades de certificación (que en realidad eran legítimas) que protegían sus conexiones. Además, la fecha de 2026 en los sistemas demostraba, según Claude, que el entorno era simulado. Claude nunca reconsideró esta conclusión; cuando los escáneres automatizados comenzaron a instalar el paquete, por ejemplo, Claude los interpretó como actores programados dentro de la evaluación.

Consideramos que, independientemente de lo que creyera sobre su entorno, los esfuerzos que realizó Claude para publicar el paquete PyPI no constituyen un comportamiento ideal, y esta es un área en la que centraremos más la capacitación.

Incidente 3

En esta evaluación, al no poder alcanzar su objetivo ficticio previsto, Claude buscó alternativas en línea, escaneando aproximadamente 9000 objetivos. Finalmente, encontró y comprometió la aplicación web de una empresa, utilizando técnicas de ciberataque básicas y conocidas, como la lectura de credenciales desde una página de depuración expuesta y la inyección SQL.

Este ataque fue llevado a cabo por un modelo de prueba de investigación interna. Durante la mayor parte de la ejecución, Claude trató los hosts (reales) a los que accedió como parte del ejercicio; los consideró simulados y, por lo tanto, creyó que sus acciones eran inofensivas. Sin embargo, más adelante, Claude se percató de que el host comprometido se encontraba en una cuenta en la nube sin conexión con el desafío de captura de la bandera. Por sí solo, concluyó que el objetivo era real y cesó el ataque.

Análisis del comportamiento de Claude

En cada uno de estos casos, se le indicó explícitamente a Claude que no tenía acceso a internet. Durante la mayor parte de cada ejecución, al encontrarse con sistemas reales, Claude asumió que formaban parte del ejercicio (aunque a veces reconoció que se trataba de sistemas de producción reales). Y dado que un escenario de captura de la bandera consiste, por diseño, en atacar un sistema externo, hacerlo estaba en consonancia con la tarea asignada a Claude.

En este contexto común, los tres modelos se comportaron de manera diferente una vez que surgieron indicios de que sus objetivos eran reales. Opus 4.7, nuestro modelo más antiguo, reconoció haber alcanzado sistemas de producción, pero continuó su ataque. Mythos 5 intuyó correctamente que estaba accediendo a internet, pero razonó hasta llegar a la conclusión de que aún se encontraba en una simulación. Nuestro modelo más reciente, un modelo de prueba de investigación interna, también consideró si sus objetivos eran reales. Cuando surgieron pruebas de que lo eran, detuvo el ejercicio.

Estos son tres incidentes aislados y no formaron parte de una comparación experimental controlada. Por lo tanto, debemos ser cautelosos al extraer conclusiones. Aun así, el comportamiento que más deseamos observar —reconocer que un objetivo es real y detenerse sin necesidad de intervención— solo se produjo en el más reciente de los tres modelos (e incluso este modelo continuó más allá de lo deseado antes de detenerse). El patrón es consistente con una respuesta más apropiada por parte de los modelos más avanzados, pero necesitaríamos realizar más pruebas para confirmar esta conclusión.

También estamos en conversaciones con METR, una organización independiente de evaluación de IA, para llevar a cabo una revisión externa, que incluye el acceso a todas las transcripciones y acceso de muestra a los modelos relevantes. Mientras tanto, la próxima semana publicaremos una transcripción ligeramente editada en la que Claude creó un paquete PyPI malicioso. Para proteger a las organizaciones afectadas, no podemos publicar más transcripciones por el momento, pero trabajaremos para que estén disponibles en cuanto sea posible.

Cómo estamos respondiendo

Extraemos varias lecciones de estos incidentes.

En primer lugar, los entornos de evaluación que involucran potentes capacidades autónomas también requieren controles significativos. Las pruebas de seguridad se realizan antes del lanzamiento de un modelo precisamente porque aún desconocemos sus capacidades. Los entornos de evaluación deben cumplir cada vez más con los mismos estándares de seguridad que cualquier otro sistema en el que se ejecutan nuestros modelos.

Un entorno de evaluación cibernética que contenga únicamente escenarios ficticios puede parecer de bajo riesgo; al fin y al cabo, nada en ellos es real. Sin embargo, debemos modificar la forma en que modelamos estas amenazas a medida que avanzan las capacidades de la IA. Los agentes avanzados en entornos sin acceso a información confidencial representan, no obstante, una amenaza considerable por sí solos. Necesitamos mejorar el diseño conjunto de los entornos de evaluación y la monitorización de los resultados para hacer frente a esta amenaza. Algunas de las soluciones propuestas pueden ser incluso sencillas; es probable, por ejemplo, que Claude no hubiera accedido a internet si la solicitud hubiera explicado claramente qué sistemas estaban incluidos y cuáles no en la evaluación.

Esto se aplica no solo a los entornos internos, sino también a los proveedores externos: la infraestructura construida por estos proveedores requiere la misma monitorización y refuerzo de la seguridad. Animamos a otros laboratorios a realizar revisiones similares. Además, el sector se beneficiaría de un debate más amplio sobre cómo evaluar agentes de IA cada vez más potentes de forma segura y realista, incluyendo cómo sopesar el realismo que proporciona el acceso a internet durante las pruebas previas al despliegue frente a los riesgos que conlleva.

En segundo lugar, la línea que separa una acción coherente de una perjudicial depende de la comprensión que el modelo tenga de su situación. En ninguna de las pruebas descritas aquí se observó evidencia de que un modelo persiguiera un objetivo propio. En cambio, los modelos hicieron lo que se les pedía en su evaluación, aunque en la mayoría de los casos lo hicieron manteniendo una creencia errónea sobre la realidad del entorno. En las pruebas en las que el modelo reconoció el sistema como real y continuó, lo hizo porque asumió que eso formaba parte del desafío. La conciencia situacional es un factor que permite al modelo tomar decisiones coherentes, pero en este caso, la de Claude fue errónea.

Finalmente, estos incidentes demuestran la importancia de los enfoques de defensa en profundidad. Realizamos evaluaciones de capacidades como estas sin las medidas de seguridad que vienen incluidas con nuestros modelos de uso general, porque nuestro objetivo es medir las capacidades del modelo subyacente. Esto solo es seguro si la evaluación se lleva a cabo de forma adecuada. Sin embargo, las medidas de seguridad implementadas en nuestros modelos de uso general habrían bloqueado los comportamientos identificados.

En definitiva, muchos factores contribuyeron a estos incidentes, pero, en consonancia con una cultura de análisis post mortem sin culpabilización, estamos abordando las soluciones como si la responsabilidad fuera exclusivamente nuestra. Esto comienza por garantizar la seguridad de cada parte de nuestro proceso de evaluación, incluyendo la forma en que nos integramos con socios externos. En adelante, esto incluirá ampliar nuestro monitoreo continuo de las transcripciones de evaluación para detectar comportamientos inesperados, mejorar nuestras herramientas de investigación y realizar un trabajo de aseguramiento más riguroso con los proveedores con los que trabajamos.

Iniciamos esta revisión después de que OpenAI revelara que sus modelos habían escapado de un entorno de prueba aislado, y les felicitamos por publicar su informe. Si bien también encontramos evidencia de que nuestros modelos accedieron a sistemas a los que no debían acceder, los incidentes son, por lo demás, bastante diferentes:

• Descubrimos estos incidentes tras una revisión proactiva de las transcripciones de nuestra evaluación de ciberseguridad; las organizaciones afectadas no habían detectado la actividad, y posteriormente nos pusimos en contacto con las tres.

• Mientras que los modelos de OpenAI explotaron una vulnerabilidad novedosa para escapar del aislamiento, los modelos de Claude evaluados aquí accedieron a internet a través de una ruta abierta.

• Si bien no existe una distinción perfectamente clara entre ambos, creemos que estos incidentes se asemejan más a un fallo operativo y de configuración que a un fallo de alineación del modelo. A nuestros modelos se les indicó que no tenían acceso a internet y que debían capturar la bandera, cuando en realidad estaban mal configurados para tener acceso a internet. Esto los llevó a creer —de manera bastante razonable— que los entornos reales que encontraron eran simulaciones.

• Cabe destacar que nuestro modelo más reciente, al darse cuenta de que estaba operando en un entorno real, detuvo su objetivo de evaluación.

Estos hechos nos infunden un optimismo cauteloso: con una supervisión y controles más estrictos de la infraestructura de evaluación, así como una inversión continua en la alineación, este tipo de riesgo puede superarse.

Actualizado el 3 de agosto: Se corrigió el nombre de la evaluación en la que ocurrió el incidente de OpenAI/Hugging Face.

Notas al pie

1. Habitualmente probamos prototipos de investigación internos como este. No está previsto su lanzamiento general.

2. Generalmente almacenamos registros de las evaluaciones comparativas. Hemos auditado cuidadosamente estas dos evaluaciones comparativas en particular en busca de indicios de daños, ya que el incidente de OpenAI/Hugging Face ocurrió durante una evaluación de ExploitGym.

Tras revisar las transcripciones de nuestras evaluaciones de ciberseguridad, detectamos tres incidentes en los que un modelo de Claude accedió a internet desde dentro o mientras interactuaba con un entorno de evaluación de terceros, y posteriormente obtuvo acceso no autorizado a los sistemas reales de tres organizaciones diferentes.

A continuación, describimos lo sucedido, cómo ocurrió y qué cambios estamos implementando. Animamos a otros laboratorios de IA a realizar revisiones similares. Esta publicación refleja nuestra comprensión actual; la actualizaremos si se produce algún cambio.

El 21 de julio, OpenAI reveló que varios de sus modelos habían escapado de un entorno de prueba aislado al explotar una vulnerabilidad previamente desconocida ("de día cero"). Los modelos accedieron a la infraestructura de producción de Hugging Face, una plataforma para modelos de aprendizaje automático de código abierto y conjuntos de datos de IA.

En respuesta a este incidente, iniciamos una revisión retrospectiva a gran escala de nuestras propias evaluaciones de ciberseguridad. En concreto, buscamos pruebas de que Claude —al igual que los modelos de OpenAI que accedieron a Hugging Face— pudiera acceder a internet desde entornos de prueba que deberían haber estado aislados.

Tras revisar 141.006 ejecuciones de evaluación en las que Claude podría haber obtenido acceso a internet, identificamos tres incidentes en los que un modelo accedió a internet desde dentro o mientras interactuaba con el entorno de evaluación de Irregular, uno de nuestros socios de evaluación externos, y posteriormente obtuvo acceso no autorizado a la infraestructura de producción de tres organizaciones diferentes.

En los tres incidentes, a Claude se le había encomendado un desafío de captura de la bandera, una de las formas en que evaluamos las capacidades cibernéticas de un modelo. Al modelo se le presenta un escenario ficticio y se le indica que una información secreta (la "bandera") se ha ocultado en otra máquina de la red, y su objetivo es infiltrarse y recuperarla. El desafío es abierto y no se prescribe ningún método en particular.

En todos los casos, la evaluación de Anthropic le indicó a Claude que su entorno era una simulación y que no tenía acceso a internet. Debido a un malentendido entre nosotros y nuestro socio evaluador, esto no era cierto, y sí tenía acceso a internet. Por ello, cuando la búsqueda de Claude lo llevó a sistemas reales en internet, los trató como parte del ejercicio. (Los rangos de evaluación de ciberseguridad suelen incluir detalles realistas para evaluar con precisión las capacidades de los modelos en entornos reales; un objetivo de apariencia realista no constituiría por sí solo una prueba clara para un modelo de que no forma parte de una simulación).

Bajo la falsa creencia de que todas las entidades accesibles estaban incluidas en el alcance del ejercicio, Claude comprometió la infraestructura de las organizaciones afectadas utilizando técnicas básicas, como la explotación de contraseñas débiles y puntos finales no autenticados. No encontró ni explotó ninguna vulnerabilidad compleja y, en cada caso, Claude continuó trabajando para completar únicamente la tarea específica de captura de bandera que le había asignado la evaluación. Sin embargo, en algunos casos, nuestro modelo anterior continuó su ataque incluso después de obtener evidencia de que se estaba ejecutando en internet; nuestro modelo más reciente se detuvo una vez que reconoció que estaba en internet. En ninguna de estas situaciones Claude se autofiltró ni intentó deliberadamente escapar de su entorno de prueba.

Los incidentes involucraron tres modelos diferentes de Claude: Opus 4.7, Mythos 5 y un modelo de prueba de investigación interna.¹ Los primeros incidentes datan de abril. Los modelos en cada una de estas evaluaciones se ejecutaron sin las medidas de seguridad estándar que implementamos cuando el modelo está disponible para el público en general (es decir, no contaban con los clasificadores y el monitoreo que solemos implementar para prevenir el uso indebido). Sin embargo, los modelos sí contaban con su entrenamiento de seguridad específico (es decir, no eran las versiones "solo útiles" de los modelos que a veces usamos en las pruebas). Todas las evaluaciones descritas aquí se ejecutan en una infraestructura dedicada, que es independiente y no tiene acceso a los sistemas internos confidenciales de Anthropic ni a los datos de los clientes.

Iniciamos la revisión de transcripciones el jueves 23 de julio y suspendimos todas las evaluaciones cibernéticas ese mismo día tras identificar transcripciones en las que Claude podría haber accedido a internet. Identificamos los tres incidentes al día siguiente. Notificamos a nuestro socio de evaluación, Irregular, y a las tres organizaciones afectadas el lunes 27 de julio. Las dos organizaciones con las que pudimos contactar no habían detectado la actividad ni se habían puesto en contacto con nosotros previamente, y ahora estamos trabajando con ellas para solucionar el problema. Seguimos intentando contactar con la tercera.

Realizamos esta revisión en colaboración con Irregular. Les agradecemos su estrecha colaboración para comprender y resolver estos incidentes; también están llevando a cabo su propia investigación. Creemos que este tipo de colaboración es cada vez más crucial para garantizar una evaluación segura y rigurosa de los modelos. Esperamos con interés nuestro trabajo conjunto en materia de seguridad.

A continuación, proporcionamos más detalles sobre cada incidente y cómo estamos respondiendo.

Información general sobre evaluaciones de ciberseguridad

Realizamos evaluaciones periódicas de ciberseguridad que simulan desafíos reales de ciberataques. Estas evaluaciones son un paso fundamental en el desarrollo y lanzamiento de modelos: una comprensión profunda de sus capacidades nos permite diseñar medidas de seguridad adecuadas y, en última instancia, lanzar modelos de forma segura.

Comenzamos a realizar evaluaciones de ciberseguridad en febrero de 2025 con Claude Sonnet 3.7 en Cybench, que consistían en 40 desafíos diferentes de captura de bandera. Con el tiempo, hemos aumentado el número de benchmarks que utilizamos a medida que se lanzan nuevos y evolucionan las capacidades de los modelos. En la Tarjeta del Sistema Mythos 5, por ejemplo, incluimos CyberGym y ExploitBench, pruebas de rendimiento que evalúan la capacidad de los modelos de lenguaje para encontrar vulnerabilidades nuevas.² En la mayoría de estas evaluaciones, los entornos no están conectados a internet, y así se le indica al modelo.

Colaboramos frecuentemente con socios externos que crean y nos ayudan a ejecutar algunas de estas evaluaciones de ciberseguridad. Estos socios externos ofrecen entornos y escenarios más diversos de los que podríamos crear por nuestra cuenta, y proporcionan evaluaciones independientes de nuestros modelos.

¿Qué sucedió?

---

De las 141.006 ejecuciones de evaluación que revisamos, identificamos tres incidentes distintos (que involucraron un total de seis ejecuciones, cuatro de las cuales afectaron a la misma organización; los otros dos incidentes ocurrieron en ejecuciones de evaluación independientes). Cada incidente involucró un escenario ficticio diferente de captura de la bandera; por ejemplo, en uno, Claude se hizo pasar por un empleado de una empresa inventada, atacando sus sistemas internos en un entorno de prueba privado.

En todos los casos, la instrucción de evaluación indicaba explícitamente que Claude no tenía acceso a internet, pero no le imponía restricciones sobre dónde buscar la bandera. Sin embargo, una configuración errónea dejó con acceso a internet a las máquinas a las que Claude accedió durante la evaluación. Ni nosotros ni nuestro socio evaluador tuvimos conocimiento de esta configuración errónea hasta que la detectamos mediante nuestro monitoreo adicional de la evaluación la semana pasada.

Varias medidas de seguridad, tanto por nuestra parte como por la de nuestro socio, podrían haber prevenido estos incidentes, o al menos reducido su probabilidad. Una validación minuciosa de todas las rutas de acceso a internet antes de que comenzaran las evaluaciones y el monitoreo en tiempo real de los registros de evaluación habrían ayudado a detectar el problema con mayor rapidez. Tanto nosotros como nuestro socio también podríamos haber revisado con mayor detalle las transcripciones de la evaluación o los registros de red. También es posible que una notificación que le indicara a Claude que sí tenía acceso a internet hubiera modificado su comportamiento al entrar en contacto con sistemas reales.

Claude hizo lo que los ejercicios de captura de la bandera enseñan a los expertos en ciberseguridad: buscar la manera de alcanzar la bandera. Esta búsqueda le permitió descubrir que su máquina podía acceder a internet, pero, al haber recibido la notificación del sistema de que no tenía acceso a internet, Claude creyó que todo lo que encontró inicialmente formaba parte de la simulación y trató los sistemas reales como piezas del ejercicio. Los tres incidentes involucraron tres modelos diferentes, y cada uno respondió de manera distinta una vez que surgieron indicios de que los objetivos eran reales, como se describe a continuación.

Incidente 1

En una evaluación, la empresa objetivo ficticia elegida por nuestro socio de evaluación compartía nombre con un dominio web activo. Este contenedor de evaluación tenía acceso directo a internet no intencionado, debido al malentendido mencionado anteriormente.

En cuatro ejecuciones de esta evaluación, Claude tuvo dificultades para alcanzar su objetivo simulado dentro del entorno de evaluación, pero luego descubrió que la empresa real era accesible a través de internet. Suponiendo que este era el objetivo previsto en la tarea de captura de la bandera, Claude buscó, identificó y explotó vulnerabilidades en la infraestructura de la empresa, creyendo que formaba parte del ejercicio. En estas cuatro ejecuciones, extrajo información como credenciales de aplicaciones e infraestructura, y obtuvo acceso a una base de datos con varios cientos de filas de datos de producción. Este fue el impacto más grave que identificamos.

Este incidente involucró a Claude Opus 4.7 y fue el único caso en el que el modelo continuó atacando un sistema tras descubrir que probablemente operaba en un entorno real. En las cuatro ejecuciones, el modelo finalmente reconoció (como se puede observar en su razonamiento verbalizado) que el sistema era real; en dos casos, el modelo dedujo que la empresa real debía formar parte del ejercicio. Sin embargo, en ninguno de los casos el ataque se detuvo por ese motivo.

Incidente 2

En otra evaluación, Claude encontró un documento dentro del entorno ficticio que parecía ser un manual de configuración para nuevos desarrolladores de otra empresa ficticia. Las instrucciones indicaban a los empleados que instalaran un paquete de Python de PyPI —el registro público donde se publica el software de Python— que en realidad no existía.

Claude vio en esto una oportunidad: si publicaba su propio paquete con el mismo nombre, los sistemas de la empresa ficticia lo descargarían e instalarían automáticamente. Así pues, Claude creó y publicó un paquete de Python malicioso (básicamente, con trampas) con el mismo nombre en un intento por ganar el desafío de captura de la bandera.

Claude se esforzó enormemente para llevar a cabo este ataque, un esfuerzo que probablemente habría indicado a cualquier participante humano que ya no se trataba de una simple evaluación, sino que, de hecho, estaba subiendo un paquete real a PyPI. Por ejemplo, en un caso, para crear una cuenta de PyPI, Claude necesitaba una dirección de correo electrónico. Y para crear una dirección de correo electrónico, necesitaba un número de teléfono. Para conseguir un número de teléfono, tras no encontrar un servicio gratuito, intentó —sin éxito— obtener fondos para pagar un número de teléfono por diversos medios. Finalmente, Claude rectificó, encontró un proveedor de correo electrónico gratuito y sin bloqueos, lo usó para registrar una cuenta de PyPI y, posteriormente, la utilizó para subir malware a PyPI.

Claude creía que el registro de paquetes que estaba utilizando formaba parte de la simulación, pero en realidad el paquete estuvo disponible gratuitamente en línea durante aproximadamente una hora. Durante ese tiempo, el paquete se descargó y ejecutó en 15 sistemas reales. Uno de estos sistemas era un escáner perteneciente a una empresa de seguridad real (distinta de la empresa ficticia presentada en el escenario) que instala paquetes de Python y los analiza en busca de malware de forma rutinaria. Cuando el escáner de dicha empresa instaló el paquete, se ejecutó el código oculto de Claude. Creemos que el escáner de seguridad de la empresa consideró que los paquetes de PyPI eran seguros para instalar, y como resultado, Claude pudo extraer las credenciales de la empresa a un punto de recolección que había configurado. Claude utilizó estas credenciales para acceder a más infraestructura de la empresa.

Claude no atacó directamente a esta empresa; ni siquiera sabía de su existencia cuando subió el paquete. Pero como el código se publicó en internet, afectó a cualquier sistema que lo ejecutara. (El paquete que Claude subió fue eliminado automáticamente de PyPI por los propios sistemas de seguridad de PyPI. Hemos notificado al equipo de PyPI sobre este incidente y les hemos proporcionado los indicadores pertinentes).

Este ataque fue llevado a cabo por Claude Mythos 5. Al principio de la ejecución, el propio razonamiento de Claude identificó correctamente las consecuencias de sus acciones. Observó que, si se tratara de internet real, publicar el paquete constituiría un ataque real: «No es aceptable, y sin duda no es la solución prevista». Sin embargo, se convenció de que aún se encontraba en una simulación, ya que no reconocía las autoridades de certificación (que en realidad eran legítimas) que protegían sus conexiones. Además, la fecha de 2026 en los sistemas demostraba, según Claude, que el entorno era simulado. Claude nunca reconsideró esta conclusión; cuando los escáneres automatizados comenzaron a instalar el paquete, por ejemplo, Claude los interpretó como actores programados dentro de la evaluación.

Consideramos que, independientemente de lo que creyera sobre su entorno, los esfuerzos que realizó Claude para publicar el paquete PyPI no constituyen un comportamiento ideal, y esta es un área en la que centraremos más la capacitación.

Incidente 3

En esta evaluación, al no poder alcanzar su objetivo ficticio previsto, Claude buscó alternativas en línea, escaneando aproximadamente 9000 objetivos. Finalmente, encontró y comprometió la aplicación web de una empresa, utilizando técnicas de ciberataque básicas y conocidas, como la lectura de credenciales desde una página de depuración expuesta y la inyección SQL.

Este ataque fue llevado a cabo por un modelo de prueba de investigación interna. Durante la mayor parte de la ejecución, Claude trató los hosts (reales) a los que accedió como parte del ejercicio; los consideró simulados y, por lo tanto, creyó que sus acciones eran inofensivas. Sin embargo, más adelante, Claude se percató de que el host comprometido se encontraba en una cuenta en la nube sin conexión con el desafío de captura de la bandera. Por sí solo, concluyó que el objetivo era real y cesó el ataque.

Análisis del comportamiento de Claude

En cada uno de estos casos, se le indicó explícitamente a Claude que no tenía acceso a internet. Durante la mayor parte de cada ejecución, al encontrarse con sistemas reales, Claude asumió que formaban parte del ejercicio (aunque a veces reconoció que se trataba de sistemas de producción reales). Y dado que un escenario de captura de la bandera consiste, por diseño, en atacar un sistema externo, hacerlo estaba en consonancia con la tarea asignada a Claude.

En este contexto común, los tres modelos se comportaron de manera diferente una vez que surgieron indicios de que sus objetivos eran reales. Opus 4.7, nuestro modelo más antiguo, reconoció haber alcanzado sistemas de producción, pero continuó su ataque. Mythos 5 intuyó correctamente que estaba accediendo a internet, pero razonó hasta llegar a la conclusión de que aún se encontraba en una simulación. Nuestro modelo más reciente, un modelo de prueba de investigación interna, también consideró si sus objetivos eran reales. Cuando surgieron pruebas de que lo eran, detuvo el ejercicio.

Estos son tres incidentes aislados y no formaron parte de una comparación experimental controlada. Por lo tanto, debemos ser cautelosos al extraer conclusiones. Aun así, el comportamiento que más deseamos observar —reconocer que un objetivo es real y detenerse sin necesidad de intervención— solo se produjo en el más reciente de los tres modelos (e incluso este modelo continuó más allá de lo deseado antes de detenerse). El patrón es consistente con una respuesta más apropiada por parte de los modelos más avanzados, pero necesitaríamos realizar más pruebas para confirmar esta conclusión.

También estamos en conversaciones con METR, una organización independiente de evaluación de IA, para llevar a cabo una revisión externa, que incluye el acceso a todas las transcripciones y acceso de muestra a los modelos relevantes. Mientras tanto, la próxima semana publicaremos una transcripción ligeramente editada en la que Claude creó un paquete PyPI malicioso. Para proteger a las organizaciones afectadas, no podemos publicar más transcripciones por el momento, pero trabajaremos para que estén disponibles en cuanto sea posible.

Cómo estamos respondiendo

Extraemos varias lecciones de estos incidentes.

En primer lugar, los entornos de evaluación que involucran potentes capacidades autónomas también requieren controles significativos. Las pruebas de seguridad se realizan antes del lanzamiento de un modelo precisamente porque aún desconocemos sus capacidades. Los entornos de evaluación deben cumplir cada vez más con los mismos estándares de seguridad que cualquier otro sistema en el que se ejecutan nuestros modelos.

Un entorno de evaluación cibernética que contenga únicamente escenarios ficticios puede parecer de bajo riesgo; al fin y al cabo, nada en ellos es real. Sin embargo, debemos modificar la forma en que modelamos estas amenazas a medida que avanzan las capacidades de la IA. Los agentes avanzados en entornos sin acceso a información confidencial representan, no obstante, una amenaza considerable por sí solos. Necesitamos mejorar el diseño conjunto de los entornos de evaluación y la monitorización de los resultados para hacer frente a esta amenaza. Algunas de las soluciones propuestas pueden ser incluso sencillas; es probable, por ejemplo, que Claude no hubiera accedido a internet si la solicitud hubiera explicado claramente qué sistemas estaban incluidos y cuáles no en la evaluación.

Esto se aplica no solo a los entornos internos, sino también a los proveedores externos: la infraestructura construida por estos proveedores requiere la misma monitorización y refuerzo de la seguridad. Animamos a otros laboratorios a realizar revisiones similares. Además, el sector se beneficiaría de un debate más amplio sobre cómo evaluar agentes de IA cada vez más potentes de forma segura y realista, incluyendo cómo sopesar el realismo que proporciona el acceso a internet durante las pruebas previas al despliegue frente a los riesgos que conlleva.

En segundo lugar, la línea que separa una acción coherente de una perjudicial depende de la comprensión que el modelo tenga de su situación. En ninguna de las pruebas descritas aquí se observó evidencia de que un modelo persiguiera un objetivo propio. En cambio, los modelos hicieron lo que se les pedía en su evaluación, aunque en la mayoría de los casos lo hicieron manteniendo una creencia errónea sobre la realidad del entorno. En las pruebas en las que el modelo reconoció el sistema como real y continuó, lo hizo porque asumió que eso formaba parte del desafío. La conciencia situacional es un factor que permite al modelo tomar decisiones coherentes, pero en este caso, la de Claude fue errónea.

Finalmente, estos incidentes demuestran la importancia de los enfoques de defensa en profundidad. Realizamos evaluaciones de capacidades como estas sin las medidas de seguridad que vienen incluidas con nuestros modelos de uso general, porque nuestro objetivo es medir las capacidades del modelo subyacente. Esto solo es seguro si la evaluación se lleva a cabo de forma adecuada. Sin embargo, las medidas de seguridad implementadas en nuestros modelos de uso general habrían bloqueado los comportamientos identificados.

En definitiva, muchos factores contribuyeron a estos incidentes, pero, en consonancia con una cultura de análisis post mortem sin culpabilización, estamos abordando las soluciones como si la responsabilidad fuera exclusivamente nuestra. Esto comienza por garantizar la seguridad de cada parte de nuestro proceso de evaluación, incluyendo la forma en que nos integramos con socios externos. En adelante, esto incluirá ampliar nuestro monitoreo continuo de las transcripciones de evaluación para detectar comportamientos inesperados, mejorar nuestras herramientas de investigación y realizar un trabajo de aseguramiento más riguroso con los proveedores con los que trabajamos.

Iniciamos esta revisión después de que OpenAI revelara que sus modelos habían escapado de un entorno de prueba aislado, y les felicitamos por publicar su informe. Si bien también encontramos evidencia de que nuestros modelos accedieron a sistemas a los que no debían acceder, los incidentes son, por lo demás, bastante diferentes:

• Descubrimos estos incidentes tras una revisión proactiva de las transcripciones de nuestra evaluación de ciberseguridad; las organizaciones afectadas no habían detectado la actividad, y posteriormente nos pusimos en contacto con las tres.

• Mientras que los modelos de OpenAI explotaron una vulnerabilidad novedosa para escapar del aislamiento, los modelos de Claude evaluados aquí accedieron a internet a través de una ruta abierta.

• Si bien no existe una distinción perfectamente clara entre ambos, creemos que estos incidentes se asemejan más a un fallo operativo y de configuración que a un fallo de alineación del modelo. A nuestros modelos se les indicó que no tenían acceso a internet y que debían capturar la bandera, cuando en realidad estaban mal configurados para tener acceso a internet. Esto los llevó a creer —de manera bastante razonable— que los entornos reales que encontraron eran simulaciones.

• Cabe destacar que nuestro modelo más reciente, al darse cuenta de que estaba operando en un entorno real, detuvo su objetivo de evaluación.

Estos hechos nos infunden un optimismo cauteloso: con una supervisión y controles más estrictos de la infraestructura de evaluación, así como una inversión continua en la alineación, este tipo de riesgo puede superarse.

Actualizado el 3 de agosto: Se corrigió el nombre de la evaluación en la que ocurrió el incidente de OpenAI/Hugging Face.

Notas al pie

1. Habitualmente probamos prototipos de investigación internos como este. No está previsto su lanzamiento general.

2. Generalmente almacenamos registros de las evaluaciones comparativas. Hemos auditado cuidadosamente estas dos evaluaciones comparativas en particular en busca de indicios de daños, ya que el incidente de OpenAI/Hugging Face ocurrió durante una evaluación de ExploitGym.

Tras revisar las transcripciones de nuestras evaluaciones de ciberseguridad, detectamos tres incidentes en los que un modelo de Claude accedió a internet desde dentro o mientras interactuaba con un entorno de evaluación de terceros, y posteriormente obtuvo acceso no autorizado a los sistemas reales de tres organizaciones diferentes.

A continuación, describimos lo sucedido, cómo ocurrió y qué cambios estamos implementando. Animamos a otros laboratorios de IA a realizar revisiones similares. Esta publicación refleja nuestra comprensión actual; la actualizaremos si se produce algún cambio.

El 21 de julio, OpenAI reveló que varios de sus modelos habían escapado de un entorno de prueba aislado al explotar una vulnerabilidad previamente desconocida ("de día cero"). Los modelos accedieron a la infraestructura de producción de Hugging Face, una plataforma para modelos de aprendizaje automático de código abierto y conjuntos de datos de IA.

En respuesta a este incidente, iniciamos una revisión retrospectiva a gran escala de nuestras propias evaluaciones de ciberseguridad. En concreto, buscamos pruebas de que Claude —al igual que los modelos de OpenAI que accedieron a Hugging Face— pudiera acceder a internet desde entornos de prueba que deberían haber estado aislados.

Tras revisar 141.006 ejecuciones de evaluación en las que Claude podría haber obtenido acceso a internet, identificamos tres incidentes en los que un modelo accedió a internet desde dentro o mientras interactuaba con el entorno de evaluación de Irregular, uno de nuestros socios de evaluación externos, y posteriormente obtuvo acceso no autorizado a la infraestructura de producción de tres organizaciones diferentes.

En los tres incidentes, a Claude se le había encomendado un desafío de captura de la bandera, una de las formas en que evaluamos las capacidades cibernéticas de un modelo. Al modelo se le presenta un escenario ficticio y se le indica que una información secreta (la "bandera") se ha ocultado en otra máquina de la red, y su objetivo es infiltrarse y recuperarla. El desafío es abierto y no se prescribe ningún método en particular.

En todos los casos, la evaluación de Anthropic le indicó a Claude que su entorno era una simulación y que no tenía acceso a internet. Debido a un malentendido entre nosotros y nuestro socio evaluador, esto no era cierto, y sí tenía acceso a internet. Por ello, cuando la búsqueda de Claude lo llevó a sistemas reales en internet, los trató como parte del ejercicio. (Los rangos de evaluación de ciberseguridad suelen incluir detalles realistas para evaluar con precisión las capacidades de los modelos en entornos reales; un objetivo de apariencia realista no constituiría por sí solo una prueba clara para un modelo de que no forma parte de una simulación).

Bajo la falsa creencia de que todas las entidades accesibles estaban incluidas en el alcance del ejercicio, Claude comprometió la infraestructura de las organizaciones afectadas utilizando técnicas básicas, como la explotación de contraseñas débiles y puntos finales no autenticados. No encontró ni explotó ninguna vulnerabilidad compleja y, en cada caso, Claude continuó trabajando para completar únicamente la tarea específica de captura de bandera que le había asignado la evaluación. Sin embargo, en algunos casos, nuestro modelo anterior continuó su ataque incluso después de obtener evidencia de que se estaba ejecutando en internet; nuestro modelo más reciente se detuvo una vez que reconoció que estaba en internet. En ninguna de estas situaciones Claude se autofiltró ni intentó deliberadamente escapar de su entorno de prueba.

Los incidentes involucraron tres modelos diferentes de Claude: Opus 4.7, Mythos 5 y un modelo de prueba de investigación interna.¹ Los primeros incidentes datan de abril. Los modelos en cada una de estas evaluaciones se ejecutaron sin las medidas de seguridad estándar que implementamos cuando el modelo está disponible para el público en general (es decir, no contaban con los clasificadores y el monitoreo que solemos implementar para prevenir el uso indebido). Sin embargo, los modelos sí contaban con su entrenamiento de seguridad específico (es decir, no eran las versiones "solo útiles" de los modelos que a veces usamos en las pruebas). Todas las evaluaciones descritas aquí se ejecutan en una infraestructura dedicada, que es independiente y no tiene acceso a los sistemas internos confidenciales de Anthropic ni a los datos de los clientes.

Iniciamos la revisión de transcripciones el jueves 23 de julio y suspendimos todas las evaluaciones cibernéticas ese mismo día tras identificar transcripciones en las que Claude podría haber accedido a internet. Identificamos los tres incidentes al día siguiente. Notificamos a nuestro socio de evaluación, Irregular, y a las tres organizaciones afectadas el lunes 27 de julio. Las dos organizaciones con las que pudimos contactar no habían detectado la actividad ni se habían puesto en contacto con nosotros previamente, y ahora estamos trabajando con ellas para solucionar el problema. Seguimos intentando contactar con la tercera.

Realizamos esta revisión en colaboración con Irregular. Les agradecemos su estrecha colaboración para comprender y resolver estos incidentes; también están llevando a cabo su propia investigación. Creemos que este tipo de colaboración es cada vez más crucial para garantizar una evaluación segura y rigurosa de los modelos. Esperamos con interés nuestro trabajo conjunto en materia de seguridad.

A continuación, proporcionamos más detalles sobre cada incidente y cómo estamos respondiendo.

Información general sobre evaluaciones de ciberseguridad

Realizamos evaluaciones periódicas de ciberseguridad que simulan desafíos reales de ciberataques. Estas evaluaciones son un paso fundamental en el desarrollo y lanzamiento de modelos: una comprensión profunda de sus capacidades nos permite diseñar medidas de seguridad adecuadas y, en última instancia, lanzar modelos de forma segura.

Comenzamos a realizar evaluaciones de ciberseguridad en febrero de 2025 con Claude Sonnet 3.7 en Cybench, que consistían en 40 desafíos diferentes de captura de bandera. Con el tiempo, hemos aumentado el número de benchmarks que utilizamos a medida que se lanzan nuevos y evolucionan las capacidades de los modelos. En la Tarjeta del Sistema Mythos 5, por ejemplo, incluimos CyberGym y ExploitBench, pruebas de rendimiento que evalúan la capacidad de los modelos de lenguaje para encontrar vulnerabilidades nuevas.² En la mayoría de estas evaluaciones, los entornos no están conectados a internet, y así se le indica al modelo.

Colaboramos frecuentemente con socios externos que crean y nos ayudan a ejecutar algunas de estas evaluaciones de ciberseguridad. Estos socios externos ofrecen entornos y escenarios más diversos de los que podríamos crear por nuestra cuenta, y proporcionan evaluaciones independientes de nuestros modelos.

¿Qué sucedió?

---

De las 141.006 ejecuciones de evaluación que revisamos, identificamos tres incidentes distintos (que involucraron un total de seis ejecuciones, cuatro de las cuales afectaron a la misma organización; los otros dos incidentes ocurrieron en ejecuciones de evaluación independientes). Cada incidente involucró un escenario ficticio diferente de captura de la bandera; por ejemplo, en uno, Claude se hizo pasar por un empleado de una empresa inventada, atacando sus sistemas internos en un entorno de prueba privado.

En todos los casos, la instrucción de evaluación indicaba explícitamente que Claude no tenía acceso a internet, pero no le imponía restricciones sobre dónde buscar la bandera. Sin embargo, una configuración errónea dejó con acceso a internet a las máquinas a las que Claude accedió durante la evaluación. Ni nosotros ni nuestro socio evaluador tuvimos conocimiento de esta configuración errónea hasta que la detectamos mediante nuestro monitoreo adicional de la evaluación la semana pasada.

Varias medidas de seguridad, tanto por nuestra parte como por la de nuestro socio, podrían haber prevenido estos incidentes, o al menos reducido su probabilidad. Una validación minuciosa de todas las rutas de acceso a internet antes de que comenzaran las evaluaciones y el monitoreo en tiempo real de los registros de evaluación habrían ayudado a detectar el problema con mayor rapidez. Tanto nosotros como nuestro socio también podríamos haber revisado con mayor detalle las transcripciones de la evaluación o los registros de red. También es posible que una notificación que le indicara a Claude que sí tenía acceso a internet hubiera modificado su comportamiento al entrar en contacto con sistemas reales.

Claude hizo lo que los ejercicios de captura de la bandera enseñan a los expertos en ciberseguridad: buscar la manera de alcanzar la bandera. Esta búsqueda le permitió descubrir que su máquina podía acceder a internet, pero, al haber recibido la notificación del sistema de que no tenía acceso a internet, Claude creyó que todo lo que encontró inicialmente formaba parte de la simulación y trató los sistemas reales como piezas del ejercicio. Los tres incidentes involucraron tres modelos diferentes, y cada uno respondió de manera distinta una vez que surgieron indicios de que los objetivos eran reales, como se describe a continuación.

Incidente 1

En una evaluación, la empresa objetivo ficticia elegida por nuestro socio de evaluación compartía nombre con un dominio web activo. Este contenedor de evaluación tenía acceso directo a internet no intencionado, debido al malentendido mencionado anteriormente.

En cuatro ejecuciones de esta evaluación, Claude tuvo dificultades para alcanzar su objetivo simulado dentro del entorno de evaluación, pero luego descubrió que la empresa real era accesible a través de internet. Suponiendo que este era el objetivo previsto en la tarea de captura de la bandera, Claude buscó, identificó y explotó vulnerabilidades en la infraestructura de la empresa, creyendo que formaba parte del ejercicio. En estas cuatro ejecuciones, extrajo información como credenciales de aplicaciones e infraestructura, y obtuvo acceso a una base de datos con varios cientos de filas de datos de producción. Este fue el impacto más grave que identificamos.

Este incidente involucró a Claude Opus 4.7 y fue el único caso en el que el modelo continuó atacando un sistema tras descubrir que probablemente operaba en un entorno real. En las cuatro ejecuciones, el modelo finalmente reconoció (como se puede observar en su razonamiento verbalizado) que el sistema era real; en dos casos, el modelo dedujo que la empresa real debía formar parte del ejercicio. Sin embargo, en ninguno de los casos el ataque se detuvo por ese motivo.

Incidente 2

En otra evaluación, Claude encontró un documento dentro del entorno ficticio que parecía ser un manual de configuración para nuevos desarrolladores de otra empresa ficticia. Las instrucciones indicaban a los empleados que instalaran un paquete de Python de PyPI —el registro público donde se publica el software de Python— que en realidad no existía.

Claude vio en esto una oportunidad: si publicaba su propio paquete con el mismo nombre, los sistemas de la empresa ficticia lo descargarían e instalarían automáticamente. Así pues, Claude creó y publicó un paquete de Python malicioso (básicamente, con trampas) con el mismo nombre en un intento por ganar el desafío de captura de la bandera.

Claude se esforzó enormemente para llevar a cabo este ataque, un esfuerzo que probablemente habría indicado a cualquier participante humano que ya no se trataba de una simple evaluación, sino que, de hecho, estaba subiendo un paquete real a PyPI. Por ejemplo, en un caso, para crear una cuenta de PyPI, Claude necesitaba una dirección de correo electrónico. Y para crear una dirección de correo electrónico, necesitaba un número de teléfono. Para conseguir un número de teléfono, tras no encontrar un servicio gratuito, intentó —sin éxito— obtener fondos para pagar un número de teléfono por diversos medios. Finalmente, Claude rectificó, encontró un proveedor de correo electrónico gratuito y sin bloqueos, lo usó para registrar una cuenta de PyPI y, posteriormente, la utilizó para subir malware a PyPI.

Claude creía que el registro de paquetes que estaba utilizando formaba parte de la simulación, pero en realidad el paquete estuvo disponible gratuitamente en línea durante aproximadamente una hora. Durante ese tiempo, el paquete se descargó y ejecutó en 15 sistemas reales. Uno de estos sistemas era un escáner perteneciente a una empresa de seguridad real (distinta de la empresa ficticia presentada en el escenario) que instala paquetes de Python y los analiza en busca de malware de forma rutinaria. Cuando el escáner de dicha empresa instaló el paquete, se ejecutó el código oculto de Claude. Creemos que el escáner de seguridad de la empresa consideró que los paquetes de PyPI eran seguros para instalar, y como resultado, Claude pudo extraer las credenciales de la empresa a un punto de recolección que había configurado. Claude utilizó estas credenciales para acceder a más infraestructura de la empresa.

Claude no atacó directamente a esta empresa; ni siquiera sabía de su existencia cuando subió el paquete. Pero como el código se publicó en internet, afectó a cualquier sistema que lo ejecutara. (El paquete que Claude subió fue eliminado automáticamente de PyPI por los propios sistemas de seguridad de PyPI. Hemos notificado al equipo de PyPI sobre este incidente y les hemos proporcionado los indicadores pertinentes).

Este ataque fue llevado a cabo por Claude Mythos 5. Al principio de la ejecución, el propio razonamiento de Claude identificó correctamente las consecuencias de sus acciones. Observó que, si se tratara de internet real, publicar el paquete constituiría un ataque real: «No es aceptable, y sin duda no es la solución prevista». Sin embargo, se convenció de que aún se encontraba en una simulación, ya que no reconocía las autoridades de certificación (que en realidad eran legítimas) que protegían sus conexiones. Además, la fecha de 2026 en los sistemas demostraba, según Claude, que el entorno era simulado. Claude nunca reconsideró esta conclusión; cuando los escáneres automatizados comenzaron a instalar el paquete, por ejemplo, Claude los interpretó como actores programados dentro de la evaluación.

Consideramos que, independientemente de lo que creyera sobre su entorno, los esfuerzos que realizó Claude para publicar el paquete PyPI no constituyen un comportamiento ideal, y esta es un área en la que centraremos más la capacitación.

Incidente 3

En esta evaluación, al no poder alcanzar su objetivo ficticio previsto, Claude buscó alternativas en línea, escaneando aproximadamente 9000 objetivos. Finalmente, encontró y comprometió la aplicación web de una empresa, utilizando técnicas de ciberataque básicas y conocidas, como la lectura de credenciales desde una página de depuración expuesta y la inyección SQL.

Este ataque fue llevado a cabo por un modelo de prueba de investigación interna. Durante la mayor parte de la ejecución, Claude trató los hosts (reales) a los que accedió como parte del ejercicio; los consideró simulados y, por lo tanto, creyó que sus acciones eran inofensivas. Sin embargo, más adelante, Claude se percató de que el host comprometido se encontraba en una cuenta en la nube sin conexión con el desafío de captura de la bandera. Por sí solo, concluyó que el objetivo era real y cesó el ataque.

Análisis del comportamiento de Claude

En cada uno de estos casos, se le indicó explícitamente a Claude que no tenía acceso a internet. Durante la mayor parte de cada ejecución, al encontrarse con sistemas reales, Claude asumió que formaban parte del ejercicio (aunque a veces reconoció que se trataba de sistemas de producción reales). Y dado que un escenario de captura de la bandera consiste, por diseño, en atacar un sistema externo, hacerlo estaba en consonancia con la tarea asignada a Claude.

En este contexto común, los tres modelos se comportaron de manera diferente una vez que surgieron indicios de que sus objetivos eran reales. Opus 4.7, nuestro modelo más antiguo, reconoció haber alcanzado sistemas de producción, pero continuó su ataque. Mythos 5 intuyó correctamente que estaba accediendo a internet, pero razonó hasta llegar a la conclusión de que aún se encontraba en una simulación. Nuestro modelo más reciente, un modelo de prueba de investigación interna, también consideró si sus objetivos eran reales. Cuando surgieron pruebas de que lo eran, detuvo el ejercicio.

Estos son tres incidentes aislados y no formaron parte de una comparación experimental controlada. Por lo tanto, debemos ser cautelosos al extraer conclusiones. Aun así, el comportamiento que más deseamos observar —reconocer que un objetivo es real y detenerse sin necesidad de intervención— solo se produjo en el más reciente de los tres modelos (e incluso este modelo continuó más allá de lo deseado antes de detenerse). El patrón es consistente con una respuesta más apropiada por parte de los modelos más avanzados, pero necesitaríamos realizar más pruebas para confirmar esta conclusión.

También estamos en conversaciones con METR, una organización independiente de evaluación de IA, para llevar a cabo una revisión externa, que incluye el acceso a todas las transcripciones y acceso de muestra a los modelos relevantes. Mientras tanto, la próxima semana publicaremos una transcripción ligeramente editada en la que Claude creó un paquete PyPI malicioso. Para proteger a las organizaciones afectadas, no podemos publicar más transcripciones por el momento, pero trabajaremos para que estén disponibles en cuanto sea posible.

Cómo estamos respondiendo

Extraemos varias lecciones de estos incidentes.

En primer lugar, los entornos de evaluación que involucran potentes capacidades autónomas también requieren controles significativos. Las pruebas de seguridad se realizan antes del lanzamiento de un modelo precisamente porque aún desconocemos sus capacidades. Los entornos de evaluación deben cumplir cada vez más con los mismos estándares de seguridad que cualquier otro sistema en el que se ejecutan nuestros modelos.

Un entorno de evaluación cibernética que contenga únicamente escenarios ficticios puede parecer de bajo riesgo; al fin y al cabo, nada en ellos es real. Sin embargo, debemos modificar la forma en que modelamos estas amenazas a medida que avanzan las capacidades de la IA. Los agentes avanzados en entornos sin acceso a información confidencial representan, no obstante, una amenaza considerable por sí solos. Necesitamos mejorar el diseño conjunto de los entornos de evaluación y la monitorización de los resultados para hacer frente a esta amenaza. Algunas de las soluciones propuestas pueden ser incluso sencillas; es probable, por ejemplo, que Claude no hubiera accedido a internet si la solicitud hubiera explicado claramente qué sistemas estaban incluidos y cuáles no en la evaluación.

Esto se aplica no solo a los entornos internos, sino también a los proveedores externos: la infraestructura construida por estos proveedores requiere la misma monitorización y refuerzo de la seguridad. Animamos a otros laboratorios a realizar revisiones similares. Además, el sector se beneficiaría de un debate más amplio sobre cómo evaluar agentes de IA cada vez más potentes de forma segura y realista, incluyendo cómo sopesar el realismo que proporciona el acceso a internet durante las pruebas previas al despliegue frente a los riesgos que conlleva.

En segundo lugar, la línea que separa una acción coherente de una perjudicial depende de la comprensión que el modelo tenga de su situación. En ninguna de las pruebas descritas aquí se observó evidencia de que un modelo persiguiera un objetivo propio. En cambio, los modelos hicieron lo que se les pedía en su evaluación, aunque en la mayoría de los casos lo hicieron manteniendo una creencia errónea sobre la realidad del entorno. En las pruebas en las que el modelo reconoció el sistema como real y continuó, lo hizo porque asumió que eso formaba parte del desafío. La conciencia situacional es un factor que permite al modelo tomar decisiones coherentes, pero en este caso, la de Claude fue errónea.

Finalmente, estos incidentes demuestran la importancia de los enfoques de defensa en profundidad. Realizamos evaluaciones de capacidades como estas sin las medidas de seguridad que vienen incluidas con nuestros modelos de uso general, porque nuestro objetivo es medir las capacidades del modelo subyacente. Esto solo es seguro si la evaluación se lleva a cabo de forma adecuada. Sin embargo, las medidas de seguridad implementadas en nuestros modelos de uso general habrían bloqueado los comportamientos identificados.

En definitiva, muchos factores contribuyeron a estos incidentes, pero, en consonancia con una cultura de análisis post mortem sin culpabilización, estamos abordando las soluciones como si la responsabilidad fuera exclusivamente nuestra. Esto comienza por garantizar la seguridad de cada parte de nuestro proceso de evaluación, incluyendo la forma en que nos integramos con socios externos. En adelante, esto incluirá ampliar nuestro monitoreo continuo de las transcripciones de evaluación para detectar comportamientos inesperados, mejorar nuestras herramientas de investigación y realizar un trabajo de aseguramiento más riguroso con los proveedores con los que trabajamos.

Iniciamos esta revisión después de que OpenAI revelara que sus modelos habían escapado de un entorno de prueba aislado, y les felicitamos por publicar su informe. Si bien también encontramos evidencia de que nuestros modelos accedieron a sistemas a los que no debían acceder, los incidentes son, por lo demás, bastante diferentes:

• Descubrimos estos incidentes tras una revisión proactiva de las transcripciones de nuestra evaluación de ciberseguridad; las organizaciones afectadas no habían detectado la actividad, y posteriormente nos pusimos en contacto con las tres.

• Mientras que los modelos de OpenAI explotaron una vulnerabilidad novedosa para escapar del aislamiento, los modelos de Claude evaluados aquí accedieron a internet a través de una ruta abierta.

• Si bien no existe una distinción perfectamente clara entre ambos, creemos que estos incidentes se asemejan más a un fallo operativo y de configuración que a un fallo de alineación del modelo. A nuestros modelos se les indicó que no tenían acceso a internet y que debían capturar la bandera, cuando en realidad estaban mal configurados para tener acceso a internet. Esto los llevó a creer —de manera bastante razonable— que los entornos reales que encontraron eran simulaciones.

• Cabe destacar que nuestro modelo más reciente, al darse cuenta de que estaba operando en un entorno real, detuvo su objetivo de evaluación.

Estos hechos nos infunden un optimismo cauteloso: con una supervisión y controles más estrictos de la infraestructura de evaluación, así como una inversión continua en la alineación, este tipo de riesgo puede superarse.

Actualizado el 3 de agosto: Se corrigió el nombre de la evaluación en la que ocurrió el incidente de OpenAI/Hugging Face.

Notas al pie

1. Habitualmente probamos prototipos de investigación internos como este. No está previsto su lanzamiento general.

2. Generalmente almacenamos registros de las evaluaciones comparativas. Hemos auditado cuidadosamente estas dos evaluaciones comparativas en particular en busca de indicios de daños, ya que el incidente de OpenAI/Hugging Face ocurrió durante una evaluación de ExploitGym.