La inteligencia artificial en defensa necesita algo más que modelos potentes: debe poder operar dentro del perímetro autorizado, con datos protegidos, trazabilidad y autoridad humana efectiva. En entornos sensibles o con conectividad limitada, la arquitectura debe conservar las funciones esenciales de forma segura, degradarse sin perder el control y sincronizarse de nuevo cuando las comunicaciones lo permitan.
Esta capacidad no equivale a aislar toda la tecnología ni a automatizar decisiones críticas. Significa diseñar una IA gobernable, interoperable y resiliente, donde cada organización pueda decidir qué se ejecuta localmente, qué servicios externos acepta y qué dependencias no puede asumir.
En defensa, la autonomía tecnológica útil no consiste en retirar al ser humano del proceso. Consiste en mantener capacidad de operar, verificar, intervenir y detener el sistema incluso cuando cambian la conectividad, el proveedor o las condiciones del entorno.
Qué significa desplegar inteligencia artificial en defensa
Aplicar IA en defensa abarca realidades muy distintas: mantenimiento predictivo, análisis documental, apoyo logístico, gestión del conocimiento, detección de anomalías, simulación, ciberseguridad o asistencia a equipos técnicos. Cada caso utiliza datos diferentes, interviene en procesos con distinta criticidad y exige límites específicos.
Por eso no existe una única “arquitectura de defensa”. Un asistente que consulta documentación pública puede admitir servicios compartidos. Un sistema que procesa información sensible, trabaja sobre una plataforma desplegada o necesita responder con comunicaciones degradadas requerirá controles reforzados y mayor capacidad local. La decisión debe partir del proceso y del riesgo, no de una preferencia tecnológica.
La Agencia Europea de Defensa vincula la confianza en la IA aplicada a defensa con dimensiones como la gobernanza, la seguridad, la fiabilidad y la soberanía. Su marco no prescribe una solución universal, pero sí convierte una pregunta abstracta en una decisión operativa: ¿qué partes del sistema deben permanecer controlables para que la misión, el dato y la responsabilidad no dependan de un elemento inaccesible?
Por qué la autonomía local se ha convertido en una cuestión estratégica
Una solución que solo funciona con acceso continuo a un servicio remoto puede ser adecuada para muchos procesos corporativos. En un entorno con comunicaciones intermitentes, latencia elevada, restricciones de transferencia o necesidad de continuidad, esa dependencia puede convertirse en el principal punto de fallo.
La OTAN describe una infraestructura digital que conecta servicios seguros desde la nube hasta el edge. La relevancia empresarial de este enfoque está en distribuir la capacidad: acercar cómputo, datos y decisiones técnicas al lugar donde se necesitan, sin perder una política común de identidades, registros y supervisión.
La autonomía local tampoco significa funcionamiento ilimitado sin comunicaciones. Un diseño serio define qué capacidades permanecen disponibles, durante cuánto tiempo, con qué datos, qué acciones quedan bloqueadas y cómo se recupera la coherencia al restablecerse la conexión. La degradación segura es una función de arquitectura; no una promesa de independencia absoluta.
Seis condiciones para una IA autónoma y gobernable
La soberanía tecnológica no se obtiene al instalar un modelo en un servidor propio. Aparece cuando la organización puede demostrar control sobre el conjunto de datos, infraestructura, identidades, reglas, integraciones y operación. Estas seis condiciones permiten evaluar ese control.
1. Ejecución local de las funciones esenciales
El sistema debe identificar qué inferencias, búsquedas, validaciones o automatizaciones necesitan seguir disponibles dentro del entorno autorizado. Esto requiere modelos adecuados al hardware, gestión de versiones, almacenamiento local y procedimientos de actualización que no introduzcan cambios sin verificar.
2. Datos y conocimiento dentro del perímetro definido
Documentos, instrucciones, historiales, vectores, registros y resultados forman parte del dato operativo. La arquitectura debe establecer dónde se procesan, cuánto tiempo se conservan, quién accede y qué información puede salir. “No entrenamos con tus datos” no responde por sí solo a todas esas preguntas.
3. Degradación segura y recuperación
Cuando falta un servicio, el sistema debe pasar a un modo conocido: limitar funciones, advertir al usuario, utilizar una versión validada o derivar la decisión. Al recuperar conectividad, la sincronización debe resolver conflictos y conservar evidencia de lo ocurrido durante la desconexión.
4. Interoperabilidad y capacidad de sustitución
Los datos, las políticas y la lógica del proceso no deberían quedar encerrados en un único modelo o proveedor. Interfaces documentadas, formatos portables y componentes desacoplados permiten cambiar una parte sin reconstruir toda la solución. La independencia tecnológica se demuestra con opciones practicables de salida.
5. Trazabilidad técnica y operativa
La organización necesita reconstruir qué versión intervino, qué datos recibió, qué respuesta produjo, qué regla se aplicó y quién confirmó la acción. Los registros deben ser útiles para operación, seguridad, evaluación e investigación de incidentes; acumular eventos sin contexto no crea rendición de cuentas.
6. Autoridad humana efectiva
El control humano exige capacidad real para comprender límites, revisar resultados, gestionar excepciones, detener procesos y responder por las decisiones. No basta con colocar una aprobación al final si el operador carece de información, tiempo o autoridad para cuestionar la recomendación.
Autonomía técnica no significa decisión autónoma sin límites
En el debate público, “autonomía” puede referirse tanto a la capacidad de un sistema para operar sin conexión como a su capacidad para actuar sin intervención. Son problemas distintos. Una plataforma puede ejecutar modelos localmente y, al mismo tiempo, exigir validación humana antes de cualquier acción con impacto relevante.
| Dimensión | Pregunta de diseño | Control esperado |
|---|---|---|
| Autonomía de infraestructura | ¿Puede continuar la función esencial sin un servicio externo? | Modo local validado, límites temporales y procedimiento de recuperación. |
| Autonomía del modelo | ¿Puede sustituirse o actualizarse sin perder reglas y conocimiento? | Versionado, evaluación, interfaces estables y alternativa practicable. |
| Autonomía de acción | ¿Qué puede ejecutar el sistema y bajo qué condiciones? | Permisos mínimos, políticas, umbrales, aprobaciones y parada. |
| Autoridad humana | ¿Quién puede revisar, corregir, bloquear y responder? | Roles claros, información comprensible, formación y tiempo de intervención. |
Los principios de uso responsable de la IA publicados por la OTAN incluyen legalidad, responsabilidad, explicabilidad y trazabilidad, fiabilidad, gobernabilidad y mitigación de sesgos. Son principios institucionales, no una certificación técnica. Su valor para un proyecto está en traducirlos a requisitos verificables: pruebas, registros, límites de uso, responsables y procedimientos de intervención.
Arquitectura local, edge, privada o híbrida: cómo elegir
La ubicación correcta depende de la sensibilidad del dato, la latencia, la conectividad, la criticidad y la capacidad de operación. Un despliegue completamente local ofrece control adicional, pero también exige hardware, actualizaciones, seguridad, observabilidad y equipos capaces de mantenerlo. Una arquitectura híbrida puede reservar el perímetro más protegido para datos y funciones críticas y utilizar servicios externos para cargas compatibles.
| Patrón | Cuándo puede encajar | Riesgo que debe gestionarse |
|---|---|---|
| Local / on premise | Datos muy sensibles, conectividad restringida o continuidad independiente. | Capacidad operativa, actualización segura, coste y obsolescencia. |
| Edge AI | Respuesta cercana al origen del dato, latencia baja o ancho de banda limitado. | Recursos limitados, diversidad de nodos y gestión de versiones. |
| Nube privada o soberana | Servicios compartidos con control reforzado de acceso, ubicación y operación. | Dependencia contractual, jurisdicción, portabilidad y concentración. |
| Híbrida o federada | Casos con distintos niveles de criticidad y necesidad de escalar selectivamente. | Complejidad de políticas, identidades, observabilidad y sincronización. |
La opción más soberana no siempre es la más aislada. Puede ser la que conserva bajo control los componentes críticos y permite utilizar, comparar o reemplazar el resto. El objetivo es evitar que una decisión táctica —un modelo, una nube o una interfaz— se convierta sin evaluación en una dependencia estratégica.
Seguridad y gobierno durante todo el ciclo de vida
El despliegue es solo una etapa. Los sistemas de IA cambian cuando se actualizan datos, modelos, instrucciones, conectores o reglas. La seguridad debe cubrir desarrollo, evaluación, distribución, operación y retirada. Esto incluye cadena de suministro, integridad de artefactos, gestión de vulnerabilidades, segregación de entornos y respuesta ante incidentes.
En el sector público español, el Esquema Nacional de Seguridad exige proteger dimensiones como acceso, confidencialidad, integridad, trazabilidad, autenticidad, disponibilidad y conservación, con medidas ajustadas al riesgo y a la categoría del sistema. El ENS no obliga a ejecutar toda IA localmente ni sustituye el análisis específico del caso, pero sí refuerza la necesidad de documentar arquitectura, responsables y controles.
El Reglamento europeo de IA excluye de su ámbito los sistemas utilizados exclusivamente con fines militares, de defensa o seguridad nacional. Los usos duales o no excluidos requieren un análisis jurídico propio. Presentar el AI Act como regla universal para cualquier sistema militar sería incorrecto; ignorarlo en una solución que también presta usos civiles tampoco sería prudente.
Casos de uso donde empezar sin convertir la IA en espectáculo
El mejor primer caso no es el más llamativo, sino aquel donde existe un problema operativo, datos accesibles, responsables claros y una forma de validar el resultado. En organizaciones de defensa y su cadena de suministro, varios ámbitos permiten aprender sin atribuir a la máquina decisiones que no le corresponden.
- Mantenimiento y soporte técnico: localizar procedimientos, resumir incidencias y preparar diagnósticos para revisión especializada.
- Logística y planificación: detectar anomalías, anticipar necesidades y ayudar a reconciliar información entre sistemas.
- Gestión documental: clasificar expedientes, extraer requisitos y comparar versiones dentro de repositorios autorizados.
- Ciberseguridad: priorizar señales, correlacionar eventos y asistir al analista sin ejecutar respuestas irreversibles fuera de política.
- Formación y simulación: adaptar escenarios, apoyar ejercicios y registrar aprendizaje con contenidos y límites validados.
- Ingeniería y calidad: consultar evidencia, revisar coherencia y mantener trazabilidad entre requisitos, pruebas y cambios.
Cada caso debe comenzar con una línea base: tiempo, errores, disponibilidad, carga manual, capacidad de auditoría o coste operativo. Sin esa referencia, el proyecto podrá demostrar que el modelo funciona, pero no que mejora el proceso.
Cómo elegir un partner tecnológico de IA para defensa
Un proveedor no debería evaluarse únicamente por el acceso a un modelo. El valor está en integrar la IA con sistemas, datos, identidades y procedimientos existentes, conservando seguridad y capacidad de operación. La conversación comercial debe aterrizar en decisiones comprobables.
- ¿Puede diseñar patrones locales, edge, privados e híbridos sin forzar una única infraestructura?
- ¿Separa datos, reglas, modelos y acciones para reducir el coste de sustitución?
- ¿Integra permisos, registros, evaluación, consumo y gestión de excepciones desde el inicio?
- ¿Define claramente qué hace la máquina, qué valida una persona y quién tiene autoridad de parada?
- ¿Prueba condiciones degradadas, recuperación, sincronización y cambio de componentes?
- ¿Conecta la solución con aplicaciones, APIs, repositorios y procesos corporativos reales?
- ¿Distingue objetivos, prototipos, capacidades desplegadas y resultados medidos?
OpenSistemas aborda la IA corporativa como una capacidad gobernada que combina arquitectura, datos, integración y operación. Este enfoque permite diseñar soluciones en función de la criticidad y del perímetro requerido, con modelos públicos, privados o desplegados localmente cuando el caso lo justifica. La plataforma SofIA articula gobierno, integración y operación de servicios de IA; su encaje concreto debe validarse contra los requisitos técnicos, de seguridad y contratación de cada organización.
Para profundizar en la relación entre datos, modelos, infraestructura y capacidad de sustitución, puede consultarse también nuestra guía sobre IA soberana y control arquitectónico.
Una hoja de ruta para pasar del interés a una capacidad verificable
1. Seleccionar un proceso y clasificar su criticidad
Defina usuarios, datos, decisiones, disponibilidad necesaria y consecuencias de un error o una interrupción. El resultado debe delimitar qué funciones podrían automatizarse y cuáles deben permanecer sujetas a validación.
2. Mapear el perímetro y las dependencias
Identifique flujos de información, sistemas, modelos, proveedores, identidades, comunicaciones y equipos de operación. Marque qué elementos pueden desconectarse, sustituirse o recuperarse.
3. Diseñar el patrón de despliegue
Decida qué se ejecuta localmente, en el edge, en nube privada o mediante servicios externos. Añada desde el principio política de versiones, observabilidad, secretos, evaluación y control de consumo.
4. Probar límites, no solo respuestas
Valide calidad, latencia y coste, pero también pérdida de conectividad, datos incompletos, instrucciones adversas, cambio de modelo, parada y recuperación. Una prueba que solo muestra la respuesta correcta en condiciones ideales no demuestra resiliencia.
5. Operar con responsables y métricas
Asigne propietarios técnicos y de negocio, frecuencia de revisión, umbrales, tratamiento de excepciones y procedimiento de retirada. Mida contra la línea base y conserve evidencia suficiente para decidir si escalar.
Nos vemos en los próximos encuentros sobre seguridad e IA responsable
OpenSistemas estará presente en la III edición de Diálogos para la Seguridad, encuentro de EL PAÍS que se celebrará el 17 de septiembre de 2026 en el CESEDEN, Madrid. También asistiremos a la II Jornada de Inteligencia Artificial Responsable en el Ámbito Militar. Defensa–Empresa–Universidad, organizada en Soria los días 22 y 23 de septiembre de 2026 por el Ministerio de Defensa, a través del CESTIC, junto con ISDEFE.
Serán dos espacios para conversar sobre soberanía tecnológica, gobernanza, colaboración y aplicación responsable de la IA. Si su organización está evaluando cómo desplegar capacidad de IA bajo control, podemos aprovechar estos encuentros para contrastar requisitos y enfoques.
GUÍA PARA COMITÉS DE DIRECCIÓN
¿Cómo pasar de los pilotos de IA a una capacidad operativa real?
Una guía para estructurar la conversación sobre adopción de IA empresarial antes de la próxima inversión.
Descargar la guíaPreguntas frecuentes sobre inteligencia artificial en defensa
¿Qué es la inteligencia artificial en defensa?
La inteligencia artificial en defensa comprende sistemas que apoyan tareas como mantenimiento, logística, ciberseguridad, gestión documental, simulación o análisis. Su diseño debe adaptarse a la criticidad del proceso, la sensibilidad de los datos, la disponibilidad requerida y los límites de actuación y supervisión definidos por la organización.
¿Qué significa que una IA funcione de forma local?
Significa que determinadas funciones de inferencia, búsqueda o automatización se ejecutan dentro del entorno autorizado sin depender continuamente de un servicio remoto. No implica aislamiento total: puede formar parte de una arquitectura híbrida y necesita procedimientos para actualización, sincronización, registro y recuperación.
¿Es lo mismo IA local que IA soberana?
No. El despliegue local aporta control sobre infraestructura y datos, pero la soberanía también incluye modelos, licencias, identidades, cadena de suministro, portabilidad, operación y capacidad de sustitución. Un sistema local puede seguir siendo muy dependiente de un proveedor o de un equipo difícil de reemplazar.
¿Cómo se mantiene el control humano sobre la IA?
El control humano requiere roles, información y autoridad reales: comprender los límites del sistema, revisar resultados, gestionar excepciones, bloquear acciones y detener el servicio. El mecanismo adecuado depende del riesgo y puede incluir validación previa, supervisión durante la ejecución o revisión posterior con trazabilidad.
¿El Reglamento europeo de IA se aplica a los sistemas militares?
El Reglamento excluye los sistemas utilizados exclusivamente con fines militares, de defensa o seguridad nacional. Los sistemas de doble uso o destinados también a fines no excluidos pueden quedar dentro de su ámbito. La aplicación concreta requiere analizar finalidad, rol de la organización y contexto jurídico.
¿Qué debería demostrar un piloto de IA para defensa?
Además de calidad, debe aportar evidencia sobre seguridad, latencia, disponibilidad, trazabilidad, intervención humana, comportamiento con conectividad degradada, recuperación y capacidad de sustituir componentes. También debe comparar el proceso con una línea base para decidir si existe valor operativo y si procede escalar.
Fuentes consultadas
- OTAN: estrategia revisada de inteligencia artificial.
- OTAN: plan de implementación de autonomía.
- OTAN: Digital Backbone.
- Agencia Europea de Defensa: Trustworthiness for AI in Defence.
- Reglamento (UE) 2024/1689 de inteligencia artificial.
- Real Decreto 311/2022, Esquema Nacional de Seguridad.
- Ministerio de Defensa: Plan de Acción de Transformación Digital.
- Agenda de la III edición de Diálogos para la Seguridad.
- Ministerio de Defensa: II Jornada de Inteligencia Artificial Responsable en el Ámbito Militar.
