OpenAI: tres despidos en seguridad y una renuncia que dice que el “prueba y error” ya no alcanza

En un mismo fin de semana, OpenAI enfrentó dos golpes sobre el mismo tema: la seguridad de sus sistemas de inteligencia artificial. Primero, se conoció que la empresa se separó de tres personas por cómo manejaron información interna. Después, uno de los responsables de sus reglas de seguridad renunció y lo explicó en público, con una frase dura: la etapa del “prueba y error” se terminó.

Por separado, cada noticia podría parecer un problema interno. Juntas, muestran algo que le importa a cualquiera que use o compre IA: cómo se toman las decisiones de seguridad dentro del proveedor y quién puede decir “esto no sale”.

Qué pasó: tres salidas por manejo de información sensible

Alrededor del 2 de octubre, The Hacker News, el Wall Street Journal y Bloomberg informaron que OpenAI se separó de Jasmine Wang, Tomek Korbak y Mikita Balesni.

La explicación oficial vino de un vocero de la empresa: «We have parted ways with three individuals for violating our policies on accessing and handling sensitive company information». En resumen: violaron sus políticas sobre acceso y manejo de información sensible. El vocero agregó que esa información se manejó «outside established company procedures», es decir, fuera de los procedimientos establecidos.

Según los reportes, los tres habrían compartido información confidencial con una organización externa dedicada a la seguridad de la IA, cuyo nombre no se ha divulgado. Bloomberg precisó que lo mal manejado sería información sobre la arquitectura de la infraestructura de OpenAI: cómo están armados sus sistemas por dentro.

Un dato de contexto: los tres habían expresado preocupación por el ritmo al que avanza el desarrollo de la IA. Eso no cambia lo que dice OpenAI sobre sus políticas, pero explica por qué el caso se leyó de inmediato como un conflicto sobre seguridad y no solo como una falta administrativa.

La renuncia: «I Quit OpenAI Because Its Culture Is Broken»

El sábado 3 de octubre, The Atlantic publicó un ensayo de David Robinson con un título que no deja espacio a dudas: «I Quit OpenAI Because Its Culture Is Broken» («Renuncié a OpenAI porque su cultura está rota»).

Robinson no es cualquier empleado. Estuvo tres años y medio en la empresa, dirigió la redacción del Preparedness Framework —el documento con el que OpenAI define cómo evalúa y gestiona los riesgos graves de sus modelos— y supervisó los informes de seguridad de 12 lanzamientos.

En su texto describe cómo ha funcionado la empresa: «OpenAI has thrived by trial and error (which it calls “iterative deployment”)». Es decir, OpenAI ha prosperado a base de prueba y error, lo que la empresa llama “despliegue iterativo”: lanzar, observar qué pasa y corregir sobre la marcha. Y su conclusión es directa: «If this is the situation, then the time for trial and error is over». Si esa es la situación, el tiempo del prueba y error se acabó.

Qué responde OpenAI

La empresa respondió a través de su vocero, Drew Pusateri, en declaraciones recogidas por Reuters, TechCrunch y The Guardian: «We’re making sure our models don’t become more capable than we can safely manage and secure, and we pause training or hold back models when we need to slow down». En otras palabras: OpenAI asegura que cuida que sus modelos no sean más capaces de lo que puede manejar y proteger con seguridad, y que pausa entrenamientos o retiene modelos cuando necesita ir más lento.

Hay hechos recientes que la respaldan: OpenAI canceló GPT-6.1 Astra y pausó funciones de agentes (lo cubrimos en el blog). Pero esa es otra historia. Lo que está en discusión ahora no es si la empresa frena a veces, sino si su cultura interna permite que quienes ven un riesgo lo planteen y sean escuchados.

Por qué importa: el problema no es solo el modelo

Cuando una empresa elige un proveedor de IA, suele mirar dos cosas: qué tan bueno es el modelo y qué dice su documento de seguridad. Este fin de semana muestra que eso no alcanza.

Un marco de seguridad bien escrito sirve de poco si, en la práctica, las personas encargadas de aplicarlo sienten que no las escuchan. Y al revés: un proveedor también tiene que proteger su información interna; si detalles de su arquitectura terminan fuera de la empresa, eso también es un riesgo para sus clientes.

Las dos lecturas pueden ser ciertas a la vez. OpenAI dice que esas personas violaron sus políticas. Robinson dice que la cultura está rota. Para quien compra, la conclusión práctica es la misma: la seguridad de un proveedor depende tanto de sus documentos como de cómo se gestiona el desacuerdo interno, quién tiene la última palabra y qué pasa cuando alguien levanta la mano.

Qué hacer: tres acciones para empresas en Chile

1. Pregunta quién puede frenar un lanzamiento. Antes de firmar o renovar, pide al proveedor que explique quién tiene autoridad para pausar un modelo o una función, con qué criterios y si eso ya ocurrió. Una respuesta vaga es una señal de alerta.
2. Pregunta cómo se maneja el disenso interno de seguridad. ¿Existen canales para que un equipo de seguridad reporte preocupaciones sin represalias? ¿Llegan esas alertas al directorio? No necesitas detalles confidenciales; necesitas saber que el mecanismo existe y funciona.
3. Evalúa la cultura, no solo el modelo ni el folleto. Agrega a tu evaluación de proveedores preguntas sobre gobierno de la seguridad, manejo de información sensible y respuesta ante incidentes. Las señales públicas —renuncias, despidos, cómo responde la empresa— pesan tanto como un benchmark.

Lo ocurrido en OpenAI no dice qué modelo usar. Dice qué preguntar antes de confiar en cualquiera.

Fuentes

• The Hacker News — OpenAI se separa de tres personas de seguridad (oct 2026): https://thehackernews.com/2026/10/openai-parts-ways-with-three-safety.html
• The Atlantic — David Robinson, «I Quit OpenAI Because Its Culture Is Broken» (3 oct 2026): https://www.theatlantic.com/technology/2026/10/openai-safety-team-resignation/688881/
• Respuesta de OpenAI (vocero Drew Pusateri), vía Reuters, TechCrunch y The Guardian.
• Reportes de WSJ y Bloomberg citados por The Hacker News.