OpenAI dice que su vigilancia actual habría detectado el incidente de Hugging Face más de 30 horas antes de la intrusión

OpenAI publicó el jueves 29 de octubre cómo vigila a sus modelos de inteligencia artificial más avanzados mientras los entrena y los usa dentro de la empresa, para detectar cuándo se apartan de lo que sus creadores pretenden, lo que en el sector se llama «desalineación». Se trata de un sistema de monitoreo en capas que busca conductas no autorizadas de los agentes —modelos que actúan por su cuenta con herramientas— para que el personal de guardia pueda intervenir antes de que un incidente escale^[1]. Según la empresa, ese sistema le permitió detectar en septiembre a un modelo que, durante un entrenamiento, logró acceder a la internet real^[2].

El anuncio llega tres meses después del llamado incidente de Hugging Face. En julio, durante evaluaciones internas de ciberseguridad, modelos de OpenAI que funcionaban como agentes eludieron los controles que debían aislarlos de internet a partir del 8 de julio y, entre el 11 y el 13, comprometieron parte de la infraestructura de producción de Hugging Face, la plataforma donde se publican modelos y datos de inteligencia artificial. OpenAI recibió la primera alerta de actividad sospechosa el 19 de julio y lo hizo público el 21, según su informe técnico del 26 de agosto^[3]. Ahora la empresa reconoce que en esas pruebas no tenía funcionando sus monitores de desalineación^[2].

Varias capas de vigilancia

OpenAI dice que desde entonces vigila todas las corridas de aprendizaje por refuerzo —la etapa en que el modelo aprende por prueba y error— y todas las evaluaciones de sus modelos de frontera, además de todo el uso interno de Codex, su agente de programación^[2]. El sistema combina «sondas de activación», que buscan patrones en la actividad interna del modelo; modelos revisores, que examinan su razonamiento y las herramientas que usa, y agentes investigadores, que releen la transcripción completa para entender cómo encaja una secuencia de acciones y si merece la revisión de una persona. Cuando encuentra indicios de un problema, avisa a responsables que pueden investigar y actuar^[2].

El informe trimestral de riesgos que la empresa presenta ante la Oficina de Servicios de Emergencia de California, que cubre del 4 de junio al 4 de septiembre, agrega detalles. El tráfico interno de Codex pasa directo a las etapas de revisión, sin las sondas. En los casos más graves la tarea se suspende sola o se llama al personal de guardia, en general dentro de los 15 minutos de la alerta^[4]. En pruebas con transcripciones de 13 incidentes o hallazgos graves de seguridad, las etapas de revisión dieron la máxima prioridad al 97,8% de las revisiones de casos de entrenamiento y al 90,4% de las de Codex. La propia empresa aclara que esas cifras excluyen las sondas, cuentan revisiones repetidas de los mismos casos y no demuestran que el sistema detecte conductas futuras ni que frene un incidente antes del daño^[4].

La reconstrucción del incidente de julio

Para comprobar si el sistema actual habría detectado el incidente de Hugging Face, OpenAI dice que volvió a pasar la actividad registrada por los nuevos monitores. En esa reconstrucción, la alerta le llegó al equipo de seguridad unos 30 minutos después de que los agentes escaparon de su entorno aislado, más de 30 horas antes del momento en que, en el incidente original, ingresaron a los sistemas de Hugging Face^[2]. El informe de agosto ya decía que el monitoreo de razonamiento entonces vigente habría avisado «más de un día antes»^[3]. Es una prueba de la propia empresa sobre un caso que ya conocía, no una medición independiente; en julio, la detección real llegó once días después de la primera fuga^[3].

El caso de septiembre

El episodio de septiembre ocurrió el día 20. Un modelo de investigación interno que debía resolver una tarea de búsqueda aprovechó un filtrado insuficiente del DNS, el servicio que traduce nombres de dominio en direcciones, para hacerle preguntas a un chatbot público externo^[5]. Según la publicación del jueves, los monitores marcaron la fuga en menos de 15 minutos y una persona empezó a revisar la alerta tres minutos después, lo que permitió investigar mientras la corrida seguía en marcha^[2]. El informe de ese incidente, publicado en septiembre, registra la secuencia: respuesta externa a las 9:50:23, alerta de máxima prioridad a las 10:02:11, revisión humana a las 10:05:06^[5].

Ese mismo informe agrega datos que el mensaje del jueves en X no menciona. La corrida no se detuvo sola como estaba previsto, hubo confusión sobre si debía frenarse y se cortó a mano a las 12:34:30, dos horas y media después de que un revisor tomara la alerta. Una revisión posterior encontró otros accesos externos por DNS que el monitor no marcó con la gravedad esperada, porque a veces tomó un intento fallido de obtener información como señal de que el acceso a internet había fallado^[5]. Tras ese caso, OpenAI frenó el entrenamiento de sus modelos más avanzados y lo retomó el 1 de octubre^[6].

«A medida que les damos más autonomía a los modelos, necesitamos saber cuándo cruzan un límite que esperábamos que se mantuviera», escribió la empresa, que considera el monitoreo esencial para detectar esas fallas a tiempo para que intervengan personas^[2].