La Soberanía Tecnológica Europea: Un Paso Hacia la Autonomía Digital

Europa ha vuelto a hacer una promesa ambiciosa en tecnología: menos dependencia externa, más capacidad propia y un ecosistema digital que no tiemble cada vez que Washington o Shenzhen estornudan. Esa es la idea de fondo del nuevo paquete sobre soberanía tecnológica. La pregunta útil no es si suena bien —suena estupendamente—, sino qué cambia de verdad para bancos, aseguradoras, fintech, proveedores cloud y equipos de compliance que ya viven atrapados entre DORA, NIS2, GDPR y una cadena de suministro cada vez más opaca.

La respuesta corta: cambia el lenguaje político, se refuerza una dirección regulatoria que ya venía consolidándose y se estrecha el margen para seguir gestionando dependencias tecnológicas como si fueran un asunto puramente de compras. La soberanía digital europea ya no se presenta solo como política industrial. Empieza a funcionar, en la práctica, como criterio de resiliencia, gobernanza y concentración de riesgo.

Qué persigue realmente el paquete

La fuente disponible lo sitúa en un terreno bastante claro: autonomía digital, resiliencia, desarrollo de semiconductores, inteligencia artificial, servicios cloud y software de código abierto. Ese foco importa porque evita una lectura simplista. No estamos ante una norma única que imponga obligaciones directas de un plumazo, sino ante una arquitectura política y regulatoria que empuja a las organizaciones a revisar dónde están sus dependencias críticas y qué capacidad real tienen para absorber una disrupción tecnológica prolongada.

Conviene no proyectar sobre el paquete cosas que la fuente no dice. No habla expresamente de protección de infraestructura crítica, no menciona la pandemia ni conflictos internacionales como detonantes, y tampoco describe inversiones concretas en 5G, creación de centros de datos regionales o un esquema detallado de estándares comunes para interoperabilidad y seguridad de redes. Todo eso puede encajar en el debate europeo más amplio sobre autonomía digital, sí, pero mezclarlo aquí como si estuviera negro sobre blanco sería hacer literatura, no periodismo.

Lo que sí puede sostenerse es algo más útil: el paquete encaja en una secuencia política en la que la UE intenta reducir vulnerabilidades estructurales en capacidades digitales clave. Semiconductores, IA, cloud y open source no son cuatro palabras de moda puestas en una diapositiva. Son cuatro capas donde Europa ha identificado dependencia tecnológica, riesgo de concentración y pérdida de capacidad estratégica.

Por qué esto importa al sector financiero aunque no sea una norma financiera

El sector financiero europeo lleva años descubriendo, a veces con cierta pereza, que su riesgo operativo ya no termina en el perímetro de la entidad. Vive en proveedores SaaS, hyperscalers, integradores, repositorios de código, modelos de IA de terceros y una cadena contractual donde demasiadas veces nadie sabe quién subcontrata a quién. La soberanía tecnológica entra aquí no como consigna geopolítica, sino como pregunta incómoda: si mañana falla un proveedor dominante o cambia unilateralmente sus condiciones, ¿tu entidad tiene margen real de maniobra?

Ahí DORA deja de ser un ejercicio de cumplimiento y se convierte en el idioma operativo de esta conversación. El régimen sobre riesgo de terceros TIC se articula en el Capítulo V y arranca en el artículo 28, que obliga a las entidades financieras a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante de su marco de gestión del riesgo TIC. No es una nota a pie de página. Es una obligación de gobierno, estrategia, registro, supervisión y salida.

La lectura correcta del artículo 28 no es “hay que portarse mejor con los proveedores”. La lectura correcta es otra: la dependencia tecnológica externa deja de ser una cuestión comercial y pasa a ser una cuestión regulatoria sometida a control interno, seguimiento por la dirección y evidencia documental. Ese matiz cambia bastante las cosas.

DORA no exige magia; exige saber de quién dependes

Durante meses se han repetido formulaciones imprecisas sobre DORA. Algunas, directamente, atribuyen al artículo 12 funciones que no le corresponden en materia de terceros TIC. Otras meten en el artículo 28 exigencias contractuales o de auditoría formuladas de manera demasiado libre. Si vamos a hablar en serio, mejor ir al texto.

El núcleo sobre terceros proveedores TIC está en el Capítulo V de DORA, especialmente en los artículos 28 a 30. El artículo 28 obliga a adoptar una estrategia sobre riesgo de terceros TIC, mantener un registro de información relativo a todos los acuerdos contractuales sobre servicios TIC, y revisar regularmente los riesgos de concentración y subcontratación. El artículo 30, por su parte, entra en los elementos contractuales clave que deben cubrir los acuerdos sobre servicios TIC que apoyen funciones críticas o importantes. Traducido: si alguien te vende “artículo 28 = auditorías regulares obligatorias” o “artículo 28 = continuidad garantizada por contrato” como resumen autosuficiente, se está dejando medio régimen fuera.

Lo más interesante aquí no es el tecnicismo jurídico, sino la consecuencia operativa. Las entidades tendrán que demostrar que conocen su mapa de dependencias, que distinguen entre servicios ordinarios y aquellos que soportan funciones críticas o importantes, y que han pensado el escenario menos glamuroso de todos: la salida. La soberanía tecnológica, en términos empresariales, empieza con algo bastante menos heroico que un gran plan industrial: un inventario serio y una estrategia de sustitución que no dé risa.

La conexión con NIS2: menos épica, más plazos

NIS2 también suele aparecer citada a medias. El artículo 21 no regula la notificación con un plazo máximo de 72 horas. Ese punto está en el artículo 23. Y conviene precisarlo porque no es un detalle menor: NIS2 prevé una alerta temprana sin dilación indebida y, en cualquier caso, dentro de las 24 horas desde que la entidad tenga conocimiento del incidente significativo; una notificación del incidente dentro de las 72 horas; y un informe final a más tardar un mes después.

Por qué importa esta corrección? Porque mucha organización cree que “72 horas” resume todo el régimen de reporte. No lo resume. Si tu modelo de respuesta a incidentes sigue diseñado como si el reloj empezara a correr solo una vez que tienes la fotografía completa, vas tarde. NIS2 asume incertidumbre temprana. Primero alertas, luego completas. Bastante lógico, por cierto, aunque a algunas segundas líneas les siga pareciendo una descortesía regulatoria pedir información cuando aún no la tienes ordenada.

Para entidades financieras y proveedores tecnológicos que puedan caer en el perímetro de NIS2 según su transposición nacional, esto conecta de forma natural con DORA: clasificación de activos, trazabilidad de dependencias, escalado interno y criterios de materialidad. Si esos cuatro elementos fallan, no fallará solo el reporte. Fallará la gobernanza.

Cloud, IA y open source: donde la soberanía se vuelve práctica

La fuente menciona tres vectores que sí merecen lectura detenida: cloud, inteligencia artificial y software de código abierto. Los tres tienen algo en común: son palancas de innovación, sí, pero también superficies de dependencia.

En cloud, la cuestión no es solo dónde están los datos. Esa obsesión, a estas alturas, se queda corta. La cuestión es quién controla la arquitectura, la capacidad de migración, las herramientas de observabilidad, las condiciones de salida, la subcontratación en cascada y los puntos únicos de fallo. DORA empuja a mirar ese riesgo con bastante más disciplina de la que muchas entidades han aplicado hasta ahora.

En IA, la soberanía no equivale a prohibir proveedores extranjeros ni a fabricar modelos europeos por patriotismo de PowerPoint. Equivale, más bien, a preguntarse qué dependencia genera cada capa del stack: datos, cómputo, modelo fundacional, afinado, despliegue y supervisión. Si tu proveedor de IA es una caja negra contractual y técnica, el problema no es solo ético o reputacional. También es de resiliencia operativa y de capacidad de control.

Y en open source aparece una paradoja deliciosa. Europa lo presenta como activo estratégico precisamente porque reduce dependencia de proveedores cerrados; pero al mismo tiempo exige madurez para gestionar vulnerabilidades, mantenimiento, procedencia del código y responsabilidad sobre componentes integrados. El código abierto no elimina el riesgo de terceros. Solo lo redistribuye. A veces de forma más sana. A veces de forma más caótica.

Lo que no conviene mezclar en esta conversación

Cuando un debate regulatorio se pone de moda, enseguida aparece la tentación de meterlo todo en la misma batidora. Mala idea.

No hay base, con la fuente dada, para afirmar que la UE esté destinando fondos significativos a startups europeas dentro de este paquete concreto, ni para describir programas de financiación específicos. Puede haber instrumentos en otras iniciativas europeas, pero eso sería otra pieza y otra documentación.

Tampoco corresponde presentar el Cyber Resilience Act como una norma dirigida específicamente a productos de software y hardware “utilizados en el sector financiero”. El CRA establece requisitos para productos con elementos digitales de forma transversal. Su impacto en finanzas puede ser relevante, desde luego, porque bancos, aseguradoras y proveedores usan esos productos. Pero una cosa es impacto sectorial y otra ámbito material de la norma. Confundirlos no aclara nada.

Lo mismo ocurre con referencias técnicas mal clavadas, como citar “ISO 27001 Anexo A 8.1.1” para hablar de responsabilidad en la gestión de activos sin especificar edición ni contexto. Ese tipo de precisión aparente queda muy elegante en un artículo mediocre y muy mal en uno riguroso. Si la fuente no lo sustenta y la referencia puede variar según la edición, mejor no fingir exactitud.

Y no, tampoco tiene sentido arrastrar HIPAA a esta discusión como si el marco europeo de soberanía tecnológica necesitara una excursión normativa a Estados Unidos para ganar empaque. HIPAA es relevante en sanidad estadounidense. Aquí, introducirlo sin conexión directa con la fuente ni con el argumento principal solo añade ruido.

La consecuencia real para compliance: menos storytelling, más cartografía de riesgo

La novedad de fondo no está en una obligación aislada, sino en la convergencia. Política industrial, resiliencia digital y supervisión de terceros empiezan a apuntar en la misma dirección. Para compliance y riesgo operativo eso implica abandonar tres hábitos bastante extendidos.

El primero: tratar el riesgo tecnológico como un catálogo de controles técnicos. Ya no basta. DORA lo convierte en asunto de gobernanza, el GDPR lo conecta con seguridad y gestión de brechas mediante los artículos 32 y 33, y NIS2 lo aterriza en gestión de riesgos y reporte en sus artículos 21 y 23. Si esos marcos se gestionan por separado, el resultado suele ser el de siempre: tres inventarios distintos, cuatro taxonomías incompatibles y ninguna visión ejecutiva útil.

El segundo: creer que el problema de terceros se resuelve con una cláusula contractual estándar. Tampoco. El contrato importa, desde luego, y DORA dedica al contenido contractual una atención específica en el artículo 30. Pero si la entidad no sabe qué servicio soporta qué proceso crítico, qué subcontratación existe y cuál es el coste real de salida, el contrato será una foto bonita de un desorden estructural.

El tercero: seguir confundiendo localización con control. Tener datos en territorio europeo puede mitigar ciertos riesgos jurídicos o de transferencia, pero no resuelve por sí solo la dependencia tecnológica, la concentración de mercado ni la asimetría contractual con determinados proveedores. Soberanía no es geografía a secas. Es capacidad de decisión bajo estrés.

Qué deberían revisar ya las entidades

Sin inventar obligaciones nuevas ni vender humo estratégico, hay una agenda bastante concreta que sí se desprende de esta evolución regulatoria.

• Inventario de terceros TIC con criterio funcional. No solo quién presta el servicio, sino qué proceso soporta, si afecta a una función crítica o importante y qué subcontratación existe aguas abajo. Eso conecta directamente con DORA art. 28.
• Registro contractual utilizable. No un archivo muerto. Un registro que permita saber qué derechos de acceso, salida, soporte, localización y notificación existen en cada acuerdo, especialmente en servicios que sostienen funciones críticas o importantes.
• Mapa de concentración. Si varios procesos dependen del mismo proveedor, de la misma región cloud o del mismo componente tecnológico, el riesgo no está repartido aunque el Excel tenga muchas filas.
• Proceso de notificación de incidentes alineado con NIS2. Si la organización puede quedar sujeta a ese marco, debe operar con la lógica del artículo 23: alerta temprana, notificación posterior y reporte final. Esperar a tener certezas completas no es una estrategia de cumplimiento.
• Plan de salida realista. No hace falta prometer migraciones milagrosas. Sí hace falta identificar dependencias sin alternativa viable y reconocerlas como riesgo residual, no esconderlas detrás de un anexo técnico.

Esto último suele ser el punto más incómodo. Las entidades descubren que “exit plan” suena estupendo hasta que alguien pregunta cuánto tardaría una migración, qué datos habría que transformar, qué licencias bloquean la transición y qué coste tendría replicar integraciones críticas. Ahí se acaba la poesía regulatoria y empieza el trabajo de verdad.

Mi lectura: Europa está redefiniendo la dependencia como problema de gobernanza

Ese es, a mi juicio, el giro más relevante. El paquete de soberanía tecnológica no debe leerse solo como una apuesta por desarrollar capacidades europeas en semiconductores, IA, cloud y open source. Debe leerse también como una señal para sectores regulados: ciertas dependencias tecnológicas ya no son una simple externalización eficiente. Son una vulnerabilidad que hay que identificar, medir, gobernar y, cuando sea posible, reducir.

Eso no significa que Europa vaya a desacoplarse de los grandes proveedores globales ni que las entidades financieras vayan a repatriar de golpe sus cargas críticas a soluciones domésticas. Sería una caricatura. Significa algo bastante más sobrio y más serio: que supervisores, legisladores y consejos de administración van a preguntar cada vez con más insistencia qué margen de control tiene la entidad sobre las tecnologías de las que depende.

Y esa pregunta, por cierto, no se responde con un eslogan sobre innovación responsable ni con una presentación de cuarenta diapositivas. Se responde con contratos entendibles, inventarios fiables, criterios de criticidad coherentes, rutas de salida plausibles y un gobierno interno que no descubra sus dependencias el día del incidente.

Si tu organización sigue tratando la soberanía tecnológica como un debate abstracto de Bruselas, va tarde. No porque mañana vaya a llegar una sanción mágica asociada a ese paquete, sino porque la dirección regulatoria ya está bastante clara: la dependencia tecnológica se ha convertido en un asunto de resiliencia operativa y de responsabilidad de gestión. Y eso, a diferencia de muchos discursos públicos, sí tiene consecuencias muy concretas.