El Ministerio de Defensa celebra los días 22 y 23 de septiembre en Soria la segunda Jornada de Inteligencia Artificial Responsable en el Ámbito Militar, un encuentro dirigido a personal del departamento y a profesionales de empresas, universidades, centros de investigación e instituciones españolas vinculadas al desarrollo y uso de estas tecnologías. La cita se desarrolla en el Palacio de la Audiencia y está organizada por la Secretaría de Estado de Defensa, a través del CESTIC, junto con la empresa pública ISDEFE.
El Ministerio ha definido cuatro objetivos: reforzar la colaboración con empresas nacionales de tecnologías de la información y las comunicaciones; promover desarrollos nacionales de IA responsable vinculados a soberanía tecnológica; aumentar la participación de universidades, centros de investigación y think tanks; y presentar NEXUS, un modelo organizativo pensado para dar continuidad a la iniciativa internacional REAIM sobre inteligencia artificial responsable en el ámbito militar.
La jornada da continuidad a la primera edición celebrada en Jaén en noviembre de 2025 y a la tercera cumbre REAIM, celebrada en A Coruña los días 4 y 5 de febrero de 2026. El foco de esta nueva fase está menos en formular principios generales y más en cómo llevar gobernanza, control humano y responsabilidad a proyectos concretos.
Una segunda edición centrada en aplicación práctica
El salto desde una primera jornada a una segunda permite pasar de sensibilización a metodologías.
Las organizaciones pueden comparar cómo documentar modelos, establecer controles y validar sistemas antes de utilizarlos.
La continuidad evita que el debate sobre IA responsable quede limitado a declaraciones institucionales.
CESTIC como organizador tecnológico
El Centro de Sistemas y Tecnologías de la Información y las Comunicaciones del Ministerio de Defensa participa en la organización.
Su papel sitúa la discusión dentro de la arquitectura tecnológica del departamento.
La gobernanza de IA necesita conectarse con sistemas, redes, identidad, seguridad y datos ya existentes.
ISDEFE
La empresa pública aporta experiencia en ingeniería de sistemas y apoyo a Defensa.
En tecnologías complejas, una entidad de ingeniería puede ayudar a convertir principios de responsabilidad en requisitos verificables.
La definición de criterios antes de contratar es especialmente importante cuando el mercado evoluciona rápido.
Empresas nacionales
Uno de los objetivos oficiales es reforzar la colaboración con compañías TIC españolas.
La capacidad nacional puede reducir determinadas dependencias, aunque los sistemas seguirán utilizando cadenas de suministro internacionales.
La soberanía tecnológica debe medirse por capacidad de elección, conocimiento y mantenimiento, no únicamente por la nacionalidad de un proveedor.
Universidades y centros de investigación
La jornada busca aumentar su participación.
Los centros académicos pueden aportar evaluación, nuevos modelos y metodologías de verificación.
La transferencia requiere entornos donde un prototipo científico pueda probarse sin acceder directamente a sistemas sensibles.
Think tanks y análisis estratégico
Los centros de pensamiento pueden estudiar implicaciones jurídicas, éticas y geopolíticas.
La IA militar no es solo un problema técnico.
Las decisiones sobre autonomía, responsabilidad y control humano necesitan enfoques multidisciplinares.
NEXUS
El Ministerio presenta NEXUS como modelo organizativo para dar continuidad a REAIM.
Un modelo de este tipo puede definir actores, procesos y mecanismos de coordinación.
Su valor dependerá de que los principios se conviertan en controles operativos y no únicamente en documentos.
REAIM
Responsible Artificial Intelligence in the Military Domain es una iniciativa internacional centrada en uso responsable de IA en el ámbito militar.
La cumbre de A Coruña de febrero de 2026 buscó avanzar hacia medidas concretas.
La jornada de Soria se presenta como una continuación nacional de ese trabajo.
Control humano
Uno de los principios centrales es mantener responsabilidad humana sobre decisiones relevantes.
La expresión necesita concretarse: qué decisiones requieren autorización, quién puede detener un sistema y qué información recibe la persona supervisora.
La experiencia de Asturias sobre supervisión humana muestra cómo la misma cuestión aparece también en usos civiles.
Niveles de autonomía
No todos los sistemas realizan las mismas funciones.
Un modelo de análisis documental, un sistema predictivo y un agente capaz de ejecutar acciones necesitan controles distintos.
La clasificación funcional ayuda a evitar reglas demasiado genéricas.
Autorización de acciones
Cuando un sistema puede actuar sobre herramientas, la arquitectura debe limitar permisos.
El principio de mínimo privilegio reduce el impacto de un error o compromiso.
La arquitectura PICEE-PA ofrece una referencia pública sobre separación entre capacidad del modelo y autorización para actuar.
Trazabilidad
Los sistemas necesitan registrar qué modelo intervino, qué información recibió y qué salida generó.
La trazabilidad permite investigar fallos y reconstruir decisiones.
Los logs deben protegerse porque pueden contener información sensible.
Versionado
Una actualización puede modificar el comportamiento de un modelo.
Los proyectos deberían conservar la versión exacta utilizada durante una prueba o decisión.
Sin versionado resulta difícil reproducir resultados.
Evaluación antes de despliegue
Los sistemas pueden probarse con escenarios controlados, casos adversos y datos sintéticos.
Las pruebas deberían medir precisión, robustez y comportamiento fuera de los casos habituales.
La aprobación de un prototipo no implica automáticamente autorización para producción.
Red teaming
Los equipos de evaluación pueden intentar provocar errores o eludir controles.
Esta metodología ayuda a descubrir vulnerabilidades antes de que un sistema sea utilizado por terceros.
Los ejercicios deben realizarse en entornos autorizados y aislados.
Ciberseguridad
La IA introduce modelos, APIs y nuevas dependencias de software.
Los sistemas deben proteger credenciales y datos de entrenamiento.
El Threat Landscape 2026 de ENISA destaca los riesgos de cadena de suministro que también afectan a entornos complejos.
Supply chain de modelos
Un sistema puede incorporar librerías, pesos, datos y servicios de terceros.
Cada dependencia introduce actualizaciones y riesgos.
El inventario técnico debería permitir saber qué componentes forman parte de cada solución.
Modelos abiertos y propietarios
La elección depende de requisitos de seguridad, calidad y mantenimiento.
Los modelos abiertos ofrecen mayor capacidad de inspección en determinados casos, pero requieren equipos capaces de operarlos.
Los servicios propietarios pueden simplificar despliegue, aunque aumentan dependencia contractual.
Despliegue local
Algunos usos sensibles pueden requerir infraestructura controlada por la organización.
La ejecución local reduce determinadas exposiciones de datos, pero no elimina riesgos de software.
La capacidad de mantenimiento y actualización es esencial.
Cloud soberano
La soberanía tecnológica puede incluir proveedores y regiones cloud con requisitos específicos.
La CNMC ha señalado la importancia de portabilidad y competencia en cloud público.
Estos criterios son relevantes cuando una carga debe poder migrarse.
Datos de entrenamiento
La calidad y procedencia de los datos condicionan el comportamiento del modelo.
Los proyectos deberían documentar fuentes y restricciones de uso.
En ámbitos sensibles, la trazabilidad de datos puede ser tan importante como la del software.
Datos sintéticos
Los conjuntos artificiales pueden permitir pruebas sin utilizar información operativa real.
Sin embargo, deben representar suficientemente el entorno que se quiere evaluar.
Un modelo entrenado solo con escenarios simplificados puede fallar cuando cambia el contexto.
Clasificación de información
El programa de trabajo debe separar claramente qué información puede utilizarse en talleres o demostradores.
Las herramientas externas no deberían recibir contenidos sensibles si no están autorizadas.
La clasificación necesita traducirse a controles técnicos, no solo a instrucciones.
IA generativa
Los modelos de lenguaje pueden apoyar síntesis, búsqueda o redacción.
Su capacidad para producir respuestas plausibles pero incorrectas obliga a revisar resultados.
Los primeros usos pueden centrarse en tareas de bajo riesgo.
RAG
Los sistemas de generación aumentada por recuperación permiten responder usando documentos autorizados.
Esto mejora trazabilidad si la aplicación muestra fuentes.
La seguridad debe controlar qué documentos puede recuperar cada usuario.
Agentes de IA
La evolución hacia agentes aumenta autonomía y capacidad de ejecutar cadenas de tareas.
Cada herramienta disponible para el agente debe tener permisos definidos.
La supervisión debe aumentar con el impacto de las acciones.
Modelos pequeños especializados
No todos los casos necesitan un gran modelo general.
Modelos más pequeños pueden ejecutarse localmente y consumir menos recursos.
La selección debería basarse en calidad y requisitos, no en tamaño.
Edge AI
Procesar información cerca del sensor reduce latencia y dependencia de conectividad.
También limita la capacidad de actualizar centralmente si no existe una gestión adecuada.
El diseño debe considerar operación desconectada.
Sistemas críticos
Cuanto mayor sea el impacto potencial, más exigentes deben ser las pruebas y la supervisión.
La disponibilidad de un modo degradado o manual puede ser necesaria.
Un fallo de IA no debería inutilizar funciones esenciales sin alternativa.
Explicabilidad
El nivel de explicación necesario depende de la decisión.
En algunos sistemas bastará con trazabilidad de datos y reglas; en otros será necesario comprender factores que influyeron en una recomendación.
La explicación debe servir a la persona responsable, no ser un documento formal incomprensible.
Sesgos y robustez
Los modelos pueden comportarse de forma distinta ante datos poco frecuentes.
Las pruebas deben incluir situaciones adversas y variaciones.
La robustez se mide sobre escenarios, no con una única cifra general.
Contratación pública
Los pliegos pueden exigir documentación del modelo, capacidad de auditoría y políticas de actualización.
También necesitan definir propiedad intelectual y salida.
Comprar una “solución de IA” sin requisitos verificables dificulta supervisión posterior.
Transferencia de conocimiento
La colaboración con empresas no debería dejar todo el conocimiento fuera del Ministerio.
Los equipos internos necesitan entender arquitectura, riesgos y mantenimiento.
La transferencia permite conservar capacidad de decisión.
Talento
El ecosistema necesita perfiles de IA, datos, ciberseguridad, derecho e ingeniería.
Las universidades pueden participar en formación y proyectos.
La jornada de Soria busca precisamente fortalecer esas conexiones.
Relación con la aceleradora naval de Murcia
La Región de Murcia acaba de poner en marcha una aceleradora de IA aplicada a Defensa Naval.
Ambas iniciativas muestran dos niveles complementarios: gobernanza general y desarrollo de casos sectoriales.
Los aprendizajes pueden circular entre programas sin compartir información sensible.
Soberanía tecnológica
Defensa incluye expresamente este objetivo.
La soberanía puede medirse por capacidad para operar, auditar, modificar y sustituir componentes.
No exige construir todo desde cero, pero sí evitar dependencias que impidan actuar.
Interoperabilidad
Los sistemas deben integrarse con arquitecturas existentes.
Interfaces documentadas facilitan sustituir componentes.
La modularidad también reduce el coste de evaluar nuevas soluciones.
Criptografía postcuántica
La planificación tecnológica de largo plazo debe considerar la transición criptográfica.
España ha establecido una hoja de ruta postcuántica para la Administración.
Las nuevas plataformas deberían evitar dependencias difíciles de actualizar.
Métricas de IA responsable
Una organización puede medir porcentaje de sistemas inventariados, evaluaciones completadas, incidencias, correcciones humanas y tiempos de respuesta.
Estas métricas convierten principios en seguimiento.
El objetivo no es maximizar el número de sistemas, sino demostrar control.
Qué significa avanzar desde REAIM
La fase práctica exige definir procesos repetibles.
Inventarios, evaluaciones, pruebas, logs y autorizaciones pueden formar un ciclo de vida común.
NEXUS deberá demostrar si es capaz de articular ese ciclo entre actores diferentes.
Fuente oficial
El Ministerio de Defensa, a través del CESTIC, publicó el anuncio y los objetivos de la II Jornada de Inteligencia Artificial Responsable en el Ámbito Militar, celebrada en Soria los días 22 y 23 de septiembre de 2026.
La noticia muestra una transición relevante: la discusión sobre responsabilidad está pasando de los principios a la arquitectura organizativa y técnica. El resultado dependerá de que NEXUS y las colaboraciones posteriores generen controles verificables y capacidad propia para operar sistemas de forma segura.
Una gobernanza específica para el ciclo de vida militar
Los sistemas utilizados en Defensa pueden permanecer operativos durante años y atravesar múltiples actualizaciones de software, sensores y modelos. La gobernanza responsable necesita acompañar todo ese ciclo y no limitarse a una evaluación inicial antes del despliegue.
Cada modificación relevante debería registrar qué cambió, qué pruebas se repitieron y si aparecen nuevos riesgos. La trazabilidad permite que operadores y responsables conozcan la configuración exacta que estaba activa ante una incidencia.
Datos sintéticos y entornos de prueba
La experimentación puede utilizar datos sintéticos o entornos aislados cuando la información real tenga restricciones de seguridad. Este enfoque permite comparar modelos y validar integraciones sin exponer sistemas operativos ni información clasificada.
Las pruebas deberían incluir escenarios adversos, degradación de sensores y entradas inesperadas. Un modelo que funciona en condiciones ideales no está necesariamente preparado para un entorno complejo.
Interoperabilidad con sistemas existentes
La IA militar no opera como una aplicación aislada. Puede depender de redes, plataformas de mando, sensores o sistemas logísticos. Las interfaces y formatos deben documentarse para que una actualización de un proveedor no rompa dependencias críticas.
Esta disciplina también facilita sustituir componentes y reduce el riesgo de bloqueo tecnológico a largo plazo.
Fotografía: Pavel Danilyuk / Pexels.