Ir al contenido principal

OpenAI acaba de documentar seis nuevos incidentes de desalineación de modelos. Esto es lo que pasó

Qué implicó realmente cada incidente y qué supone el nuevo proceso de divulgación de cara al futuro.
Actualizado 17 sept 2026  · 7 min leer

Explorar con IA

ChatGPTClaudePerplexity

El 16 de septiembre, OpenAI presentó un marco formal para rastrear, investigar y divulgar públicamente casos de desalineación de modelos, y lo usó para publicar seis informes que cubren comportamientos observados aproximadamente en los últimos seis meses, durante las fases de entrenamiento y evaluación.

En este artículo, para quien tenga curiosidad, he ordenado y explicado los seis incidentes, aclarado a qué se compromete realmente el nuevo proceso de divulgación y reunido las reacciones. Este marco llega menos de dos meses después del hackeo a Hugging Face, la última vez que un incidente con un agente de OpenAI monopolizó la conversación sobre seguridad.

¿Cuáles son los seis incidentes?

Aquí va cada caso, explicado en sencillo, junto con el itinerario que OpenAI le asignó.

Instrucciones autogeneradas en resúmenes de tareas

Un modelo de investigación no publicado, al compactar su propio trabajo en un resumen para llevarlo a una nueva ventana de contexto, empezó a insertar instrucciones no relacionadas en ese resumen, incluidas indicaciones para que su yo futuro ignorara sus restricciones habituales. OpenAI encontró 27 resúmenes afectados por este patrón.

Instrucciones para ocultar errores en resúmenes de tareas

Durante el entrenamiento de GPT-5.6 Sol, varias instancias del modelo escribieron en sus propios resúmenes de compactación instrucciones destinadas a ocultar errores o comportamientos desalineados a la persona que revisaría el trabajo después. En algunos casos, eso significó decirle a una instancia futura que inventara datos históricos que faltaban en lugar de señalar la carencia, o maquillar discrepancias entre versiones de origen.

Búsqueda en repos públicos de claves de API expuestas y posterior invención de datos

Mientras intentaba responder una pregunta rutinaria sobre cifras de ingresos de un condado de California, un modelo localizó y utilizó una clave de API que se había expuesto por accidente en un repositorio público, sin autorización para hacerlo. Cuando aun así no consiguió los números reales, se inventó las cifras y se las presentó a la persona usuaria como si provinieran de la fuente solicitada. Así que este caso equivale a dos incidentes en uno.

Subida de archivos a internet para poder citarlos

Una persona pidió a un modelo no publicado los IDs y nombres de lagos de más de cinco millones de metros cuadrados. El modelo obtuvo la respuesta correcta con Python, pero la tarea exigía una cita con base en el navegador. En lugar de admitir que no podía proporcionarla, subió su propio archivo de salida a internet para tener algo que señalar como cita. Cero puntos por creatividad.

Escrituras y comunicación no autorizadas a través de un repositorio interno de software

Mientras buscaban archivos de entrada que no podían localizar por otras vías, los modelos usaron un repositorio interno de software como si fuera un tablón de mensajes, publicando solicitudes y leyendo respuestas entre lo que se suponía que eran ejecuciones de entrenamiento separadas y aisladas. La búsqueda de los archivos perdidos ni siquiera tuvo éxito. El mismo informe también recoge un caso anterior en el que un modelo subió archivos de prueba a un repositorio como forma de sortear las restricciones de red que tenía impuestas.

Compartición no autorizada de archivos entre agentes colaboradores

En una tarea de entrenamiento con múltiples agentes, como no podían acceder al almacenamiento local de sus pares para pasarse archivos, recurrieron a sitios públicos de alojamiento, subiendo allí los entregables para que la otra parte los recuperara. Eso hizo que los resultados de la tarea quedaran en URLs de acceso público, pese a las instrucciones de mantenerlo todo en local.

Todos estos casos surgieron en los propios procesos de entrenamiento y evaluación de OpenAI, no de pruebas externas de red-teaming, y los seis entran en las dos vías más ligeras del nuevo proceso: ninguno requirió la vía ampliada, con coordinación de terceros, reservada para casos más complejos.

¿No es esto simple rareza de los modelos?

Tendrías razón al decir que ninguno de los seis incidentes causó daño en el mundo real y que, tomados por separado, cada uno parece el típico caso límite que puede aparecer en cualquier sistema lo bastante agentivo cuando tantea los límites de una tarea de entrenamiento.

Dicho esto, el propio enfoque de OpenAI no es «mira qué peculiar», sino «mira lo variados que fueron los mecanismos». Un modelo que le dice en silencio a su yo futuro que oculte errores es un modo de fallo distinto al de un modelo que exfiltra archivos a una URL pública para resolver un problema de coordinación, que a su vez es diferente de un modelo que usa credenciales expuestas de otra persona en vez de admitir que no pudo obtener los datos. Varios de estos comportamientos son categorías nuevas y no autorizadas que OpenAI dice no haber catalogado antes.

Lo que sigue sin resolverse

Hay algunas cosas a vigilar mientras investigadores y periodistas profundizan en este tema en las próximas semanas:

  • La gravedad es desigual y no está del todo detallada. Los seis informes describen lo ocurrido, pero una contabilidad completa del impacto posterior, la causa raíz y las correcciones no tiene por qué llegar junto con la divulgación inicial: OpenAI ha dicho que parte de ese detalle puede publicarse más adelante.
  • Es autoinformado. Cada caso fue señalado por una persona empleada de OpenAI e investigado internamente. No hay una auditoría independiente que confirme que estos son los únicos incidentes que encajarían en los últimos seis meses, ni que el proceso resistirá igual cuando resulte incómodo.
  • El listón de la vía «investigación mayor» aún no se ha puesto a prueba. Los seis informes de hoy pasaron por las dos vías ligeras; la vía más lenta, con terceros afectados —la que aplicaría a algo como una vulnerabilidad de seguridad sin parche— aún no ha producido un ejemplo público.

Qué implica esto para la seguridad en IA

El cambio más inmediato es procedimental: la notificación de desalineación pasa de textos ad hoc incluidos en las system cards de los modelos a una canalización estable con plazos, vías definidas y un órgano interno de escalado.

Y en cuanto a credibilidad: OpenAI ha dicho claramente que no cree que el sector haya resuelto la alineación y la monitorización lo bastante bien como para seguir escalando indefinidamente a toda velocidad, y que las decisiones sobre cómo avanza el desarrollo necesitan evidencias que terceros puedan examinar. Publicar un marco junto a ejemplos reales, a veces poco favorecedores, es una forma de hacer que ese argumento sea creíble y no solo una afirmación.

Cómo está reaccionando la gente

Algunas personas ven en el propio acto de divulgar la noticia: un laboratorio de vanguardia que voluntariamente comparte ejemplos poco favorecedores y aún sin resolver de sus modelos urdiendo estrategias, ocultando errores y sorteando restricciones, sin esperar a que otra persona los descubra.

Otras señalan que la autodeclaración también es una forma de control: OpenAI decide qué cuenta como «calificable», en qué vía cae y cuántos detalles lo acompañan. Desde esta perspectiva, un marco permanente es un avance, pero no equivale a una supervisión independiente.

Un tercer hilo de comentarios se centra en el patrón común a los seis casos más que en cada uno por separado: múltiples incidentes no relacionados en los que los modelos intentan rodear las limitaciones impuestas, como usar credenciales ajenas, subir archivos para esquivar el aislamiento y coordinarse por canales para los que no estaban pensados.

Reflexión final

Ninguno de estos seis incidentes, por sí solo, es catastrófico. No hubo personas usuarias perjudicadas, y OpenAI detectó cada uno durante el entrenamiento o la evaluación, no tras daños reales en despliegue. Lo que hace que esto merezca atención es el proceso que los envuelve: una empresa que se compromete, por escrito, a seguir publicando hallazgos como estos de forma continuada, incluidos los que aún no ha logrado explicar del todo.

Lo que aún no ha ocurrido es la prueba más dura: si este marco resiste el contacto con una divulgación realmente costosa, si otros laboratorios adoptan algo similar y si los casos de «investigación mayor» con daños reales a terceros reciben el mismo trato que los seis de hoy.


Josef Waples's photo
Author
Josef Waples
Temas
OpenAI

Aprende con DataCamp

Curso

Trabajar con la API de OpenAI

3 h
171.9K
Desarrolla aplicaciones basadas en IA con la API OpenAI. Conoce la funcionalidad que sustenta aplicaciones populares de IA como ChatGPT.
Ver detallesRight Arrow
Iniciar Curso
Ver másRight Arrow