La cuestión de la nube europea no es dónde está el servidor
Una ubicación puede ser verdadera y aun así dejar la pregunta abierta
Hay un momento familiar en cualquier conversación sobre la nube. Alguien pregunta dónde se almacenarán los datos. Otro responde con el nombre de una ciudad europea. La sala se relaja un poco. La respuesta puede ser perfectamente exacta, y puede importar muchísimo. La geografía afecta a la latencia, la seguridad física, la electricidad, la planificación de la resiliencia, el empleo, la responsabilidad pública y los acuerdos legales en torno a un servicio. Una autoridad pública que necesite que determinados registros permanezcan dentro de un territorio declarado tiene un motivo legítimo para preguntar. El problema empieza cuando se espera que el nombre de la ciudad resuelva todas las demás cuestiones del acuerdo.
Un servidor está en algún sitio. Un servicio no. Un servicio es una relación entre entidades jurídicas, personas con derechos de administrador, componentes de software, proveedores de hardware, contratos, equipos de soporte, redes, acuerdos de cifrado, subcontratistas y el cliente que depende del resultado. El edificio es una parte material de esa relación. No revela quién puede emitir una instrucción privilegiada desde otro lugar, qué grupo empresarial controla la empresa operadora, qué jurisdicción puede alcanzar a un proveedor, si ha cambiado un subprocesador o qué puede llevarse el cliente cuando termina el contrato.
Esto no es un argumento contra los centros de datos europeos ni contra los proveedores europeos. Es un argumento contra dejar que una respuesta útil haga un trabajo que no puede hacer. La cuestión de la nube europea no es si un servidor puede colocarse en suelo europeo. Es si la organización que utiliza el servicio puede comprender y ejercer suficiente control sobre todo el acuerdo para el trabajo en juego. La ubicación forma parte de esa respuesta. No puede ser toda la respuesta, del mismo modo que la dirección de una empresa no nos dice quién tiene las llaves de sus cuentas.
La distinción importa sobre todo donde la nube hace un trabajo corriente y de consecuencias. Una administración local puede tener correspondencia, expedientes e información pública en un entorno alojado. Un fabricante puede tener diseños y datos operativos. Un grupo de investigación puede tener un conjunto de datos que no puede moverse a la ligera. Un hospital puede usar servicios que tocan información personal. Ninguno de estos ejemplos necesita una caída dramática ni una novela de espías para volverse serio. La pregunta diaria es más simple: ¿quién tiene autoridad práctica sobre un sistema que se ha convertido en parte de la capacidad de trabajar de la organización?
La legislación y las orientaciones europeas tratan cada vez más esta cuestión como una cuestión de pruebas, roles y cambio de proveedor, y no como una cuestión de vocabulario tranquilizador. La Ley de Datos otorga a los clientes derechos y a los proveedores obligaciones en torno al cambio de proveedor, los datos exportables y las interfaces de los servicios de procesamiento de datos. El SEPD lleva tiempo diciendo que las instituciones europeas que usan servicios en la nube siguen siendo responsables de sus obligaciones de protección de datos. El trabajo de ENISA sobre riesgo en la nube señala el bloqueo y el riesgo legal como asuntos a evaluar. No son instrumentos idénticos y no crean una doctrina única de la nube. Juntos apuntan en una dirección útil: el control tiene que describirse, no darse por supuesto.
El pin del mapa y el plano de control
El lenguaje de la nube a menudo hace más difícil ver la distinción. La palabra nube sugiere un sistema meteorológico: grande, lejano y quizá inevitable. En la práctica, un servicio en la nube tiene un plano de control y un plano de trabajo. El plano de trabajo es donde se ejecuta una carga de trabajo, se almacenan datos, se procesan solicitudes y se devuelven resultados. El plano de control es el conjunto de mecanismos mediante los cuales se gestionan identidades, se cambian políticas, se actualiza software, se asigna capacidad, se presta soporte, se recuperan registros y se detienen o restauran sistemas. Ambos planos pueden estar distribuidos técnicamente. Ambos pueden cruzar fronteras organizativas.
Una declaración de ubicación normalmente habla primero del plano de trabajo. Puede indicar dónde se encuentra un almacén de datos, una máquina virtual o una región concretos. Esa información debe ser lo bastante específica como para resultar útil. Debe indicar qué cubre, qué categorías de datos le afectan, cómo se notifican los cambios y si las copias de seguridad, los registros, la información de soporte y los datos derivados siguen la misma regla. Una afirmación que solo mencione Europa, sin un límite, es un punto de partida para una pregunta, no una respuesta. Europa es un lugar grande y la arquitectura de servicios es aficionada a las excepciones.
El plano de control plantea una serie de preguntas distinta. ¿Quién puede crear o eliminar a un administrador? ¿Quién aprueba una intervención de emergencia? ¿Quién opera el servicio de identidad? ¿Quién puede ver la información de diagnóstico? ¿Qué empresa mantiene el software que hace funcionar la plataforma? ¿Qué entidad jurídica recibe una solicitud de una autoridad? ¿A qué subcontratista se le permite gestionar el soporte? ¿Qué parte puede cambiar una descripción del servicio o retirar una funcionalidad? Un cliente puede iniciar sesión todos los días y aun así no tener ninguna vía independiente para responder a ninguna de estas preguntas.
Esto no significa que los clientes deban esperar operar todos los dispositivos físicos. Normalmente no pueden, y la mayoría no lo necesita. La cuestión es hacer visible la delegación. La operación delegada puede ser responsable y eficiente cuando los poderes delegados están definidos, supervisados y son reversibles. Se convierte en un problema de soberanía cuando el cliente solo tiene una etiqueta contractual de control mientras el proveedor conserva las personas, las interfaces, los registros y el conocimiento técnico necesarios para ejercerlo. Un contrato que no se puede usar en la práctica es un objeto decorativo con buena tipografía.
Para un comprador, la consecuencia práctica es sencilla. Mantenga la pregunta sobre la ubicación. Añada la pregunta sobre el control a su lado. Pregunte dónde reside la carga de trabajo y luego pregunte quién puede cambiar sus condiciones. Pregunte dónde se procesan los datos y luego pregunte quién puede acceder a la vía administrativa. Pregunte dónde se guarda la copia de seguridad y luego pregunte quién puede restaurarla y bajo qué autoridad. Las respuestas pueden ser satisfactorias. Pueden revelar una dependencia que haya que aceptar deliberadamente. Cualquiera de los dos resultados es mejor que descubrir que un pin en un mapa estaba haciendo el trabajo de un modelo operativo.
La propiedad no es un detalle administrativo
A veces se trata la propiedad como un debate aparte sobre banderas, bolsas de valores y orgullo nacional. Es algo más concreto que eso. La propiedad puede determinar quién nombra al consejo, quién aprueba una venta, quién dirige la inversión, quién posee la propiedad intelectual, qué políticas del grupo se aplican y qué entidad decide en última instancia si un servicio sigue siendo una línea de negocio. Un cliente no necesita una regla simplista según la cual solo una estructura de propiedad sea aceptable. Sí necesita conocer la estructura antes de calificar el acuerdo de independiente.
La organización corporativa también afecta a lo que significa una promesa de nube. Una marca puede ser local mientras el servicio lo gestiona una entidad distinta. Una filial europea puede contratar con un cliente europeo mientras un grupo en otro lugar proporciona software esencial, operaciones de seguridad, soporte, facturación, análisis de datos o autoridad ejecutiva. Un socio local puede aportar genuinamente un valioso trabajo de implementación mientras depende de una plataforma que no puede modificar. Ninguno de estos acuerdos es automáticamente improcedente. Son acuerdos de control diferentes y no deberían parecer idénticos por compartir un logotipo y un número de teléfono local.
La pregunta pertinente no es si un comprador puede encontrar una conexión extranjera en algún lugar de una larga cadena de suministro. La tecnología moderna está interconectada, y las pruebas de pureza no son un método de contratación. La cuestión es dónde una dependencia se vuelve decisiva. ¿Qué entidad puede modificar el contrato? ¿Qué entidad controla la propiedad intelectual del servicio? ¿Qué entidad puede asumir un compromiso de soporte? ¿Qué entidad tiene las credenciales o los conocimientos necesarios para restablecer la función? ¿Qué entidad puede ser adquirida, sancionada, reorganizada o instruida de una manera que cambie la posición del cliente? Esas son preguntas sobre el poder real.
La propiedad también cambia. Una adquisición, una ronda de financiación, una reestructuración o una transferencia interna pueden alterar el panorama de control sin mover un solo servidor. Una cláusula de ubicación redactada en el momento de la firma puede seguir siendo fácticamente correcta mientras los hechos organizativos que la rodean han cambiado. Por eso un archivo de nube serio necesita un proceso de cambio. El cliente debe saber qué cambio debe notificarse, quién evaluará su efecto, qué evidencia debe actualizarse y qué autoridad puede pausar un nuevo flujo de datos mientras se realiza la evaluación. No es un trabajo glamuroso. Tampoco lo es revisar el aceite de un coche, quizá por eso la gente lo recuerda cuando el motor se queja.
En sus directrices sobre la nube de 2018, el SEPD subrayó que las instituciones de la UE siguen siendo responsables de sus obligaciones de protección de datos cuando utilizan servicios de computación en la nube y deben garantizar un nivel de protección equivalente al de otros modelos de infraestructura. Eso no es una exigencia de que cada institución sea propietaria de todo. Es un recordatorio de que externalizar una función no externaliza el deber de comprender el acuerdo. El deber hace que la propiedad sea relevante porque la responsabilidad no puede ejercerse mediante un diagrama que omita a la parte con el poder práctico.
El alcance legal no se borra por una dirección europea
La jurisdicción suele ser la capa más incómoda porque se resiste a la respuesta sencilla. Un contrato puede elegir una ley aplicable y un tribunal. Esas elecciones importan. No hacen desaparecer otros poderes legales. El alcance legal puede seguir a una entidad, un establecimiento, un proveedor de servicios, un grupo empresarial, una persona con acceso, un proveedor de hardware o la ubicación y naturaleza de datos concretos. El análisis exacto depende de los hechos y del derecho. Una entrada de blog no puede resolverlo para una organización real, y una plantilla de contratación no puede sustituir al asesoramiento adecuado cuando el riesgo es material.
La disciplina útil consiste en separar una cuestión jurídica de una afirmación geográfica. Un centro de datos en la Unión Europea nos dice dónde está situado el equipo. No nos dice por sí solo qué entidades pueden ser obligadas, qué autoridades podrían hacer una solicitud, qué notificación es posible, o si un proveedor tiene obligaciones bajo otro ordenamiento jurídico. Tratar ambos como equivalentes puede producir una falsa sensación de cierre. El comprador puede haber cumplido un requisito de residencia mientras deja el análisis legal completamente sin realizar.
Las directrices finales del CEPD sobre la interacción entre el artículo 3 del RGPD y las transferencias internacionales del capítulo V son útiles precisamente porque se resisten a los atajos. Distinguen el ámbito territorial del RGPD de la cuestión de si una operación de tratamiento es una transferencia internacional. Esa distinción no ofrece una conclusión universal para cada acuerdo de nube. Sí muestra por qué frases como con sede en la UE o cubierto por el RGPD no pueden sostener todas las inferencias legales que un comprador pueda querer hacer. El análisis de protección de datos sigue el tratamiento real y a los actores implicados.
La Ley de Datos introduce una cuestión conexa en el expediente de los servicios en la nube. Su capítulo VII trata sobre el acceso gubernamental internacional ilícito y la transferencia de datos no personales custodiados en la Unión. El Reglamento exige a los proveedores de servicios de tratamiento de datos que adopten medidas técnicas, organizativas y jurídicas adecuadas, incluidas medidas contractuales, en las circunstancias descritas en el artículo 32. No promete que un proveedor pueda hacer desaparecer cualquier solicitud externa. Exige una respuesta disciplinada ante un conflicto que no puede disiparse con un término de marketing.
Para los clientes, el trabajo inmediato es un mapa de evidencia. Identifique la entidad contratante, las entidades proveedoras que operan partes esenciales del servicio, los lugares donde se producen el tratamiento de datos y la administración, las jurisdicciones declaradas, la vía para recibir e impugnar solicitudes, las condiciones de notificación y el asesoramiento jurídico necesario para la carga de trabajo concreta. Señale qué se sabe, qué declara el suministrador, qué está comprometido contractualmente y qué requiere aún investigación. Un mapa con fecha y una brecha identificada es más útil que un párrafo de garantía permanente.
El control operativo es donde una promesa se hace realidad
El control operativo es la capacidad de hacer que un sistema realice una acción, o deje de realizarla, mediante una autoridad y un mecanismo definidos. Incluye cuestiones cotidianas: crear una cuenta, cambiar una política de red, rotar una clave, restaurar una copia de seguridad, aprobar un lanzamiento, aislar un inquilino, retirar a un administrador, inspeccionar un registro y exportar un documento. Ninguna de estas acciones es un certificado de soberanía. En conjunto, muestran si el cliente y el proveedor tienen una división de responsabilidades inteligible.
Un acuerdo de nube es débil cuando toda acción relevante termina en un correo electrónico a una dirección de soporte genérica. El soporte importa, y el soporte experto puede ser una de las buenas razones para utilizar un servicio gestionado. Pero una organización crítica debe distinguir entre una vía de soporte y una vía de autoridad. Una vía de soporte es cómo el proveedor ayuda. Una vía de autoridad es cómo el cliente puede iniciar, aprobar, observar y registrar una acción por la que sigue siendo responsable. Ambas pueden encontrarse en un ticket. No deben confundirse.
Consideremos un caso claramente hipotético. Un consorcio de investigación europeo utiliza un entorno analítico alojado para un proyecto sensible pero lícito. Dispone de un contrato con región europea y una ubicación de datos documentada. Durante una revisión interna, el consorcio quiere suspender una canalización concreta, conservar los registros asociados e impedir que se conecte una nueva fuente de datos hasta que termine la revisión. Las preguntas útiles no son si un operador imaginario actúa heroicamente. Son si el consorcio tiene un rol designado capaz de ordenar el cambio, si la plataforma expone un mecanismo controlado, si la acción queda registrada y si los flujos dependientes son visibles antes de utilizar el conmutador.
El caso hipotético es deliberadamente sosegado porque la autoridad ordinaria es el punto central. Un servicio no necesita fallar para que el cliente necesite control. Una revisión de privacidad, un cambio de finalidad, una decisión de contratación, una disputa contractual, una preocupación de seguridad o la salida de personal pueden requerir una acción acotada. Si nadie sabe quién puede emprenderla, o si el cliente no puede inspeccionar qué hizo la acción, el problema no es que la nube sea misteriosa. El problema es que el modelo operativo nunca se completó.
Un buen control operativo no tiene por qué estar centralizado. Una gran institución puede repartir responsabilidades entre un responsable del servicio, una función de seguridad, una función de protección de datos, un equipo de operaciones y un proveedor. La división puede reducir el riesgo de que una sola persona tome una decisión perjudicial por su cuenta. Lo importante es que el límite de autoridad sea legible. Cada rol debe saber qué puede iniciar, qué puede aprobar, qué debe registrar, cuándo debe escalar y cómo se recupera la organización cuando la persona habitual no está disponible. La nube no está exenta de gobernanza porque su panel de control sea ordenado.
La línea de subcontratación forma parte del servicio
La mayoría de los servicios en la nube no los presta una sola empresa con un solo edificio y una sola pila de software. Pueden intervenir proveedores de infraestructura, operadores de red, servicios de seguridad gestionada, socios de soporte, procesadores de pagos, mantenedores de software, servicios de identidad, fabricantes de hardware y subcontratistas especializados. Una cadena compleja no es señal de fracaso. Es un motivo para describir la cadena. El cliente necesita saber dónde empiezan las dependencias materiales, qué se les permite hacer y cómo se comunicará un cambio.
El vocabulario de protección de datos de responsable y encargado resulta útil aquí, pero no debe convertirse en un sustituto de la comprensión. Una lista de encargados puede identificar organizaciones que tratan datos personales en nombre de un proveedor. Puede que no responda a todas las preguntas operativas sobre suministro de software, soporte de hardware, administración remota, telemetría, respuesta a incidentes o autoridad corporativa. A la inversa, un inventario de ingeniería puede identificar componentes, pero omitir quién tiene una obligación contractual con el cliente. Ambas perspectivas deben leerse conjuntamente, no utilizarse como documentos enfrentados.
La guía sobre la nube del SEPD recomienda una asignación clara de responsabilidades y atención a los roles de las partes implicadas en los servicios en la nube. Esa preocupación práctica sigue vigente porque los modelos de prestación complejos pueden crear la impresión de que la responsabilidad se ha evaporado en la arquitectura. No es así. Alguien sigue decidiendo la finalidad de una operación de tratamiento. Alguien sigue fijando las condiciones técnicas. Alguien sigue aceptando a un subcontratista. Alguien sigue teniendo que explicar qué ha ocurrido cuando cambia un sistema. La complejidad puede explicar por qué la respuesta tarda en llegar. No hace que la pregunta sea irrazonable.
Existe una prueba útil para la materialidad. Si un proveedor desapareciera del acuerdo mañana, ¿perdería el servicio una función que el cliente necesita, perdería una propiedad de seguridad, perdería el acceso a un registro o perdería la capacidad de migrar? Si la respuesta es afirmativa, ese proveedor pertenece al mapa de control. El mapa no tiene que exponer cada resistencia ni hacer pública toda relación comercial. Sí tiene que mostrar las dependencias que alteran la capacidad del cliente para gobernar el trabajo. Una dependencia oculta no es una abstracción inteligente. Es una reunión futura con un tono ligeramente distinto.
El control de los subcontratistas también depende del tiempo. El comprador debe saber cómo se incorporan nuevos encargados y proveedores operativos materiales, qué aviso se da, qué proceso de objeción o evaluación se aplica y cómo se registra un cambio. Una lista estática es mejor que ninguna lista. Una lista actualizada y revisable es mejor porque reconoce que un servicio no queda congelado en la firma. La organización no puede gobernar las dependencias de cuya llegada no se le ha informado.
El hardware tiene una política y una consecuencia operativa
Resulta tentador detener el análisis en la interfaz de software. El servicio funciona, el panel está en el idioma correcto, el acuerdo menciona una región europea y la infraestructura subyacente parece demasiado remota para resultar útil. Sin embargo, el hardware y su cadena de soporte pueden ser decisivos cuando importan la disponibilidad, la confidencialidad, el mantenimiento, la reparación, la capacidad o la continuidad. La cuestión no es si un cliente debe auditar cada chip. La cuestión es si el cliente sabe qué dependencias hacen posible el servicio elegido y qué ocurre cuando una de ellas cambia.
Aquí es donde la distinción entre aspiración soberana y autosuficiencia merece atención. Europa participa en cadenas de suministro globales. Ninguna organización seria puede fabricar todos los semiconductores, cables, servidores, componentes de firmware, sistemas operativos y herramientas dentro de un único límite de contratación. Tampoco sería un umbral sensato para cada carga de trabajo. La soberanía práctica es la capacidad de reconocer la dependencia, establecer condiciones en torno a ella, mantener alternativas donde se necesiten y evitar fingir que un componente externo indispensable no lo es.
Las dependencias de hardware pueden afectar al control de la nube mediante la asignación de capacidad, el acceso de mantenimiento, las actualizaciones de software, las vías de sustitución y los componentes de confianza. También pueden afectar a la viabilidad de una migración. Una carga de trabajo diseñada en torno a una función gestionada concreta, un entorno de aceleración específico o una integración no documentada puede ser técnicamente portable solo en el mismo sentido en que un piano es portable cuando alguien se ofrece a subirlo seis tramos de escaleras. El sustantivo es correcto. El plan está incompleto.
La evaluación de riesgos en la nube de ENISA es ya una publicación antigua, pero su advertencia sobre el bloqueo, el riesgo legal y la pérdida de control no ha quedado obsoleta. El vocabulario técnico ha cambiado varias veces desde su aparición. La pregunta subyacente no ha cambiado: ¿qué pierde el cliente si el servicio cambia, la relación termina o una dependencia no se comporta como se esperaba? Una evaluación de riesgos no exige que el comprador rechace todo servicio gestionado. Le pide que asocie consecuencias a las dependencias antes de que la dependencia se convierta en una emergencia.
Un archivo de nube consciente del hardware puede mantener la proporción. Registre la arquitectura en el nivel que importa para la carga de trabajo. Identifique las dependencias únicas y los puntos únicos de conocimiento operativo. Indique las condiciones contractuales que afectan a la continuidad y la migración. Pregunte qué vía de soporte es necesaria para las actualizaciones de seguridad o la recuperación. Compruebe si un entorno de sustitución necesita los mismos componentes propietarios. El objetivo no es un catálogo de museo. Es una imagen sobria de las cosas que deben seguir estando disponibles para que la organización pueda seguir haciendo su trabajo.
La salida es una capacidad, no un botón de descarga
La pregunta más reveladora sobre la nube suele ser qué ocurre cuando el cliente quiere marcharse. Marcharse puede significar trasladarse a otro proveedor, recuperar una función en un entorno local, cambiar la arquitectura, reducir el servicio o detenerlo. Un cliente puede a veces exportar una base de datos y aun así no poder reanudar el servicio. La función también puede depender de la configuración, las identidades, las claves, los registros, los permisos, la automatización, los modelos, el material de evaluación, el linaje de datos, las reglas de integración y el conocimiento operativo que hace que las piezas funcionen juntas.
La Ley de Datos es inusualmente concreta en este punto. Sus disposiciones sobre el cambio de proveedor exigen que los contratos establezcan derechos y obligaciones en torno al cambio y a la portabilidad de los datos exportables y los activos digitales. Establece un período transitorio máximo normal de 30 días naturales tras el período de preaviso correspondiente, al tiempo que permite un período alternativo en casos definidos de inviabilidad técnica, sujeto a condiciones. También aborda las interfaces abiertas y la interoperabilidad. El Reglamento ofrece a los compradores algo valioso: una razón legal para pedir la ruta antes de necesitarla.
Los límites son igual de importantes. La Ley de Datos no hace transferible cualquier activo digital, no exige que un proveedor revele propiedad intelectual protegida o secretos comerciales, y no garantiza equivalencia funcional en el destino. Un proveedor puede cumplir sus obligaciones legales mientras una migración sigue siendo difícil. Un comprador puede tener derecho de exportación pero carecer de las personas, el presupuesto o el destino necesarios para ejercerlo. Por eso la salida debe tratarse como una capacidad compartida entre contrato, arquitectura y organización, y no como una promesa hecha en una línea de un formulario de pedido.
Un expediente de salida creíble registra el tipo de servicio de destino, los datos y activos exportables, sus formatos, el procedimiento para obtenerlos, las condiciones de continuidad previstas, el periodo de recuperación, las hipótesis sobre el destino y las partes de la función que no pueden simplemente trasladarse. Identifica quién validará que el material exportado es utilizable. Registra qué registros y evidencias deben conservarse. Nombra la autoridad que puede aceptar el cambio o decidir que aún no es seguro completarlo. Esto es menos emocionante que un anuncio de migración. Pero es mucho más probable que haga realidad ese anuncio.
Las pruebas importan. Un ejercicio pequeño y acotado puede revelar si un formato está meramente disponible o es realmente utilizable, si una identidad puede recrearse sin alterar permisos, si una clave puede transferirse con la autoridad adecuada, si los registros conservan su significado y si un servicio reducido puede continuar mientras se traslada el servicio completo. Esto no es afirmar que toda organización deba ensayar una salida completa de la nube cada mes. El alcance debe reflejar la consecuencia de una interrupción. Es afirmar que una salida no probada es una intención, no todavía una opción.
Qué debe contener una evaluación europea de la nube
Una evaluación útil comienza nombrando la función, no al proveedor. ¿Qué trabajo se espera que respalde el servicio? ¿Qué datos, registros, derechos, necesidades de continuidad y consecuencias públicas están implicados? Una herramienta de colaboración de bajo riesgo y un sistema que contiene registros operativos sensibles no necesitan controles idénticos. Empezar por la carga de trabajo evita que una organización aplique una gran etiqueta de soberanía a una decisión pequeña y específica, o que trate un servicio crítico como si fuera otra suscripción de oficina.
Después, haga una declaración de ubicación con un límite. Indique dónde se espera que opere el plano de trabajo pertinente, qué categorías de datos cubre, qué copias y diagnósticos están incluidos, qué transferencias están permitidas, cómo se evidencia la posición y cómo se notifican los cambios. Si el proveedor solo puede hacer una declaración regional amplia, registre esa limitación. Un comprador puede distinguir entre un compromiso preciso y una descripción comercial general. Esa distinción no es hostil. Es para eso que sirven los contratos.
A continuación, elabore un mapa de entidades y autoridades. Registre la entidad contratante, las entidades del grupo con un papel material, los procesadores o subprocesadores designados cuando corresponda, los roles que pueden administrar el servicio, la vía de escalado, los acuerdos de identidad y claves, y la autoridad del cliente que permanece tras la externalización. Incluya la evidencia legal y técnica que respalda cada entrada. No escriba proveedor o cliente cuando se conoce una entidad, rol o mecanismo concreto. Los sustantivos generales son muy buenos para ocultar ausencias específicas.
Add a dependency map. This should include material software, hardware, network, support and integration dependencies, the change path for each, and the consequences of loss or alteration. It does not need to predict the future. It needs to make the current design challengeable. If a dependency is acceptable, record why. If it is not acceptable, state the refusal condition. If it is unknown, do not resolve the discomfort by calling it low risk. Unknown is a real status, and it often earns the next piece of work.
Finally, attach the exit and review record. Capture the applicable contractual provisions, export procedures, tests performed, gaps found, corrective actions, review date and events that trigger reassessment. The point is not to produce a perfect folder. It is to establish a living account of control that survives a staff change, a service update, a contract renewal and the day when somebody has to make an uncomfortable decision quickly. A report that cannot be updated becomes history with an invoice attached.
What public procurement can ask without pretending to solve everything
Public buyers have a particular reason to insist on this evidence because they often hold responsibilities that do not end when a contract is signed. They may be accountable to citizens, subject to public-record rules, responsible for essential functions or required to explain why a decision was reasonable. That does not mean public procurement can eliminate every foreign dependency, or that a national preference is a substitute for a technical assessment. It means the tender can ask questions that make the arrangement visible before it becomes embedded.
A proportionate tender can ask for the entities that will provide material parts of the service, the geographical and legal boundaries claimed, the role and authority model, the subcontractor change process, the support and incident route, the evidence retained for the customer, the export and switching procedure, and the conditions under which a customer can suspend, limit or end use. It can score the quality of answers rather than reward an adjective. A supplier that knows its own operating model should be able to explain it without a fog machine.
There are trade-offs. More evidence may lengthen a procurement. Some requirements may reduce the number of bids. A small provider may have less capacity to produce elaborate documentation even when its control model is strong. An incumbent may have an excellent technical service but an exit path that needs negotiation. These are not arguments for skipping the questions. They are the facts a buyer needs in order to decide which cost is acceptable: the cost of evidence and alternatives now, or the cost of dependence later.
The European Commission's work on cloud sovereignty has made this direction visible in procurement terms, but buyers do not need to wait for a universal badge. They can specify their own risk boundary and demand evidence that fits it. A public library, a research agency, a city department and a critical-infrastructure operator will not use the same threshold. They should not. The test is whether the requirements follow the function, are published fairly, can be evaluated consistently and preserve the customer's ability to explain what it has chosen.
That is the quieter promise of European cloud policy. It can move the conversation away from nationality theatre and towards governing relationships. The European answer need not be a sealed technological island. It can be a more adult market in which claims about location, control, law and exit are separate claims, supported with separate evidence. Interdependence does not disappear when it is named. It becomes possible to decide where it is tolerable.
The controls do not answer one another
Vale la pena resistirse a un último atajo. El cifrado fuerte no responde a una cuestión de propiedad. Las claves en manos del cliente pueden reducir ciertos riesgos de acceso y constituir un control importante, pero por sí solas no determinan quién opera el servicio, quién controla la plataforma, qué información permanece visible en los metadatos ni si el cliente puede trasladar la función. Una buena cláusula de salida no responde a una cuestión jurisdiccional. Una matriz europea no responde a una cuestión de soporte de hardware. Cada control tiene una función. Cada uno debe evaluarse según la función que realmente desempeña.
Por eso también una decisión sobre la nube debería poder decir «no es suficiente» sin volverse teatral. Un comprador puede considerar que el compromiso de ubicación es adecuado, pero que el aviso de cambios es demasiado vago. Puede aceptar un subencargado, pero exigir una vía de autoridad más clara. Puede aceptar una dependencia de hardware extranjero, siempre que se documente un plan de sustitución. Puede decidir que un servicio concreto no es adecuado para una categoría de datos, pero sí para otra. El matiz no es una incapacidad para decidir. Es la condición para decidir con base en la evidencia y no en el reconocimiento de la marca.
El trabajo resulta más fácil cuando la evidencia se mantiene cerca de la decisión. No guarde la declaración de ubicación de los datos en un sistema, el contrato en otro, la revisión de accesos en una bandeja de entrada y el plan de salida en la memoria de alguien. Vincúlelos al registro del servicio y asigne un responsable a ese registro. Cuando cambie un requisito, la organización debería poder encontrar la evidencia, identificar el límite afectado y decidir si el servicio puede continuar. Eso es gobernanza en su versión menos glamurosa y más útil.
Una breve nota nuestra
Nuestro informe The Sovereignty Illusion utiliza cinco lentes prácticas para una cuestión similar: propiedad, tecnología, capital, infraestructura y exposición legal. Ese es nuestro marco de investigación, no una clasificación jurídica ni una prueba de que un servicio concreto satisface las necesidades de un cliente. Su contribución útil es un hábito de atención. Cuando una afirmación sobre la nube suene completa, pregúntese cuáles de esas lentes ha cubierto realmente y cuáles quedan fuera del encuadre.
Ese hábito también determina cómo describimos nuestro propio trabajo. Una afirmación de soberanía debe acotarse a la implementación, el contrato y la responsabilidad operativa, no inflarse hasta convertirse en una promesa que una página de producto no puede cumplir. El cliente, la carga de trabajo y el modelo de control acordado siguen decidiendo qué se puede afirmar con honestidad. En un campo repleto de sustantivos grandilocuentes, la mesura no es un inconveniente de marketing. Es parte de la evidencia.
La pregunta tras el nombre de la ciudad
La ubicación europea sigue siendo una pregunta que merece la pena plantear. Puede ser un requisito legal, un requisito operativo, una elección de resiliencia, una elección de seguridad física o una expresión de responsabilidad pública. Un comprador no debería sentir vergüenza por preguntar dónde se ejecuta un sistema. Simplemente debería plantear la pregunta en compañía. ¿Quién posee la entidad que importa? ¿Quién tiene autoridad operativa? ¿Qué órdenes jurídicas pueden alcanzar el acuerdo? ¿Qué subcontratistas y componentes son materiales? ¿Qué puede inspeccionar, detener, trasladar y conservar el cliente?
Esas preguntas no hacen que la computación en la nube sea menos útil. Hacen que su uso sea más deliberado. Sustituyen una atmósfera de tranquilidad por un expediente que puede revisarse. Ofrecen a los proveedores una oportunidad justa de mostrar los controles que han construido, y a los compradores una forma justa de distinguir un límite útil de una afirmación vacía. Y lo más importante: preservan la posibilidad de cambiar de rumbo antes de que una dependencia se convierta en una acusación.
La cuestión de la nube europea no es, por tanto, dónde está el servidor. Es dónde está el control cuando el sistema tiene que cambiar. Un centro de datos puede ser parte de la respuesta. Un contrato europeo puede ser parte de la respuesta. Un proveedor europeo puede ser parte de la respuesta. La respuesta solo resulta creíble cuando la organización puede seguir la ruta desde el lugar hasta la propiedad, desde la propiedad hasta el alcance legal, desde el alcance legal hasta la autoridad operativa, y desde la autoridad hasta una vía de salida probada. Esa ruta es menos memorable que una bandera junto a un edificio. También es donde comienza el trabajo.
Fuentes
- Cloud Computing, Supervisor Europeo de Protección de Datos. Utilizado para la posición de orientación del EDPS sobre la nube según la cual las instituciones de la UE siguen siendo responsables de sus obligaciones de protección de datos y deben garantizar una protección equivalente.
- EDPB publishes three guidelines following public consultation, Comité Europeo de Protección de Datos, 24 de febrero de 2023. Utilizado para el alcance y la finalidad de las directrices definitivas sobre el artículo 3 del RGPD y las transferencias internacionales del capítulo V.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Utilizado para las disposiciones sobre cambio de proveedor, exportación, continuidad, interoperabilidad y acceso gubernamental internacional aplicables a los servicios de tratamiento de datos.
- Cloud Computing Risk Assessment, Agencia de la Unión Europea para la Ciberseguridad. Utilizado para el marco de evaluación de riesgos de bloqueo, riesgo legal y pérdida de control.
- The Sovereignty Illusion, Dweve. Utilizado únicamente para el marco de investigación de cinco lentes divulgado por Dweve.