El centro de datos no es un argumento legal

El centro de datos no es un argumento legal

La dirección del folleto

Hay una frase que aparece en las licitaciones de servicios en la nube con la seguridad de un argumento concluido: los datos se almacenarán en un centro de datos europeo. La frase puede ser cierta. También puede estar haciendo mucho más trabajo del que puede soportar.

Un centro de datos tiene una ubicación. Esa ubicación importa para la seguridad física, la resiliencia, la energía, la conectividad, las normas nacionales y el alcance práctico de una autoridad local. Le dice al comprador algo útil sobre dónde se encuentra parte del equipamiento. No le dice, por sí sola, quién es el propietario del servicio, quién opera el equipamiento, dónde se hacen las copias, quién tiene las claves, qué personas pueden administrarlo, qué empresas pueden subcontratar partes del trabajo o qué sistema jurídico puede obligar a una parte a facilitar el acceso.

La distinción es fácil de enunciar y sorprendentemente fácil de perder. Un código postal es visible. El control está distribuido. El código postal encaja perfectamente en una hoja de cálculo de contratación; el control llega como una cadena de contratos, identidades, cuentas de soporte, planos de gestión, claves de cifrado, relaciones corporativas, procedimientos operativos y obligaciones legales. Lo primero es un dato sobre el lugar. Lo segundo es una cuestión de poder.

La legislación europea de protección de datos ha venido insistiendo en este punto con un lenguaje cada vez más preciso. En la sentencia Schrems II, de 16 de julio de 2020, el Tribunal de Justicia de la Unión Europea examinó cómo podían salir los datos personales del Espacio Económico Europeo manteniendo un nivel de protección esencialmente equivalente al garantizado dentro de él. El Tribunal confirmó las cláusulas contractuales tipo como posible instrumento de transferencia, pero dejó claro que no operan en el vacío. El exportador debe examinar la legislación y la práctica del destino en las circunstancias de la transferencia, y actuar cuando las salvaguardas no puedan funcionar en la práctica.

La sentencia no dijo que una frontera sea irrelevante. Dijo que una frontera es una parte de la cuestión. Las recomendaciones posteriores del Comité Europeo de Protección de Datos convierten ese principio en un método: conocer las transferencias, identificar el instrumento jurídico, evaluar la legislación y la práctica que pueden afectarlo, añadir medidas allí donde puedan funcionar, completar el procedimiento exigido y mantener la evaluación bajo revisión. Una dirección de servidor aparece en ese mapa. No es el mapa.

Esto importa más allá de los datos personales. La Ley de Datos trata los servicios de computación en la nube y otros servicios de procesamiento de datos como infraestructura de la que los clientes deberían poder cambiar de proveedor. También aborda las condiciones en las que una autoridad pública de un tercer país solicita acceso a datos no personales conservados en la Unión. De nuevo, la respuesta jurídica se construye con actores, finalidades, salvaguardas, pruebas y recursos. Hay un edificio de por medio. Un edificio no basta.

La lección práctica para una institución europea es, por tanto, contundente. Pregunte dónde están los datos. Luego siga preguntando hasta que la respuesta incluya quién puede leerlos, quién puede modificarlos, quién puede detenerlos, quién puede exportarlos, quién puede verse obligado a revelarlos y qué pruebas quedarán cuando las partes discrepen. Si la respuesta termina en la puerta del centro de datos, la parte útil de la investigación apenas ha comenzado.

La residencia tiene que ver con el lugar

La residencia de datos es una declaración sobre dónde se almacenan o procesan los datos en virtud de un acuerdo definido. La definición necesita un alcance. ¿Es la copia principal, la copia de seguridad, el índice, la caché, la telemetría, el sitio de recuperación ante desastres o todos ellos? ¿El procesamiento incluye que un administrador vea un registro desde otro país? ¿Cuenta una sesión de soporte? ¿Qué ocurre cuando un equipo de incidentes necesita copiar un rastro de diagnóstico? Una promesa de residencia que no dice qué cubre es una etiqueta atractiva pegada a una frase inacabada.

Los sistemas en la nube están diseñados para mover trabajo. La replicación puede mejorar la disponibilidad. Un segundo emplazamiento puede mantener un servicio activo cuando el primero no está disponible. Una ubicación perimetral puede reducir la latencia. Un equipo de seguridad puede enrutar un registro hacia un sistema central de análisis. Son decisiones de ingeniería ordinarias, no pruebas de irregularidades. Sí implican que la expresión «almacenado en Europa» necesita un objeto técnico asociado. ¿Qué datos, en qué estado, durante qué periodo y bajo qué operación?

La evaluación de riesgos de la nube de ENISA, publicada por primera vez en 2009, sigue siendo útil precisamente porque se negó a tratar la geografía como un control completo. Identifica riesgos derivados del almacenamiento en múltiples jurisdicciones, la información insuficiente sobre ellas, la pérdida de gobernanza, la subcontratación y los cambios en el control del proveedor. El documento tiene la edad suficiente como para sentir debilidad por siglas que los equipos modernos quizá no compartan, pero el problema organizativo no ha desaparecido. Si un cliente no puede ver dónde se procesan los datos ni quién es responsable del siguiente traspaso, no puede tomar una decisión de riesgo fiable.

La residencia puede ser un requisito válido. Un archivo público puede necesitar que los registros permanezcan dentro de un área legal definida. Un servicio de salud puede necesitar un acuerdo de tratamiento que limite dónde pueden viajar los datos sensibles. Un consorcio de investigación puede tener obligaciones vinculadas a un financiador o a un acuerdo de intercambio de datos. Esos requisitos deberían redactarse como condiciones operativas, con un método para verificarlas, y no como un único nombre de país que se invita a todos a interpretar con generosidad.

También hay una diferencia entre una restricción y una garantía. Exigir a un proveedor que mantenga un almacén principal en la Unión Europea restringe una clase de movimiento. No garantiza que ninguna persona fuera de la Unión pueda acceder a un registro, que no salga ningún metadato ni que ninguna obligación legal extranjera pueda alcanzar al proveedor. Una restricción puede ser útil sin ser una garantía. Confundir ambas cosas crea una historia de cumplimiento que supera una visita a la sala de servidores y fracasa ante un examen más detenido del plano de gestión.

La pregunta útil sobre la residencia no es simplemente «¿dónde está?». Es «¿qué ubicaciones son posibles para cada estado de estos datos y quién puede provocar ese cambio de estado?». Un proveedor debería poder explicar la respuesta en términos que un ingeniero pueda implementar y un comprador pueda verificar. Si la explicación depende de una excepción no documentada, de un hábito de soporte o de la promesa de que los subcontratistas del propio proveedor probablemente se comportarán bien, la afirmación de residencia aún no es operativa.

Cinco preguntas escondidas dentro de la palabra dónde

Cuando las personas preguntan dónde están sus datos, a menudo se refieren a varias cosas distintas a la vez. Separar las preguntas hace que una conversación de contratación sea menos teatral y más útil.

1. ¿Dónde están los bits? Esta es la pregunta sobre el almacenamiento físico y lógico. Incluye los datos primarios, las réplicas, las copias de seguridad, las cachés, los índices y los registros relevantes. Una respuesta satisfactoria nombra el alcance y las condiciones bajo las cuales la respuesta cambia.

2. ¿Dónde ocurre el procesamiento? Un registro puede almacenarse en una jurisdicción y transformarse, buscarse, clasificarse, cifrarse o descifrarse en otro lugar. El procesamiento puede ser un trabajo programado, una acción de soporte, un canal de supervisión o una copia temporal creada durante la recuperación.

3. ¿Quién puede acceder a él? Esta es la pregunta sobre identidad y operación. Incluye al personal, los administradores, los contratistas, las cuentas de servicio, los equipos de respuesta a incidentes y los sistemas automatizados. Una persona no necesita vivir junto a un servidor para tener acceso efectivo a él.

4. ¿Quién puede exigir ese acceso? Esta es la pregunta sobre jurisdicción y autoridad legal. Sigue a las organizaciones y personas relevantes, los roles que ocupan, los contratos que firman y las obligaciones legales que pueden vincularlos. No se responde solo con un marcador en el mapa.

5. ¿Qué puede hacer el cliente cuando la respuesta cambia? Esta es la pregunta sobre control y salida. ¿Puede el cliente restringir el acceso, rotar las claves, obtener un registro confiable, restaurar el servicio, mover los datos y terminar la relación sin perder aquello que intentaba proteger?

Estas preguntas se superponen, pero no son intercambiables. Un proveedor puede responder la primera de manera convincente y la tercera de forma deficiente. Un contrato puede responder la quinta sobre el papel mientras el equipo técnico nunca ha ejecutado la salida. Una filial local puede responder la pregunta sobre identidad corporativa mientras el servicio depende de la infraestructura o la organización de soporte de la empresa matriz. La respuesta correcta no es elegir la opción más reconfortante. Es mantener el conjunto intacto.

Esta es también la razón por la que las evaluaciones de soberanía pueden volverse confusas. Se pide que la palabra cubra la residencia física, la independencia legal, la competencia operativa, la propiedad económica, la autonomía estratégica y la capacidad de salir. Esas son ambiciones relacionadas. No son una sola propiedad. Una institución precisa dice qué propiedad necesita y qué evidencia demostraría que existe.

La jurisdicción sigue a la autoridad

La jurisdicción no es una nube mística que rodea a un país. Es una forma de describir qué autoridades legales pueden regular, ordenar, investigar, revisar o remediar la conducta de los actores relevantes. En un servicio distribuido, los actores importan tanto como los lugares. Una empresa puede estar constituida en un Estado miembro, operar instalaciones en un segundo, utilizar un equipo de soporte en un tercero y depender de una matriz o subcontratista sujeto a obligaciones en otro lugar. Un cliente que intenta comprender el alcance legal debe seguir la cadena de autoridad, no detenerse en el edificio más cercano.

Esto no significa que toda conexión extranjera derrote el control europeo. Los servicios europeos están interconectados por diseño. El comercio transfronterizo, la investigación, el soporte, la financiación y la infraestructura son normales. La cuestión es si la institución sabe qué conexión conlleva qué poder. Un operador europeo puede rechazar una solicitud ordinaria pero carecer de autoridad para resistir una instrucción vinculante de otra organización. Un subcontratista puede tener una credencial que el contratista principal no ha incluido en su propio inventario de accesos. Un proceso de soporte puede permitir el acceso remoto incluso cuando el contrato de almacenamiento promete una región local.

El análisis jurídico también depende del tipo de datos y del tipo de solicitud. Los datos personales ponen sobre la mesa las normas de transferencia del RGPD y el marco de los derechos fundamentales. Los datos no personales no viven en un vacío legal. La Ley de Datos contiene salvaguardas para determinadas solicitudes de autoridades públicas de terceros países relativas a datos no personales custodiados en la Unión. Toda solicitud debe examinarse a la luz de las condiciones del reglamento, incluida la naturaleza de la solicitud y las protecciones disponibles en el ordenamiento jurídico del tercer país. Los dos regímenes son distintos, y esa diferencia es precisamente la razón por la que un comprador no debería comprimirlos en la palabra residencia.

La sentencia del TJUE en el asunto C-311/18 ofrece un patrón jurídico europeo útil. El Tribunal no se preguntó si un contrato tenía el aspecto formal suficiente. Se preguntó si la protección garantizada por el Derecho europeo seguiría siendo esencialmente equivalente en las circunstancias de la transferencia, teniendo en cuenta el Derecho y la práctica que pudieran afectar a los datos. Las cláusulas contractuales tipo pueden vincular a las partes que las firman. No vinculan a una autoridad pública que no sea parte del contrato. Cuando el entorno jurídico socava las salvaguardas prometidas, el exportador tiene que reaccionar.

Esa lógica va más allá de la controversia concreta. Un contrato es un instrumento de asignación privada. La jurisdicción es el campo en el que puede actuar la autoridad pública. El contrato puede decirle a un proveedor lo que ha prometido al cliente. No puede, por sí solo, eliminar un poder público que vincula al proveedor o a su personal. Una buena gobernanza se toma en serio ambas afirmaciones. Utiliza los contratos para fijar obligaciones y las medidas técnicas para hacer observables esas obligaciones, reconociendo al mismo tiempo que el alcance jurídico puede seguir alterando las opciones disponibles.

Resulta tentador convertir esto en una caza de un único país peligroso. Eso es menos útil que trazar un mapa de las autoridades reales. ¿Qué entidad es el responsable o el encargado del tratamiento? ¿Qué entidad emplea al administrador? ¿Qué entidad custodia las claves de cifrado? ¿Qué entidad puede hacer una réplica? ¿Qué entidad recibe una solicitud de soporte? ¿Qué autoridad podría dictar una orden? ¿Qué recurso tendría el cliente y ante qué foro? El mapa puede resultar tranquilizador. Puede que no. Cualquiera de los dos resultados vale más que una pegatina con un país.

La propiedad es un título, no una llave

La propiedad tiene una fuerza jurídica y económica real. Puede determinar quién puede vender un activo, nombrar administradores, licenciar propiedad intelectual, recibir ingresos o tomar determinadas decisiones. En un organismo público puede estar ligada a la responsabilidad legal sobre los registros o la infraestructura. En un grupo empresarial puede explicar quién puede votar, fusionarse, financiar o sustituir a un proveedor. La propiedad tiene cabida en una evaluación de soberanía.

La propiedad no proporciona automáticamente control operativo. Un cliente puede ser dueño de los datos mientras un proveedor opera la base de datos, gestiona el sistema de copias de seguridad y controla la cuenta del servicio. Una institución pública puede ser dueña de un edificio mientras un contratista custodia las credenciales de mantenimiento y la única vía probada para restaurar el equipo. Una empresa puede ser dueña del código fuente mientras un tercero controla la clave de firma, el ejecutor de compilación, el registro de paquetes y la identidad de despliegue. El título es real. También lo es la dependencia.

La distinción se hace visible en los verbos. La propiedad es un sustantivo en un contrato. El control es la capacidad de inspeccionar, operar, modificar, detener, recuperar, exportar, eliminar y demostrar. Un proceso de contratación que solo registra sustantivos puede dejar los verbos importantes sin asignar. Puede tener un propietario designado para la plataforma y, aun así, no tener ninguna persona designada que pueda rotar una clave, retirar una cuenta privilegiada o restaurar desde una copia de seguridad sin pedírselo a una organización que no está en la sala.

No hay virtud en exigir la posesión máxima. Un hospital, una universidad o un ayuntamiento puede carecer del personal y de la capacidad de seguridad necesarios para gestionar cada capa de forma segura. Delegar una tarea puede ser responsable cuando los límites son explícitos y el cliente conserva la capacidad de supervisar, probar y recuperar. La cuestión no es colocar cada servidor en un sótano público. La cuestión es decidir qué poderes son esenciales para la misión y mantener esos poderes lo bastante cerca como para gobernarlos.

Esa decisión necesita evidencia. «El cliente es el propietario de los datos» debería llevar a preguntas sobre el formato de exportación, la custodia de claves, la retención, el borrado, los registros de acceso y los permisos de soporte. «El proveedor es europeo» debería llevar a preguntas sobre el control corporativo, los subcontratistas, la infraestructura, la exposición legal y la continuidad. «Los datos están en la Unión» debería llevar a preguntas sobre la administración remota, las réplicas, las ubicaciones de procesamiento y las solicitudes legales. Una buena respuesta puede ser complicada. La complicación no es un defecto cuando el sistema es complicado.

El control operativo es el derecho a actuar

El control operativo se entiende mejor a través de una acción que de un adjetivo. Consideremos un cliente que necesita revocar a un administrador. ¿Quién puede realizar la revocación? ¿Qué sistema de identidad la autoriza? ¿Se exige al proveedor que ejecute el cambio, o puede hacerlo el cliente directamente? ¿La acción cubre las cuentas de soporte, las cuentas de emergencia y las credenciales inactivas? ¿Un registro demuestra cuándo desapareció el permiso? Si una acción depende de un servicio de asistencia, ese servicio forma parte del plano de control.

La misma prueba se aplica a las claves. El cifrado puede reducir la exposición, pero su gobernanza depende de quién crea, almacena, rota, recupera y puede usar las claves. Un registro almacenado localmente puede permanecer ilegible para una parte que no pueda obtener la clave. También puede volverse inaccesible para el cliente cuando la única vía de recuperación reside en un proveedor. La custodia de claves no es, por tanto, ni un eslogan de soberanía ni un borrador mágico de jurisdicción. Es un control concreto que debe asignarse y ensayarse.

Los registros merecen el mismo tratamiento. Un panel puede mostrar actividad. La evidencia requiere un registro que el cliente pueda conservar, interpretar y cuestionar. ¿Quién escribe el registro? ¿Puede un administrador alterarlo? ¿Es fiable la fuente de tiempo? ¿Cubre el acceso de soporte y el procesamiento automatizado? ¿Puede el cliente obtener una exportación utilizable sin el permiso del proveedor? ¿Qué ocurre cuando se cierra la cuenta? Un registro que desaparece con el servicio es útil para las operaciones y débil para la rendición de cuentas.

La recuperación es la prueba más difícil del control operativo porque hace visible cada dependencia. Un proveedor puede prometer copias de seguridad, pero la restauración puede requerir una región concreta, una licencia no disponible, un ingeniero que ya no trabaja allí o un secreto almacenado en un sistema separado. El cliente puede ser propietario del archivo de copia de seguridad y aun así carecer de la capacidad de convertirlo en un servicio operativo. La recuperación debe probarse como una acción completa, con el resultado registrado y las carencias asignadas a personas que puedan cerrarlas.

Detener un servicio también es control. Una institución puede necesitar pausar una integración, aislar un conjunto de datos, suspender el procesamiento automatizado o impedir que se cree una nueva réplica. Si solo un proveedor puede realizar la detención, la identidad, las obligaciones legales, el tiempo de respuesta y el proceso de soporte del proveedor pasan a formar parte del riesgo de la institución. Puede ser un acuerdo aceptable. No es uno invisible.

El objetivo de estas pruebas no es desconfiar de todos los proveedores. Es sustituir la confianza por una relación que pueda inspeccionarse. Un proveedor con una respuesta clara puede explicar qué acciones realiza él, cuáles realiza el cliente y cuáles requieren cooperación. Un proveedor que se apoya en una única frase tranquilizadora aún no ha respondido a la cuestión operativa.

Los subcontratistas convierten una respuesta en una cadena

Un servicio rara vez consiste en una sola organización que hace una sola cosa en un solo lugar. Los proveedores de nube utilizan infraestructura especializada, socios de soporte, servicios de monitorización, operaciones de seguridad, mantenimiento de hardware, operadores de red y otros suministradores. Algunos son visibles en el contrato. Otros aparecen en una lista de subencargados, una descripción del servicio, un aviso de incidente o un flujo de soporte. La cadena es algo habitual. También lo es la obligación de comprenderla.

La evaluación de riesgos de la ENISA señala un fallo conocido: un proveedor de nube puede subcontratar servicios a un tercero que no ofrece las mismas garantías, mientras que un cambio de control puede alterar las condiciones del proveedor. El informe no es una especificación de arquitectura moderna, ni necesita serlo. Su advertencia perdurable es de carácter organizativo. Un cliente no puede afirmar que comprende un servicio si solo ha evaluado a la primera empresa que figura en la factura.

Las recomendaciones del CEPD son más específicas para los datos personales. El primer paso es conocer las transferencias, incluidas las transferencias posteriores a encargados y subencargados. El acceso remoto desde un tercer país puede considerarse en sí mismo una transferencia, incluso cuando el registro permanece en un centro de datos del EEE. Un acuerdo de soporte forma parte, por tanto, del mapa de transferencias de datos, y no una nota a pie de página que pueda resolverse después del despliegue.

La visibilidad de los subcontratistas no es lo mismo que el control sobre ellos. Una lista indica al cliente quién participa. El control pregunta qué puede hacer cada parte, qué datos puede ver, qué instrumento jurídico ampara la actividad, cómo se notifica un cambio y qué remedio existe cuando la parte deja de cumplir las condiciones. La cadena debe tener límites y evidencia en cada traspaso.

Hay una razón práctica para resistirse a las cadenas vagas. Cuando ocurre un incidente, la responsabilidad suele viajar en dirección contraria a los datos. El cliente pregunta al proveedor. El proveedor pregunta al equipo de plataforma. El equipo de plataforma pregunta al suministrador especializado. El suministrador especializado pregunta a un administrador de otra organización. Cada traspaso puede añadir demora, incertidumbre y una oportunidad para que el registro original pierda contexto. Un mapa de control debería mostrar la ruta antes del incidente, mientras las personas implicadas aún tienen tiempo de ser precisas.

Datos personales: la protección viaja con el registro

El RGPD no hace que los datos personales sean seguros simplemente colocándolos tras una puerta europea. Sus normas sobre transferencias están diseñadas para preservar un alto nivel de protección cuando los datos se trasladan a un tercer país. El CEPD lo describe con claridad: un nivel de protección esencialmente equivalente debe acompañar a los datos allí donde vayan, durante y después de la transferencia.

Eso no significa que toda transferencia esté prohibida. El RGPD contempla diferentes herramientas y condiciones para las transferencias, incluidas las decisiones de adecuación y las garantías del artículo 46. La cuestión jurídica es si la herramienta elegida funciona en las circunstancias concretas. Las recomendaciones del CEPD indican a los responsables que evalúen el Derecho y la práctica aplicables a la transferencia concreta, que consideren si el destinatario o los datos pueden verse afectados por normas problemáticas y que documenten su razonamiento. Si ninguna medida complementaria puede restablecer el nivel de protección exigido, la transferencia debe evitarse, suspenderse o finalizarse.

Hay tres detalles que se pasan por alto con facilidad en una conversación sobre residencia de datos. En primer lugar, la transferencia posterior importa. Un proveedor puede conservar el registro principal en el EEE y enviar una copia a un servicio de asistencia o de análisis situado en otro lugar. En segundo lugar, el acceso importa. Un administrador en un tercer país puede leer un registro sin que este se haya trasladado físicamente al escritorio de esa persona. En tercer lugar, la responsabilidad importa. El responsable debe poder demostrar la evaluación y revisarla cuando cambien el servicio, la ley, las personas o las circunstancias.

Por tanto, el marco exige que el cliente comprenda tanto la vía técnica como el contexto jurídico. Un diagrama de regiones y flechas resulta útil, pero no puede sustituir a la evaluación de la transferencia. Tampoco puede sustituirla una promesa contractual de que el proveedor cumplirá, si el cliente no ha comprobado qué pueden lograr las garantías pertinentes frente a las leyes y prácticas que puedan aplicarse al proveedor.

El Derecho europeo de protección de datos siente una sana aversión por las palabras mágicas. «Alojamiento en la UE» puede describir un dato útil. «Conforme» puede describir una conclusión que exige razones. «Soberano» puede describir un objetivo político. Ninguna de ellas debe sustituir a la evidencia de que los datos están protegidos, el acceso está regulado y la decisión puede defenderse.

Datos no personales: un régimen distinto, la misma disciplina

La Ley de Datos regula un conjunto más amplio de relaciones con los datos e incluye normas para los servicios de procesamiento de datos, como los servicios en la nube y en el borde. No sustituye al RGPD ni convierte cada decisión sobre la nube en una evaluación de transferencia de protección de datos. Sí supone un segundo recordatorio europeo de que la ubicación, el acceso, el cambio de proveedor y la autoridad deben considerarse conjuntamente.

Para los datos no personales conservados en la Unión, la explicación de la Comisión sobre la Ley de Datos describe salvaguardas para determinadas solicitudes o decisiones de una autoridad pública de un tercer país. Cuando ningún acuerdo internacional aplicable regule el acceso, el Reglamento establece condiciones destinadas a proteger los intereses europeos, incluida la atención al sistema jurídico del tercer país y a la proporcionalidad de la solicitud. Se espera que los proveedores adopten medidas razonables, como cifrado, auditorías o acuerdos de certificación, para impedir el acceso no autorizado e informar a los clientes siempre que sea posible.

La redacción importa. La Ley de Datos no afirma que la Unión pueda hacer desaparecer los sistemas jurídicos extranjeros. Crea un marco para evaluar y limitar determinadas vías de acceso. El proveedor debe seguir conociendo qué sistemas opera, qué datos conserva, quién puede responder a una solicitud y qué pruebas puede ofrecer al cliente. El cliente debe seguir comprendiendo qué partes de los datos son personales, cuáles no lo son y qué otros regímenes jurídicos resultan aplicables.

La Ley también aborda el control a través de la conmutación. Los clientes deben poder cambiar entre servicios de procesamiento de datos, utilizar servicios en paralelo y portar datos exportables y activos digitales. Los proveedores deben ofrecer información sobre los formatos de exportación, las interfaces, las limitaciones conocidas y el tiempo necesario para el proceso. Las normas sobre equivalencia funcional reconocen una verdad práctica: un archivo que se puede descargar no es necesariamente un servicio que se pueda recuperar.

La conmutación se describe a menudo como una medida de competencia, y lo es. También es una medida de soberanía en el sentido operativo. Una institución que puede marcharse tiene más margen para rechazar un cambio que no puede aceptar. Una institución que no puede marcharse puede ser dueña de un contrato y, aun así, verse gobernada por las opciones predeterminadas del proveedor. Un derecho legal a la conmutación es un comienzo importante. Una migración ensayada que preserve los datos, la configuración y las pruebas es la parte que hace utilizable ese derecho.

Contratos, claves y los límites de las garantías

Los contratos siguen siendo esenciales. Asignan obligaciones, establecen reglas de notificación, identifican a los subencargados, definen el procesamiento permitido, describen la supresión y la retención, crean derechos de auditoría y fijan la asistencia durante una transición. Las disposiciones sobre conmutación en la nube de la Ley de Datos refuerzan la necesidad de condiciones contractuales claras, datos exportables e información sobre los mecanismos de una salida. La guía más antigua de la ENISA también recomienda prestar atención a las transferencias de datos, los cambios de control, el acceso de las autoridades policiales, las notificaciones de violaciones y la responsabilidad al evaluar contratos de nube.

Un contrato no es un control en tiempo de ejecución. Una cláusula que diga que el cliente puede exportar es más débil que una exportación ejecutada sobre un conjunto de datos representativo y restaurada en un segundo entorno. Una cláusula que diga que el proveedor suprimirá es más débil que un proceso de supresión auditable que cubra réplicas, cachés, copias de seguridad y registros derivados. Una cláusula que otorgue un derecho de auditoría es más débil que registros y pruebas que el cliente pueda obtener realmente. El papel importa. Un papel que nunca se encuentra con un sistema operativo es optimismo cortésmente enmarcado.

Las claves ofrecen una lección similar. El cifrado controlado por el cliente puede reducir lo que un proveedor o una parte no autorizada puede leer. No responde a quién puede obligar a una persona que posee una clave de recuperación, quién controla el módulo de seguridad de hardware, quién puede cambiar la política de claves o qué ocurre cuando el cliente pierde su propia credencial. El diseño correcto puede usar autoridad dividida, custodia independiente, acceso cuidadosamente limitado y recuperación probada. El diseño incorrecto puede situar la clave decisiva en una jurisdicción distinta y llamar local al acuerdo porque la base de datos es local.

Las medidas legales y técnicas deben diseñarse conjuntamente. Si un contrato exige que el cliente apruebe el acceso de soporte, el servicio debe tener un flujo de aprobación que deje constancia. Si el cliente necesita impedir transferencias posteriores, el proveedor debe exponer la ruta y hacer cumplir el límite. Si debe evaluarse una solicitud de una autoridad pública, el proceso de incidentes debe conservar la solicitud, el análisis legal, la decisión, la notificación y la respuesta. Una promesa legal se vuelve creíble cuando un sistema puede mostrar cómo se lleva a cabo.

El mismo principio se aplica a los cambios de propiedad. Una adquisición del proveedor, una nueva empresa matriz, un cambio de subcontratista o un cambio en la región operativa del servicio pueden alterar el mapa de control sin cambiar la marca visible para el cliente. Los contratos deben exigir notificación y recursos. Los inventarios técnicos deben actualizarse. Un registro de cambios debe mostrar qué poderes se trasladaron. Una gobernanza que solo existe en la firma inicial tiene una vida media corta.

El mapa de control del comprador

Un comprador público o privado no necesita un cuestionario mágico. Necesita un mapa que conecte las afirmaciones con las pruebas. Las siguientes preguntas son un punto de partida útil porque piden acciones, actores y registros en lugar de un adjetivo preferido.

La tabla es deliberadamente prosaica. Está pensada para resistir el contacto con un equipo de contratación. También ofrece al comprador una forma de comparar proveedores sin dar a entender que un certificado, una bandera nacional o una visita al centro de datos lo resuelven todo. Las pruebas pueden ser confidenciales. El requisito de contar con pruebas no debería serlo.

Solicite una demostración de la acción crítica, no solo una descripción. Muestre cómo se elimina una cuenta privilegiada. Muestre cómo se aprueba una sesión de soporte. Muestre qué recibe un cliente cuando solicita una exportación. Muestre cómo se localiza una réplica. Muestre qué efecto tiene una solicitud legal en el flujo de trabajo de incidentes. Muestre cómo continúa la organización cuando se suspende la cuenta del proveedor. La cuestión no es montar un fallo dramático. Es comprobar si el control existe fuera de la presentación.

Después pregunte quién asume el resultado. Una prueba sin responsable es un espectáculo. Una carencia sin fecha es una característica permanente. Un control sin registro es una creencia. El mapa debe, por tanto, nombrar a la persona u órgano que acepta el riesgo, al proveedor que debe ejecutar la acción y a la vía para impugnar el resultado. La gobernanza no es una pila de preguntas. Es un conjunto de decisiones con un destino al que dirigirse.

Un experimento mental sobre un archivo europeo

Lo siguiente es una hipótesis etiquetada como tal, no un informe sobre un cliente o incidente real. Imagine un archivo municipal que selecciona un servicio alojado para expedientes urbanísticos digitalizados. El pliego exige almacenamiento principal en la Unión Europea y solicita cifrado, copias de seguridad y un servicio de asistencia. Tres proveedores cumplen lo escrito. Uno está constituido localmente, pero depende de un subcontratista de soporte fuera de la Unión. Otro mantiene el almacenamiento y el soporte en la Unión, pero utiliza la plataforma de identidad de la empresa matriz. Un tercero tiene una operación local más reducida, una custodia de claves clara y una exportación probada, pero necesita un nivel de servicio cuidadosamente delimitado porque no puede ofrecer todas las funciones opcionales.

El primer proveedor puede seguir siendo aceptable. El segundo también. El tercero puede no ser adecuado para un requisito concreto de disponibilidad. La cuestión del experimento mental es que la residencia por sí sola no permite elegir entre ellos. El archivo debe preguntar qué acceso de soporte es posible, quién puede hacer una copia, qué entidades legales pueden recibir una orden, cómo se gobiernan las claves, qué muestran los registros y si los expedientes pueden recuperarse en otro lugar.

Supongamos que el archivo decide que el almacenamiento local es su condición más importante. Puede incluir ese requisito en el contrato. También debería definir los objetos cubiertos por la condición, exigir notificación de cualquier cambio y preguntar cómo se detectaría un incumplimiento. Supongamos que decide que el soporte remoto solo se permite para una incidencia documentada. El servicio necesita una vía de aprobación, credenciales con límite de tiempo y un registro que pueda revisarse. Supongamos que decide que el archivo debe poder marcharse. La salida debería probarse antes de que el servicio se convierta en el único lugar donde alguien sepa leer los registros.

Nada en este supuesto exige que el archivo opere un centro de datos. Exige que el archivo comprenda los poderes que delega. Esa es la diferencia entre una externalización responsable y una compra que traslada el riesgo a una sala en la que el comprador no puede entrar.

Qué puede significar realmente «soberano» en Europa

La soberanía europea en la infraestructura digital debería describirse en términos que resistan una pregunta incómoda. Puede significar que una institución europea conserva la autoridad sobre las decisiones críticas. Puede significar que las dependencias clave son visibles, están limitadas y son recuperables. Puede significar que los derechos legales se corresponden con la capacidad técnica. Puede significar que un comprador público puede cambiar de proveedor, impugnar, inspeccionar y seguir operando cuando un proveedor o una ley modifica la vía disponible.

No debería significar que un servicio sea automáticamente seguro porque su dirección de marketing es europea. Tampoco debería significar que toda conexión extranjera esté prohibida. Europa depende de sistemas transfronterizos, y una norma que finja lo contrario se ignorará o se eludirá en silencio. La postura madura es más exigente: permitir las dependencias que sirven a la misión, documentarlas, reducir las que concentran un poder inaceptable y mantener una salida para las que no puedan hacerse fiables.

Esa postura también ofrece a los proveedores europeos una prueba más justa. Un proveedor local no debería tener que hacer una ceremonia de bandera para que se le tome en serio. Debería poder mostrar qué opera, qué delega, quién puede acceder, qué ley puede aplicarse, cómo se protegen los datos y cómo puede marcharse un cliente. Un proveedor global debería enfrentarse a las mismas preguntas. El estándar es la evidencia de control, no el teatro del origen.

La palabra «soberanía» resulta útil cuando cambia el comportamiento de compra. Un ministerio puede usar la contratación pública para premiar una vía de salida probada. Un hospital puede exigir acuerdos clave acordes con sus obligaciones clínicas. Una universidad puede hacer visible la procedencia de los datos de investigación. Un regulador puede pedir el estado de un sistema en el momento de una decisión. Un proveedor puede diseñar su servicio para que la autoridad del cliente no sea un párrafo decorativo. Son acciones institucionales, no un concurso de eslóganes.

Una breve nota nuestra

En Dweve, nuestro análisis público The Sovereignty Illusion: where control really sits, publicado el 29 de junio de 2026, sigue una disciplina similar. Separa propiedad, tecnología, capital, infraestructura y exposición legal, en lugar de permitir que una etiqueta europea represente las cinco. Este artículo es más acotado. Sigue la afirmación sobre el centro de datos hasta las capas operativas y legales que un comprador debe gobernar.

Así es también como preferimos describir nuestro propio trabajo. Un sistema debería hacer legibles sus límites: qué es local, qué está delegado, qué queda registrado, qué puede impugnarse y qué puede cambiarse. La afirmación útil es la que un lector puede comprobar. El resto es decoración, y Europa ya tiene bastante infraestructura decorativa.

El argumento legal empieza después de la dirección

La ubicación de un centro de datos merece conocerse. Puede afectar al acceso físico, la resiliencia, la conectividad, las normas locales aplicables y el diseño de un servicio. Puede ser la primera pregunta correcta. Es una respuesta final pobre.

La respuesta final tiene que conectar el lugar con la autoridad. Tiene que nombrar al operador, las identidades, las claves, los subcontratistas, las herramientas legales, las posibles solicitudes, las pruebas y la salida. Para los datos personales, el nivel de protección europeo debe seguir siendo esencialmente equivalente cuando se transfieren los datos, y los exportadores tienen que evaluar las circunstancias en lugar de repetir una afirmación sobre la ubicación. Para los datos no personales, la Ley de Datos añade normas sobre el acceso extranjero y el cambio de proveedor de servicios en la nube, que de nuevo hacen concretos el control y la portabilidad.

No existe un único número europeo que pueda convertir un servicio complicado en uno soberano. Hay una secuencia de preguntas, pruebas y registros. La secuencia es más lenta que imprimir «alojado en la UE» en un folleto. También es la parte que sigue siendo útil después de que el folleto haya quedado desactualizado.

Cuando un comprador pregunta dónde están los datos, responda a la ubicación con precisión. Luego pregunte quién puede leerlos, quién puede actuar sobre ellos, quién puede ser obligado, quién puede demostrar qué ha ocurrido y quién puede irse. Un centro de datos europeo puede formar parte de un acuerdo digno de confianza. No puede ser el argumento legal por sí solo.

Fuentes

• Recomendaciones 01/2020 sobre medidas que complementan las herramientas de transferencia para garantizar el cumplimiento del nivel de protección de los datos personales de la UE, Comité Europeo de Protección de Datos, versión final del 18 de junio de 2021. La página enlazada incluye el PDF oficial.
• Asunto C-311/18, Data Protection Commissioner contra Facebook Ireland y Schrems II, Tribunal de Justicia de la Unión Europea, sentencia del 16 de julio de 2020, EUR-Lex.
• Reglamento (UE) 2023/2854, la Ley de Datos, Parlamento Europeo y Consejo, 13 de diciembre de 2023, EUR-Lex.
• La Ley de Datos explicada, Comisión Europea, publicada en 2025 y consultada el 5 de agosto de 2026.
• Evaluación de riesgos de la computación en la nube y el PDF del informe oficial, Agencia de la Unión Europea para la Ciberseguridad (ENISA), 2009.
• La ilusión de la soberanía: dónde reside realmente el control, Dweve, 29 de junio de 2026.