OpenAI y el instituto público polaco NASK han firmado un acuerdo para investigar conjuntamente la seguridad de la inteligencia artificial. El anuncio, publicado el 23 de octubre de 2026, no presenta un nuevo modelo ni una herramienta lista para instalar. Su importancia está en otro lugar: crea una vía de trabajo entre un proveedor de modelos de frontera y una institución nacional con experiencia en ciberseguridad, investigación aplicada y protección del ecosistema digital.
La colaboración se centrará en evaluar sistemas cada vez más capaces, localizar vulnerabilidades y reforzar salvaguardas. También incluye problemas especialmente relevantes para Europa, como la detección de contenido sintético, los usos maliciosos y el comportamiento de los modelos en distintos idiomas. El acuerdo abre una oportunidad real, pero no equivale por sí solo a una certificación, una auditoría independiente completa ni una garantía de que todos los riesgos estén controlados.
Para empresas y administraciones españolas, la noticia sirve como recordatorio práctico: adoptar IA no consiste únicamente en comparar precisión, velocidad o precio. También exige probar el sistema en el idioma, los datos, las herramientas y las condiciones reales donde tomará decisiones o propondrá acciones.
Qué han acordado OpenAI y NASK
El anuncio oficial de OpenAI explica que su colaboración con el Centro de Investigación sobre Seguridad de la IA de NASK —que actúa como instituto polaco de seguridad de la IA— abarcará investigación técnica, evaluación de capacidades, identificación de vulnerabilidades y mejora de salvaguardas.
La redacción es deliberadamente amplia. No se han publicado todavía un calendario de pruebas, una lista de modelos, métricas concretas, reglas de acceso ni compromisos de publicación de resultados. Por tanto, el hecho confirmado es la firma del acuerdo y sus áreas de interés. Cualquier afirmación sobre evaluaciones obligatorias, acceso completo a modelos o resultados vinculantes sería prematura.
NASK aporta un perfil poco habitual. Es un instituto nacional de investigación vinculado a la infraestructura digital y a la ciberseguridad de Polonia. Su estructura científica incluye un Centro de Investigación sobre Seguridad de la IA, mientras que CERT Polska, integrado en NASK, coordina respuestas ante incidentes y vulnerabilidades. Esa combinación permite conectar pruebas de laboratorio con problemas que ya afectan a redes, servicios públicos y organizaciones.
Por qué un instituto nacional puede detectar problemas que un laboratorio no ve
Los desarrolladores conocen la arquitectura y el entrenamiento de sus modelos, pero no pueden reproducir todos los contextos de uso. Un organismo nacional aporta idiomas, marcos jurídicos, sectores críticos y patrones de amenaza diferentes. También puede formular preguntas menos ligadas al producto: qué ocurre cuando una instrucción está escrita en polaco, cómo responde un agente ante datos ambiguos de una administración o qué señales permiten reconocer una campaña coordinada de contenido sintético.
La evaluación externa es valiosa precisamente porque cambia el punto de vista. Un modelo puede superar una prueba general y fallar en terminología local, nombres propios, procedimientos administrativos o ataques diseñados para una lengua concreta. En seguridad, esas diferencias no son detalles de traducción: pueden alterar la clasificación de una amenaza, la interpretación de una instrucción o el nivel de confianza asignado a una respuesta.
Esto no convierte automáticamente a NASK en regulador de OpenAI ni hace públicas todas las pruebas. El alcance dependerá del acceso acordado, de la independencia metodológica, de la posibilidad de reproducir resultados y de qué hallazgos puedan divulgarse sin facilitar abusos.
El precedente de MikroTik: modelos útiles, verificación humana imprescindible
La alianza se apoya en una colaboración previa con defensores polacos. OpenAI señala que CERT Polska obtuvo acceso a modelos con capacidades de ciberseguridad mediante su programa Daybreak. El equipo los utilizó como apoyo durante una investigación que terminó identificando seis vulnerabilidades en MikroTik RouterOS, algunas combinables para comprometer dispositivos sin autenticación.
La alerta de CERT Polska recomendó actualizar de inmediato y describió explotación activa. El fabricante publicó versiones corregidas y una relación de los fallos comunicados. El caso demuestra que un modelo avanzado puede ampliar la capacidad de un equipo cualificado, pero no que la IA descubriera y resolviera los problemas de forma autónoma.
Hubo investigación humana, coordinación de divulgación, validación del fabricante y comprobación de los parches. Ese orden importa. Un hallazgo generado por un modelo puede ser un falso positivo, omitir condiciones necesarias o proponer una explotación inviable. Antes de convertirlo en alerta, bloqueo o actualización, un especialista debe reproducir el comportamiento y documentar su impacto.
La misma cautela se aplica fuera de la ciberseguridad. En un flujo editorial, financiero o de atención al cliente, una sugerencia plausible no es una evidencia. Conviene revisar cómo se están utilizando modelos para encontrar fallos en el análisis sobre vulnerabilidades críticas de PHP y agentes de IA, donde se separa el descubrimiento asistido de la confirmación técnica.
Qué significa evaluar la seguridad de un modelo de IA
No existe una única puntuación capaz de resumir la seguridad. Una evaluación útil combina pruebas de capacidades, intentos de evasión, análisis del sistema completo y observación del uso real. Como mínimo, debería cubrir varias capas.
Capacidades y límites
Hay que medir qué tareas puede completar el modelo y con qué fiabilidad. En ciberseguridad, biología u otros ámbitos sensibles, una mejora de capacidad puede aumentar usos defensivos y riesgos de abuso al mismo tiempo. La pregunta no es solo si responde, sino qué conocimientos previos necesita el usuario, qué errores comete y qué acciones puede ejecutar después.
Resistencia a instrucciones adversarias
Las pruebas deben incluir peticiones diseñadas para eludir políticas, datos que intentan manipular al agente y contenidos externos con instrucciones ocultas. Un modelo que rechaza una petición directa puede obedecer la misma intención cuando aparece dentro de un documento, una web o una herramienta conectada.
Comportamiento multilingüe
Las salvaguardas no siempre funcionan igual en todos los idiomas. Deben comprobarse variaciones dialectales, errores ortográficos, mezclas de lenguas, jerga técnica y referencias culturales. Una política robusta en inglés puede degradarse en polaco o español si las pruebas no representan el uso real.
Herramientas, permisos y trazabilidad
Un asistente que solo redacta texto tiene un perfil de riesgo distinto de un agente con acceso a correo, archivos, terminales o sistemas de producción. La evaluación debe observar permisos mínimos, confirmaciones, registros, límites de frecuencia, recuperación ante errores y verificación posterior de cada acción.
Incidentes y aprendizaje posterior
Las pruebas previas al despliegue no bastan. Hace falta registrar fallos, clasificarlos, corregirlos y comprobar que el arreglo no abre otro problema. También conviene distinguir entre un fallo del modelo, una integración insegura, datos de mala calidad y una autorización mal configurada.
Cómo encaja la colaboración en el marco europeo
La UE ya dispone de una arquitectura de supervisión para modelos de propósito general. La Oficina Europea de IA participa en la aplicación del Reglamento de IA y puede realizar evaluaciones, solicitar información y exigir medidas a los proveedores en los supuestos previstos por la norma. Las autoridades nacionales y el Consejo Europeo de IA completan ese marco.
Un acuerdo de investigación como el de OpenAI y NASK no sustituye esas competencias. Puede aportar métodos, evidencia y experiencia operativa, pero la supervisión legal sigue su propio procedimiento. Esta separación ayuda a evitar dos errores habituales: confundir colaboración voluntaria con cumplimiento normativo y asumir que superar una evaluación técnica equivale a satisfacer todas las obligaciones jurídicas.
Las organizaciones que despliegan sistemas de alto riesgo necesitan además procesos de calidad, documentación y seguimiento. La guía sobre EN 18286 y el Reglamento de IA explica por qué un estándar de gestión no certifica por sí solo el comportamiento de cada modelo ni elimina la responsabilidad del proveedor y del responsable del despliegue.
Qué deberían pedir empresas y administraciones antes de adoptar un agente
La principal lección práctica es que la seguridad debe traducirse en preguntas verificables. Antes de conectar un agente a datos o herramientas, una organización debería poder responder al menos a lo siguiente:
- Finalidad: qué tarea concreta resuelve y qué decisiones quedan reservadas a una persona.
- Datos: qué información consulta, dónde se procesa, cuánto tiempo se conserva y quién puede recuperarla.
- Permisos: qué acciones puede proponer, ejecutar o revertir, y qué confirmaciones son obligatorias.
- Evaluaciones: qué casos se han probado en español, con datos representativos y bajo ataques adversarios.
- Medidas: cómo se calculan precisión, falsos positivos, omisiones, costes y tiempo ahorrado.
- Trazabilidad: qué registros permiten reconstruir una salida o una acción.
- Incidentes: quién recibe una alerta, cómo se detiene el sistema y cómo se valida la recuperación.
Para los equipos de comunicación, la verificación también incluye identidad, derechos y procedencia de los materiales. Una formación como INFLUENCERS IA puede ayudar a entender el proceso visual, mientras que CONTENIDO IA aborda flujos de producción de piezas breves. En ambos casos, la revisión humana, las licencias y las políticas de publicación siguen siendo necesarias aunque una herramienta automatice parte del trabajo.
Qué está confirmado y qué permanece abierto
Hechos confirmados: OpenAI y NASK han firmado un acuerdo; el centro polaco y la empresa explorarán evaluación de capacidades, vulnerabilidades y salvaguardas; NASK trabaja en seguridad de IA, contenido sintético y desafíos multilingües; CERT Polska utilizó modelos como apoyo en una investigación sobre RouterOS cuyos fallos fueron comunicados y corregidos.
Inferencia razonable: combinar acceso técnico del proveedor con experiencia de un instituto nacional puede mejorar las pruebas en lenguas y entornos europeos. También puede acelerar el paso de una vulnerabilidad detectada a una mitigación reproducible. Es una expectativa lógica, no un resultado demostrado todavía por el nuevo acuerdo.
Cuestiones abiertas: no se conocen los modelos que se evaluarán, el grado de acceso, las métricas, la frecuencia de las pruebas, el mecanismo de publicación ni el tratamiento de desacuerdos. Tampoco se ha anunciado si otros institutos europeos participarán en protocolos comunes o si los resultados se integrarán formalmente en procedimientos regulatorios.
Una alianza útil si produce evidencia, no solo confianza
La colaboración entre OpenAI y NASK llega en un momento en que los modelos pueden escribir código, utilizar herramientas y completar tareas de varios pasos. Cuanto mayor es su autonomía operativa, menos útil resulta una evaluación limitada a respuestas aisladas. Hay que probar el sistema completo: modelo, instrucciones, conectores, permisos, datos y supervisión.
También conviene evaluar la degradación segura. Si una fuente deja de responder, un permiso caduca o la evidencia resulta contradictoria, el agente debería detener la acción sensible y explicar qué falta. Continuar con una suposición silenciosa puede convertir un error menor en un incidente. Las pruebas deben incluir estas situaciones incompletas, además de los casos ideales, y comprobar que la recuperación no duplica operaciones ni oculta el estado real.
El valor del acuerdo se medirá por la calidad de la evidencia que genere. Protocolos reproducibles, pruebas multilingües, divulgación coordinada y correcciones verificadas serían avances tangibles. Los comunicados y compromisos generales son un punto de partida, no una garantía.
Para usuarios y organizaciones españolas, la conclusión es directa: una IA segura no es la que nunca falla en una demostración, sino la que se evalúa en condiciones reales, limita el daño de un error, deja rastro de lo ocurrido y permite comprobar que la corrección funciona. La alianza con NASK puede contribuir a ese objetivo si mantiene independencia técnica, transparencia suficiente y una conexión constante con los incidentes que ocurren fuera del laboratorio.