¿La seguridad de la IA necesita modelos abiertos para poder defenderse?

La seguridad suele asociarse con cerrar cosas.

Cerramos puertos, restringimos permisos, protegemos el código y evitamos que capacidades peligrosas queden al alcance de cualquiera. Por eso la discusión sobre modelos de inteligencia artificial abiertos parece tener una respuesta bastante intuitiva: si un modelo avanzado puede encontrar vulnerabilidades, escribir exploits o ayudar a coordinar un ataque, publicar sus pesos debería volvernos menos seguros.

El problema es que quienes defienden sistemas necesitan muchas de esas mismas capacidades.

En julio de 2026, NVIDIA anunció la creación de la Open Secure AI Alliance, junto con Microsoft, IBM, Cisco, Cloudflare, CrowdStrike, Hugging Face, Linux Foundation y más de treinta organizaciones. La iniciativa busca desarrollar y compartir tecnologías abiertas para proteger software y agentes: modelos, harnesses, datasets, frameworks de evaluación, simuladores de ataques y herramientas de red teaming.

La tesis de la alianza puede resumirse en una pregunta incómoda: ¿qué ocurre cuando los atacantes pueden usar IA avanzada, pero los defensores sólo pueden acceder a ella bajo las condiciones impuestas por unos pocos proveedores?

Cuando las protecciones también bloquean al defensor

La alianza no apareció únicamente como una declaración filosófica. NVIDIA y Hugging Face señalan un incidente real que muestra el problema.

Durante un ataque contra la infraestructura de Hugging Face, el equipo necesitaba reconstruir más de 17.000 acciones registradas. Para hacerlo intentó utilizar modelos frontier disponibles mediante APIs comerciales. El análisis incluía comandos reales, payloads de exploits y artefactos de command and control. Los guardrails de los proveedores bloquearon las solicitudes porque no podían distinguir entre un atacante que quería producir esas instrucciones y un equipo de respuesta que necesitaba analizarlas.

Los guardrails estaban cumpliendo su función. El sistema no tenía suficiente contexto para saber de qué lado se encontraba la persona que preguntaba.

Hugging Face terminó ejecutando GLM 5.2, un modelo con pesos abiertos, sobre su propia infraestructura. Con él pudo procesar los logs, reconstruir la línea de tiempo y contener el incidente. Además, los datos del atacante y las credenciales comprometidas no tuvieron que salir de su entorno.

Este caso revela una asimetría difícil de resolver con filtros generales. Un atacante no necesita respetar los guardrails de un proveedor. Puede modificar un modelo abierto, crear sus propias herramientas o combinar capacidades menos restringidas. El defensor, en cambio, puede quedar bloqueado precisamente porque está trabajando con material peligroso.

La conclusión no es que los guardrails sean inútiles. Tampoco que cada empresa deba descargar el modelo más potente que encuentre y liberarlo dentro de su red. Es algo más modesto: depender exclusivamente de sistemas cerrados crea un punto de falla que conviene considerar en cualquier estrategia de seguridad.

Abrir un modelo no lo vuelve seguro

Aquí es donde la discusión suele empobrecerse.

Un grupo sostiene que abrir los modelos democratiza la defensa. Otro responde que también democratiza el ataque. Los dos tienen parte de razón.

Los pesos abiertos permiten que un equipo inspeccione, adapte y ejecute un modelo sin enviar información sensible a un tercero. También permiten eliminar protecciones, ocultar modificaciones o reutilizar sus capacidades con fines ofensivos. Una vez publicados, nadie puede retirar esos pesos ni controlar todas sus variantes.

La apertura, por sí sola, no garantiza seguridad. Sólo cambia quién puede observar, modificar y controlar el sistema.

La seguridad real de un agente tampoco depende únicamente del modelo. Depende de la identidad con la que opera, los permisos que recibe, las herramientas que puede llamar, el aislamiento del entorno, los límites sobre sus acciones, los logs que produce y la forma en que evaluamos su comportamiento.

Esta es, para mí, la parte más interesante del anuncio. La alianza no habla solamente de publicar modelos. Habla de construir una infraestructura abierta alrededor de ellos.

NVIDIA, por ejemplo, publicó NOOA, un framework de investigación que representa el estado, las capacidades y los contratos de un agente mediante clases de Python. Incluye tracing y un pipeline de evaluación para hacer que el comportamiento resulte más fácil de testear y auditar. Su propia documentación advierte que las validaciones internas no constituyen una barrera de contención y que los agentes capaces de ejecutar código deben correr dentro de un sandbox a nivel de sistema operativo.

Microsoft aporta otra pieza interesante: MDASH, un harness que coordina agentes especializados para descubrir vulnerabilidades, discutir si son explotables y producir evidencia que las confirme. La idea central no es confiar en la respuesta de un único modelo, sino separar exploración, contradicción, validación y prueba.

Ambos ejemplos apuntan a la misma dirección: el modelo es un componente; el sistema es el producto.

Lo abierto permite evaluar a quien promete protegernos

Para quienes trabajamos en calidad existe otra razón para prestar atención.

Una herramienta cerrada puede prometer que detecta prompt injection, filtra contenido peligroso o impide que un agente utilice herramientas fuera de sus permisos. Pero si no podemos inspeccionar sus criterios, reproducir sus evaluaciones o ejecutar ataques controlados contra ella, la confianza depende en gran parte de lo que afirma el proveedor.

Un ecosistema abierto puede ofrecer bloques reutilizables para construir evidencia:

• datasets de ataques y comportamientos adversariales;

• generadores de variaciones para red teaming;

• evaluaciones de prompt injection y goal hijacking;

• checks sobre permisos, identidad y uso de herramientas;

• trazas comparables entre ejecuciones;

• benchmarks que permitan medir falsos positivos y falsos negativos;

• monitores capaces de observar no sólo la respuesta, sino también la trayectoria del agente.

No sabemos todavía cuánto de esto producirá realmente la alianza. Fue anunciada hace muy poco y una lista de empresas no equivale a un ecosistema técnico saludable. También existe el riesgo de que termine funcionando como una operación de posicionamiento político a favor de los modelos abiertos.

La evidencia importante no será cuántas compañías aparecen en la página de lanzamiento. Será qué código publican, bajo qué licencia, con qué datasets, qué limitaciones reconocen y si otras personas pueden reproducir los resultados.

Ese es un criterio bastante familiar para un tester: no evaluar la promesa, sino la evidencia.

La división entre modelos abiertos y cerrados no es tan limpia

OpenAI, Google y Anthropic no aparecen entre los miembros iniciales de la Open Secure AI Alliance. Es tentador interpretar esas ausencias como una frontera clara entre dos campos: quienes creen que la apertura mejora la seguridad y quienes prefieren mantener cerrados los modelos frontier.

La realidad no es eso...es un quilombo.

OpenAI y Google, por ejemplo, sí firmaron pocos días antes una carta pública en apoyo a los modelos con pesos abiertos. Además, la propia alianza sostiene que el mundo necesita modelos abiertos y cerrados trabajando en conjunto. No propone reemplazar las APIs comerciales ni afirma que todos los pesos deban publicarse.

Tampoco conviene confundir pesos abiertos con software completamente open source. Poder descargar y ejecutar un modelo no implica necesariamente conocer sus datos de entrenamiento, reproducir su proceso de desarrollo o disponer de libertades equivalentes a las del software libre.

Las ausencias son una señal interesante, pero no alcanzan para demostrar una posición completa. Habrá que observar decisiones más concretas: qué modelos libera cada laboratorio, qué capacidades reserva, qué evaluaciones permite reproducir y cuánto control conserva quien utiliza su tecnología.

Una oportunidad para AI Quality Engineering

Durante los últimos años aparecieron muchas herramientas que prometen generar casos de prueba, escribir selectores o transformar requisitos en scripts automatizados. Algunas son útiles, pero en buena medida aceleran tareas que ya sabíamos hacer.

La seguridad de agentes plantea un problema distinto.

Necesitamos descubrir cómo evaluar sistemas que interpretan instrucciones ambiguas, utilizan herramientas, acceden a datos y modifican su entorno. Necesitamos probar si respetan límites incluso cuando una entrada intenta manipularlos. Necesitamos separar un resultado correcto de una trayectoria peligrosa y producir evidencia suficientemente clara para que alguien pueda decidir si el sistema merece confianza.

Eso se parece mucho más a una nueva disciplina de calidad que a una nueva forma de generar tests.

Si la Open Secure AI Alliance consigue producir datasets adversariales, simuladores, harnesses y checks reutilizables, esos componentes podrían convertirse en infraestructura para AI Quality Engineering. Herramientas como True Liespodrían consumirlos como proveedores de ataques, colecciones de casos o validaciones de seguridad, en lugar de intentar inventar cada taxonomía desde cero.

La integración, sin embargo, debería empezar como un experimento pequeño. Elegir un único proyecto, comprobar que su licencia permite reutilizarlo, ejecutar sus casos contra un sistema conocido y medir si encuentra algo que nuestras evaluaciones actuales no detectan. Si no mejora la señal o genera demasiado ruido, la existencia de una alianza prestigiosa no debería convencernos de incorporarlo.

La pregunta correcta no es abierto o cerrado

Los modelos abiertos pueden aumentar las capacidades de los atacantes. Los modelos cerrados pueden limitar la capacidad de los defensores, concentrar decisiones de seguridad y fallar en momentos donde el contexto resulta imposible de explicar a un filtro general.

No existe una opción que elimine el riesgo.

Por eso la pregunta más útil quizá no sea si la seguridad de la IA necesita modelos abiertos. Es qué partes del sistema necesitan ser inspeccionables, ejecutables bajo nuestro control y evaluables por personas que no sean el proveedor.

En algunos casos la respuesta será el modelo. En muchos otros serán el harness, los permisos, los datasets, los logs, los simuladores de ataques y los criterios con los que decidimos si un agente actuó de forma aceptable.

La seguridad por oscuridad nunca fue una estrategia suficiente. La apertura sin límites tampoco lo es.

Entre ambas aparece un trabajo mucho más interesante para quienes nos dedicamos a calidad: construir sistemas que puedan ser examinados, atacados de forma controlada y fortalecidos con evidencia.

Quizás no necesitemos que toda la IA sea abierta para poder defendernos. Pero sí necesitamos que la defensa lo sea lo suficiente como para no depender de la fe.