Soberanía tecnológica

Europa habla cada vez más de autonomía estratégica en defensa, pero sigue dependiendo del exterior en demasiadas capacidades críticas. Y en el contexto actual —más conflicto, más fragmentación geopolítica y más presión sobre las cadenas de suministro— esa dependencia representa una vulnerabilidad real, y más, cuando los equilibrios históricos originarios del fin de la Segunda Guerra Mundial ya no están tan claros. [2]

La soberanía tecnológica en defensa es una necesidad industrial, estratégica y política.

El problema de depender de lo que se compra fuera

Basta un ejemplo sencillo para entenderlo. Aunque se haya convertido en una leyenda urbana, no es cierto que los F-35 exportados por Estados Unidos incorporen un supuesto «botón de apagado» remoto. Pero esa no es la cuestión importante.

La cuestión importante es otra: cuando dependes del exterior para software, sostenimiento, integración, repuestos o evolución de una plataforma crítica, dependes también de decisiones que no controlas del todo. En defensa, depender no siempre significa que otro pueda apagarte el sistema; basta con que pueda condicionarte su disponibilidad, las actualizaciones, el mantenimiento o su evolución y los recambios.

La paradoja europea: la innovación nace donde menos aguanta el mercado de defensa

Construir capacidades propias es extraordinariamente difícil. Y aquí aparece la paradoja central de Europa y de España: muchas de las tecnologías realmente disruptivas nacen hoy en startups, pymes tecnológicas y compañías pequeñas, pero el mercado de defensa, por su estructura, sus plazos, sus exigencias documentales y su carga regulatoria, castiga precisamente a quienes podrían renovar la base tecnológica.

Dicho de otro modo: donde más innovación puede aparecer, menos capacidad existe para sobrevivir a la travesía en el desierto que supone la entrada a un mercado tan restrictivo.

Ahí es donde la tecnología dual deja de ser un eslogan y empieza a tener sentido estratégico.

Porque una base tecnológica con potencial dual no se convierte automáticamente en una empresa dual. Entre ambas cosas media un desierto: adaptación del producto, endurecimiento técnico, validación, trazabilidad, certificación, músculo financiero y resistencia burocrática.

La dualidad no es una etiqueta de quita y pon, es una travesía… y larga.

Common Criteria: donde la teoría choca con la realidad industrial

Y en esa travesía, la certificación importa mucho más de lo que suele reconocerse.

Cuando una tecnología quiere cruzar desde un mercado civil hacia entornos de alta exigencia, no basta con que funcione. Tiene que demostrarlo de manera formal, repetible y evaluable. Tiene que soportar trazabilidad de desarrollo, documentación de seguridad, modelado de amenazas, gestión de configuración, evidencias de prueba y una disciplina de ingeniería que muchas startups no pueden sostener si dependen desde el primer día del cliente militar.

Uno de los marcos más relevantes en este terreno es Common Criteria, el estándar internacional para la evaluación de la seguridad de productos de tecnologías de la información. [3] Su importancia no reside solo en la profundidad técnica del proceso, sino también en su proyección internacional: el ecosistema se articula a través del Common Criteria Recognition Arrangement, precisamente para facilitar el reconocimiento mutuo de evaluaciones y certificados entre los países participantes. [6] España forma parte de ese ecosistema como esquema certificador.

Y dentro de Common Criteria hay un detalle especialmente revelador: la propia documentación oficial describe EAL4 como el nivel más alto en el que todavía es probable que resulte económicamente viable adaptar una línea de producto existente. [5]

Ese matiz importa mucho. Porque explica por qué la tecnología dual no fracasa solo por falta de visión estratégica y problemas operativos. Fracasa muchas veces por fricción regulatoria, por exigencias de documentación, por madurez insuficiente del producto y por costes de entrada que una gran empresa puede absorber, pero una compañía emergente no.

Lo que de verdad cuesta certificar

Aquí conviene hacer una precisión importante. No existe una tarifa oficial única ni un plazo universal cerrado para una evaluación Common Criteria. El tiempo y el coste dependen del tipo de producto, del nivel de aseguramiento perseguido, de si el producto nace ya pensado para certificarse o se intenta adaptar a posteriori, de si existe un Protection Profile aplicable y del laboratorio elegido.

Pero quien haya vivido un Common Criteria de verdad sabe que no se juega solo en el laboratorio. Se juega mucho antes: en cómo diseñas, cómo documentas, cómo controlas versiones, cómo justificas seguridad y cómo sostienes financieramente el producto durante meses.

Con esa cautela, y hablando siempre en rangos orientativos de mercado, la experiencia habitual puede resumirse así.

Software puro

Motores de base de datos, sistemas operativos o determinadas plataformas de seguridad suelen moverse entre EAL2 y EAL4. [4]

En proyectos complejos de EAL4, los tiempos y presupuestos pueden crecer mucho más. Un ejemplo público ilustrativo es SQL Server 2022, certificado en España a EAL4+, que Microsoft afirmó haber completado en unos siete meses. [7]

Productos embebidos o mixtos

Gateways seguros, equipos IoT industriales, sensores conectados, radios definidas por software o sistemas con combinación de software, firmware y hardware suelen exigir más esfuerzo. Aquí ya no se certifica solo lógica: también integración, interfaces, superficie de ataque y comportamiento del sistema completo. Por eso los plazos y costes suelen ser más duros que en software puro, incluso a igualdad de nivel.

Hardware seguro de alta criticidad

En smartcards, secure elements, circuitos integrados seguros o hardware criptográfico de alta criticidad, el salto es todavía mayor. Ahí aparecen con más frecuencia EAL5, EAL6 o superiores, y además entran dominios técnicos muy específicos. En este tipo de productos ya no suele hablarse de adaptar una solución comercial al final del proceso: suelen ser arquitecturas diseñadas desde el principio con la evaluación en mente.

La lección de fondo: muchas tecnologías no fracasan por ser malas

Todo esto tiene una consecuencia industrial muy clara: muchas tecnologías duales no fracasan porque sean malas, sino porque no sobreviven al recorrido que va desde un producto prometedor hasta un producto certificable.

Y ahí está, precisamente, el verdadero valor del enfoque dual. No se trata simplemente de que una misma tecnología pueda acabar teniendo dos mercados. Se trata de que el mercado civil puede financiar la parte más dura del camino: la validación temprana, la mejora del producto, la trazabilidad del desarrollo, la disciplina de ingeniería y, en última instancia, la madurez necesaria para afrontar procesos de evaluación y certificación mucho más exigentes.

El verdadero valor estratégico de lo dual

Por eso la tecnología dual importa de verdad.

No porque «todo sirva para todo». No porque quede bien en una estrategia pública. No porque permita usar una palabra moderna en una nota de prensa.

Importa porque es la única forma razonable de permitir que tecnologías nacidas fuera del sector defensa puedan crecer, atraer capital, madurar producto y llegar vivas al punto en el que el mercado militar deja siquiera empezar a escucharlas.

Conclusión

Europa necesita autonomía estratégica. España necesita reindustrializarse. Pero ninguna de las dos cosas ocurrirá de verdad si seguimos pensando que la innovación en defensa empieza cuando se abre el gran contrato. [8]