El gobierno acaba de prohibir un modelo de IA: la perspectiva de un ingeniero

He pasado buena parte de los últimos tres años integrando IA en la forma en que mis equipos desarrollan y entregan software. Así que, cuando esta semana se supo que el gobierno de Estados Unidos había desactivado efectivamente un modelo de IA, me sorprendí de verdad. No para un país. No para una empresa. Para todas las personas del planeta, al mismo tiempo.

Tres días. Ese fue el tiempo que estuvieron disponibles los modelos Fable 5 y Mythos 5 de Anthropic antes de que el gobierno ordenara desactivarlos para todos.

No se restringió su acceso. No se impusieron controles de exportación para una lista de países. Se desactivaron. Por completo. Para todos los usuarios. Técnicamente, la orden apuntaba al acceso de personas extranjeras, pero Anthropic no tenía una forma confiable de distinguir en tiempo real a las personas extranjeras de las personas estadounidenses. Así que, para cumplirla, retiró ambos modelos para todos. Se lanzaron el 9 de junio. Desaparecieron el 12 de junio.

Si trabajas en seguridad, esto debería captar toda tu atención. No por la política, sino por lo que nos dice sobre dónde estamos y hacia dónde vamos.

Qué ocurrió

Aquí va la versión breve.

Resultó que Mythos 5 era excepcionalmente bueno para encontrar vulnerabilidades de software. Es decir, muy bueno. Tan bueno que podía sacar a la luz errores que llevaban décadas ocultos en bases de código. Después, un investigador encontró un jailbreak que desbloqueó esas capacidades de detección de vulnerabilidades de maneras que Anthropic nunca tuvo la intención de permitir. El gobierno consideró que eso representaba un riesgo para la seguridad nacional, por temor a que sus adversarios usaran Mythos para descubrir y convertir en armas vulnerabilidades de día cero a gran escala.

Así que el gobierno emitió una directiva de control de exportaciones y, como Anthropic no podía distinguir de forma confiable a las personas estadounidenses del resto, no tenía muchas opciones. Desactivó Fable 5 y Mythos 5 para todos.

Anthropic cuestiona la gravedad real del caso. Afirma que el jailbreak era limitado y que la respuesta fue totalmente desproporcionada. Es razonable debatirlo, y mi colega Stephen Thoemmes escribió un análisis detallado de lo ocurrido y de cómo el campo de la seguridad siempre ha lidiado con las capacidades de doble uso. Lee ese análisis para conocer los detalles. Este artículo trata sobre lo que significa.

Problema 1: tu proveedor de IA ahora es un riesgo para la cadena de suministro

Hablemos de eso de lo que nadie quiere hablar.

Si tu equipo de ingeniería había integrado Fable 5 o Mythos 5 en algún flujo de trabajo (revisión de código, clasificación de vulnerabilidades, análisis de seguridad, lo que fuera), el 12 de junio despertaste y esa capacidad simplemente... había desaparecido. Sin aviso de descontinuación. Sin período para migrar. Sin un «mantendremos todo funcionando durante 90 días mientras buscas una alternativa». Simplemente desapareció.

Eso es un incidente de la cadena de suministro.

Como sector, llevamos años aprendiendo, a veces a la fuerza, que nuestras cadenas de suministro de software son frágiles. Vimos a una sola persona mantenedora borrar en masa paquetes de npm y dejar fuera de servicio a medio internet. Vimos SolarWinds. Vimos Log4Shell. Creamos SBOM y herramientas de análisis de dependencias, además de toda una categoría de soluciones para gestionar el riesgo de que el código de otra persona desaparezca o se vuelva malicioso sin que nos demos cuenta.

Así que aquí va mi pregunta: ¿cuántos de nosotros pensamos con ese mismo rigor en el acceso a modelos de IA?

La mayoría de los equipos trata el acceso a modelos de IA como un servicio básico. Te registras, obtienes una clave de API, la integras en tu flujo de trabajo y das por sentado que mañana seguirá ahí. Esta semana hizo añicos esa suposición. Y, a diferencia de una biblioteca que puedes fijar a una versión e incluir en tu repositorio, no puedes guardar en caché un modelo que se ejecuta en los servidores de otra persona. Cuando desaparece, desaparece.

En Snyk, mi equipo dedica sus días a resolver este problema: integrar la seguridad en tu código y tus agentes, para que no sea algo que, en la práctica, estés alquilando al proveedor del primer modelo que integraste. La conclusión práctica es sencilla, pero importante: trata el acceso a modelos como cualquier otra dependencia que no controlas. Ten una alternativa. Coloca una capa de abstracción delante. Ten un plan para cuando una mañana ya no esté disponible.

Problema 2: prohibir capacidades defensivas no detiene a los atacantes

Ahora, hablemos del ángulo de la ciberseguridad, que es donde esto se vuelve realmente incómodo.

La preocupación del gobierno es bastante sencilla. Mythos 5 es tan bueno para encontrar vulnerabilidades que, si los adversarios lo obtuvieran, podrían descubrir y explotar vulnerabilidades de día cero más rápido que nunca. Es una preocupación real. No voy a restarle importancia.

Pero aquí va una pregunta que no he visto hacer lo suficiente: ¿quién sale perjudicado cuando se prohíbe una herramienta que encuentra vulnerabilidades?

Los atacantes que quieren encontrar y explotar vulnerabilidades no van a presentar documentos ni a cumplir una directiva de control de exportaciones. Nunca lo han hecho. Eso es prácticamente lo que define a un atacante: no sigue las reglas. Si un Mythos con jailbreak puede encontrar vulnerabilidades de día cero, esa capacidad ya está ahí afuera. El jailbreak se publicó. No se puede dar marcha atrás.

Entonces, ¿quién sí sale perjudicado? Los defensores. Los investigadores de seguridad. Los equipos de empresas como la tuya, que intentan encontrar y corregir vulnerabilidades antes de que lleguen los atacantes.

La ciberseguridad siempre ha sido una carrera armamentista. Lo ha sido desde que existe el sector. La premisa de toda la seguridad moderna de aplicaciones es que los defensores necesitan capacidades al menos iguales a las de los atacantes, y de ser posible, mejores. Analizas tu propio código antes de que alguien más lo haga. Pones a prueba tus propios sistemas. Ejecutas las mismas herramientas que usaría un atacante, dirigidas a tu propia infraestructura, para encontrar primero los puntos débiles.

Si se les quita esa capacidad a todos los que respetan las reglas, no se frena en absoluto a los atacantes. Solo se deja a los defensores en peor situación que ayer. Y casi todo lo valioso en seguridad tiene dos caras, así funciona el doble uso. El artículo de Stephen explica cómo el sector siempre ha gestionado esa tensión, desde la divulgación coordinada hasta los controles por capas. Mi versión, más breve, es esta: si retiramos una capacidad cada vez que se pueda usar indebidamente, el interruptor terminará apuntando a quienes realmente están a la defensiva.

Esto sienta un precedente peligroso

Quiero dejar algo claro. Entiendo por qué actuó el gobierno. La seguridad nacional es un asunto serio, y da verdadero miedo pensar que Estados nación hostiles puedan usar una IA capaz de generar vulnerabilidades de día cero a gran escala. No son preocupaciones triviales.

Pero me preocupa más el precedente que el incidente.

Ahora sabemos que se puede desactivar un modelo de IA para todos, en todo el mundo y sin aviso, ante un escenario de uso indebido potencial. No un ataque real. No una vulneración confirmada. Un jailbreak que podría, en teoría, usarse para hacer daño.

Ahora llevemos esa lógica un paso más allá. ¿Qué pasa cuando el siguiente modelo sea extraordinario para detectar anomalías en el tráfico de red y esa misma capacidad pueda usarse para vigilar? ¿Qué pasa cuando un modelo sea muy bueno para generar parches de seguridad y, en teoría, también se lo pueda inducir a generar código de explotación? Casi todas las capacidades realmente útiles en seguridad son de doble uso por naturaleza. Eso no es un error: es parte esencial de este campo.

Si reaccionamos así cada vez, los defensores terminarán peleando con una mano atada a la espalda, mientras los atacantes, que nunca iban a respetar un control de exportaciones, conservan las dos manos libres.

Nadie estará más seguro por eso. Solo tendremos la sensación de haber hecho algo.

Qué debe hacer bien el sector de la seguridad

Entonces, ¿qué hacemos ahora? No pretendo tener todas las respuestas, pero hay algunas cosas que vale la pena decir en voz alta.

Necesitamos un marco real para las capacidades de IA de doble uso. «Prohibirla por completo porque no sabemos cómo controlar el acceso» es una solución demasiado drástica. Durante décadas hemos gestionado esa tensión mediante la divulgación responsable, las licencias, los marcos legales y las normas de la comunidad, no prohibiendo las herramientas. Tenemos que aplicar ese mismo criterio a la IA, en lugar de recurrir al interruptor de apagado.

La comunidad de seguridad debe participar en las decisiones. Esta decisión la tomaron reguladores comerciales, no las personas que dedican sus días a pensar en cómo proteger realmente el software. No es una crítica al Departamento de Comercio. Los controles de exportación son su responsabilidad. Pero las consecuencias para la seguridad defensiva son enormes, y quienes las entienden deben tener un lugar en la mesa antes de la próxima decisión, no después.

Las empresas deben desarrollar resiliencia en sus estrategias de IA desde ahora. No esperes a que retiren el próximo modelo. Si estás creando flujos de trabajo críticos sobre una IA que no controlas, necesitas planes de contingencia hoy: estrategias con varios proveedores, capas de abstracción y alternativas. Trata esto como el riesgo para la cadena de suministro que realmente es.

Y, mira, en Snyk creemos que poner herramientas de seguridad en manos de los desarrolladores y ahora también de los agentes de IA hace que el software sea más seguro, no menos. Cuantas más personas puedan encontrar y corregir vulnerabilidades, más seguros estaremos todos. Eso ha sido cierto con el análisis estático, las bases de datos de vulnerabilidades de código abierto y todas las capacidades de seguridad que hemos logrado democratizar. Estoy convencido de que también será cierto para la seguridad impulsada por IA.

La respuesta a «esta herramienta es poderosa» debería ser «asegurémonos de que las personas adecuadas puedan usarla de manera responsable». No «asegurémonos de que nadie pueda usarla».

El tiempo se acaba

Estamos en un punto de inflexión. Las capacidades de IA en seguridad avanzan rápidamente, y los marcos normativos intentan ponerse al día. La brecha entre lo que la tecnología puede hacer y lo que permiten las reglas es donde reside el verdadero riesgo.

La prohibición de Fable 5 y Mythos 5 de esta semana anticipa una conversación mucho más amplia, que tendremos durante años. La forma en que gestionemos la IA de doble uso en ciberseguridad determinará si los defensores mantienen el ritmo de los atacantes o quedan rezagados para siempre.

Prefiero que lo hagamos bien a que lo hagamos rápido. Pero tenemos que iniciar la conversación ahora, porque las decisiones que tomemos hoy definirán el panorama de la seguridad durante mucho tiempo.

Y mientras tanto, revisa tus dependencias de IA. En serio. Ahora mismo. Porque si algo nos enseñó esta semana, es que el modelo del que dependes hoy quizá no esté disponible mañana.