Residencia de Datos: ¿Dónde está realmente tu información?

Crees que tus datos están en Europa, pero en realidad pueden estar en Virginia, Dublín o Singapur. La residencia de datos no es una cuestión técnica menor: es una decisión estratégica que afecta a tu cumplimiento legal, tu exposición a la Cloud Act y tu capacidad de proteger la información de tus clientes. Te explicamos dónde están realmente tus datos y cómo recuperar el control.

Cuando una empresa contrata un servicio en la nube, el contrato suele incluir una cláusula que dice algo como: «sus datos se almacenarán en la región de su elección» (UE, EEUU, Asia). Pero ¿qué significa realmente «en la región»? ¿Significa que los datos nunca salen de ahí? ¿Qué pasa con las copias de seguridad, los logs o los procesos de IA que acceden a esos datos? La realidad es mucho más compleja y, a menudo, menos soberana de lo que parece. En este artículo analizamos dónde acaban realmente tus datos en la nube y por qué el hardware propio es la única garantía de residencia real.

La promesa vs. la realidad de la residencia de datos en la nube

Los grandes proveedores cloud (AWS, Azure, Google Cloud) ofrecen «regiones» geográficas. Por ejemplo, AWS tiene una región en Frankfurt (Alemania) y otra en Irlanda. Contratas servicios en esa región y el proveedor te asegura que tus datos no saldrán de esa región. Pero hay matices críticos:

• Las copias de seguridad y réplicas: para garantizar durabilidad, los proveedores replican datos entre zonas de disponibilidad. A veces esas zonas están en regiones diferentes. En casos de desastre, tus datos pueden moverse sin previo aviso.
• Los logs y metadatos: los logs de acceso, las trazas de depuración y los metadatos de facturación pueden almacenarse en regiones centrales (normalmente en EEUU). Aunque tus datos principales estén en Europa, los registros de quién accedió y cuándo pueden estar en Virginia.
• El personal del proveedor: aunque los datos estén en Frankfurt, los ingenieros que mantienen los sistemas pueden estar en cualquier parte del mundo y tener acceso remoto a los servidores. El acceso remoto significa que tus datos pueden ser «vistos» desde fuera de la UE.
• Los procesos de IA y análisis: si usas servicios de IA del proveedor (ej. AWS Bedrock, Azure OpenAI), tus prompts y respuestas pueden procesarse en regiones diferentes a donde están almacenados tus datos. El proveedor no siempre garantiza que la inferencia ocurra en la misma región.

El resultado: aunque tú hayas seleccionado la región «UE», no puedes estar 100% seguro de que tus datos (o sus metadatos) no salgan de la UE en algún momento del ciclo de vida. Para cumplir con GDPR o NIS2, esto es un problema grave.

El problema de la Cloud Act (EEUU)

La Cloud Act (Clarifying Lawful Overseas Use of Data Act) es una ley estadounidense de 2018 que permite a las autoridades de EEUU solicitar acceso a datos almacenados por empresas estadounidenses, independientemente de dónde estén físicamente los servidores. Esto significa que si usas AWS, Microsoft Azure, Google Cloud, OpenAI o cualquier proveedor con sede en EEUU, tus datos pueden ser requeridos por el FBI, la NSA o un tribunal estadounidense aunque estén en Frankfurt. El proveedor puede negarse, pero la ley le obliga a cumplir. La única excepción real es que el proveedor no tenga ningún tipo de jurisdicción estadounidense (algo muy raro). Para empresas europeas que manejan datos sensibles (salud, legal, financiero, administración pública), la Cloud Act es un riesgo inasumible.

GDPR y NIS2: lo que realmente exigen

El RGPD (GDPR) exige que los datos personales de ciudadanos europeos no sean transferidos a países sin nivel de protección adecuado (EEUU está en la lista de países cuestionables tras la invalidación del Privacy Shield). Aunque existen cláusulas contractuales tipo (SCCs) y evaluaciones de impacto, la realidad es que cualquier transferencia a un proveedor estadounidense conlleva un riesgo legal. El NIS2 (Directiva de Seguridad de Redes y Sistemas de Información) va aún más allá: exige a las entidades críticas (energía, transporte, banca, salud, administración) conocer exactamente dónde están sus datos y quién puede acceder a ellos. Las auditorías NIS2 pueden exigir trazabilidad completa de los flujos de datos. En la nube, es casi imposible demostrar que los datos nunca salieron de la UE y que ningún empleado del proveedor con sede en EEUU accedió remotamente.

Con hardware propio, la trazabilidad es total: los datos están en tu CPD, los accesos los controlas tú, las auditorías las realizas con tus logs. No hay dependencia de certificaciones de terceros ni cláusulas contractuales complejas. La ciberseguridad y el cumplimiento normativo son responsabilidad directa de la organización, pero con on‑premise tienes las herramientas para demostrarlo.

¿Dónde están realmente los datos en cada modelo?

• Nube pública (proveedor estadounidense): los datos pueden estar en servidores en Europa, pero la empresa matriz está en EEUU. Sujeto a Cloud Act. Los empleados del proveedor (potencialmente en EEUU) pueden acceder remotamente. Los logs y metadatos suelen estar en EEUU. Residencia real: incierta, pero con jurisdicción estadounidense.
• Nube pública (proveedor europeo, ej. OVH, Deutsche Telekom): los datos están en servidores en Europa, la empresa es europea. No sujeto a Cloud Act (aunque si usan subcontratas estadounidenses, el riesgo persiste). Los logs y metadatos pueden estar en Europa. Mejor, pero sigue dependiendo de terceros.
• Hardware propio (on‑premise): los datos están en tu edificio o en un CPD que controlas directamente. No hay proveedor intermediario. Los accesos los autorizas tú. No sujeto a Cloud Act. Los logs son tuyos. Residencia real: total.
• SaaS de IA (ChatGPT, Claude, Gemini): tus prompts y datos enviados a la API salen de tu red y se procesan en servidores del proveedor. Según el plan, pueden usarse para entrenar modelos. Los datos pueden viajar entre regiones. Residencia real: depende del proveedor, pero casi siempre con exposición a EEUU.

Mitos comunes sobre la residencia de datos en la nube

• «Mis datos están en Europa porque elegí la región europea» → Falso. Los metadatos, logs, copias de seguridad y accesos remotos pueden salir de Europa. La región solo garantiza la localización del almacenamiento principal, no de todo el ecosistema.
• «El proveedor tiene certificación GDPR, así que estoy cubierto» → Falso. La certificación ayuda, pero no exime de responsabilidad. Si el proveedor transfiere datos a EEUU sin las garantías adecuadas, el responsable (tu empresa) puede ser multado.
• «El hardware propio es más inseguro que la nube» → Falso. La seguridad depende de cómo lo configures. La nube no es inherentemente más segura; es más fácil de empezar, pero el control total de on‑premise permite medidas de seguridad que en la nube son imposibles (ej. air gap físico, cifrado con claves que nunca salen del edificio).
• «La Cloud Act solo afecta a empresas americanas» → Falso. Afecta a cualquier empresa que use servicios de proveedores estadounidenses. Si usas AWS, Azure, Google, OpenAI, eres susceptible.

Casos reales: cuando la residencia de datos se convirtió en un problema

Caso 1: Empresa de telecomunicaciones europea. Usaba AWS Frankfurt para datos de clientes. En una auditoría interna descubrieron que los logs de acceso se replicaban en Virginia (EEUU) para «análisis de seguridad». Multa potencial de 10 millones de euros por GDPR. Migraron a hardware propio en 3 meses.

Caso 2: Clínica privada española. Usaba un SaaS de IA estadounidense para analizar informes médicos. El proveedor cambió sus términos de servicio permitiéndose usar los datos para entrenar modelos. La clínica no podía garantizar a sus pacientes que sus datos no se usarían para entrenar IA. Migraron a un servidor de IA on‑premise TOWIN-BOX y ahora procesan todo localmente.

Caso 3: Ayuntamiento español. Necesitaba cumplir NIS2. Los auditores exigieron trazabilidad total de los datos. El proveedor cloud no pudo garantizar que los logs no salieran de la UE. El ayuntamiento optó por infraestructura propia.

Alternativas: nubes europeas y hardware propio

Si la nube es imprescindible, existen proveedores europeos (OVH, Deutsche Telekom, Hetzner, Scaleway) que no están sujetos a la Cloud Act. Son una mejora, pero sigues dependiendo de un tercero y no tienes control directo sobre los accesos del personal del proveedor. Para datos realmente sensibles, el hardware propio sigue siendo la única garantía total de residencia. Un servidor on‑premise como TOWIN-BOX o TOWIN-TORRE te da control total sobre dónde están tus datos, quién los accede y cómo se auditan. La inversión inicial es recuperable en meses si comparas con el coste de la nube a escala, y eliminas riesgos legales y reputacionales.

Conclusión: si no controlas el hardware, no controlas los datos

La residencia de datos no es una casilla que marcar en un contrato. Es una realidad técnica y legal que debes verificar constantemente. En la nube, por mucha región que elijas, siempre hay un tercero entre tus datos y tú. Ese tercero puede tener obligaciones legales (Cloud Act), puede cambiar sus términos de servicio, puede sufrir una brecha de seguridad o puede simplemente no ser tan transparente como promete. La única manera de saber dónde están realmente tus datos es tenerlos en tu propio hardware, dentro de tu perímetro de seguridad, bajo tu control exclusivo. La gestión empresarial con IA soberana empieza por saber dónde están tus datos. Si no lo sabes con certeza, no eres soberano.