IT de ubicación: Modo Alemania en lugar del dogma de la nube

16.07.2026

6 min de lectura

Muchas empresas DACH están entre requisitos de soberanía, OT de fábrica y estándares cloud globales. Quien trata la TI local solo como infraestructura subestima gobernanza, modelo operativo y gestión de Capex. Los decisores necesitan un modelo operativo que gestione ambas dimensiones y reemplace la elección ideológica de plataformas.

Lo más importante en resumen

Gestionar tres lógicas en paralelo. Las plataformas corporativas, la OT cercana a las fábricas y los requisitos regulatorios interactúan simultáneamente: la soberanía es la capacidad de controlar de forma vinculante la ubicación, el lugar de procesamiento, el operador y la vía de salida.
Cinco clases de cargas de trabajo. Al menos cinco clases de cargas de trabajo -desde SaaS hasta sistemas centrales, IA, edge y procesamientos regulados- reemplazan a las directrices genéricas de cloud-first y on-premise.
Separar roles y presupuestos. La TI corporativa establece líneas base, la región traduce el cumplimiento normativo, y la fábrica gestiona la proximidad a la OT. Empresas como Volkswagen y Siemens separan las plataformas centrales de las cargas de trabajo cercanas a la producción.
Árbol de decisiones antes del lanzamiento. La clase de datos, la latencia y la integración determinan la ubicación y el operador. La verificación operativa con RTO y RPO según ISO 22301 cierra la arquitectura.

RelacionadoSoberanía digital 2026: Delos Cloud, Gaia-X, EU Data Act / Cloud soberana: el camino de Europa hacia la soberanía digital

El campo de tensión entre soberanía, OT y plataformas globales

Los CIO y CDO gestionan hoy tres lógicas simultáneamente. Las plataformas corporativas exigen estandarización, economías de escala y ciclos de lanzamiento globales. Los sistemas de las fábricas y ubicaciones requieren disponibilidad, latencias deterministas y una integración estrecha con máquinas, sistemas de control y transiciones de turno. Los requisitos regulatorios y contractuales en materia de residencia de datos, procesamiento por encargo y rutas de auditoría imponen límites adicionales. Esto, sin embargo, no define aún una arquitectura.

El campo de tensión surge cuando una de las tres lógicas se convierte en la única directriz. Una directriz genérica de cloud-first puede generar problemas de latencia, mantenimiento y aprobación en cargas de trabajo cercanas a la OT. Una directriz genérica de on-premise encarece las aplicaciones estándar y dificulta la disciplina de parches e identidades. La soberanía en el ámbito de TI no es un compromiso político; es la capacidad de controlar de forma vinculante la ubicación, el lugar de procesamiento, el operador y la vía de salida.

A nivel práctico, esto significa que deben definirse con antelación las clases de datos, los lugares de procesamiento y las responsabilidades operativas antes de elegir la plataforma. El catálogo de criterios C5 del BSI exige a los proveedores de cloud transparencia en el sistema sobre sede judicial, ubicaciones de procesamiento de datos y obligaciones de información a autoridades. La versión C5:2026 refuerza además la implementación técnica de la soberanía y la separación de inquilinos. Paralelamente, el capítulo V del RGPD (arts. 44 y siguientes) regula la transferencia internacional de datos personales. El Reglamento EU Data Act (Reglamento (UE) 2023/2854), aplicable desde septiembre de 2025, complementa los derechos de cambio de proveedor de cloud y los mecanismos de protección contra accesos indebidos de terceros países a datos no personales almacenados en la UE. Si estas determinaciones se aplican después de la migración a cloud, los costes de subsanación y los riesgos de auditoría aumentan. Esto es especialmente relevante en entornos donde datos de producción, de personal y de interfaces con proveedores comparten la misma pila tecnológica.

Clases de carga de trabajo en lugar de la regla genérica de Cloud-First

Un modelo operativo sólido comienza con clases de carga de trabajo, no con proveedores. Lo recomendable es definir al menos cinco clases: servicios SaaS y de colaboración a nivel empresarial, sistemas centrales con altos requisitos de integración, cargas de trabajo analíticas e de IA, cargas de trabajo de control y sensorización cercanas al edge, así como procesos regulados o vinculados a ubicaciones específicas. Cada clase requiere criterios sobre latencia, clasificación de datos, frecuencia de cambios, capacidad operativa y costes de salida.

La nube es adecuada donde la elasticidad, identidades globales y procesos operativos estandarizados impulsan el valor. El edge y la capacidad de computación local son idóneos donde los ritmos de producción, la capacidad de operar sin conexión o la estrecha vinculación con OT marcan el ritmo. La estrategia híbrida consiste en asignar planificadamente las cargas de trabajo a ubicaciones y formas de operación. Para orientarse, se pueden utilizar modelos de referencia consolidados: la jerarquía funcional según ISA-95 (IEC 62264) separa el proceso físico, el control, la ejecución de la fabricación y los sistemas empresariales. La serie de normas ISA/IEC 62443 complementa este enfoque con zonas y conduits, es decir, zonas de seguridad con requisitos de protección comparables y rutas de comunicación controladas entre ellas.

Si se definen claramente las clases de carga de trabajo, se evitan dos errores típicos. En primer lugar, migrar únicamente sistemas críticos cercanos a la planta porque el estándar corporativo es la nube. En segundo lugar, bloquear cargas de trabajo estándar sin problemas tras argumentos de soberanía que no se sostienen técnica ni legalmente. La pregunta clave es: ¿qué control, qué ubicación y qué operador son adecuados para esta clase?

Roles de la planta, la región y la TI corporativa

Sin roles claros, la estrategia híbrida se desmorona en TI en la sombra y trabajo duplicado. La TI corporativa establece los principios de arquitectura, las líneas base de identidad y seguridad, los marcos de contratación y los estándares de plataforma. La TI regional adapta las directrices corporativas a la realidad de cumplimiento, contractual y operativa específica de cada país. El nivel de planta es responsable de la proximidad a OT, el trabajo por turnos, las incidencias locales y la interfaz con mantenimiento y producción.

Esta interfaz debe formalizarse. Los derechos de cambio y liberación, la propiedad de incidentes y los flujos de aprobación para cambios relevantes para OT deben incluirse en un modelo operativo con rutas de escalado claras. Las identidades, las zonas de red y el registro de logs no pueden reinventarse en cada ubicación. Al mismo tiempo, la planta necesita margen de decisión para sistemas de ritmo ajustado que no puedan seguir el ciclo de liberación corporativo.

A nivel financiero, la separación entre Capex y Opex sigue la misma lógica de roles. Las plataformas corporativas suelen presupuestarse como servicios compartidos. La infraestructura local y la vinculación con OT suelen ser más impulsadas por inversiones y requieren una planificación plurianual de mantenimiento y modernización. Ejemplos públicos de empresas confirman esta separación de niveles de control: Volkswagen construye con la Group Private Cloud 2.0, basada en T Cloud Private de T-Systems, una plataforma central para aplicaciones empresariales y, según Hauke Stars, miembro del Consejo de Dirección de TI del Grupo, enfatiza la combinación de alianzas y su propia infraestructura. En este caso, no se contempla una estrategia exclusiva de nube. Paralelamente, Volkswagen opera cargas de trabajo cercanas a la producción a través de la Plataforma de Producción Digital con AWS. Siemens describe en su planta de motores de Bad Neustadt la convergencia de IT y OT como un caso de operación local con fabricación basada en datos. Sin esta separación de roles y presupuestos, surgen presupuestos ocultos y prioridades enfrentadas entre la planta y la sede central.

Riesgos de aprovisionamiento y operativos en el modelo alemán

El modelo alemán conlleva riesgos típicos de aprovisionamiento. Los largos plazos de entrega para servidores, hardware de red y OT chocan con ventanas de mantenimiento reducidas en producción. Los contratos marco con hiperescaladores globales y proveedores de hosting locales se ejecutan en paralelo y generan inconsistencias en los SLA, derechos de auditoría y cláusulas de salida. La escasez de personal en roles operativos cercanos a OT refuerza la dependencia de integradores y el soporte de los fabricantes.

Los riesgos operativos siguen a la arquitectura. La separación de identidades entre TI y OT incrementa las superficies de ataque y dificulta la trazabilidad forense. La residencia incierta de los datos en pipelines de backup, logging y IA genera correcciones posteriores. Se acumulan retrasos en parches en sistemas cercanos a edge cuando las actualizaciones de seguridad no se coordinan con las liberaciones de producción. El BSI subraya en sus recomendaciones sobre ICS y OT que estos sistemas requieren tiempos de operación más largos, ventanas de mantenimiento escasas y requisitos en tiempo real. Por ello, las medidas de protección de la TI corporativa solo son transferibles de forma limitada. Las «Principios básicos de ciberseguridad OT» del BSI (2024) se dirigen a los decisores y exigen un control integral desde la planificación hasta la operación. La norma ISA/IEC 62443 aporta, con zonas, conductos y el informe técnico 62443-2-3, líneas base concretas para la segmentación y la gestión de parches en sistemas de automatización y control industrial. El componente de protección básica IND.1 del BSI complementa estos requisitos con exigencias para sistemas de control de procesos y tecnología de automatización.

Por tanto, el aprovisionamiento debe seguir a la arquitectura, y no al revés. Una multi-nube basada únicamente en el reflejo negociador encarece la operación y la gobernanza si no se definen previamente las clases de carga de trabajo y los flujos de datos. Las opciones de colocation local o hosting soberano solo ayudan si los procesos operativos, la gestión de claves y la recuperación se han probado y presupuestado. Aquí, el CIO gestiona los riesgos residuales y la capacidad de salida.

Árbol de decisiones para casos híbridos y edge

Un árbol de decisiones útil comienza con la clase de datos y procesos. En primer lugar, los decisores deben aclarar si la carga de trabajo procesa datos personales, sensibles o críticos para la producción, y qué obligaciones de residencia y auditoría aplican. A continuación, se plantea la cuestión de latencia y disponibilidad: ¿basta con una zona de nube regional? ¿Se requiere proximidad a la planta o capacidad offline? Después, se analiza la frecuencia de cambios y la densidad de integración con MES (Sistema de Ejecución de Fabricación), SCADA (Sistema de Supervisión, Control y Adquisición de Datos), ERP y servicios de identidad.

Solo entonces se decide la ubicación y el operador. El SaaS es admisible si la clase de datos, el contrato y la salida son compatibles. La nube privada o virtual privada es adecuada para sistemas centrales integrados con altos requisitos de control. Las instancias edge y on-premise se aplican en acoplamientos con OT, límites estrictos de latencia o aprobaciones vinculadas a ubicaciones. El modelo híbrido surge cuando el preprocesamiento de datos se realiza localmente y el análisis o entrenamiento se ejecuta de forma centralizada, siempre que las interfaces estén estandarizadas.

El árbol finaliza con la prueba de operación. Antes del lanzamiento, deben responderse preguntas clave: ¿quién opera?, ¿quién aplica parches?, ¿quién gestiona las escalaciones? y ¿cómo se logra la recuperación en qué plazo? La norma ISO 22301 sobre gestión de continuidad del negocio define para ello los objetivos clave RTO (objetivo de tiempo de recuperación, tiempo máximo de inactividad tolerable) y RPO (objetivo de punto de recuperación, pérdida máxima de datos tolerable). Si falta esta prueba, la arquitectura está incompleta, aunque la plataforma objetivo esté formalmente aprobada.

Para el CIO y el CDO la conclusión es clara: la TI de ubicación se convierte en un objeto de control con clases de carga de trabajo, modelo de roles y árbol de decisiones. La nube sigue siendo una herramienta. La soberanía, capacidad de control. La OT, una realidad operativa. Quien integre estos tres niveles en el modelo operativo reducirá la mala asignación de capex y tomará decisiones híbridas sólidas para el modo Alemania.

Preguntas frecuentes

¿Por qué aumentan los riesgos de auditoría en las determinaciones de residencia y salida realizadas con posterioridad?

Las clases de datos, los lugares de procesamiento y la responsabilidad operativa deben definirse antes de elegir la plataforma. C5:2026 exige transparencia en cuanto a la sede judicial, ubicaciones de datos y separación de clientes. El capítulo V del RGPD regula la transferencia a terceros países, y el Reglamento de Datos de la UE complementa, desde septiembre de 2025, los derechos de cambio y la protección frente a accesos indebidos de terceros países. Las correcciones posteriores generan costes de subsanación y riesgos de auditoría en cuanto los datos de producción, personal y proveedores se integran en la misma pila.

¿Qué riesgos de aprovisionamiento caracterizan especialmente la configuración en Alemania?

Los largos plazos de entrega para servidores, hardware de red y OT coinciden con ventanas de mantenimiento ajustadas en producción. Los contratos marco paralelos con hiperescaladores y proveedores locales generan inconsistencias en los SLA, derechos de auditoría y cláusulas de salida. La escasez de personal en roles operativos cercanos a OT refuerza la dependencia de integradores y el soporte de los fabricantes. El aprovisionamiento sigue a la arquitectura una vez definidas las clases de carga de trabajo y los flujos de datos.

¿Cómo se formaliza la interfaz entre la TI del grupo y la planta?

Los derechos de cambio y liberación, la propiedad de incidentes y los flujos de aprobación para modificaciones relevantes para OT deben incluirse en un modelo operativo con rutas de escalación claras. Las identidades, zonas de red y registros se mantienen estandarizados a nivel corporativo. Al mismo tiempo, la planta conserva margen de decisión para sistemas tácticos fuera del ciclo de liberación corporativo. Los gastos de capital y explotación siguen la misma lógica de roles y separan los servicios compartidos del grupo de la infraestructura local impulsada por inversiones.

¿Cuándo sigue incompleta la arquitectura a pesar de tener la plataforma objetivo aprobada?

Cuando falta la prueba de operación antes del lanzamiento. Debe responderse de forma vinculante quién opera, quién parchea, quién gestiona las escaladas y cómo se realiza la recuperación. La norma ISO 22301 define el RTO como el tiempo máximo de inactividad tolerable y el RPO como la pérdida máxima de datos admisible. Sin estos objetivos y rutas claras de propiedad, la arquitectura sigue incompleta.

Más para leer en Digital Chiefs

Digital ChiefsToken-OPEX: La inferencia controla, no el presupuesto de asientos Digital ChiefsEl hardware supera a los acuerdos de software: reorganizar el Capex Digital ChiefsLa factura de diez años de soluciones insulares

Más de la red MBF Media