Nota de contexto: del proyecto madrileño solo hay información institucional — es lo normal en esta fase y no es un reproche. No se han publicado presupuesto, calendario, operador ni nivel de certificación comprometido, así que este artículo analiza el patrón, no el diseño concreto, y distingue de forma explícita lo anunciado de lo que es lectura propia.
Los dos anuncios, en corto
El 14 de julio la Generalitat de Catalunya licitó, dentro de su estrategia ESTRATEC, una nube pública soberana de 481 millones de euros para sus datos más sensibles —historiales de La Meva Salut, información fiscal, autorizaciones ambientales— con sello SEAL 3 y entrada en operación prevista en el tercer trimestre de 2027, y un reparto declarado del 40% de los servicios en la nube soberana, 30% en privada y 30% en pública convencional.
El 18 de agosto la Comunidad de Madrid presentó el despliegue de su Nube Soberana de IA en Alcalá de Henares, de la mano del consejero de Digitalización, Miguel López-Valverde. Según la nota oficial, los primeros componentes se están implantando en el municipio por su conectividad y su posición junto a otras iniciativas de innovación e industria avanzada, con el objetivo de gestionar la información regional con mayores garantías, acelerar el desarrollo de servicios públicos y reducir costes de licencias y servicios externos, contando con la colaboración de «compañías líderes» que aportan computación avanzada y almacenamiento seguro. El Ayuntamiento cifra en hasta 600 empleos el impacto económico potencial — una previsión municipal, no un compromiso de plantilla publicado por la Comunidad.
Y ahora el detalle que da título a este artículo. El 30 de abril de 2013, en el Parque Científico Tecnológico TecnoAlcalá —impulsado por la propia Comunidad de Madrid dentro del campus de la Universidad de Alcalá— Telefónica inauguró la primera fase de su Alcalá Data Center: 120 millones invertidos de los más de 300 previstos, 23 salas de TI, 65.700 m² y certificación Tier IV del Uptime Institute. El mismo parque y la misma universidad que hoy vuelven a aparecer en el anuncio de 2026.
Por qué esto rima con la etapa del housing
Quien vivió profesionalmente aquella época reconoce el patrón sin esfuerzo. No es idéntico, pero rima en cuatro cosas concretas:
- Capacidad dedicada en una ubicación identificable. El valor se comunica en términos de dónde está la infraestructura y de quién puede entrar en la sala, igual que entonces se comunicaba en metros cuadrados, redundancia y nivel Tier.
- El mismo argumento económico. Reducir gasto en licencias y servicios externos es, casi palabra por palabra, el pitch con el que se justificaba sacar cargas del proveedor de turno y llevarlas a capacidad propia gestionada.
- El operador en segundo plano. «Compañías líderes» que aportan cómputo y almacenamiento es la versión 2026 de «nuestro partner de infraestructura». Quién administra realmente el entorno rara vez era el titular en 2013, y tampoco lo es ahora.
- Compromiso largo sobre una previsión. Se dimensiona para una demanda estimada y se firma a varios años. Cuando el perfil de carga cambia antes que el contrato, aparece el problema clásico: hierro amortizándose y arquitectura que ya no encaja.
Ese último punto es el que más daño hizo en la década pasada, y es el que menos se menciona en los anuncios. No por mala fe: es que en el momento del corte de cinta nadie sabe todavía cómo será la curva de demanda real.
Lo que ha cambiado no es el sitio: es el motor
Aquí es donde la analogía deja de sostenerse, y conviene ser preciso, porque de la diferencia salen las decisiones de diseño. En 2013 se hacía housing porque el cloud público era caro, inmaduro o no tenía la certificación necesaria. Hoy el cloud público es más barato, más capaz y está certificado — y aun así se vuelve a la capacidad propia. Cuando el resultado se repite pero la causa ha cambiado, copiar el diseño anterior es exactamente el error.
| Dimensión | Housing / hosting gestionado (≈2013) | Nube soberana de IA (2026) |
|---|---|---|
| Motivo real | Coste y madurez: el cloud público aún no compensaba | Jurisdicción y control: CLOUD Act, AI Act, exigencias de supervisión |
| Unidad de consumo | Rack, U, metro cuadrado, ancho de banda | Servicio, API, token, GPU-hora |
| Ciclo de refresco | 5–7 años de vida útil razonable del servidor | 18–24 meses de competitividad real de una generación de aceleradores |
| Modelo operativo | Ticket al proveedor, ventana de cambio, intervención manual | Autoservicio por API, infraestructura como código, despliegue continuo |
| Medida de éxito | Disponibilidad y certificación de la instalación | Tiempo desde la idea hasta el servicio público en producción |
| Riesgo dominante | Sobredimensionar y quedarse con capacidad ociosa | Quedarse con capacidad soberana y a la vez tecnológicamente obsoleta |
Merece la pena señalar algo que se pierde en el debate: los Interxion —hoy Digital Realty— y Equinix de aquella etapa no desaparecieron. Los hyperscalers viven dentro de ellos. La ubicación física dejó de ser la variable discriminante hace tiempo, y por eso preguntarse «¿esto es volver al CPD?» es la pregunta equivocada. La buena es qué capa se pone encima.
La variable que decide: el plano de control
Mi conclusión, después de darle vueltas a ambos anuncios, es esta: la diferencia entre una nube soberana y un housing con nombre nuevo no está en el hierro ni en el código postal. Está en si existe un plano de control propio y de qué calidad es. Cuatro señales lo distinguen sin ambigüedad:
Si esas cuatro están, el hecho de que el hardware esté en Alcalá es una decisión de ubicación, no de arquitectura, y el proyecto es perfectamente compatible con las prácticas de 2026. Si no están, entonces sí es un CPD con una etiqueta nueva, por muy soberana que sea.
La depreciación de la IA cambia las cuentas
Hay un factor que no existía en 2013 y que a mi juicio es el que más debería condicionar el diseño. Un servidor de propósito general daba cinco o siete años de vida útil razonable, y el modelo financiero del housing se construía sobre esa curva. Una generación de aceleradores de IA mantiene su competitividad durante bastante menos — el orden de magnitud está en dieciocho o veinticuatro meses, no en un lustro.
Comprar capacidad de IA con mentalidad de housing lleva a un resultado incómodo: en 2029 tienes una infraestructura simultáneamente soberana y desfasada, con el agravante de que la desactualización de una plataforma de IA no se nota en disponibilidad sino en qué modelos puedes ejecutar. Eso obliga a dos piezas de diseño que conviene escribir ahora y no dentro de tres años:
- Un modelo de refresco explícito, con presupuesto plurianual asociado, en lugar de una inversión inicial que se amortiza en silencio.
- Una válvula de elasticidad hacia nube pública certificada para picos, experimentación y modelos que no compense ejecutar en casa, gobernada por un criterio de clasificación de dato publicado. Es, en el fondo, lo que ya declara el reparto 40/30/30 del proyecto catalán.
El criterio que yo aplicaría: la nube soberana debería reservarse para las cargas cuya sensibilidad jurídica lo exige y cuyo perfil de consumo es estable y predecible. Todo lo variable, experimental o de pico vive mejor en nube pública certificada. Forzar el 100% al entorno más restrictivo es tan ineficiente como no proteger nada — y es la vía más rápida a la capacidad ociosa.
Dos proyectos, dos formas legítimas de plantearlo
Vale la pena poner uno al lado del otro, no para puntuarlos sino porque ilustran que «nube soberana» describe una intención, no una arquitectura, y que el eje elegido cambia todo lo demás.
| Dimensión | Generalitat de Catalunya (ESTRATEC) | Comunidad de Madrid (Nube Soberana de IA) |
|---|---|---|
| Eje del proyecto | Clasificación del dato: qué información no puede salir de una jurisdicción | Capacidad de cómputo: poder ejecutar IA sobre datos públicos sin depender de servicios externos |
| Instrumento | Licitación pública con pliego, adjudicación prevista a finales de 2026 | Despliegue en curso con colaboración de empresas del sector |
| Información publicada | Inversión, sello, calendario y reparto de cargas | Objetivos y ubicación; el detalle técnico llegará más adelante |
| Marco de gobierno | Estrategia ESTRATEC de autonomía tecnológica | Anteproyecto LADIA, con Oficina de Impulso a la IA, Consejo y Comité de Ética |
Son dos problemas distintos y ambos son reales. Un proyecto centrado en el dato puede construirse sobre tecnología estándar y auditarse con relativa claridad. Uno centrado en IA hereda además la cadena de dependencia de modelos, aceleradores y frameworks, que hoy no tiene equivalente europeo completo en todas sus capas. La ambición es mayor, y la superficie de dependencia también — lo cual no lo invalida, pero sí obliga a decir en voz alta qué capa se considera soberana: el modelo, la infraestructura de inferencia o el control operativo. Rara vez son las tres.
Cinco decisiones que harían que el péndulo sume
Que existan dos plataformas autonómicas no es un problema en sí. Lo que decide el resultado agregado es si se acuerda la capa de interoperabilidad ahora —cuando todavía es barata— o en 2029, con contratos firmados y esquemas divergentes. Cinco piezas concretas, ninguna de las cuales quita autonomía a nadie:
- Reconocimiento mutuo sobre base ENS. Un control certificado en una plataforma pública española se acepta en las demás mediante un procedimiento formal de equivalencia. Es la pieza con mejor relación entre esfuerzo de acuerdo y ahorro generado.
- Perfil técnico mínimo común. No un diseño único, sino un conjunto acotado de requisitos —identidad, cifrado, registro de auditoría, formatos de exportación— que toda plataforma soberana pública cumple, con libertad total en el resto.
- Portabilidad verificable, no declarada. Formato y proceso de exportación definidos desde el diseño y probados con un ejercicio real de migración, en la línea de lo que exige el Data Act a escala europea.
- Identidad federada entre administraciones. El acceso interadministrativo resuelto con confianza federada y trazabilidad de accesos privilegiados, en lugar de integraciones puntuales negociadas caso a caso.
- Compra agregada con ejecución regional. Negociar requisitos y condiciones una vez, desplegar y operar donde cada administración decida. Se conserva la autonomía y se recupera poder de negociación frente a proveedores globales — que es, en la práctica, una de las formas más eficaces de soberanía.
Y hay un beneficio que se menciona poco: una capa común hace que las comunidades sin presupuesto para construir la suya puedan adherirse a un esquema existente en lugar de quedarse fuera o licitar una versión menor. La alternativa —cada una por su cuenta— es la que produce el resultado que nadie quiere: el coste completo de la soberanía sin la escala que la hace sostenible.
Qué mirar cuando se publique el detalle
Cuando aparezcan pliegos, contratos o la arquitectura de referencia, estos son los puntos que, en mi experiencia, determinan si el resultado se parece a una plataforma o a un CPD renombrado. No son una lista de sospechas: son los mismos criterios que aplicaría a un proyecto propio.
- Nivel de certificación comprometido, con categoría ENS explícita y posición respecto a los esquemas europeos.
- Jurisdicción del equipo de operación, incluida la cadena de subcontratistas de soporte — no solo la ubicación del centro de datos.
- Existencia y madurez del plano de control: autoservicio, catálogo, IaC y políticas heredadas por defecto.
- Criterio publicado de clasificación de datos que determine qué carga va a dónde. Sin él, el reparto se decide por inercia presupuestaria.
- Qué capa del stack de IA se considera soberana y qué dependencias externas se asumen conscientemente.
- Modelo de refresco tecnológico con horizonte y presupuesto plurianual asociados.
- Mecanismo de interoperabilidad y reconocimiento mutuo con el ENS y con otras administraciones, con responsable y calendario.
- Portabilidad y exit plan del operador, verificables mediante prueba periódica y no solo declarados en el contrato.
Si trabajas en banca o seguros y crees que esto no te afecta: te afecta. Estas plataformas van a alojar datos sanitarios, fiscales y de identidad que intervienen en verificación de clientes, scoring y peritaciones. Cuanto mejor sea la capa de interoperabilidad que se acuerde ahora, menos integraciones a medida y menos due diligence de terceros bajo DORA tendrás que sostener después. Es un buen momento para que el sector privado opine, porque todavía se está diseñando.
La pregunta de 2029
Mi lectura, en una frase: no volvemos diez años atrás, vuelve a oscilar el péndulo entre control y elasticidad, como ya osciló con el mainframe, con el cliente-servidor, con el housing y con el cloud. Cada oscilación deja mejor tecnología que la anterior siempre que el plano de control avance con ella. Solo es un retroceso cuando se mueve el hierro y se deja quieta la forma de operarlo.
Así que la pregunta para 2029, cuando ambas plataformas estén en producción, no es dónde está el dato. Es si un equipo de una consejería puede desplegar un servicio nuevo en una tarde sin abrir un ticket, si un expediente puede cruzar de una comunidad a otra sin una integración construida a medida, y si una administración pequeña puede adherirse a lo que ya existe en lugar de empezar de cero. Si las tres respuestas son sí, el péndulo habrá sumado.
Alcalá de Henares, mientras tanto, gana un proyecto tecnológico de primer nivel trece años después del anterior, en el mismo parque y con la misma universidad al lado. Esa continuidad dice algo bueno sobre cómo se construye tejido tecnológico: no con un anuncio, sino con dos décadas de insistir en el mismo sitio.