El sistema de IA más importante puede ser el que nadie ve

El modelo es la capa visible. La capacidad real de IA de Europa depende de los chips, la computación, las redes, los registros, los contratos y las personas...

El sistema de IA más importante puede ser el que nadie ve

La máquina que hay detrás de la respuesta

El primer superordenador de exaescala de Europa no es una metáfora. JUPITER es un sistema real en el Forschungszentrum Jülich, gestionado por el Jülich Supercomputing Centre. La Empresa Común EuroHPC describe su arquitectura BullSequana de refrigeración líquida directa, una partición flash ultrarrápida de 20 petabytes y un diseño pensado para simulaciones exigentes e inteligencia artificial de gran intensidad computacional. La descripción está llena de los detalles que hacen posible un sistema: una arquitectura de procesador, un nivel de almacenamiento, un método de refrigeración, una institución operadora y una vía de acceso. El modelo que quizá llegue a ejecutarse sobre él es solo una parte de la frase.

Esa distinción es fácil de perder porque la parte visible de la IA es una respuesta. Una persona hace una pregunta, un modelo devuelve texto y la pantalla da la impresión de que la inteligencia llegó en un solo paquete. El trabajo oculto es menos cinematográfico. La electricidad debe llegar al edificio. Los componentes deben llegar en las condiciones adecuadas. Una imagen de firmware debe ser de confianza. Las redes deben transportar datos entre procesadores y almacenamiento. La identidad debe establecer qué persona o servicio puede usar qué recurso. Un planificador debe encontrar capacidad. Un registro debe indicar al operador qué modelo, contenedor y versión de datos están en uso. La supervisión debe detectar que el sistema ha cambiado. Alguien debe seguir sabiendo cómo repararlo un martes lluvioso cuando la documentación del proveedor ha adquirido un nuevo número de versión y la única persona que entendía la anterior está de vacaciones.

Por tanto, el sistema de IA importante puede ser el que nadie ve. Es la cadena de suministro, el contrato de energía, la red, el plan de mantenimiento, el árbol de dependencias de software, la decisión de contratación y la memoria institucional que permiten usar un modelo sin fingir que el modelo es todo el servicio. Cuando ese sistema oculto es débil, un modelo más capaz no hace más fuerte el servicio. Le da al sistema débil una forma más impresionante de fallar.

Esto no es un argumento en contra de los modelos ni de los grandes programas públicos de computación. Es un argumento a favor de describirlos con honestidad. Europa está creando capacidad mediante la Ley de Chips, EuroHPC y el programa AI Factories. Las páginas políticas de la Comisión hablan de dependencias estratégicas, resiliencia de la cadena de suministro, acceso para las empresas más pequeñas y la infraestructura necesaria para una IA fiable. Esas son cuestiones de infraestructura, no de marca. Si el continente quiere capacidad útil y no una colección de demostraciones impresionantes, tiene que tratar las capas silenciosas como parte de la capacidad.

La respuesta es la capa superior. El servicio depende de todas las capas que hay debajo.

Un modelo es un componente, no un país

En el debate público, a menudo se usa un modelo como abreviatura de toda una capacidad. Un país tiene un modelo, una empresa tiene un modelo, un departamento tiene un modelo, y se trata el modelo como si llevara consigo su propia cadena de suministro. No es así. Un modelo tiene un archivo, parámetros, un tiempo de ejecución y un conjunto de suposiciones sobre el trabajo que se espera que haga. El servicio que lo rodea asume el resto de las obligaciones.

Consideremos un sistema modesto que clasifica los documentos entrantes antes de que un equipo humano los revise. Necesita un canal de entrada, una cola, un analizador, almacenamiento, control de acceso, un tiempo de ejecución del modelo, un almacén de resultados, una vía de notificación, una forma de revertir una versión y un registro de lo ocurrido. El clasificador puede ser preciso en su conjunto de pruebas y aun así ser inutilizable si el analizador pierde un campo, si el sistema de identidad otorga el rol equivocado, si no se puede recuperar el contenedor del modelo o si el operador no puede saber qué versión hizo una recomendación. Ninguno de estos fallos son alucinaciones del modelo. Son fallos en el servicio que hizo que el modelo fuera relevante.

El error contrario es igual de común. Los equipos describen un servicio completo como resiliente porque el modelo ha sido evaluado, mientras dejan las dependencias fuera del límite de la evaluación. Una prueba del modelo puede comprobar los resultados para una carga de trabajo seleccionada. Rara vez comprueba si un certificado caduca al mismo tiempo que un repositorio de software cambia su clave de firma, si un nivel de almacenamiento tiene suficiente capacidad para un documento más largo de lo habitual, o si una persona puede recuperar el registro original después de que un proveedor cambie una interfaz de programación de aplicaciones. Esas preocupaciones pertenecen al sistema operativo. Siguen siendo parte de lo que un usuario experimenta como IA.

La pregunta útil no es si un modelo es bueno de forma aislada. Es qué otras cosas deben ser ciertas antes de que se pueda confiar en el resultado del modelo, y quién tiene la autoridad para reparar esas cosas. Esa pregunta traslada la conversación de un catálogo de modelos a un límite del sistema. También crea un inventario menos halagador pero más útil.

  • ¿Qué recursos físicos deben permanecer disponibles?
  • ¿Qué componentes de software y firmware deben llegar intactos y seguir teniendo soporte?
  • ¿Qué servicios de identidad, red, almacenamiento y registro deben responder?
  • ¿Qué organización es responsable cuando cambia la dependencia?
  • ¿Qué evidencia permite que otra persona verifique la respuesta más tarde?
  • Propuesta para la Ley de Chips 2.0, Comisión Europea, 3 de junio de 2026.

Estas preguntas no son teóricas. Son la diferencia entre una capacidad que se puede operar y una capacidad que se puede demostrar una vez. Las demostraciones son agradables. Los servicios esenciales tienen que sobrevivir a la próxima ventana de mantenimiento.

Las cadenas de suministro están dentro del límite del sistema

El trabajo de ENISA sobre la integridad de la cadena de suministro comienza con una observación poco glamurosa: los gobiernos, las organizaciones, las empresas y los consumidores dependen cada vez más de los productos y servicios de las TIC y, por tanto, de las cadenas de suministro que los entregan. Su informe menciona amenazas que van desde la manipulación durante el desarrollo, la distribución o la operación hasta la sustitución por componentes falsificados o clonados. El punto es más amplio que una lista de verificación de seguridad. Lo que se suministra no es solo una caja. Es una secuencia de personas, código, componentes, contratos y decisiones a través de la cual la caja se vuelve lo suficientemente confiable como para usarse.

Un servicio de IA hereda esa secuencia. Una ejecución de entrenamiento depende de una imagen base, un compilador, un controlador, un kernel, un programador y un conjunto de datos de origen. Un servicio de inferencia depende de las mismas capas más un tiempo de ejecución de servicio, un índice, una puerta de políticas y una interfaz que pueda seguir funcionando cuando el tráfico no se parezca al conjunto de pruebas. Una institución pública puede comprar un servicio en lugar de cualquiera de esas partes, pero la cadena oculta no desaparece porque el contrato la llame plataforma.

La actualización prospectiva de la ENISA de 2024 sitúa el compromiso de la cadena de suministro de software en lo más alto de su lista de amenazas a la ciberseguridad para 2030. También coloca la escasez de competencias, el error humano en los ecosistemas ciberfísicos, los proveedores transfronterizos de servicios TIC como punto único de fallo y el impacto físico de las perturbaciones ambientales en la infraestructura digital crítica entre las principales preocupaciones. No se trata de afirmar que todo proyecto de IA se topará con todas ellas. Son un recordatorio de que la superficie de amenaza está hecha de relaciones. Un parche, un proveedor, una persona y una inundación pueden afectar al mismo servicio, aunque aparezcan en registros de riesgo distintos.

El lenguaje del mismo informe resulta útil porque resiste la fantasía de que el riesgo cibernético pertenece solo al equipo de seguridad. Una dependencia puede verse comprometida en el software, pero sus consecuencias pueden llegar a través de un proceso físico, una decisión de contratación o una competencia ausente. Un servicio puede convertirse en un punto único de fallo porque su proveedor es técnicamente excelente y muy utilizado. La concentración no es lo mismo que la incompetencia. Es una propiedad de la red que rodea a un servicio.

Esto crea un problema práctico de límites. Si una organización evalúa solo el modelo y su entorno de ejecución inmediato, el resultado puede ser preciso para el límite elegido y engañoso para el servicio que opera. Si evalúa a cada proveedor con la misma intensidad, producirá una hoja de cálculo que nadie podrá mantener. La respuesta es un mapa de dependencias que siga la consecuencia. Identifique qué puede alterar un resultado, interrumpir un servicio, borrar evidencia, ampliar autoridad o impedir la recuperación. Luego pregúntese si la dependencia es lo bastante visible para supervisarla y si existe otra ruta.

Ese mapa debe incluir materiales ordinarios. Un servidor requiere memoria, dispositivos de almacenamiento, conversión de energía, equipos de refrigeración y piezas de repuesto. Una red requiere componentes ópticos, conmutadores, software de enrutamiento y personas que conozcan la topología. Una cadena de suministro de software requiere mantenedores, infraestructura de compilación, registros de paquetes, claves de firma y procedimientos de publicación. Nada de esto pierde importancia porque el folleto del producto diga inteligencia artificial.

Resulta tentador responder con un cuestionario de proveedores más extenso. Un cuestionario puede ser útil, pero no es un mapa de dependencias. Registra lo que un proveedor dice en un momento dado. La cuestión operativa es si el comprador puede notar un cambio, interpretarlo y adoptar una acción proporcionada. Una lista de certificados no sustituye a saber qué componente detendría el servicio si desapareciera mañana por la mañana. Las organizaciones europeas son admirablemente buenas recopilando documentos. El oficio más difícil es hacer que los documentos apunten a una decisión.

Los chips hacen visible lo invisible físico

La Ley Europea de Chips afirma un hecho que debería ser obvio y que aún necesita ser enunciado: los semiconductores son componentes básicos de los productos electrónicos y resultan centrales para sectores que van desde las comunicaciones y el procesamiento de datos hasta la sanidad, la energía, el transporte y la automatización industrial. La Ley entró en vigor en septiembre de 2023 y establece objetivos que incluyen el fortalecimiento de la investigación y el liderazgo tecnológico, el refuerzo de la capacidad de diseño, fabricación y empaquetado, el abordaje de la escasez de competencias y el desarrollo de una comprensión más profunda de la cadena de suministro mundial de semiconductores.

Esa lista importa para la IA porque la capacidad de cómputo no la crea un logotipo de nube. La crea una cadena de diseños, obleas, equipos, empaquetado, pruebas, suministro de energía, refrigeración, redes y mantenimiento. Una escasez o un retraso en una parte puede cambiar lo que un centro de datos puede ofrecer incluso cuando los archivos del modelo están listos. Si un componente tiene un plazo de entrega largo, un operador no puede solucionar el problema con un mensaje ingenioso. Si una dependencia de firmware no puede actualizarse de forma segura, la elección puede estar entre una reducción controlada del servicio y un intento inseguro de mantenerlo todo en funcionamiento.

El resumen de la Comisión recoge los tres pilares de la Ley de Chips. El primero apoya el desarrollo de capacidades y la innovación, incluidas las líneas piloto y los centros de competencia. El segundo aborda la seguridad del suministro y la resiliencia mediante la fabricación, el empaquetado avanzado, las pruebas y el ensamblaje. El tercero crea mecanismos de seguimiento y respuesta ante crisis, incluido un Consejo Europeo de Semiconductores que cartografía y supervisa la cadena de valor y coordina las respuestas a las crisis de semiconductores. El diseño institucional es una corrección útil a la idea de que la soberanía significa producir todos los componentes en el país. La resiliencia depende en parte de la capacidad, en parte de la visibilidad y en parte de la capacidad de responder cuando una dependencia se desplaza.

La página también ofrece ejemplos concretos de instalaciones pioneras aprobadas en Catania, Crolles, Dresde, Novara, Premstätten, Milán y otras localizaciones europeas. Esas entradas no demuestran que Europa haya resuelto el problema de los semiconductores. Demuestran que la cadena de valor tiene lugares físicos, tecnologías y decisiones de inversión que pueden nombrarse. Nombrarlos cambia la conversación. Permite preguntar qué capacidad aporta cada instalación, de qué insumos sigue dependiendo, qué competencias necesita y cómo recibiría apoyo durante una interrupción.

La propuesta de la Comisión para una Ley de Chips 2.0, publicada en junio de 2026, afirma que la Unión sigue dependiendo de terceros países en ámbitos clave como la fabricación avanzada de chips y el diseño de semiconductores. Para un artículo del 31 de julio, esta es una declaración política actual, no una predicción sobre una futura ley. Su implicación práctica es sencilla: un servicio europeo puede estar alojado en Europa y seguir dependiendo de una cadena global cuyas decisiones más importantes se toman en otro lugar. La ubicación física es valiosa. No es lo mismo que el control.

La política de IA puede volverse más rigurosa cuando adopta este vocabulario físico. En lugar de preguntar si un modelo es europeo, hay que preguntar qué partes del servicio pueden repararse, sustituirse, inspeccionarse y pausarse dentro de las instituciones europeas. En lugar de preguntar si un proveedor tiene una región europea, hay que preguntar cómo se mueven el hardware, el firmware, las dependencias de software y la autoridad operativa a través del servicio. La respuesta será desordenada. Bien. Los mapas desordenados suelen ser los primeros honestos.

La computación es una capacidad pública

EuroHPC ofrece un caso útil porque hace visible la infraestructura de computación sin convertirla en un producto de consumo. Su lista pública indica que la Empresa Común ha adquirido doce supercomputadores de última generación en toda Europa. La lista nombra sistemas y sedes: JUPITER en Jülich (Alemania), LUMI en Kajaani, Leonardo en Bolonia, MareNostrum 5 en Barcelona, Karolina en Ostrava y Arrhenius en la Universidad de Linköping, entre otros. Las ubicaciones importan menos como tabla de clasificación que como recordatorio de que la computación está integrada en instituciones, edificios, personal, sistemas eléctricos, almacenamiento y programas de investigación.

JUPITER se describe como el primer supercomputador exaescala de Europa, con una arquitectura de refrigeración líquida directa, una partición flash de 20 petabytes y un módulo de clúster que utiliza el procesador SiPearl Rhea1 junto con un acelerador GPU. La página de LUMI describe particiones separadas de CPU, GPU, análisis de datos y nube de contenedores, con un sistema de almacenamiento que combina flash, un sistema de archivos paralelo y un servicio de gestión de datos. Estos detalles no son solo curiosidades para ingenieros. Le dicen a quien lee políticas que un supercomputador es un conjunto de recursos de formas distintas. Una carga de trabajo que cabe en una partición puede no caber en otra. El acceso, la planificación y el movimiento de datos forman parte de la capacidad.

MareNostrum 5, alojado en el Barcelona Supercomputing Center, y Arrhenius, que se está instalando en la Universidad de Linköping y será operado por la National Academic Infrastructure for Supercomputing en Suecia, demuestran lo mismo de maneras distintas. Una capacidad europea distribuida no es una única máquina gigante. Es un conjunto de sistemas con distintos procesadores, configuraciones de almacenamiento, operadores, reglas de acceso y comunidades científicas. La red entre ellos importa, pero también importan las costuras.

La política de AI Factories de la Comisión describe un programa construido sobre esa realidad. Las AI Factories utilizan la capacidad de supercomputación de EuroHPC para desarrollar IA generativa avanzada y conectar centros de cálculo, universidades, pequeñas y medianas empresas, industria y actores financieros. La página indica que, en el momento de su actualización de abril de 2026, había diecinueve AI Factories y trece antenas operativas, con al menos nueve supercomputadores optimizados para IA previstos. También describe una inversión a largo plazo de diez mil millones de euros a través de EuroHPC entre 2021 y 2027. Son acuerdos institucionales, no una garantía de que todos los proyectos recibirán la capacidad que desean ni de que todos los modelos serán fiables.

El valor de estos acuerdos no es solo la velocidad. El cálculo público puede crear un espacio donde los investigadores y las empresas europeas puedan ejecutar cargas de trabajo bajo reglas y acuerdos de acceso visibles para las instituciones públicas. Puede respaldar experimentos que de otro modo quedarían fuera de alcance por el precio, y puede hacer que parte del conocimiento sea reproducible entre distintos centros. También puede introducir nuevas dependencias si un programa depende de un número reducido de proveedores, de una única pila de software o de una plantilla que no se puede sustituir. La propiedad pública de una instalación no elimina el trabajo operativo. Hace que la responsabilidad sea más difícil de ocultar, lo cual es más sano.

Cuando el cálculo se convierte en capacidad pública, su éxito debería medirse más allá del rendimiento máximo. ¿Puede un grupo de investigación pequeño obtener acceso? ¿Puede una carga de trabajo sensible separarse de una general? ¿Puede un operador mostrar qué software y hardware se utilizaron? ¿Puede un equipo trasladar una carga de trabajo cuando una partición está llena o una dependencia se retira? ¿Puede una autoridad pública explicar las condiciones en las que se entrenó un modelo? Una máquina rápida que no puede responder a estas preguntas sigue siendo útil para cierta ciencia, pero todavía no es una base completa para la IA pública.

Las redes, el almacenamiento y la identidad hacen el trabajo silencioso

Las capas más importantes suelen ser las que no aparecen en un diagrama de IA. Un diagrama dibuja un modelo entre una entrada y una salida. Un operador ve una cadena de rutas de red, clases de almacenamiento, afirmaciones de identidad, colas, certificados, registros, secretos, canalizaciones de observabilidad y controles de cambios. El diagrama no es incorrecto. Es incompleto exactamente de la manera que produce sorpresas costosas.

Empecemos por la red. Un servicio de modelos a gran escala puede mover datos entre aceleradores, memoria, almacenamiento y otros servicios. Una carga de trabajo de investigación pública puede mover conjuntos de datos a un supercomputador y devolver los resultados a una universidad. Un flujo de trabajo de producción puede cruzar un límite de política antes de llegar a un modelo y otro límite antes de devolver una decisión. La latencia, la pérdida de paquetes, los cambios de enrutamiento y el mantenimiento pueden alterar el comportamiento de todo el servicio sin cambiar un solo parámetro del modelo. Un tiempo de espera agotado puede convertirse en un reintento, un reintento puede convertirse en trabajo duplicado, y el trabajo duplicado puede convertirse en un registro incorrecto. El modelo no decidió reintentar. Lo decidió el sistema que lo rodea.

El almacenamiento tiene su propia gramática oculta. Está el registro fuente, el registro transformado, el índice, la caché, el log, la copia de seguridad, el marcador de borrado y la evidencia que indica qué versión se utilizó. Un servicio puede ser capaz de responder a una pregunta y, aun así, no poder demostrar qué datos hicieron posible la respuesta. La retención y la recuperación no son imágenes especulares. Conservarlo todo para siempre puede vulnerar una limitación de finalidad; borrar la fuente y dejar un derivado o una caché puede generar un problema distinto. Un límite de datos serio especifica qué se almacena, durante cuánto tiempo, por quién y cómo un revisor posterior puede comprobar que se respetó ese límite.

La identidad no es una pantalla de inicio de sesión. Es el mecanismo que otorga a una persona, servicio o agente la autoridad para realizar una acción. Si un endpoint de inferencia puede llamar a una herramienta, el sistema debe saber qué principal hizo la solicitud, qué política permitió la llamada y a qué podía acceder la herramienta. Si un registro permite promover un contenedor, debe saber quién puede aprobar la promoción y qué evidencia se requiere. Si un certificado se renueva automáticamente, el servicio debe tener igualmente una forma de detectar que la relación de identidad ha cambiado. Un secreto que sigue siendo válido después de que la persona que lo solicitó se marcha es un problema de mantenimiento con una consecuencia de seguridad.

Los registros son la memoria de un sistema en movimiento. Un registro de modelos puede contener versiones y metadatos. Un registro de artefactos puede contener contenedores, paquetes o versiones firmadas. Un registro de datos puede describir esquemas y propiedad. Un inventario de hardware puede identificar una placa, la versión de firmware y el estado de sustitución. La cuestión no es crear un registro para todo. La cuestión es hacer explícita la fuente autoritativa de cada afirmación. Si ningún sistema puede responder qué modelo, controlador, versión de datos y versión de política estaban activos, una revisión posterior se verá obligada a inferir la historia a partir de los logs que hayan sobrevivido.

La observabilidad cierra el ciclo. Las métricas indican al operador que una cola ha crecido o que un dispositivo está caliente. Los traces muestran la ruta seguida por una solicitud. Los logs aportan contexto, aunque siguen siendo fáciles de malinterpretar. Los eventos y las atestaciones pueden preservar decisiones y cambios. Estos objetos tienen funciones distintas. Tratarlos como intercambiables produce ruido o una falsa sensación de prueba. La cuestión de diseño es qué debe saber una persona cuando el servicio llega tarde, falla, no está disponible o se cuestiona, y qué registro puede responder a esa pregunta sin un ejercicio de reconstrucción.

Se puede describir esto como ingeniería aburrida. Eso no es un insulto. La ingeniería aburrida es la parte que sigue funcionando después de que la publicación del lanzamiento haya bajado en la página de inicio. También es la parte que determina si se puede adoptar un nuevo modelo sin reescribir la institución en torno a él.

El mantenimiento es una capacidad, no una partida de gastos

Las historias de infraestructura suelen terminar en el despliegue. Ahí es cuando el trabajo se convierte en un servicio. Se publica un modelo, se pone en marcha un clúster, se abre una fábrica, se firma un contrato y la narrativa pasa al siguiente anuncio. El sistema en sí continúa a través de parches, sustitución de hardware, formación, revisiones de acceso, actualizaciones, retiradas de funciones, respuesta a incidentes y la desaparición gradual de las personas que recuerdan por qué se eligió una configuración.

El informe de amenazas de ENISA sitúa la escasez de competencias entre las principales preocupaciones a largo plazo. Esto no es solo un problema del mercado laboral. Es un problema de resiliencia. Un servicio cuyas dependencias no puede entender más de una persona tiene un punto único de fallo oculto. Una organización puede tener máquinas de repuesto y aun así carecer de la capacidad de usarlas de forma segura porque el runbook, el proceso de compilación o el contrato de datos vive en la memoria de un solo ingeniero. Comprar soporte puede reducir el riesgo, pero el comprador sigue necesitando el conocimiento suficiente para cuestionar al proveedor y decidir cuándo detenerse.

El mantenimiento también cambia lo que significa una afirmación de rendimiento. Una prueba de referencia ejecutada en una versión concreta dice algo sobre esa versión en las condiciones indicadas. No dice que el sistema vaya a tener el mismo comportamiento después de una actualización de controladores, un cambio de compilador, un nuevo planificador, una ruta de almacenamiento distinta o una carga de trabajo nueva. Un servicio útil mantiene las condiciones de sus afirmaciones. Registra versiones, entradas, hardware, políticas y cambios para que alguien pueda repetir una prueba o explicar por qué la repetición ya no es posible.

Fingir que el mantenimiento es una preocupación de segundo orden tiene un coste humano. Los operadores retrasan las actualizaciones porque el grafo de dependencias no está claro. Los equipos de seguridad se esfuerzan por determinar qué paquete está realmente en producción. Compras renueva un contrato porque nadie ha ensayado una salida. Los investigadores no pueden reproducir un resultado porque el entorno ha cambiado. Los usuarios encuentran errores intermitentes que se atribuyen al modelo porque el servicio no tiene un lenguaje común para las capas que hay debajo. El resultado no es un único fallo dramático. Es una reducción lenta de la confianza.

Un calendario de mantenimiento debería incluir, por tanto, algo más que fechas de parches. Debería incluir revisiones de propiedad, caducidad de accesos, rotación de certificados y claves, pruebas de restauración de copias de seguridad, revisión de dependencias, ciclo de vida del hardware, avisos de cambio de proveedor, retirada de modelos y las evidencias necesarias para cada elemento. Algunas de estas tareas pueden automatizarse. La responsabilidad no puede automatizarse. Alguien debe decidir qué cuenta como cambio material, quién recibe la señal y qué autoridad puede pausar el servicio.

El instinto europeo de crear un comité para un problema difícil se ridiculiza a veces, a menudo injustamente. Un comité que posee un mapa de dependencias, una regla de cambio y una vía de escalado es más útil que un panel que no pertenece a nadie. El problema no es la gobernanza. El problema es una gobernanza que no puede llegar a la máquina.

La contratación es donde las dependencias se convierten en compromisos

Los contratos convierten una dependencia en un compromiso. Un comprador elige un proveedor, un componente, un acuerdo de soporte, una ubicación de datos, un periodo de renovación y una condición de salida. La decisión puede describirse como la compra de un servicio de IA, pero el comprador también está comprando el proceso de actualización del proveedor, su respuesta ante incidentes, su modelo de identidad, la estabilidad de su interfaz, su documentación y su capacidad para seguir en el negocio. Esos no son elementos secundarios. Determinan cuánta autoridad conserva el comprador.

El documento del grupo asesor de ENISA de 2025 sobre la aplicación de la Directiva NIS2 es inusualmente directo al respecto. Señala que las empresas más pequeñas pueden verse arrastradas al trabajo de cumplimiento de la NIS2 porque suministran a entidades que están dentro del ámbito de aplicación. Defiende un marco europeo de seguridad de la cadena de suministro y contratación pública con una base de medidas y un método común de diligencia debida. También pide una base de contratación con requisitos mínimos en los contratos, cláusulas estándar, enfoques de pruebas de seguridad y una forma sencilla de que el cliente evalúe a los proveedores. El documento es una opinión consultiva, no un reglamento. Su valor aquí es que nombra la fricción operativa que se produce cuando cada comprador inventa una versión distinta de la diligencia.

Los equipos de contratación no necesitan exigir que cada proveedor revele todos los detalles internos. Sí necesitan hacer preguntas que conecten con las consecuencias. ¿Qué componentes son esenciales para el servicio? ¿Cómo se comunican los cambios? ¿Cómo puede el comprador verificar el software y el firmware en uso? ¿Qué ocurre si un proveedor o subproveedor no puede suministrar un componente? ¿Qué datos y evidencias pueden exportarse? ¿Cuánto tiempo continúa el soporte después de retirar una versión? ¿Quién puede pausar una operación y qué ocurre con el trabajo ya en curso?

Estas preguntas son menos vistosas que una demostración. También son más difíciles de falsear. Un proveedor puede mostrar una respuesta fluida en diez minutos. Es más difícil mostrar un inventario completo de dependencias, una restauración probada, una ruta de migración y una persona autorizada a decir que no en el momento oportuno. El comprador no debería tratar esta dificultad como un motivo para evitar las preguntas. Es el motivo para plantearlas antes de que el servicio se vuelva difícil de reemplazar.

El riesgo de concentración merece un lenguaje cuidadoso. Un proveedor muy utilizado no es automáticamente inseguro, y un proveedor pequeño no es automáticamente resiliente. La concentración se convierte en un riesgo cuando un proveedor, un repositorio de software, una ruta geográfica, una autoridad de identidad o un equipo de mantenimiento soporta más consecuencias de las que la organización puede absorber. El informe prospectivo de ENISA describe a los proveedores transfronterizos de servicios TIC como un posible punto único de fallo. La respuesta adecuada no es fingir que la concentración puede eliminarse. Es identificar dónde existe, fijar una dependencia aceptable y ensayar qué ocurre si la ruta no está disponible.

Las cláusulas de salida suelen redactarse como mobiliario jurídico. Una cláusula de salida real tiene una forma técnica. Nombra formatos, interfaces, derechos de recuperación, claves, registros, pruebas, soporte durante la transición, confirmación de borrado y la información mínima necesaria para reconstruir un servicio en otro lugar. Es más sólida cuando se ha probado con una carga de trabajo pequeña. La prueba no tiene por qué ser teatral. Una exportación controlada, una restauración en un entorno independiente y una comparación del comportamiento resultante pueden revelar más que varias páginas de garantías.

La infraestructura crítica es una red de dependencias

La Directiva sobre resiliencia de las entidades críticas hace un movimiento similar a nivel de los servicios esenciales. Define la resiliencia como la capacidad de una entidad para prevenir, proteger frente a, responder a, resistir, mitigar, absorber, asumir y recuperarse de un incidente. Describe la infraestructura crítica como un activo, instalación, equipo, red o sistema necesario para un servicio esencial. La redacción es deliberadamente más amplia que un edificio. Trata el servicio como una relación entre activos, personas y funciones.

La directiva señala que los Estados miembros deben considerar los riesgos intersectoriales y transfronterizos, y apunta a las crecientes interdependencias entre infraestructuras y sectores. También indica que los efectos en la cadena de suministro deben tenerse en cuenta al evaluar la importancia de un incidente disruptivo. Esto importa para la infraestructura de IA porque el servicio relevante puede no estar etiquetado como inteligencia artificial en absoluto. Un enlace de datos, un sistema eléctrico, un servicio de identidad, un sistema de registros hospitalarios o una red de investigación pueden ser la capa que hace posible un servicio basado en IA.

La directiva no es un manual de operaciones de IA. No clasifica todo servicio de modelos como crítico, y no sustituye las normas específicas de cada sector. Aporta una forma de pensar sobre las consecuencias. Si un sistema respalda un servicio esencial, la cuestión no es solo si el modelo ha superado una evaluación. Es si la entidad puede seguir prestando el servicio esencial cuando cambia un componente, una instalación, un proveedor, una red o una condición externa.

La Directiva NIS2 se sitúa junto a esta visión física y organizativa con obligaciones de gestión de riesgos de ciberseguridad y notificación de incidentes para las entidades pertinentes. La interacción jurídica es específica y depende de la entidad y del sector. La lección general no es que una sola directiva resuelva la resiliencia. Es que las dependencias cibernéticas y físicas deben coordinarse. Una red puede ser segura frente a un tipo de ataque y aun así fallar cuando no hay refrigeración disponible. Una instalación puede tener energía redundante y aun así no poder autenticar a los operadores. Un proveedor puede notificar un incidente de software mientras el comprador carece de los registros necesarios para comprender su efecto.

La resiliencia necesita, por tanto, un vocabulario para el servicio degradado, no solo para la interrupción total. ¿Puede el sistema aceptar menos solicitudes? ¿Puede desactivar una función de alto riesgo mientras conserva una de bajo riesgo? ¿Puede cambiar a un modelo más pequeño o a una vía manual? ¿Puede continuar mientras se vacía una cola y se verifica una fuente? ¿Puede demostrar qué trabajo se retrasó o se reprocesó? Estas son decisiones operativas. También determinan si los ciudadanos, los investigadores y las empresas experimentan una limitación controlada o una respuesta misteriosa que llega después de que la institución haya perdido el contexto para revisarla.

La imagen útil es una red cuyos nodos tienen propietarios y cuyos bordes tienen condiciones. Un borde puede ser una conexión eléctrica, una dependencia de software, un contrato, una transferencia de datos o una relación de autoridad. Un diseño resiliente no asume que todos los bordes seguirán disponibles. Registra el borde, supervisa la condición que importa y define una respuesta antes de que llegue la presión.

Un compuesto ilustrativo, no un informe de incidentes

Conviene hacer concreto el problema de las dependencias sin inventar una interrupción real. Lo siguiente es un compuesto ilustrativo. No describe ninguna organización, proveedor, instalación, persona, fecha o evento con nombre. Es un experimento mental construido a partir de relaciones de infraestructura ordinarias.

Imagínese un servicio público de investigación que permite a equipos autorizados enviar un documento, ejecutar un flujo de trabajo de clasificación y recibir un resultado para revisión humana. El servicio está alojado en infraestructura europea. Su modelo se almacena en un registro de artefactos. Los documentos fuente viven en un nivel de almacenamiento y el índice en otro. Una pasarela verifica la identidad y reenvía el trabajo a una cola. Los trabajadores utilizan una imagen de contenedor y un controlador de hardware. Los resultados se escriben en un almacén de registros y en un flujo de evidencia. Un panel informa al equipo de operaciones si el sistema está sano.

Nada de esto es inusual. Ese es el punto. Ahora cambie una condición a la vez. El registro cambia su política de firma. La actualización del controlador requiere un nuevo tiempo de ejecución de contenedor. Un certificado caduca para el servicio que escribe evidencia, mientras que el almacén de resultados continúa aceptando escrituras. Se alcanza una cuota de almacenamiento para un índice derivado, pero no para los documentos fuente. Un proveedor cambia una interfaz y el consumidor de la cola reintenta una operación que no fue diseñada para repetirse. Un operador experto se marcha y el manual de operaciones aún describe el despliegue anterior. Ninguno de estos cambios requiere que un modelo produzca una frase falsa. Cada uno puede cambiar la fiabilidad del servicio o su capacidad de explicarse a sí mismo.

Una organización que solo vigila la precisión del modelo puede no ver ninguna advertencia. El conjunto de pruebas sigue pasando. Una organización que vigila todo el servicio verá señales diferentes: un fallo de verificación, un recuento de reintentos creciente, una brecha en el flujo de evidencia, un umbral de almacenamiento, un cambio sin revisar o una alarma de propiedad. Las señales no son equivalentes, y no todas exigen una interrupción. Exigen una regla sobre quién decide qué ocurre después.

Supongamos que el equipo decide reducir la capacidad mientras comprueba la dependencia. Eso no es una señal de que el servicio haya fallado en su propósito. Puede ser una señal de que el servicio tiene un propósito mayor que el rendimiento. Si el sistema puede conservar el registro fuente, marcar el trabajo retrasado, impedir reintentos no autorizados y dar a una persona una vía clara para inspeccionar los casos afectados, se ha degradado de forma controlada. Si continúa produciendo respuestas pulidas mientras su vía de evidencia está rota, ha preservado la apariencia de servicio a costa de la confianza.

El compuesto es deliberadamente corriente porque los incidentes espectaculares hacen la lección demasiado fácil. Todo el mundo entiende que una inundación puede interrumpir una instalación. El trabajo más difícil es reconocer que un certificado caducado, un registro sin propietario, un contrato de proveedor modificado o una prueba de recuperación ausente también pueden sacar un servicio de su límite operativo seguro. Las dependencias aburridas no son menos causales por carecer de una fotografía dramática.

El fallo se propaga a través de las relaciones

Un mapa de propagación de fallos debe seguir las relaciones, no las etiquetas tecnológicas. Empiece por la promesa del servicio. ¿Qué espera el usuario que ocurra y qué debe seguir siendo cierto para que se cumpla esa expectativa? Luego trace hacia atrás a través del modelo, el tiempo de ejecución, la puerta de políticas, la identidad, la red, el almacenamiento, el hardware, la energía, el proveedor y la institución. En cada paso, pregunte cómo se ve el fallo, cómo se detecta, quién es responsable de la respuesta y qué evidencia queda.

Esto suena lineal, pero los sistemas reales se ramifican. Un modelo puede estar disponible mientras un servicio de políticas no lo está. Una política puede permitir una llamada mientras un registro de identidad está desactualizado. Una solicitud puede ser aceptada mientras una cola no puede drenarse. Un resultado puede devolverse mientras falta el registro necesario para impugnarlo. Un equipo de infraestructura puede restaurar el servicio mientras un propietario de datos aún debe decidir si el trabajo afectado es de confianza. El mapa de propagación debe mostrar estas ramas porque una única luz de estado verde no puede.

Una forma útil de dibujar el mapa es separar cuatro tipos de consecuencias. La disponibilidad pregunta si el trabajo puede realizarse. La integridad pregunta si el trabajo y sus registros están sin cambios y completos. La autoridad pregunta si el actor tenía permiso para realizar el trabajo. La recuperabilidad pregunta si el servicio puede volver a un estado conocido y explicar lo que ocurrió. Una dependencia puede ser aceptable para una dimensión e inaceptable para otra. Una caché puede mejorar la disponibilidad y a la vez ser inadecuada como registro autoritativo. Un servicio de identidad de terceros puede ser conveniente y a la vez dificultar la inspección de la autoridad durante una interrupción.

El mapa también debe mostrar el tiempo. Algunas dependencias fallan de inmediato. Otras se degradan lentamente. Un modelo puede permanecer disponible mientras sus datos de respaldo se vuelven obsoletos. Un componente de hardware puede funcionar mientras el stock de repuestos se vuelve imposible de obtener. Un contrato puede seguir siendo válido mientras la política de cambios de un proveedor elimina lentamente la interfaz en la que el comprador confiaba. Cuanto más tarde llega una señal, más caro es interpretarla. El tiempo es parte de la dependencia, no una nota en el informe de incidentes.

Los equipos de operaciones suelen llamar a esto observabilidad. Esa palabra solo es útil cuando apunta a una acción. Un gráfico que parece saludable no le dice a nadie qué autoridad tiene, qué cambio provocó el movimiento del gráfico o qué evidencia debe conservarse. El propósito de un mapa de fallos es hacer posible una decisión. Si el flujo de evidencia está incompleto, pause la acción afectada. Si el registro de modelos no puede verificar un artefacto, no lo promueva. Si un proveedor cambia un componente fuera del límite probado, repita la evaluación correspondiente. Si una prueba de recuperación no puede restaurar el registro, no llame al respaldo un plan de recuperación.

No existe un umbral universal para estas decisiones. Un experimento de investigación, un servicio público y un flujo de trabajo crítico para la seguridad tienen tolerancias diferentes. Lo importante es que el umbral pertenezca al propietario del servicio, sea visible para los operadores y pueda revisarse cuando cambie la evidencia. De lo contrario, el umbral lo establecerá la primera persona que note el fallo, que es una forma notablemente democrática de gestionar un sistema y una mala forma de gobernarlo.

Una dependencia no necesita destruir el modelo para cambiar lo que el servicio puede afirmar con seguridad.

Medir la capacidad sin ocultar el denominador

La infraestructura invita a cifras impresionantes. Exaflops, petabytes, recuentos de procesadores, totales de inversión y el número de instalaciones de un programa describen algo real. Ninguna de ellas es el servicio por sí sola. Una cifra resulta útil cuando su denominador y sus condiciones son visibles.

El rendimiento máximo de computación no le dice a una investigadora con qué rapidez una carga de trabajo concreta obtendrá una partición, moverá sus datos, completará una ejecución o recuperará el resultado. El número de AI Factories no le dice a una pequeña empresa si su aplicación recibirá acceso en las condiciones que necesita. Un total de inversión en semiconductores no le dice a un operador qué componente estará disponible durante una escasez. Un alto porcentaje de disponibilidad no le dice a una institución pública si puede recuperar la evidencia de una decisión impugnada.

Una descripción responsable de la capacidad combina, por tanto, el titular con el camino que hay detrás. Nombra el límite entre hardware y software. Indica si la cifra es máxima, sostenida, prevista u observada. Describe la carga de trabajo, el modelo de acceso y las exclusiones. Señala qué dependencias quedan fuera de la medición. Mantén la afirmación vinculada a la versión, el hardware, el conjunto de datos y la política bajo los cuales se hizo. El objetivo no es hacer ilegible cada página. Es hacer verificables las páginas importantes.

Esta disciplina también mejora el debate público. Europa no necesita elegir entre ambición y prudencia. Puede construir grandes instalaciones, financiar investigación ambiciosa y aun así señalar dónde termina la evidencia. Un sistema público que nombra sus limitaciones es más creíble que uno que presenta una cifra limpia sin ninguna vía para inspeccionarla. La limitación puede ser una cola, una interfaz, un proveedor, una brecha de competencias, un límite de energía o una frontera legal. Nombrarla no hace la capacidad más pequeña. Le dice a la gente qué tipo de capacidad es.

La incertidumbre no es una admisión de derrota. Es una señal de mantenimiento. Si nadie sabe cómo afectará un cambio del proveedor a una carga de trabajo, el siguiente paso es una prueba o una suposición explícita, no un adjetivo más grande. Si un registro no puede distinguir una versión de modelo de una configuración de despliegue, el siguiente paso es un mejor registro. Si una institución no puede saber qué persona puede detener una operación, el siguiente paso es un mapa de autoridad. La precisión es una forma de decidir qué reparar.

Las capas silenciosas son donde la soberanía se vuelve práctica

La soberanía europea a veces se discute como si fuera una bandera colocada sobre un centro de datos. Un servicio puede estar ubicado dentro de la Unión y aun así depender de componentes externos, del alcance legal de otros países, de interfaces propietarias, de habilidades escasas o de un proveedor cuyas decisiones de cambio no se puedan cuestionar. La ubicación es un factor más en la evaluación de la soberanía. El control práctico depende de la cadena completa.

El enfoque de la Ley de Chips en comprender la cadena de suministro mundial de semiconductores, la atención de la Directiva CER a las interdependencias entre sectores y las advertencias de la ENISA sobre las dependencias de software y los puntos únicos de fallo apuntan todos en la misma dirección. La soberanía no es un interruptor único. Es la capacidad de entender de qué depende un servicio, de decidir qué dependencia es aceptable, de sustituirla o limitarla cuando sea necesario y de conservar suficientes pruebas para defender esa decisión.

Esa capacidad se puede construir con pequeños gestos. Un grupo de investigación público puede mantener un inventario del entorno de ejecución, del controlador y de la versión de datos utilizados para un resultado. Un equipo de contratación puede exigir una vía de exportación probada en lugar de una promesa de portabilidad. Un equipo de operaciones puede definir un modo degradado y ensayarlo. Un regulador puede preguntar qué registros estarían disponibles después de un cambio de proveedor. Un proveedor puede publicar el límite de su soporte y las condiciones en las que una actualización cambia el comportamiento. Ninguna de estas acciones hace que un sistema sea autónomo. Hacen que sea menos opaco.

En Dweve, esta es la razón concreta por la que nos importan las bases abiertas y las piezas silenciosas que las rodean. Proyectos como Core y Mesh solo son útiles cuando se sitúan dentro de un límite operativo honesto, con registros claros, autoridad y límites. No sustituyen a la infraestructura europea, a las instituciones públicas ni a la política de cadena de suministro, y este artículo no afirma que resuelvan esos problemas. La postura es más modesta: un componente abierto es más fácil de inspeccionar, sustituir y enseñar cuando sus contratos son explícitos. Eso es un ladrillo, no todo el edificio.

El edificio importa porque la gente ve la última planta y convive con los cimientos. La respuesta en la pantalla puede ser fluida, pero el carácter real del servicio lo deciden las capas que determinan de dónde procede la respuesta, quién podría cambiarla, qué ocurre cuando una dependencia se mueve y si alguien puede explicar el resultado más adelante.

Construye el sistema que la gente aún puede ver

El sistema de IA más importante puede ser el que nadie ve porque está distribuido en lugares que nunca se han llamado IA. Es la instalación de chips y el circuito de refrigeración. Es el superordenador y el planificador. Es el registro de paquetes, el proveedor de identidad, la política de almacenamiento, la ruta de red y el cuadrante de mantenimiento. Es el contrato que dice qué ocurre cuando un proveedor cambia un componente. Es la institución que puede pausar un flujo de trabajo antes de que una señal débil se convierta en un fallo público.

Nada de esto reduce la importancia de la calidad del modelo. Le da a la calidad del modelo un lugar donde importar. Un modelo solo puede servir a una persona a través de un sistema que pueda recibir la entrada, realizar el trabajo, conservar el registro pertinente y devolver el resultado con suficiente contexto para que alguien lo confíe o lo cuestione. El modelo es un componente importante de ese sistema. No es un país, una cadena de suministro, un plan de recuperación ni una persona con autoridad para reparar las partes que no puede ver.

Los programas de infraestructura de Europa son una oportunidad para hacer visibles estas dependencias mientras se construye la capacidad. La oportunidad es práctica. Publica interfaces y límites operativos. Financia el mantenimiento y las habilidades junto con el equipamiento. Trata la contratación como una decisión de diseño. Conecta la ciberseguridad con la resiliencia física. Da a las organizaciones más pequeñas una vía para usar la infraestructura pública sin obligarlas a ser especialistas en cada capa. Mide el acceso, la recuperación y las pruebas con el mismo cuidado que el rendimiento máximo.

Existe un cierto placer europeo en descubrir que la respuesta a una gran pregunta tecnológica es un inventario, un manual de operaciones y una persona autorizada a detener la máquina. No es glamuroso, pero tiene la ventaja de sobrevivir al contacto con el martes. Cuando el sistema oculto es lo bastante visible para inspeccionarlo, el modelo puede hacer su trabajo sin cargar con un mito que nunca fue construido para sostener.

Fuentes