El día que la nube se volvió blanco de guerra
El 1 de marzo, un dron iraní destruyó un datacenter de AWS en Emiratos Árabes. Por primera vez en la historia de la humanidad, la infraestructura cloud es blanco de guerra.
“Objects struck the data center, creating sparks and fire.”
Eso fue lo que apareció en el health dashboard de AWS a las 4:30 AM hora del Pacífico, el 1 de marzo de 2026. Objetos impactaron el datacenter. Chispas e incendio. Sin la palabra “dron”. Sin la palabra “ataque”. Sin la palabra “Irán”. Objects struck. Como si hubiera caído un rayo.
No fue un rayo.
Horas antes, la Guardia Revolucionaria Iraní había lanzado 189 misiles balísticos, 941 drones y 3 misiles crucero contra Emiratos Árabes Unidos. La mayor represalia desde la Operación Epic Fury, el bombardeo conjunto de Estados Unidos e Israel contra Irán iniciado el 28 de febrero. Entre los blancos: bases militares, terminales petroleras y, por primera vez en la historia, infraestructura de computación en la nube.
Los drones no alcanzaron una instalación. Alcanzaron tres. Dos datacenters de AWS en Emiratos Árabes con impacto directo. Un tercero en Bahréin, dañado por un ataque cercano. La región ME-CENTRAL-1 reportó 109 servicios afectados. Bancos como ADCB y Emirates NBD. Fintechs de pagos como Alaan y Hubpay. Careem, el Uber del Golfo. Snowflake, una de las plataformas de datos empresariales más usadas del mundo. Cientos de operaciones offline, sin fecha de recuperación.
Y luego vino lo que nadie esperaba. Fars News, la agencia estatal iraní, publicó una declaración: los ataques buscaban “identificar el rol de estos centros en el apoyo a las actividades militares y de inteligencia del enemigo.” Amazon declinó comentar.
El mensaje estaba enviado. Esto no fue daño colateral.
Un dron de menos de $50,000 dólares dejó offline infraestructura que servía a una economía entera. Y el comunicado de la empresa de cloud más grande del mundo no tenía las palabras para describirlo. Cuando diseñas para 99.99% de uptime, para redundancia, para failover automático, no diseñas para un dron.
Qué pasó
El 28 de febrero de 2026, a las 2:00 AM hora local de Teherán, aviones estadounidenses e israelíes iniciaron la Operación Epic Fury: ataques coordinados contra instalaciones nucleares y militares iraníes. Más de 300 objetivos en menos de 72 horas. La operación aérea más intensa contra Irán desde 1979.
La respuesta tardó horas, no días.
Entre el 1 y el 4 de marzo, la Guardia Revolucionaria lanzó 189 misiles balísticos, 941 drones y 3 misiles crucero contra Emiratos Árabes Unidos, Bahréin, Qatar y Arabia Saudita. Las defensas del Golfo interceptaron la mayoría: 161 de 174 misiles, los 8 crucero, 645 de 689 drones. Pero 44 impactaron. Tres civiles muertos. 78 heridos de más de quince nacionalidades.
Los blancos principales fueron bases militares. Al Dhafra Air Base en Abu Dhabi. Instalaciones navales en Bahréin. Terminales petroleras.
Pero hubo una categoría nueva: datacenters.
Tres instalaciones de Amazon Web Services alcanzadas entre el 1 y el 2 de marzo. Dos en Emiratos Árabes, parte de la región ME-CENTRAL-1, con impacto directo de drones. Una tercera en Bahréin, dañada por la onda de un ataque cercano. AWS reportó 109 servicios degradados o interrumpidos.
Las caídas en cascada fueron inmediatas. ADCB y Emirates NBD perdieron sus plataformas digitales. Alaan y Hubpay offline. Careem, la app de transporte dominante en la región, dejó de funcionar. Snowflake, plataforma de datos que usan miles de empresas globales, con interrupciones en toda la zona. Empresas de logística entre Dubai, Riad y Mumbai perdieron visibilidad de sus cadenas de suministro.
Cuarenta y ocho horas después, Fars News publicó su declaración: los ataques buscaban “identificar el rol de estos centros en el apoyo a las actividades militares y de inteligencia del enemigo.”
Amazon emitió un segundo comunicado: “In the UAE, two of our facilities were directly struck, while in Bahrain, a drone strike in close proximity to one of our facilities caused physical impacts to our infrastructure.”
Ningún otro cloud provider reportó daños. Microsoft, Google y Oracle operan en la región pero sus instalaciones no fueron alcanzadas.
Al momento de escribir esto, 7 de marzo, AWS aún no restablece completamente ME-CENTRAL-1.
La ficción que murió
Todos en tecnología hemos dicho la misma frase: “La nube no existe. Son los servidores de otra empresa.” Era un chiste. Una forma de recordar que detrás del marketing hay fierro, cables y aire acondicionado industrial.
Después del 1 de marzo, el chiste dejó de ser divertido.
Porque la conversación ya no es de quién son los servidores. Es dónde están. Y qué más corren ahí adentro.
AWS lanzó ME-CENTRAL-1 en agosto de 2022. Parte de una carrera entre Amazon, Microsoft, Google y Oracle por servir al Golfo: gobiernos, petroleras, operaciones de defensa. Negocio enorme. Nadie puso una nota al pie que dijera “esta infraestructura se convierte en blanco militar si la región entra en conflicto.”
Pero acá está lo que me preocupa.
Los modelos de inteligencia artificial que hoy se usan para planificación militar corren en infraestructura cloud. Los que optimizan rutas de drones, procesan imágenes satelitales, coordinan ataques. No estoy especulando. Project Nimbus es un contrato de $1.2 mil millones entre AWS, Google y el gobierno de Israel para proveer cloud e inteligencia artificial a sus fuerzas armadas. El JWCC es el contrato de $9 mil millones del Pentágono, repartido entre AWS, Google, Microsoft y Oracle.
No son contratos de almacenamiento. Son la columna vertebral computacional de operaciones militares activas.
Y acá se cierra el loop: la IA que planifica los ataques corre en los mismos servidores que reciben los drones de la represalia. Los modelos que procesaron imágenes satelitales de objetivos iraníes, que calcularon rutas de vuelo, que optimizaron el daño, vivían en infraestructura cloud en Medio Oriente. Irán no atacó el software. Atacó el fierro.
Primera vez que la infraestructura que hace posible una guerra se convierte en objetivo de esa misma guerra.
Piénsalo un segundo. La IA necesita datacenters. Los datacenters están en algún lugar físico. Ese lugar es blanco ahora. Y la IA que se usa para atacar ese lugar... también corre en datacenters.
El dato que nadie quiere discutir
En julio de 2021, cuando se filtró el contrato de Project Nimbus, más de 400 empleados de Google y Amazon firmaron una carta pública pidiendo que se cancelara. No querían que su tecnología se usara para vigilancia y operaciones militares.
Google y Amazon respondieron con la misma línea: el contrato era para “servicios generales de cloud computing”, no para “aplicaciones de armas.” La misma distinción que la industria nuclear intentó hacer durante décadas entre uso pacífico y armamento.
El problema tiene nombre técnico: dual-use. Un datacenter que sirve Netflix en Dubai puede correr modelos de targeting para un dron militar. El mismo GPU que entrena un modelo de lenguaje procesa imágenes satelitales para identificar baterías antiaéreas. La infraestructura es la misma. Lo que cambia es el prompt.
Y el problema no es chico. Project Nimbus: $1.2 mil millones, AWS y Google, cloud e inteligencia artificial para las fuerzas armadas y agencias de inteligencia israelíes. El contrato prohíbe a Google y Amazon negarle servicio a cualquier entidad del gobierno israelí, incluido su ejército. JWCC: $9 mil millones, el Pentágono repartiendo cargas de trabajo militar entre los cuatro grandes. Al cierre de 2024 ya se habían ejecutado casi $1,000 millones en órdenes de trabajo.
Después del 1 de marzo, el dual-use dejó de ser un debate ético de empleados incómodos. Se convirtió en un problema de derecho internacional.
El Protocolo de las Convenciones de Ginebra dice que la infraestructura civil no puede ser objetivo militar. Pero el Yale Law Journal publicó en 2024 un análisis que pone el dedo en la llaga: el derecho internacional humanitario no reconoce “objeto de uso dual” como categoría legal. Un objeto es civil o es militar. No hay punto medio. Y para que algo se convierta en objetivo legítimo, tiene que cumplir dos condiciones: que contribuya efectivamente a la acción militar, y que destruirlo ofrezca una ventaja militar concreta.
Un datacenter que corre modelos de IA para operaciones de defensa cumple ambas condiciones.
Eso significa que el mismo rack de servidores que procesa tu app de delivery puede ser objetivo legítimo bajo cierta lectura del derecho internacional, si tres racks más allá corre inteligencia de señales para una operación militar. No hay jurisprudencia. No hay precedente. El derecho humanitario fue escrito para un mundo donde una fábrica de tanques era una fábrica de tanques.
Y hay un dato más que está pasando desapercibido. Desde marzo de 2023, Lloyd’s of London exige que todas las pólizas de cyber-seguros incluyan cláusulas de exclusión para ataques cibernéticos respaldados por estados y operaciones durante conflictos armados. Si tu datacenter cae durante una guerra, tu póliza de cyber-riesgo no cubre. Tu póliza de propiedad probablemente tampoco, porque la mayoría excluyen actos de guerra.
¿Quién absorbe el costo? Nadie sabe todavía.
Lo que esto significa si eres CEO en Latinoamérica
Puedo escuchar el argumento: “Esto pasó en Medio Oriente. Es una guerra entre Irán, Estados Unidos e Israel. ¿Qué tiene que ver con mi operación en Santiago, Bogotá o Ciudad de México?”
Probablemente nada. Hoy. Latinoamérica no está en guerra y la probabilidad de que un dron caiga en un datacenter en São Paulo es cercana a cero. Pero eso no es lo relevante.
Lo relevante es que el 1 de marzo se estableció un precedente: los datacenters son blancos de guerra. Punto. Eso ya no se puede des-aprender. Cualquier planificador militar en cualquier país del mundo vio lo que pasó en UAE y tomó nota. Y cualquier aseguradora también.
Eso cambia las reglas del juego para todos, incluido el CEO latinoamericano que nunca pensó en geopolítica cuando firmó su contrato de cloud.
Primer cambio: la conversación sobre dónde están tus datos dejó de ser técnica. Hasta ahora, elegir una región de cloud era una decisión de latencia y compliance regulatorio. Ahora tiene una dimensión geopolítica. No porque São Paulo vaya a ser bombardeada, sino porque tu proveedor de cloud opera globalmente, tiene contratos militares en otras regiones, y el precedente de que eso convierte su infraestructura en objetivo ya existe.
Segundo cambio: el riesgo de concentración se ve diferente. AWS tiene tres regiones en Latinoamérica. Google Cloud tiene São Paulo, Santiago y Querétaro. Suena razonable hasta que entiendes que la redundancia geográfica ya no se trata solo de desastres naturales o fallas técnicas. Se trata de no tener todos tus datos en infraestructura de un proveedor que, en otra parte del mundo, es clasificable como objetivo militar.
Tercer cambio: los contratos de cloud y las pólizas de seguro que firmaste no contemplan esto. Las exclusiones de Lloyd’s por actos de guerra ya están vigentes. Tu SLA te garantiza uptime contra fallas de infraestructura, no contra un conflicto armado. Si mañana una escalada geopolítica afecta una región de AWS donde corren tus backups, ¿quién responde?
Nada de esto requiere pánico. Requiere que la próxima vez que revises tu arquitectura de cloud, la conversación incluya una pregunta que antes no existía: ¿qué más corre en la infraestructura donde viven mis datos, y qué implica eso en un mundo donde los datacenters son blancos militares?
Lo que viene después
Antes del 1 de marzo, la seguridad de un datacenter era un problema de ingeniería. Supresión de incendios. Acceso biométrico. Generadores redundantes. Enfriamiento líquido. Perímetro físico con guardias y cámaras. Todo diseñado para proteger contra incendios, fallos eléctricos, intrusos, desastres naturales.
Ningún datacenter del mundo fue diseñado para resistir un ataque militar.
Y ahora alguien tiene que responder la pregunta obvia: ¿qué sigue? ¿Los datacenters van a necesitar sistemas anti-dron como hoy tienen sistemas anti-incendio? ¿Escudos de interferencia electromagnética? ¿Defensa aérea perimetral? Suena ridículo hasta que recuerdas que un dron de $50,000 acaba de dejar offline tres instalaciones de la empresa de cloud más grande del planeta.
La pregunta no es si van a invertir en esto. La pregunta es quién paga. ¿AWS? ¿El gobierno del país donde está el datacenter? ¿El cliente enterprise que paga por disponibilidad? Los contratos actuales no dicen nada al respecto. Los SLAs cubren fallas de infraestructura, no actos de guerra. Las pólizas de seguro ya excluyeron este tipo de eventos. Hay un vacío y nadie quiere ser el primero en llenarlo.
Mientras tanto, el vocabulario del sector ya cambió. Antes del 1 de marzo hablábamos de uptime, latencia, compliance, data residency. Palabras de ingeniero. Problemas técnicos con soluciones técnicas.
Ahora la conversación incluye soberanía digital, riesgo geopolítico, uso dual, derecho humanitario, exclusiones de guerra. Palabras que ningún CTO esperaba tener que usar en una reunión de board.
Los cloud providers van a responder como saben: más regiones, más zonas de disponibilidad, más opciones de multi-cloud. Lo van a presentar como innovación. En realidad es una admisión: no pueden proteger un edificio de un dron, así que van a distribuir el riesgo geográficamente. La misma lógica de la disuasión nuclear aplicada a servidores.
No puedes defender un datacenter. Pero puedes hacer que destruir uno no sea suficiente.
El problema es que esa distribución cuesta. Cuesta en arquitectura, en latencia, en complejidad y en plata. Y ese costo lo va a pagar el cliente.
El 1 de marzo, la nube dejó de ser una metáfora. Se convirtió en lo que siempre fue: edificios, cables, generadores y las personas que los operan. Edificios que se pueden destruir. Cables que se pueden cortar.
Y la IA que supuestamente iba a protegernos, la que detecta amenazas, optimiza defensas, anticipa ataques, corre en esos mismos edificios.
Esa es la paradoja. No la resuelve un SLA. No la resuelve un contrato multi-cloud. La resuelve entender que la tecnología más poderosa que hemos construido depende de la infraestructura más vulnerable que tenemos. Y que alguien, por primera vez, decidió apuntar ahí.