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

Llevo casi tres años integrando IA en la forma en que mis equipos crean y entregan software. Así que, cuando esta semana se supo que el gobierno de EE. UU. 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. Eso es lo 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 controló su exportación a 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 manera 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. Para el 12 de junio, ya no estaban.

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é pasó

Esta es la versión resumida.

Mythos 5 resultó ser excepcionalmente bueno para encontrar vulnerabilidades de software. O sea, muy bueno. Tiene la capacidad de descubrir errores que llevaban décadas ocultos en bases de código. Luego, un investigador encontró un jailbreak que desbloqueaba esas capacidades de detección de vulnerabilidades de formas que Anthropic nunca tuvo previstas. El gobierno evaluó la situación y decidió que representaba un riesgo para la seguridad nacional, por temor a que sus adversarios usaran Mythos para descubrir y aprovechar vulnerabilidades de día cero a gran escala.

Entonces, 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 tuvo otra opción real. Desactivó Fable 5 y Mythos 5 para todos.

Anthropic cuestiona la gravedad real de lo ocurrido. Afirma que el jailbreak era limitado y que la respuesta fue totalmente desproporcionada. Hay argumentos razonables de ambos lados, y mi colega Stephen Thoemmes escribió un análisis detallado de lo ocurrido y de cómo el sector de la seguridad siempre ha abordado las capacidades de uso dual. Lee su artículo para conocer los detalles. Este artículo trata sobre lo que significa.

Problema 1: tu proveedor de IA ahora es un riesgo en 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 o lo que fuera), el 12 de junio te despertaste y esa capacidad simplemente... había desaparecido. Sin aviso de descontinuación. Sin plazo para migrar. Sin un «mantendremos todo funcionando durante 90 días mientras encuentras una alternativa». Simplemente desapareció.

Eso es un incidente en la cadena de suministro.

Como sector, llevamos años aprendiendo, a veces a las malas, que nuestras cadenas de suministro de software son frágiles. Vimos a un solo mantenedor eliminar en masa paquetes de npm y afectar a la mitad de internet. Vimos SolarWinds. Vimos Log4Shell. Creamos SBOM y herramientas de análisis de dependencias, además de toda una categoría de herramientas para gestionar el riesgo de que el código de alguien más desaparezca o se vuelva malicioso sin que nos demos cuenta.

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

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 hecho, sin decirlo, que mañana seguirá disponible. Esta semana hizo estallar esa suposición. Y, a diferencia de una biblioteca que puedes fijar a una versión e incluir en tu repositorio, no puedes almacenar en caché un modelo que se ejecuta en los servidores de otra persona. Cuando desaparece, desaparece.

Este es el problema al que mi equipo se dedica en Snyk: hacer que la seguridad acompañe a tu código y a tus agentes, para que no sea algo que, en la práctica, alquilas del proveedor del modelo que integraste primero. La recomendación práctica es poco emocionante, 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 el día en que desaparezca.

Problema 2: prohibir las capacidades defensivas no detiene a los atacantes

Ahora, hablemos del aspecto 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 consiguieran, podrían descubrir y aprovechar vulnerabilidades de día cero más rápido que nunca. Es una preocupación real. No voy a restarle importancia.

Pero aquí está la pregunta que no he visto que suficiente gente se haga: ¿quién sale perjudicado cuando prohíbes una herramienta que encuentra vulnerabilidades?

Los atacantes que quieren encontrar y aprovechar vulnerabilidades no van a presentar los documentos ni a cumplir una directiva de control de exportaciones. Nunca lo han hecho. Eso es, en esencia, lo que define a un atacante. No siguen las reglas. Si un Mythos con jailbreak puede encontrar vulnerabilidades de día cero, esa capacidad ya está disponible. El jailbreak se publicó. No puedes deshacerlo.

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 los atacantes lleguen primero.

La ciberseguridad siempre ha sido una carrera armamentista. Lo ha sido desde que existe el sector. La premisa central de 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. Haces pruebas de penetración en tus propios sistemas. Ejecutas las mismas herramientas que usaría un atacante, pero contra tu propia infraestructura, para encontrar primero las brechas.

Si les quitas esa capacidad a todos los que juegan según las reglas, no frenas en absoluto a los atacantes. Solo dejas a los defensores en peor posición que ayer. Y casi todo lo que vale la pena en seguridad tiene esta doble cara: por naturaleza, es de uso dual. El artículo de Stephen explica cómo el sector siempre ha manejado esa tensión, desde la divulgación coordinada hasta los controles por capas. Mi versión es más breve: si retiras una capacidad cada vez que pueda usarse indebidamente, el interruptor terminará apuntando a quienes realmente están defendiendo.

Esto sienta un precedente peligroso

Quiero dejar algo claro. Entiendo por qué actuó el gobierno. La seguridad nacional es un asunto serio, y da mucho miedo pensar que Estados nación hostiles utilicen una IA que genere vulnerabilidades de día cero en masa. Estas preocupaciones no son triviales.

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

Ahora hemos establecido 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 filtración confirmada. Un jailbreak que podría usarse teóricamente para hacer daño.

Ahora llevemos esa lógica a sus consecuencias. ¿Qué pasa cuando el próximo modelo sea increíble para detectar anomalías en el tráfico de red y esa misma capacidad pueda usarse para vigilar? ¿Qué pasa cuando un modelo sea excelente para generar parches de seguridad y, en teoría, también se pueda inducir a generar código de explotación? Casi todas las capacidades realmente útiles en seguridad son de uso dual por naturaleza. No es un error. Así es este campo.

Si reaccionamos así cada vez, los defensores terminarán luchando con una mano atada a la espalda, mientras que los atacantes, que de todos modos nunca iban a respetar un control de exportaciones, seguirán teniendo libertad de acción.

Nadie estará más seguro. Solo sentiremos que hicimos algo.

Qué debe hacer bien el sector de la seguridad

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

Necesitamos un marco real para las capacidades de IA de uso dual. «Prohibirla por completo porque no podemos resolver cómo controlar el acceso» es una medida demasiado drástica. Llevamos décadas manejando esa tensión mediante la divulgación responsable, las licencias, los marcos legales y las normas comunitarias, no prohibiendo las herramientas. Debemos aplicar esa misma perspectiva 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 el software en la práctica. 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 incorporar resiliencia en su estrategia de IA desde ahora. No esperes a que retiren el próximo modelo. Si estás creando flujos de trabajo críticos con IA que no controlas, necesitas planes de contingencia desde 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 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 para 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 seguirles el ritmo. Esa brecha entre lo que la tecnología puede hacer y lo que las reglas permiten es donde reside el verdadero riesgo.

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

Prefiero que lo hagamos bien a que lo hagamos rápido. Pero debemos iniciar la conversación ahora, porque las decisiones que tomemos hoy darán forma al panorama de 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.