El 26 de febrero, Dario Amodei publicó una declaración formal diciendo que Anthropic no iba a ceder a dos demandas del Departamento de Defensa. El 27, el secretario de Defensa Pete Hegseth le puso un ultimátum con fecha y hora: hasta las 5:01 de la tarde del viernes. El día empezó con un artículo de CNBC titulado “Anthropic faces lose-lose scenario”. Y el 5 de marzo, el Pentágono hizo efectiva la designación. Anthropic es oficialmente, según el Departamento de Defensa de los Estados Unidos, un riesgo para la cadena de suministro nacional. Nunca antes esa etiqueta se había aplicado a una empresa del propio país. Cuando lo leí, mi reacción inmediata no fue política. Fue de oficio. Me pregunté cuántos equipos habían tomado la decisión de construir sobre los modelos de Anthropic sin haber pensado siquiera una vez en este tipo de escenario.
Quiero contar esta historia con cuidado, porque tiene varias capas y es fácil quedarse con la más ruidosa. La más ruidosa es la geopolítica: el gobierno de Trump vs. una empresa de IA, derechos civiles vs. capacidad militar, Silicon Valley vs. Washington. Eso es real y es importante, pero no es de lo que quiero hablar. Lo que me interesa de esta historia es lo que revela sobre las dependencias que construimos sin darnos cuenta, y sobre una dimensión de riesgo que casi nunca aparece en los mapas de arquitectura que miramos antes de elegir un proveedor.
La historia, tal como pasó#
Hay un contexto que la mayoría de los artículos sobre este episodio omite porque hace más incómodo el relato. En julio de 2025, Anthropic firmó un contrato con el Departamento de Defensa por 200 millones de dólares para “prototipar capacidades de IA de frontera que avancen la seguridad nacional de EE.UU.”. Claude fue el primer modelo de un laboratorio privado en integrarse en redes clasificadas del gobierno. En esas condiciones, Anthropic incluyó salvaguardas: ciertas aplicaciones estarían fuera de los términos del contrato.
La tensión escaló cuando, según fuentes consultadas por ethixbase360, el Pentágono apareció utilizando Claude en una operación que Anthropic consideró que excedía sus términos —la operación que derivó en la captura de Nicolás Maduro en Venezuela. Cuando Anthropic objetó ese uso, la administración Trump endureció su postura: quería acceso sin restricciones a Claude para cualquier uso legal, sin excepciones. Y Anthropic se negó.
El 26 de febrero, Dario Amodei publicó una declaración que me pareció uno de los documentos más interesantes que leí este mes. Allí explicó los dos límites que Anthropic no estaba dispuesto a cruzar en sus discusiones con el Departamento de Guerra de Estados Unidos: la vigilancia masiva doméstica y las armas completamente autónomas.
Sobre la primera, escribió que una IA poderosa permite ensamblar datos dispersos, individualmente inocuos, hasta construir un panorama completo de la vida de cualquier persona, de forma automática y a escala masiva. Sobre la segunda, sostuvo que los sistemas actuales de IA de frontera todavía no son lo suficientemente confiables como para impulsar armas completamente autónomas.
Y cerró con una frase que fue recogida por varios medios: “Estas amenazas no cambian nuestra posición: no podemos, en buena conciencia, acceder a su pedido”.
El Pentágono respondió a través de su vocero Sean Parnell, en un tono muy distinto: “Este es un pedido simple y de sentido común que va a evitar que Anthropic ponga en riesgo operaciones militares críticas y potencialmente ponga en peligro a nuestros combatientes. No vamos a dejar que NINGUNA empresa dicte los términos sobre cómo tomamos decisiones operacionales.” Emil Michael, el subsecretario de defensa para investigación e ingeniería, fue más directo aún: en X, llamó a Amodei “un mentiroso con complejo de Dios”.
La analista Lauren Kahn, del Centro de Seguridad y Tecnología Emergente de Georgetown, resumió lo que muchos en la industria pensaban pero no querían decir: “No hay ganadores acá. Le deja un gusto amargo a todos.” Sam Altman, el CEO de OpenAI —competidor directo de Anthropic— dijo públicamente que no creía “que el Pentágono debería estar amenazando con la Ley de Producción de Defensa contra estas empresas”.
Más de 330 empleados de Google y OpenAI firmaron una carta abierta titulada “We Will Not Be Divided”, pidiendo a sus líderes que “se unieran para seguir rechazando las demandas actuales del Departamento de Guerra de obtener permiso para usar nuestros modelos para vigilancia doméstica masiva y matar personas de forma autónoma sin supervisión humana”.
el 5 de marzo, con la designación formal, se cierra el primer capítulo de una disputa que probablemente tenga muchos más.
Las dos líneas que Anthropic no cruzó#
Quiero detenerme un momento en el contenido del desacuerdo, porque es importante para entender la dimensión técnica del problema.
Las dos excepciones que Anthropic mantuvo —vigilancia masiva doméstica y armas completamente autónomas— no son caprichosas. Son exactamente los dos casos donde la IA generativa de última generación amplifica de forma cualitativa, no solo cuantitativa, lo que ya era posible antes. Para la vigilancia: la capacidad de ensamblar datos dispersos en un perfil integro ya existía, pero requería esfuerzo humano o sistemas especializados. Un modelo de lenguaje poderoso lo hace a escala industrial, en tiempo real, sobre cualquier persona. Para las armas autónomas: la capacidad de tomar decisiones complejas en contextos de incertidumbre alta existe desde hace tiempo en software especializado, pero los modelos de frontera introducen una capa de razonamiento y adaptación que hace el problema cualitativamente diferente.
Lo que esto revela es una tensión que va a estar presente durante mucho tiempo: quién controla los límites de uso de una capacidad tecnológica que está integrada en sistemas críticos. El Pentágono sostiene que, si firmaron un contrato para usar una herramienta en misiones de defensa nacional, la empresa no debería poder dictar qué misiones están dentro o fuera del contrato. Anthropic sostiene que, si su tecnología puede ser usada para cosas que consideran incompatibles con valores democráticos, tienen tanto derecho como obligación de poner condiciones.
Ninguna de las dos posiciones es absurda. Y esa es, precisamente, la incomodidad. No es una disputa entre bueno y malo; es una disputa entre dos principios legítimos —la soberanía operacional de un Estado y la responsabilidad ética de quien construye la herramienta— que en este caso concreto colisionaron.
La pregunta que me queda de esto no es quién tiene razón. Es: ¿queremos un mundo donde los proveedores de modelos de IA que usamos tienen condiciones de uso que pueden entrar en conflicto con los intereses del gobierno del que dependemos, o de otros gobiernos? Y si la respuesta es “depende”, ¿cómo mapeamos ese riesgo?
Ya lo habíamos visto antes, aunque no lo llamábamos igual#
Esta historia no es completamente nueva. La lógica de fondo —un proveedor que en un momento puede cambiar sus términos por razones completamente fuera de nuestro control— ya la discutimos antes, aunque con otros nombres y otros mecanismos.
Cuando escribí sobre las dependencias invisibles, el disparador era técnico: un paquete que cambiaba de licencia, una biblioteca que dejaba de mantenerse. El patrón era el mismo: construimos sobre algo que funciona, dejamos de mirarlo, y cuando cambia el costo llega junto.
Cuando escribí sobre la confianza como vulnerabilidad, el escenario era de seguridad: un atacante que usaba en su favor la confianza implícita que depositamos en software que nunca revisamos. La lección era que la confianza es a la vez nuestra fortaleza y nuestra fragilidad.
Cuando analicé los grandes apagones, el patrón era el mismo en los tres casos: una dependencia asumida sólida que colapsó de formas que nadie anticipó, y cuyo fallo se propagó mucho más lejos de lo que el diseño original preveía.
Lo que agrega esta saga es una dimensión que en todos esos casos estaba ausente: el riesgo no técnico, no de seguridad, sino político e institucional. Y esa dimensión siempre existió en la infraestructura tecnológica, pero en el ecosistema de los modelos de IA era prácticamente invisible. Porque los proveedores de modelos no son como los proveedores de nube: están en un campo que está siendo regulado y disputado geopolíticamente con una intensidad que los proveedores de infraestructura tradicional no enfrentaron, al menos no con esta velocidad.
El precedente que no queremos recordar#
No llegamos a este momento sin historia previa. La idea de que los gobiernos puedan presionar o influir sobre el acceso a tecnología crítica no es nueva —lo nuevo es que la tecnología en cuestión son los modelos de IA que usamos en producción.
A lo largo de las últimas décadas, varios episodios mostraron que cuando una empresa tecnológica alcanza posición dominante en infraestructura crítica, su relación con los gobiernos se complica de formas que nadie anticipó cuando la empresa era pequeña. Las revelaciones de 2013 sobre el programa PRISM —que documentó cómo la NSA accedía a datos de usuarios de las principales plataformas tecnológicas de EE.UU., en algunos casos con colaboración activa de las empresas y en otros a través de acceso compulsivo— mostraron que el Estado puede operar dentro de la infraestructura tecnológica de formas que ningún usuario o cliente corporativo había asumido. No hace falta tener certeza sobre los detalles de cada caso particular para reconocer el patrón general: cuando algo se vuelve infraestructura crítica, los gobiernos quieren tener algo que decir sobre cómo funciona.
El caso Huawei es otro ángulo del mismo problema, desde el lado opuesto: un proveedor de infraestructura de telecomunicaciones que fue bloqueado en múltiples mercados occidentales por razones de seguridad nacional, independientemente de la evidencia técnica específica sobre cada producto. Lo que importa aquí no es si el bloqueo fue justificado o no —eso es un debate para el que no tengo la información ni la especialidad— sino que mostró claramente que los mercados de infraestructura crítica pueden cerrarse por razones políticas con una velocidad que nadie que haya construido dependencias sobre ese proveedor anticipaba.
Los modelos de IA están entrando en esa misma categoría, y lo están haciendo mucho más rápido de lo que les llevó a las plataformas de datos o a las empresas de telecomunicaciones. Y como casi siempre pasa, el problema se hace visible justo cuando la dependencia ya está construida y sería costoso deshacerla.
La nueva capa que falta en nuestros mapas de dependencias#
Cuando mapeamos las dependencias de un sistema tecnológico, pensamos en capas: la base de datos, el proveedor de nube, las bibliotecas de software, las APIs externas. Cada capa puede fallar de formas técnicas conocidas: un bug, una caída de servicio, un cambio en la API.
Lo que la IA agrega —y que casi no aparece en esos mapas— es una capa nueva: el proveedor del modelo. Y ese proveedor tiene tres características que lo distinguen de cualquier capa de dependencia anterior.
Primero, el modelo no es intercambiable a costo bajo. Cambiar de Claude a GPT, o a un modelo abierto local, no es como cambiar de un servicio de almacenamiento a otro. Los comportamientos son distintos, los prompts hay que ajustarlos, los flujos que se construyeron asumiendo cierto estilo de respuesta pueden no funcionar igual. El costo de cambio es real, acumulativo, y casi nunca se mide antes de que sea necesario pagarlo.
Segundo, el proveedor del modelo está sujeto a riesgos que los proveedores de infraestructura tradicional no enfrentan con la misma intensidad: regulación específica de IA que está cambiando en tiempo real, presión de múltiples gobiernos con intereses distintos, y posiciones éticas o comerciales que pueden hacerlos objeto de restricciones sin precedente. Esta semana lo vimos con Anthropic, pero OpenAI, Google y Microsoft no son inmunes al mismo tipo de presión —desde EE.UU., desde Europa con el AI Act, desde China para sus propias empresas.
Tercero, la dependencia de un modelo de IA no es solo técnica: es epistémica. Si construimos flujos de trabajo donde el modelo toma decisiones, genera contenido, analiza datos, y ese modelo deja de estar disponible o cambia de manera significativa, no solo perdemos un servicio: perdemos la capacidad de operar de la manera que aprendimos durante meses a operar. Esa pérdida no se recupera en un fin de semana.
La designación de Anthropic como supply chain risk tiene una consecuencia práctica inmediata que vale la pena entender: las empresas que fabrican productos o prestan servicios al Departamento de Defensa —que son muchas más de lo que parece en un primer vistazo— ahora deben certificar que no usan modelos de Anthropic. Esto no afecta directamente a quien no trabaja con el gobierno estadounidense, pero es la primera vez que el Estado puede, por decisión política, sacar a un proveedor de modelos del mercado de toda una categoría de clientes. Y si puede hacerlo con Anthropic en EE.UU., otros gobiernos pueden hacerlo con otros proveedores en otros mercados, por otras razones.
En los equipos donde me toca trabajar este tema, esta conversación aparece cada vez más seguido. No alcanza con preguntarnos qué modelo responde mejor, cuál es más barato o cuál tiene la ventana de contexto más grande. También tenemos que preguntarnos qué tan atados estamos a ese proveedor si mañana cambia sus condiciones, su disponibilidad, sus políticas de uso o queda alcanzado por una restricción externa.
Por eso intento pensar las implementaciones de IA menos como una integración directa contra un modelo específico y más como una capa de agentes, procesos y memoria propia que pueda conectarse a distintos LLM según la necesidad. El objetivo no es abstraer la IA como si todos los modelos fueran iguales, porque no lo son. El objetivo es no construir procesos críticos alrededor de una dependencia que después no podamos reemplazar sin romper la forma en que trabajamos.
La objeción honesta#
Antes de seguir, quiero nombrar el argumento en contra de todo lo que dije hasta acá, porque existe y es legítimo.
La saga Anthropic-Pentágono involucra a una empresa que tiene contratos directos con el Departamento de Defensa de los Estados Unidos por 200 millones de dólares. La mayoría de los equipos que usan Claude en producción no tienen ni remotamente esa exposición: usan la API para tareas internas, para asistentes de código, para análisis de datos. La probabilidad de que una restricción gubernamental afecte ese uso cotidiano en el corto plazo es baja.
Eso es verdad. Y sin embargo, hay dos razones por las que la historia importa más allá del caso específico.
La primera es que la designación de supply chain risk afecta a toda la cadena de proveedores del gobierno, no solo a los contratistas directos. Una empresa que hace software para una empresa que hace software para el Departamento de Defensa también puede verse afectada. Las cadenas de proveedores son largas y las dependencias son opacas, exactamente como veíamos con el post sobre las dependencias invisibles.
La segunda es más amplia: lo que importa de este episodio no es el resultado final de esta disputa específica —que puede resolverse en semanas o escalar durante meses— sino lo que revela sobre una categoría de riesgo que casi nadie había mapeado. El riesgo de que el proveedor de un modelo que usamos en producción sea restringido, presionado, o cambie sus términos por razones ajenas a la calidad del producto es real, existe independientemente de que involucre al Pentágono, y es un riesgo que la industria todavía no sabe bien cómo pensar.
El riesgo de sobrediversificar los proveedores de modelos también es real: mantener integraciones paralelas con múltiples modelos es costoso y puede introducir inconsistencias peores que la dependencia original. No es una receta para correr tres modelos en paralelo por las dudas. Es una invitación a hacerse la pregunta antes de construir la dependencia, no después.
Qué conviene hacerse antes de que el hipotético se vuelva concreto#
Para los apagones de AWS y Cloudflare, escribí que la resiliencia no está en pretender que las caídas no van a pasar, sino en diseñar asumiendo que van a pasar. La lección análoga para este episodio es más incómoda porque el diseño tiene que anticipar no solo fallas técnicas sino también decisiones políticas.
El ejercicio que vale la pena hacer —y que la mayoría de los equipos no hace, igual que no mapeaba sus dependencias técnicas antes de que alguna se cayera— es simple: para los modelos que usamos en producción, ¿sabemos qué pasaría si mañana ese modelo deja de estar disponible? No hace falta tener un plan de contingencia detallado. Hace falta, al menos, haber pensado la respuesta una vez en frío. ¿El impacto es bajo, hay sustitutos razonables, el costo de cambio es manejable? Bien. ¿O la respuesta honesta es que no sabemos, que nunca lo pensamos, y que si eso pasara estaríamos a ciegas? Eso conviene saberlo antes de que alguien nos obligue a averiguarlo a las apuradas.
Hay un segundo plano de la pregunta que es más difícil. La dependencia de un modelo de IA no es solo “¿puedo cambiar de proveedor?”. Es también “¿sobre qué condiciones de uso construimos nuestros flujos de trabajo?”. Si los prompts, las integraciones, los comportamientos que asumimos están afinados para un modelo con un determinado perfil ético y de seguridad, y ese perfil cambia —porque el proveedor cedió ante una presión que nosotros no veíamos venir— ¿sabemos qué cambia en el sistema que construimos encima? Esa pregunta casi nunca aparece en las evaluaciones que hacemos antes de integrar un modelo.
Lo más honesto que puedo decir es que no tengo una respuesta práctica clara para esto. La industria está aprendiendo a pensar estas dependencias en tiempo real, al mismo tiempo que las construye. Lo que sí me parece claro es que el mapa de riesgos que usamos para evaluar proveedores de IA va a tener que crecer para incluir una dimensión que hoy casi no existe en él: no solo la calidad técnica, no solo el precio, no solo la disponibilidad, sino también la estabilidad institucional y el perfil de riesgo político del proveedor. No porque eso sea fácil de medir, sino porque esta semana quedó claro que ignorarlo no es gratis.
Lo que me queda de esta semana#
Me resulta llamativo que la designación formal de hoy haya llegado casi sin sorpresa. El sector tecnológico venía siguiendo esta historia desde el 26 de febrero como si fuera inevitable, resignado a que el desenlace iba a ser este aunque nadie lo quisiera. Esa sensación de inevitabilidad me dice algo sobre cómo percibimos estas tensiones: las vemos venir, pero no tenemos todavía las herramientas conceptuales ni los procesos para responder antes de que escalen.
La paradoja que más me pesa de todo esto es la que subrayó el propio Amodei en su declaración: el Pentágono las dos cosas al mismo tiempo, que Anthropic es un riesgo para la cadena de suministro Y que Claude es esencial para la seguridad nacional. Una designación los pone afuera del mercado de contratistas del gobierno; la otra reconoce que sin Claude hay operaciones que se complican. Esa contradicción no es solo burocrática: es la contradicción de fondo de la IA como infraestructura crítica. Necesitamos estas capacidades; y precisamente porque las necesitamos, su control se vuelve objeto de disputa.
Eso va a seguir pasando, con Anthropic y con otros. Y cada vez que pase, la pregunta va a rebotar sobre todos los que construyeron dependencias sin haberla pensado antes.
¿En sus equipos alguna vez evaluaron un proveedor de modelos de IA con la misma pregunta que harían sobre un servicio de nube crítico: qué pasa si mañana deja de estar disponible, o cambia los términos de forma que no controlamos? ¿Y si la respuesta es no, cuándo sería el mejor momento para hacerse esa pregunta: ahora, o cuando ya sea urgente?
Fuentes consultadas#
- Dario Amodei, “Statement from Dario Amodei on our discussions with the Department of War”, Anthropic, 26 de febrero de 2026.
- CNBC, “Anthropic faces lose-lose scenario in Pentagon conflict as deadline for policy change looms”, 27 de febrero de 2026. (Fuente de las citas de Amodei, Parnell, Michael, Kahn y Altman.)
- Politico, “Pentagon formally designates Anthropic a supply-chain risk”, 5 de marzo de 2026.
- WVIA / NPR, “Pentagon labels AI company Anthropic a supply chain risk”, 5 de marzo de 2026.
- ethixbase360, “Compliance Implications of Anthropic’s Dispute with the Pentagon”. (Contexto de la operación Venezuela/Maduro como detonante del conflicto.)