Los equipos de finanzas, legal y energía llevan años construyendo stacks de BI sobre infraestructura de grandes proveedores cloud, y la mayoría de esos stacks funcionan bien desde el punto de vista técnico. El problema aparece cuando llega el auditor, o cuando el equipo legal empieza a preguntar dónde residen realmente los datos y quién puede exigir acceso a ellos. En ese momento, una arquitectura de data warehouse bien ajustada se convierte en un pasivo de cumplimiento, no porque la ingeniería sea incorrecta, sino porque los cimientos contractuales y jurisdiccionales nunca se diseñaron pensando en la soberanía.

Este artículo trata de cerrar esa brecha sin reconstruir desde cero. Las decisiones de arquitectura son abordables. El panorama de cumplimiento es más matizado de lo que la mayoría de los equipos de BI percibe, y entender bien ese matiz es lo que distingue una plataforma que satisface a los auditores de una que genera nuevas preguntas cada trimestre.

Qué exige realmente el RGPD de una carga de trabajo analítica

El RGPD se describe habitualmente como una ley de residencia de datos. Esa descripción es técnicamente imprecisa y lleva a los equipos a tomar decisiones arquitectónicas equivocadas. El RGPD no prohíbe almacenar datos personales de la UE fuera de la UE; exige que cualquier transferencia a un tercer país cuente con un mecanismo adecuado: una decisión de adecuación, Cláusulas Contractuales Tipo o Normas Corporativas Vinculantes, respaldadas por una evaluación del impacto de la transferencia cuando el entorno legal del destino así lo justifique.

En el ámbito analítico, el artículo 30 es la disposición que más condiciona. Exige registros documentados de las actividades de tratamiento, lo que significa que tu data warehouse necesita un modelo de linaje capaz de responder, en cualquier momento, qué datos entraron en el sistema, de qué fuente, bajo qué base legal y qué transformaciones han sufrido. La mayoría de los despliegues de BI en infraestructura de grandes proveedores tratan el linaje como algo deseable pero no prioritario. Para cualquier organización que procese datos personales de la UE a escala, es un requisito legal.

La seudonimización y la tokenización son las herramientas prácticas aquí. Los tokens reemplazan los campos sensibles en la capa analítica; la tabla de correspondencia permanece en un almacén controlado jurisdiccionalmente. Los analistas trabajan con tokens en agregaciones y dashboards; los identificadores originales nunca salen del perímetro conforme. Esto no es un rodeo: es la arquitectura que la regulación está diseñada para fomentar.

El problema de Schrems II que el alojamiento en región UE no resuelve

El problema más estructural para el diseño de una plataforma de BI soberana no es la residencia bajo el RGPD, sino la US CLOUD Act. La sentencia Schrems II del TJUE en 2020 invalidó el Escudo de Privacidad UE-EE. UU. y puso las Cláusulas Contractuales Tipo en entredicho, con el argumento de que un contrato no puede proteger los datos del aparato de vigilancia de un Estado extranjero. La conclusión central de esa sentencia no ha sido revertida. El Marco de Privacidad de Datos UE-EE. UU. que sustituyó al Escudo de Privacidad en 2023 superó su primer desafío legal en septiembre de 2025, pero sigue recurrido, y se aconseja a las organizaciones que dependan únicamente de él que mantengan mecanismos de respaldo con Cláusulas Contractuales Tipo.

La CLOUD Act alcanza a cualquier proveedor con matriz estadounidense independientemente de dónde se encuentren físicamente los servidores. La residencia de datos en una región de la UE no elimina el riesgo de transferencia; solo cambia la etiqueta del problema.

El cumplimiento de Schrems II exige que los datos sean ininteligibles para las autoridades gubernamentales. El cifrado gestionado por el proveedor no supera esta prueba, porque se puede obligar a un proveedor cloud a descifrar. La arquitectura que elimina la cuestión por completo es una infraestructura operada por una entidad de jurisdicción europea con las claves de cifrado bajo la custodia del propio cliente. En ese caso no existe ningún nexo estadounidense que pueda ser compelido y, en términos jurídicos, no hay transferencia a un tercer país. Esto no es una postura de marketing; es la conclusión lógica de la jurisprudencia.

DORA y la trampa de la responsabilidad en la externalización

Las instituciones financieras que ejecutan cargas de trabajo de BI enfrentan una segunda capa de obligaciones desde enero de 2025, cuando DORA (Reglamento UE 2022/2554) entró en aplicación. DORA trata los contratos cloud como acuerdos de externalización, y las directrices de la EBA sobre externalización son explícitas: la responsabilidad de una institución financiera sobre sus propias actividades no puede externalizarse, independientemente de las certificaciones del proveedor. El certificado ISO 27001 de tu proveedor cloud no le transfiere la responsabilidad.

DORA también exige que las entidades financieras mapeen sus dependencias de TIC con terceros y eviten una concentración excesiva en un único proveedor o en un grupo reducido de ellos. Un stack de BI que funciona íntegramente sobre un único gran proveedor, utilizando su data warehouse propietario, su motor de consultas y su capa de visualización, es exactamente el riesgo de concentración que la regulación pretende limitar. El derecho de auditoría debe estar garantizado contractualmente; las ubicaciones de residencia y tratamiento de datos deben estar documentadas; las relaciones con subcontratistas deben conocerse y divulgarse.

Para el análisis de datos con residencia en la UE en el sector financiero, esto significa que la elección de arquitectura y el contrato con el proveedor son inseparables. Un data warehouse técnicamente sólido sobre una infraestructura que no puede satisfacer los requisitos de auditoría y concentración de DORA no es un despliegue conforme.

Una arquitectura de referencia para BI conforme en la UE

La arquitectura que satisface tanto a analistas como a auditores tiene cinco capas, y la soberanía es una propiedad del stack en su conjunto, no de ningún componente aislado.

  • Perímetro de ingesta y seudonimización: los datos entran a través de un pipeline que aplica tokenización antes de que nada llegue a la capa del data warehouse. El almacén de tokens reside en un almacenamiento con jurisdicción UE garantizada contractualmente. Aquí es donde se generan los registros de linaje del artículo 30 del RGPD.
  • Capa del data warehouse: formatos columnares de estándar abierto (Parquet, ORC) sobre almacenamiento de objetos que controlas tú, consultable mediante un motor que puedes ejecutar en tu propia infraestructura. Evitar el bloqueo en un data warehouse propietario es tanto un requisito de concentración de DORA como una garantía práctica de portabilidad.
  • Capa de cómputo: separada del almacenamiento para poder escalar la capacidad de consulta de forma independiente. Kubernetes gestionado o bare metal según los requisitos de latencia de las consultas. La propiedad clave es que el cómputo se ejecuta en un entorno donde tú custodias las claves de cifrado.
  • Capa semántica y de acceso: control de acceso basado en roles vinculado a un proveedor de identidad corporativo, con seguridad a nivel de columna y de fila aplicada en el motor, no en la aplicación. Cada consulta queda registrada con la identidad que la emitió: este es tu registro de auditoría del artículo 30 en forma operativa.
  • Observabilidad y linaje: herramientas de linaje de datos que rastrean cada transformación desde el origen hasta el dashboard, exportables en un formato que tus auditores puedan leer sin necesitar herramientas del proveedor. OpenLineage es el estándar abierto sobre el que merece la pena construir.

Qué debe decir el contrato de infraestructura

La arquitectura anterior solo ofrece sus propiedades de cumplimiento si la infraestructura subyacente está regida por el contrato adecuado. Aquí es donde los términos operativos y contractuales importan tanto como el diseño técnico.

Este tipo de cargas de trabajo las ejecutamos sobre infraestructura Tier III, carrier-neutral, certificada con ISO 27001, con un SLA contractual de disponibilidad del 99,9 %. La palabra contractual importa: el SLA de un gran proveedor cloud es típicamente un mecanismo de créditos, no un compromiso legal. Cuando un auditor o un regulador solicita evidencias de resiliencia, un SLA contractual respaldado por una entidad de jurisdicción europea es un documento diferente a una tabla de créditos de servicio en las condiciones de uso de una empresa estadounidense. La soberanía aquí no es una opción de configuración; es una cláusula del acuerdo.

NIS2 (Directiva UE 2022/2555, que sustituyó a la Directiva NIS original en octubre de 2024) incorpora los centros de datos y los servicios de computación en la nube como entidades esenciales dentro de la infraestructura digital, con supervisión proactiva, obligaciones de notificación y requisitos de auditoría de la cadena de suministro. Esto significa que la postura de seguridad de tu proveedor cloud forma ahora parte de tu propia evidencia de cumplimiento de NIS2. Un proveedor certificado con ISO 27001 que opera bajo legislación europea y con derechos de auditoría contractuales cierra ese eslabón de la cadena de suministro de forma limpia.

Migración sin reescritura

La objeción más habitual a migrar un stack de BI a infraestructura soberana es el coste de reconstruirlo. En la mayoría de los casos, la reescritura no es necesaria. Si la capa del data warehouse ya usa formatos abiertos, la migración es un ejercicio de movimiento de datos con un cambio de configuración en el motor de consultas. El perímetro de seudonimización puede insertarse como una etapa del pipeline sin tocar los dashboards existentes. El modelo de control de acceso se mapea a cualquier proveedor de identidad compatible con OIDC.

Lo que sí requiere un esfuerzo deliberado es la capa contractual: renegociar o reemplazar los acuerdos con proveedores para incluir los derechos de auditoría, las garantías de residencia y las declaraciones de concentración que DORA y NIS2 exigen ahora. Ese trabajo no es opcional, y es más sencillo hacerlo una sola vez, sobre una infraestructura diseñada para ello, que intentar añadir soberanía contractual a posteriori en un stack construido para escalar sin tenerla en cuenta.

Los analistas quieren consultas rápidas y dashboards estables. Los auditores quieren linaje documentado, claridad jurisdiccional y responsabilidad contractual. Estos requisitos no están en tensión; apuntan a la misma arquitectura. Construye el stack sobre estándares abiertos, pon las claves bajo tu propia custodia y asegúrate de que el contrato de infraestructura diga lo que tu equipo legal necesita que diga.