Una guerra sin conexión

«La resiliencia no nace de confiar en que habrá conexión, sino de estar preparado para perderla». A medida que Estados Unidos incorpora inteligencia artificial a distintas ramas de sus fuerzas armadas, los combates en Oriente Próximo están poniendo de manifiesto el punto débil de esta estrategia: la IA necesita capacidad de cálculo y canales de comunicación, y en la guerra estos tienen la desagradable costumbre de desaparecer.

Los drones, los sensores, los sistemas de asistencia al apuntado y las herramientas de apoyo a la toma de decisiones dependen de una infraestructura informática. Destruir un solo centro de datos avanzado puede reducir considerablemente las capacidades de una unidad entera. Surgen preguntas prácticas: cómo cambiará su misión un dron sin conexión, cómo seguirá reconociendo objetos un modelo sin datos nuevos y a qué habrá que renunciar para que la IA resista una interrupción.

El conflicto en torno al estrecho de Ormuz sale caro, pero también está dejando a los militares lecciones dolorosas. Los centros de datos tradicionales de Oriente Próximo han demostrado ser vulnerables: los grandes edificios son fáciles de localizar y un solo ataque puede bastar para inutilizar una parte importante del sistema.

Palantir ya está desplegando una alternativa: contenedores con equipos de Nvidia. Se pueden situar más cerca del frente e integrar directamente en los procesos de trabajo, repartiendo la capacidad de cálculo entre varios emplazamientos en lugar de concentrarla en un único centro grande.

La empresa Scaleout está creando infraestructura para la IA en el borde y el aprendizaje federado. Este enfoque permite entrenar modelos con datos sensibles distribuidos sin tener que enviar todo el conjunto a un centro único. Scaleout ha colaborado con la OTAN, incluidas las Fuerzas Aéreas suecas, y con contratistas de defensa como BAE Systems.

Andreas Hellander, director ejecutivo y cofundador de Scaleout, explicó cómo hacer más resilientes los sistemas de IA de combate. Su principio fundamental es sencillo: no se puede prometer una conexión ininterrumpida, pero sí evitar que el fallo de un componente haga caer toda la capacidad del sistema.

Si un nodo pierde la conexión, continúa el análisis local con el último modelo aprobado y conserva las detecciones y la telemetría hasta que se restablezca el canal. Varios centros de agregación pueden dar servicio a los nodos periféricos: si uno falla, los clientes se redistribuyen y el entrenamiento prosigue a través de los puntos disponibles. Así, las capacidades se degradan gradualmente, en vez de pasar de golpe de «funciona» a «no hay nada».

La centralización ofrece una visión operativa común, gran capacidad de cálculo, controles de seguridad, aprobación de modelos y cumplimiento de las normas de mando. Pero concentra el riesgo: el daño a un solo canal o instalación puede privar a las tropas de una parte desproporcionadamente grande de sus capacidades. Además, transferir grandes conjuntos de datos o información secreta puede ser lento, estar prohibido o resultar físicamente imposible.

Una arquitectura distribuida procesa los datos cerca del sensor, reduce la latencia y mantiene las funciones locales cuando se interrumpe la conexión. El precio es la fragmentación. Decidir con una imagen incompleta o anticuada es peligroso, y la logística local puede resultar ineficiente para el conjunto de la fuerza. Por eso, el modelo más sensato es híbrido: coordinación centralizada cuando hay conexión y funciones locales claramente limitadas cuando se pierde. La autoridad sigue en manos del mando y de la persona que toma la decisión.

Conviene distinguir entre ejecutar un modelo y volver a entrenarlo. Las plataformas pequeñas suelen realizar inferencia, es decir, utilizan un modelo ya entrenado para reconocer elementos durante el vuelo. El reentrenamiento controlado y la aprobación de una nueva versión se llevan a cabo en una unidad terrestre o en un ordenador periférico más potente. El reentrenamiento autónomo durante una misión sigue siendo un campo de investigación y plantea serios problemas para verificar la fiabilidad.

Un dron conectado transmite detecciones, recibe tareas y contribuye a la imagen operativa común. Cuando pierde la conexión, sigue un plan aprobado de antemano: continúa con una tarea limitada, regresa, se mantiene en vuelo estacionario o aterriza, según la misión. El procesamiento a bordo mantiene la navegación y la percepción, pero la aeronave pierde el contexto externo, las nuevas órdenes y la coordinación con el grupo. La desconexión debe ser un modo de funcionamiento previsto, con límites claros, y no una emergencia improvisada.

A menudo, lo más difícil de transmitir no es el modelo, sino los datos útiles. Por eso se lleva el modelo hasta los datos, y no al revés. Los programas de aprendizaje activo seleccionan las imágenes que probablemente mejoren más el sistema: reconocimientos dudosos, objetos desconocidos o cambios en las condiciones. La persona sigue etiquetando el material; el programa simplemente le evita tener que buscar los fragmentos pertinentes.

Después, el modelo se ajusta en el lugar y se comprueba con un conjunto de control. La nueva versión puede funcionar en paralelo con la vigente, en modo sombra, hasta que el operador la apruebe. Si las normas y la conexión lo permiten, los emplazamientos intercambian actualizaciones protegidas del modelo, en vez de las grabaciones de vídeo originales. El aprendizaje federado reduce la cantidad de datos que hay que transferir, pero las actualizaciones siguen requiriendo protección, verificación y registro.

Las principales limitaciones son la alimentación eléctrica, el calor, el peso, el clima, las vibraciones, la guerra electrónica, la heterogeneidad de los datos y las actualizaciones seguras del software en flotas mixtas. La integración y la certificación pueden resultar tan complicadas como el propio modelo de aprendizaje automático.

El equipo informático ya está disponible: módulos de bajo consumo como NVIDIA Jetson sirven para plataformas pequeñas, mientras que los servidores GPU reforzados y los complejos periféricos en contenedores se destinan a instalaciones terrestres. La energía es más problemática. Cada procesador compite por recursos con el motor, los sensores y las comunicaciones, y las baterías, los generadores y los equipos de distribución aumentan la carga y los posibles puntos de fallo. En una demostración pública de Scaleout y BAE Systems Bofors, un sistema de reconocimiento funcionó en un ordenador a bordo a −18 °C y sin conexión. La regla práctica es usar la configuración mínima suficiente y considerar de antemano que tanto la energía como el ancho de banda pueden escasear.

Scaleout afirma que su plataforma funciona en la infraestructura del cliente, en redes aisladas y sin necesidad de conectarse al servidor de licencias, a la propia empresa ni a una nube pública. Esto reduce la dependencia de un proveedor remoto, que en un conflicto puede convertirse en una vulnerabilidad. Aun así, las decisiones sobre la relación con proveedores comerciales en tiempos de guerra corresponden a los responsables políticos, los juristas y las propias empresas; no es correcto sacar conclusiones sobre los modelos de riesgo de terceros sin datos.

Las comunicaciones mejorarán, también gracias a los satélites en órbita terrestre baja. Sin embargo, conectar directamente cada sensor al espacio no será una solución universal: los terminales requieren energía y espectro radioeléctrico, cuestan dinero y dejan una huella electrónica visible. Es más resiliente combinar redes malladas locales, sincronización cuando se presente la oportunidad y pasarelas independientes hacia canales por satélite o de largo alcance.

Es posible funcionar mucho tiempo sin conexión, pero el límite suele venir marcado por las baterías, el clima y el mantenimiento, no por el software. Y aquí es fundamental distinguir entre funcionar sin conexión y funcionar sin autoridad humana. Lo primero es una característica de resiliencia; lo segundo, una decisión política, jurídica y ética. El futuro de la IA militar no está en la autonomía sin control, sino en una gestión verificable: debe saberse qué modelo funcionaba en cada plataforma, quién lo creó y aprobó, cuáles son sus límites y por qué se le asignó una tarea concreta.