Cuando un gobierno retira un modelo de IA: qué significa la suspensión de Fable 5 y Mythos 5 para los equipos de seguridad

La noche del 12 de junio de 2026, Anthropic deshabilitó el acceso a dos de sus modelos más recientes, Claude Fable 5 y Claude Mythos 5, para todos sus clientes en todo el mundo. La empresa no lo hizo debido a una interrupción del servicio ni a una falla que hubiera detectado por cuenta propia. Lo hizo para cumplir una directiva de control de exportaciones del gobierno de EE. UU., recibida a las 5:21 p. m., hora del este, que invocaba facultades de seguridad nacional.

Para quienes trabajan en seguridad, los detalles importan más que la política: cuál fue realmente el detonante informado, cómo se desarrolló la medida y qué revela sobre depender del modelo de otra empresa. Son preguntas sobre las que los equipos de seguridad pueden actuar, independientemente de su postura en el debate sobre políticas.

Qué ocurrió realmente con Fable 5 y Mythos 5 de Anthropic

Conviene ser precisos, porque la versión abreviada que circula en línea («el gobierno prohibió el modelo para todo el mundo») no coincide exactamente con lo que indican los registros.

Según la declaración de Anthropic, la directiva ordenaba a la empresa «suspender todo acceso a Fable 5 y Mythos 5 por parte de cualquier ciudadano extranjero, dentro o fuera de Estados Unidos, incluidos los empleados de Anthropic que fueran ciudadanos extranjeros». En principio, la restricción apuntaba al acceso de ciudadanos extranjeros, no al de todos los usuarios.

El cierre global fue la consecuencia práctica. Como explicó Anthropic: «el efecto neto de esta orden es que debemos deshabilitar de manera abrupta Fable 5 y Mythos 5 para todos nuestros clientes a fin de garantizar el cumplimiento». No hay una forma confiable de distinguir en tiempo real a los ciudadanos extranjeros de las personas estadounidenses entre una base de usuarios de cientos de millones, y menos aún con aviso el mismo día. Por eso, la empresa apagó los modelos para todos. Esa distinción importa: la orden apuntaba al acceso de ciudadanos extranjeros, pero, en la práctica, la única forma de hacerla cumplir con tan poco aviso era cerrar el acceso para todos.

El motivo declarado fue un supuesto «jailbreak de IA». Así describió Anthropic las pruebas que recibió: «el gobierno solo nos ha proporcionado pruebas verbales de un posible jailbreak limitado y no universal, que básicamente consiste en pedirle al modelo que lea una base de código específica y corrija cualquier falla de software». La empresa agregó que «el nivel de capacidad que se mostró está ampliamente disponible en otros modelos (incluido GPT-5.5 de OpenAI) y los equipos defensivos que protegen los sistemas lo usan todos los días».

El gobierno no ha publicado la directiva y la carta no proporcionó una base técnica específica, por lo que la información pública depende en gran medida del relato de Anthropic. Las capacidades cibernéticas de los modelos de frontera son un motivo legítimo de preocupación para la seguridad nacional, y los informes indican que la directiva se emitió a raíz de la afirmación de un tercero sobre un jailbreak. Lo que se puede analizar aquí es la naturaleza de la medida y cómo se compara con las prácticas de seguridad establecidas, no los detalles clasificados que la motivaron.

El detonante informado: análisis y corrección de código

Pedirle a un modelo que lea una base de código y corrija sus fallas no es un ataque exótico. Es una revisión automatizada de código y una corrección de vulnerabilidades, el mismo trabajo que realizan el análisis estático, los fuzzers, la revisión de código asistida por IA y cualquier ingeniero de seguridad que ejecuta un análisis antes de un lanzamiento. Es una capacidad que los equipos defensivos usan habitualmente y, como ocurre con la mayoría de las capacidades de seguridad, tiene usos tanto defensivos como ofensivos.

La comunidad técnica lo señaló rápidamente. En Hacker News, un comentarista lo planteó así: «Si lo entendí bien, el “jailbreak” consiste en pedirle al modelo que corrija la base de código y entonces revela las fallas. Parece una brecha casi imposible de corregir sin sacrificar una gran capacidad. Uno quiere que pueda corregir su base de código». No existe un modelo de programación capaz de corregir vulnerabilidades que no pueda también describirlas.

En los días previos a la suspensión, algunos investigadores de seguridad se quejaban justo de lo contrario: que las barreras de protección de Fable 5 eran demasiado estrictas para el trabajo defensivo legítimo. Valentina Palmiotti, de IBM X-Force, le dijo a TechCrunch que el modelo «rechaza cualquier solicitud que pueda tener alguna relación, aunque sea tangencial, con la ciberseguridad». En la misma semana, se criticó al modelo por ser demasiado restrictivo para los equipos defensivos y se lo retiró por una capacidad usada con fines defensivos.

Las capacidades tienen usos tanto defensivos como ofensivos, una característica bien conocida en seguridad. Un escáner de puertos, un analizador de paquetes, un fuzzer, un motor SAST, un depurador y una prueba de concepto de corrupción de memoria son herramientas «ofensivas» o «defensivas» según quién las use y con qué propósito. No prohibimos nmap ni clasificamos Wireshark como un arma. En general, el campo de la seguridad ha concluido que no se puede mejorar la defensa si se prohíben las herramientas que esta necesita.

Cómo aborda el campo de la seguridad los riesgos de doble uso

El problema general es antiguo: existe una capacidad poderosa y podría usarse de forma indebida. El campo de la seguridad lleva décadas desarrollando una respuesta, y esa respuesta aporta un contexto útil, cualquiera que sea la conclusión sobre esta medida en particular. Se basa en varias disciplinas.

Divulgación coordinada. Cuando alguien descubre una falla grave, la norma establecida es reportarla de forma privada a la parte que puede corregirla, acordar un plazo y publicarla una vez que haya una solución. El objetivo de la divulgación responsable es reducir el daño y, a la vez, hacer avanzar el ecosistema. Según Anthropic, solo recibió pruebas verbales de un posible jailbreak y no le comunicaron por escrito los hallazgos específicos. El gobierno no ha descrito públicamente su propio proceso.

Defensa en profundidad. No se espera que ningún control por sí solo sea perfecto, por eso se combinan varios y se asume que algunos fallarán. Anthropic afirma que diseñó Fable 5 precisamente con este principio y lo explicó en su lanzamiento: «sospechamos que actualmente ningún proveedor de modelos puede lograr una resistencia perfecta a los jailbreaks». Por eso, la estrategia consistía en hacer que los jailbreaks fueran «limitados [...] o muy costosos de producir» y «combinar esto con una supervisión exhaustiva para detectar y detener rápidamente cualquier ataque exitoso». Es la misma lógica que guía la seguridad de aplicaciones por capas: análisis en el IDE, comprobaciones en el pull request, controles en CI y supervisión en producción. No se espera que nunca se cuele nada. Se espera que las capas detecten y contengan lo que sí se cuele.

Priorización basada en el riesgo. Los programas de seguridad maduros no tratan cada hallazgo como una emergencia máxima, porque eso es imposible y contraproducente. Cuando se publica una CVE crítica en un paquete popular de npm, el ecosistema no desconecta todo npm. Evalúa la posibilidad de explotación y reachability, prioriza los casos que realmente importan, aplica parches y verifica los resultados. Todo el enfoque de Snyk para proteger el código generado por IA y para la seguridad de aplicaciones en general se basa en esta idea: la gravedad es necesaria, pero no suficiente. La pregunta útil siempre es «¿cuáles de estos riesgos son reales, alcanzables y los más importantes para atender primero?». Los equipos de seguridad rara vez se enfrentan a una opción binaria y absoluta entre activar o desactivar todo; la práctica consiste en encontrar una respuesta gradual que se ajuste al riesgo real.

Es difícil determinar cómo se ajusta esta medida en particular a esas prácticas a partir de la información pública, ya que el gobierno no ha descrito su proceso. Estas prácticas ofrecen un marco de referencia compartido para el debate que siguió.

Cómo se dividieron las reacciones ante la suspensión de Fable 5

La reacción pública se dividió rápidamente. Una línea de argumentación señaló que Anthropic había pedido públicamente que el gobierno tuviera autoridad sobre los despliegues de IA y que ahora objetaba que se aplicara esa autoridad. En su declaración, Anthropic estuvo de acuerdo en que los gobiernos deberían poder bloquear despliegues inseguros, pero solo «como parte de un proceso legal transparente, justo y claro, basado en hechos técnicos», y afirmó que «esta medida no respeta esos principios». La base declarada por el gobierno fue la seguridad nacional, una preocupación reconocida en torno a las capacidades cibernéticas de los modelos de frontera, y los informes indican que la directiva se emitió tras la afirmación de un tercero sobre un jailbreak. Las pruebas específicas no se han hecho públicas.

Otras reacciones tuvieron poco que ver con cualquiera de las partes. Los desarrolladores que habían integrado Fable 5 en sus sistemas se centraron en la confiabilidad, y muchos consideraron que el episodio era un argumento a favor de los modelos de pesos abiertos o alojados por cuenta propia, cuyo acceso no se puede cortar desde fuera. Algunos lo interpretaron, con escepticismo, como publicidad previa a una salida a bolsa. Simon Willison registró el minuto en que se interrumpió el acceso.

También hay precedentes. En la década de 1990, Estados Unidos consideró la criptografía robusta como munición controlada y restringió su exportación. Finalmente, los tribunales estadounidenses determinaron que publicar código de seguridad es una forma de expresión protegida. Esos controles restringían las exportaciones; no obligaban a desconectar un producto ya implementado para los usuarios nacionales, una de las diferencias de este caso.

El aspecto de la confiabilidad que los equipos de seguridad no pueden ignorar

Dejemos de lado las cuestiones legales, porque hay una lección operativa que se mantiene independientemente de cómo se resuelva el debate sobre políticas.

Una sola directiva dejó fuera de servicio un producto de disponibilidad general para toda su base de usuarios global en cuestión de horas. Para cualquiera que hubiera integrado Fable 5 en un flujo de trabajo, la disponibilidad del modelo podía revocarse por fuerzas fuera de su control y del de su proveedor. Quienes desarrollaban con el modelo y reaccionaron en tiempo real llegaron a una conclusión evidente: contar con modelos redundantes es ahora un requisito de resiliencia, no solo una consideración de costos o rendimiento. Tratar un único modelo alojado como una dependencia imprescindible crea un punto único de falla. Y los puntos únicos de falla son un problema de seguridad, ya sea que fallen por una interrupción del servicio, un problema de facturación, un cambio de políticas o una carta del gobierno.

Esta es la misma disciplina que Snyk aplica al resto de la cadena de suministro de software. No puedes gestionar lo que no puedes ver. Por eso, conocer tu radio de impacto de la IA, hacer un inventario de dónde residen realmente los componentes y las dependencias de IA en tus sistemas mediante el descubrimiento de activos, y planificar cómo responder a la falla de cualquiera de ellos se está convirtiendo en un requisito básico. La suspensión de Fable 5 demuestra en tiempo real por qué.

Mejor en conjunto: el papel de las herramientas de seguridad

Sea cual sea el resultado del debate sobre políticas, los equipos de seguridad deben seguir operando. La pregunta práctica es cómo gestionar en el día a día las capacidades de IA de doble uso, y el campo de la seguridad cuenta con prácticas consolidadas para hacerlo. En Snyk, ya vemos cómo se desarrolla esta situación en las propias herramientas de IA: nuestro estudio ToxicSkills auditó casi 4,000 habilidades de agentes de IA y encontró que más de un tercio tenía al menos una falla de seguridad, desde inyección de instrucciones hasta secretos expuestos y malware propiamente dicho.

La divulgación coordinada, los controles por capas, la supervisión continua y la priorización basada en el riesgo no son conceptos abstractos. Son prácticas cotidianas que permiten al mundo seguir lanzando software, aunque se descubran vulnerabilidades constantemente. Se aplican directamente al desarrollo y la operación con IA:

• Protege continuamente el código que generan estos modelos. La IA escribe más código y más rápido, pero no todo es seguro. Analizar el código generado por IA en el momento en que se crea y en el pull request, con correcciones automatizadas cuando sea posible, permite mantener la velocidad y la seguridad en armonía. Este es el eje de las recomendaciones de Snyk sobre desarrollar de forma segura con IA y sobre los enfoques de nivel de tipos para generar código seguro con IA.

• Establece barreras de protección para el comportamiento de la IA. Por lo general, la unidad de control útil es la acción, no el modelo entero. El trabajo de Snyk sobre las barreras de protección para asistentes de programación con IA y el futuro de la seguridad de los agentes de IA refleja este enfoque: limita lo que puede hacer un agente, supervísalo e intervén de forma específica.

• Trata los sistemas de IA como parte de la superficie de ataque que ya gestionas. La inyección de prompts, la divulgación de información confidencial y las demás categorías de la lista OWASP Top 10 para LLM son riesgos de las aplicaciones y se pueden abordar con prácticas de seguridad de aplicaciones. Los hallazgos de ToxicSkills mencionados arriba son exactamente ese tipo de riesgo: real, medible y manejable con las herramientas y los procesos que los equipos de defensa ya tienen.

La mayoría de los equipos empieza por proteger el código generado por IA. Este breve recorrido de Snyk muestra cómo hacerlo en la práctica:

Play Video: The Secret to Secure AI Code

El secreto para proteger el código generado por IA (Cómo mantener seguro el código escrito por IA a medida que aumentan su volumen y velocidad)

Nada de esto exige elegir entre «la IA es segura» y «la IA es peligrosa». Es el mismo enfoque que adopta la industria de la seguridad ante cualquier tecnología poderosa: asumir que existe un riesgo, crear capas para gestionarlo, divulgarlo y remediarlo de forma coordinada, y asegurarse de que los equipos de defensa cuenten con las herramientas necesarias.

Qué deben tener en cuenta los equipos de seguridad y quienes desarrollan software

1. No dependas por completo de un único modelo alojado. Incorpora redundancia de modelos y alternativas que permitan continuar con normalidad en los sistemas importantes. La disponibilidad que no controlas es un riesgo para el que debes prepararte.

2. Haz un inventario de los lugares de tu stack donde se usa IA. No puedes evaluar el alcance del impacto sin descubrir primero tus activos. Identifica qué servicios, pipelines y productos dependen de cada modelo y componente de IA.

3. Analiza el código generado por IA de forma predeterminada, no como algo secundario. El volumen y la velocidad del código escrito por IA hacen que analizarlo al crearlo y en las solicitudes de cambios, junto con la remediación automatizada, sea la forma práctica de mantener el ritmo.

4. Prioriza las medidas de protección y el monitoreo por encima de los interruptores de emergencia. Limita las acciones, observa el comportamiento e intervén de forma precisa. Reserva la eliminación completa para los casos que realmente lo justifiquen y define de antemano cuáles son.

5. Practica la divulgación coordinada y espérala de los demás. Un hallazgo que no puedes ver es un hallazgo que no puedes corregir. Exige pruebas y un plan de remediación, y ofrece lo mismo a los demás.

Conclusión

La suspensión de Fable 5 y Mythos 5 seguirá siendo objeto de debate jurídico y político durante algún tiempo. Personas razonables tendrán opiniones distintas sobre si los gobiernos deberían poder desconectar un modelo ya implementado. Para los equipos de seguridad, las conclusiones duraderas no dependen de quién tenga razón. La capacidad en el centro de la disputa es una que los equipos de defensa usan habitualmente. El resultado práctico —la retirada en cuestión de horas de una dependencia disponible en todo el mundo— demuestra claramente la importancia de la redundancia y la visibilidad.

Las capacidades poderosas y de doble uso no son un problema nuevo, y el sector de la seguridad ya tiene un plan para abordarlas: contar con suficiente redundancia de modelos para no depender por completo de un solo proveedor, saber dónde se usa IA en tu stack, analizar el código generado por IA a medida que se incorpora, establecer límites a lo que puede hacer la IA en lugar de recurrir a interruptores de emergencia y practicar la divulgación coordinada en ambas direcciones. Aplicar estas medidas de forma continua permite a los equipos seguir lanzando software frente a los riesgos de doble uso. Ahí es donde encajan las herramientas de seguridad, incluida Snyk. Ese es el camino para avanzar mejor juntos.