¿Qué es la residencia de datos?
Privacidad, seguridad e identidad
La residencia de datos es el requisito o la decisión de diseño de que los datos se almacenen, y en ocasiones se procesen, en una ubicación geográfica determinada. Se refiere a dónde residen físicamente los datos y dónde se ejecutan ciertos pasos de computación. No es lo mismo que la soberanía de datos, que trata sobre qué leyes y autoridades legales son aplicables. En la práctica, la residencia de datos se implementa mediante la elección de regiones, la arquitectura, los contratos, los controles del proveedor y una delimitación clara de qué datos se mantienen realmente dentro de la región.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Si alguien pregunta sobre residencia de datos, la pregunta más sencilla en lenguaje claro es: "¿Dónde residen físicamente los datos y dónde se gestionan?". Parece simple, pero en los sistemas modernos de nube e IA la respuesta suele ser más granular de lo que se espera.
Un servicio puede almacenar los archivos de clientes en una región, ejecutar la inferencia del modelo en otra, conservar los registros y los metadatos de facturación en otro lugar, y contar con personal de soporte de varios países. Por eso la residencia de datos rara vez es un único interruptor. Es un conjunto de compromisos de ubicación que se aplican a tipos de datos específicos y a pasos de procesamiento concretos.
Aquí es también donde comienza la confusión. La residencia de datos no es lo mismo que la soberanía de datos. La residencia tiene que ver con la ubicación física. La soberanía tiene que ver con el control legal y la jurisdicción. Los datos pueden residir en un lugar y seguir estando sujetos a obligaciones legales, normas de transferencia o cuestiones de acceso gubernamental vinculadas a otro lugar. Los dos conceptos están relacionados, pero no son intercambiables.
Para quienes toman decisiones, esa distinción importa porque muchas conversaciones sobre "mantener los datos en local" mezclan ubicación de almacenamiento, ubicación de procesamiento, transferencias transfronterizas, controles contractuales y jurisdicción legal. Tomar buenas decisiones exige separarlos.
Por qué importa
La residencia de datos importa porque se sitúa en la intersección del cumplimiento normativo, la contratación, la confianza, la arquitectura y la resiliencia operativa. Algunas organizaciones se enfrentan a requisitos explícitos de almacenamiento o procesamiento local. Otras se enfrentan a expectativas sectoriales, condiciones contractuales con clientes o normas de política interna que en la práctica son casi igual de importantes.
También importa porque los sistemas de IA crean nuevos flujos de datos. Los prompts, los archivos cargados, los embeddings, los datos de fine-tuning, los resultados generados, los registros y los rastros de evaluación pueden plantear preguntas de residencia. Un equipo puede creer que ha resuelto el problema eligiendo una región de la UE o del Reino Unido, y descubrir después que una funcionalidad solo almacena el contenido del cliente dentro de la región, mientras que los metadatos o los registros que no son contenido se enrutan a otro lugar.
Las decisiones de residencia también pueden afectar a la latencia y la resiliencia. Mantener los datos o la inferencia más cerca del usuario puede mejorar el rendimiento. Por otro lado, las restricciones estrictas de residencia pueden reducir las regiones disponibles, las opciones de conmutación por error o las alternativas de proveedor, por lo que generalmente existe una compensación entre control y flexibilidad.
Lo más importante es que la residencia de datos puede ser una cuestión de confianza a nivel directivo. Si un proveedor no puede explicar con claridad dónde se almacenan los datos, dónde se produce la inferencia, qué está dentro del alcance, qué queda fuera y qué sigue cruzando fronteras, la dirección debería considerarlo una brecha grave de diligencia debida.
Cómo funciona
La residencia de datos funciona combinando decisiones de diseño técnico con compromisos del proveedor y cláusulas contractuales.
La primera decisión de diseño es la ubicación en reposo. Este es el significado más habitual de residencia de datos. Se refiere a dónde se almacenan los datos cuando están en una base de datos, un almacén de objetos, un sistema de archivos, una copia de seguridad u otra capa persistente. En las plataformas en la nube, esto suele controlarse seleccionando una región o multirregión al crear el servicio o la carga de trabajo correspondiente.
La segunda decisión de diseño es la ubicación de procesamiento. Es donde los datos se gestionan activamente. En los sistemas de IA, esto incluye la inferencia del modelo, la creación de embeddings, la indexación, la ejecución de código, el procesamiento de imágenes y, en ocasiones, la moderación o la revisión de seguridad. La ubicación de procesamiento puede ser tan importante como la de almacenamiento. Un archivo almacenado en una región pero procesado en otra puede seguir generando problemas de transferencia o de gobernanza.
La tercera decisión de diseño es la delimitación del alcance. Aquí es donde surgen muchos malentendidos. Los proveedores suelen aplicar los controles de residencia únicamente al "contenido del cliente" definido o a funcionalidades específicas del producto. Los registros de cuenta, los datos de facturación, los análisis de uso, los metadatos operativos y algunos registros pueden quedar fuera del alcance. Esto significa que "residencia de datos activada" no implica necesariamente que cada dato vinculado al servicio permanezca dentro de la región.
Un cuarto elemento es la arquitectura en torno a la replicación y la conmutación por error. Muchos sistemas dependen de copias de seguridad, copias de recuperación ante desastres, redundancia multirregión o servicios globales que mejoran la disponibilidad. Si esas copias o las funciones del plano de control mueven datos fuera de la geografía objetivo, la posición de residencia puede ser más débil de lo que sugiere el resumen comercial.
En la práctica, esto significa que se necesita un mapa de flujo de datos, no solo un selector de región. Hay que mapear dónde se recopilan, almacenan, procesan, almacenan en caché, indexan, respaldan, registran y a los que acceden el soporte o los subencargados del tratamiento. Solo entonces se puede determinar si el diseño de residencia se ajusta al requisito.
Esto es especialmente importante en los servicios de IA. A mediados de 2026, los principales proveedores ofrecen combinaciones distintas de residencia de almacenamiento y residencia de inferencia. Algunos permiten el almacenamiento en reposo en muchas regiones, pero ofrecen procesamiento dentro de la región solo para un conjunto más reducido. Algunos separan los controles de almacenamiento de los controles de inferencia. Algunos admiten controles de región solo para determinados modelos o funcionalidades. Algunos siguen enrutando partes de la carga de trabajo de forma global a menos que se opte por configuraciones más estrictas.
Esto significa que quienes toman decisiones deben hacer preguntas más precisas que "¿Admite residencia de datos?". Preguntas más adecuadas son: ¿Qué tipos de datos están dentro del alcance? ¿Qué funcionalidades están cubiertas? ¿Dónde se ejecuta la inferencia en GPU? ¿Qué sigue ocurriendo fuera de la región? ¿Las copias de seguridad son locales? ¿Los embeddings son locales? ¿Los registros con contenido son locales? ¿Los procesos de soporte o los subencargados están fuera de la región?
Ahora, el aspecto legal. La residencia de datos y el cumplimiento de las transferencias internacionales están relacionados, pero no son idénticos. En virtud del GDPR de la UE y del UK GDPR, si los datos personales se ponen a disposición de una organización distinta fuera del EEE o del Reino Unido, pueden aplicarse las normas de transferencia. Por tanto, elegir una región local no elimina automáticamente todos los problemas transfronterizos. Puede ayudar de forma sustancial, pero no equivale a demostrar que no se produce ninguna transferencia restringida.
Por eso la residencia debe entenderse como un control arquitectónico y contractual, no como una etiqueta mágica de cumplimiento. Apoya el cumplimiento normativo, los compromisos con los clientes y los objetivos de contratación, pero no sustituye al análisis legal ni a la diligencia debida con los proveedores.
También conviene distinguir la residencia de datos de la localización de datos. La residencia describe dónde se almacenan o procesan los datos. La localización suele referirse a un requisito legal de mantener los datos en un lugar determinado, a veces con restricciones más estrictas para moverlos a otro lugar. No toda decisión de residencia obedece a una ley de localización. En ocasiones, el factor determinante es la confianza del cliente, las expectativas del sector o la política interna.
Un último punto práctico: el autoalojamiento puede mejorar el control de residencia, pero tampoco resuelve el panorama completo. Si la propia arquitectura sigue utilizando telemetría remota, canales de soporte externos, moderación de terceros o copias de seguridad fuera de la región, puede seguir existiendo exposición de ubicación.
Así pues, la realidad operativa es sencilla pero exigente. La residencia de datos requiere especificidad disciplinada. Es necesario saber qué datos, qué pasos de procesamiento, qué regiones, qué excepciones y qué compromisos contractuales se aplican realmente.
Ejemplos
Un organismo del sector público puede exigir que los documentos de ciudadanos, los prompts y los resúmenes generados permanezcan en una región europea, con evidencia clara de que las funcionalidades cubiertas se almacenan allí y de que la inferencia también se ejecuta allí para la carga de trabajo aprobada. En ese caso, la residencia solo de almacenamiento puede no ser suficiente.
Una aseguradora puede querer que los documentos de siniestros y los campos extraídos de reclamaciones permanezcan en el país o en la región, pero puede permitir que los registros operativos que no son contenido estén fuera de la región si el contrato lo describe con claridad y la revisión legal lo acepta.
Un fabricante puede ejecutar un modelo local en el borde de la planta para el triaje de equipos porque la dependencia de internet o el flujo de datos transfronterizo es inaceptable para el flujo de trabajo. Aquí la residencia de datos está impulsada tanto por la política como por la resiliencia.
Un comprador multinacional de SaaS puede utilizar la residencia como compromiso de confianza con el cliente. Incluso cuando la ley no exige estrictamente el alojamiento local, los clientes pueden insistir en que sus archivos cargados y los artefactos generados por IA permanezcan dentro de una geografía determinada.
Malentendidos frecuentes
Un malentendido habitual es creer que la residencia de datos y la soberanía de datos son lo mismo. No lo son. La residencia tiene que ver con dónde residen y se ejecutan los datos. La soberanía tiene que ver con qué autoridad legal es aplicable.
Otro es pensar que elegir una región significa que todo permanece en esa región. A menudo solo se cubren algunas categorías de datos o funcionalidades. Los registros, los metadatos de cuenta, el enrutamiento y los procesos de soporte pueden tratarse de forma diferente.
Un tercer malentendido es que si los datos están cifrados, la ubicación deja de importar. El cifrado es importante, pero no elimina los requisitos contractuales, regulatorios, de transferencia o de contratación sobre dónde se almacenan o procesan los datos.
Los equipos también asumen que la residencia de datos solo tiene que ver con el almacenamiento. En los sistemas de IA, la ubicación de procesamiento puede ser igual de importante, especialmente para la inferencia y la indexación.
Por último, algunos directivos creen que el autoalojamiento demuestra automáticamente la residencia. Puede mejorar el control, pero solo si la arquitectura más amplia, las copias de seguridad, el acceso de soporte, los subencargados del tratamiento y el registro están diseñados en consecuencia.
Riesgos y límites
El principal riesgo son los requisitos vagos. Si la organización dice "mantener los datos en Europa" sin definir qué datos, qué funcionalidades y qué etapas de procesamiento importan, los equipos pueden construir algo que suene a cumplimiento pero que no se ajuste al requisito real.
Otro riesgo son las brechas de alcance ocultas. Un proveedor puede almacenar el contenido del cliente dentro de la región mientras mantiene los metadatos, la actividad del plano de control o los registros que no son contenido fuera de la región. Eso puede ser aceptable o no. Lo importante es que debe identificarse y evaluarse.
También existe una compensación en materia de resiliencia. Una residencia estricta puede limitar la conmutación por error y la elección de proveedor. Puede merecer la pena, pero debe ser una decisión consciente.
La residencia tampoco sustituye a los controles más amplios de privacidad y seguridad. La minimización, el control de acceso, el cifrado, la retención, la respuesta a incidentes y la gestión de proveedores siguen siendo importantes. Los datos pueden tener una residencia perfecta y seguir estando mal gobernados.
Esta sección es orientación práctica, no asesoramiento legal. Si su caso de uso implica datos personales regulados, contratos gubernamentales, información sanitaria, registros financieros o derechos de procesamiento transfronterizo, consulte con los especialistas legales, de privacidad y de seguridad adecuados.
Próximos pasos
Comience por convertir "residencia de datos" en un requisito preciso. Especifique qué clases de datos importan, si se refiere al almacenamiento en reposo, la inferencia dentro de la región, el procesamiento en el endpoint, las copias de seguridad, los registros o todo lo anterior.
A continuación, mapee el flujo de trabajo de extremo a extremo. Incluya prompts, cargas, resultados, embeddings, índices, copias de seguridad, análisis, moderación, acceso de soporte y subencargados del tratamiento. No se puede gobernar lo que no se ha mapeado.
Después, interpele a los proveedores con preguntas precisas. Pregunte qué está dentro del alcance, qué queda fuera, qué regiones son compatibles con qué funcionalidades y qué procesamiento puede seguir ocurriendo en otro lugar. Solicite la respuesta por escrito.
A continuación, alinee el diseño con los contratos y los controles. La configuración de región por sí sola no es suficiente. Los acuerdos, los procedimientos operativos, la configuración de retención y las evidencias de auditoría deben coincidir con la arquitectura.
Por último, revise la residencia periódicamente. Las capacidades de los proveedores, el alcance de las funcionalidades y la compatibilidad de regiones cambian con el tiempo. Un diseño que cumple el requisito ahora puede quedar desfasado si nuevas funcionalidades eluden los mismos controles.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es la residencia de datos lo mismo que la soberanía de datos?
No. La residencia de datos se refiere a la ubicación física de almacenamiento y procesamiento. La soberanía de datos se refiere a la jurisdicción legal y el control.
¿Exige el GDPR que los datos permanezcan siempre en la UE?
En general, no. El GDPR incluye normas para las transferencias internacionales fuera del EEE, pero no establece una regla universal que obligue a que todos los datos permanezcan en la UE.
¿Cuál es la diferencia entre residencia de datos y localización de datos?
La residencia describe dónde se almacenan o procesan los datos. La localización suele referirse a un requisito legal de mantener los datos en un lugar determinado.
Si un proveedor ofrece residencia de datos, ¿cubre todos los datos?
No necesariamente. Muchos proveedores limitan los compromisos de residencia a contenido específico del cliente o a determinadas funcionalidades, mientras que los datos de cuenta, los registros o los metadatos pueden tratarse por separado.
¿La inferencia dentro de la región significa que todo el procesamiento permanece en la región?
No siempre. Algunos proveedores distinguen la inferencia en GPU de otros tipos de procesamiento, como la autenticación, el enrutamiento o el registro.
¿Cómo puede un directivo evaluar la afirmación de residencia de un proveedor?
Solicite una declaración clara sobre los datos dentro del alcance, las regiones compatibles, las funcionalidades cubiertas, las excepciones de procesamiento fuera de la región, el comportamiento de las copias de seguridad y los compromisos contractuales.
Fuentes
International data transfers (European Data Protection Board). Primary regulatory source for the point that GDPR transfer rules still matter when personal data is made available to another organisation outside the EEA.
International transfers (ICO). Primary regulatory source for the equivalent UK framing that transfer rules apply when personal information goes to other countries.