Los controles de residencia de datos del RGPD necesitan pruebas, no promesas

Un selector de región de la UE es útil, pero no demuestra que los datos personales permanezcan en esa región. Los compradores deben seguir cada copia y cada persona que pueda acceder a ella: la base de datos activa, el almacenamiento de objetos, los registros, las copias de seguridad, las solicitudes a proveedores de modelos, la telemetría y las sesiones de soporte. Si una ruta sale del límite prometido, la afirmación de residencia necesita un mecanismo de transferencia y pruebas que la respalden.

Por eso, los controles de residencia de datos del RGPD deben evaluarse como una cadena de hechos exigibles. Una captura de pantalla de la consola muestra una configuración. No muestra qué cubre esa configuración, si un administrador puede modificarla ni qué ocurre durante un incidente. El área de compras debe exigir un compromiso contractual, una descripción del sistema y una prueba repetible para cada afirmación relevante.

Este artículo ofrece a los compradores un criterio práctico para evaluar creadores de aplicaciones de IA. No sustituye el asesoramiento jurídico sobre una transferencia, jurisdicción o perfil de riesgo concretos.

La fijación de región debe definir cada clase de datos

La fijación de región solo resulta creíble cuando el proveedor define tanto el límite geográfico como los datos que cubre. «Alojamiento en la UE» puede significar que la base de datos principal está en Fráncfort, mientras los prompts se envían a un endpoint de modelo situado en otro lugar, los registros llegan a un servicio global de analítica y las copias de seguridad se replican entre regiones. La etiqueta dice poco hasta que el proveedor traza el flujo de datos.

Pide un anexo de ubicación de datos que indique el país permitido o conjunto de países para cada clase de datos. Como mínimo, debe cubrir registros de la aplicación, archivos cargados, prompts y respuestas del modelo, embeddings, secretos, datos de autenticación, registros, métricas, trazas, informes de fallos, archivos adjuntos de soporte y copias de seguridad. También debe aclarar si «UE» significa la Unión Europea, el EEE en sentido amplio o un grupo definido por el proveedor que incluye otros países.

El control necesita un alcance claro. ¿La región elegida se aplica al espacio de trabajo del creador, al entorno de producción de la aplicación generada o a ambos? ¿Cubre entornos de vista previa, despliegues por rama, trabajadores temporales de compilación, colas, cachés, índices de búsqueda, cachés de distribución de contenido y copias de recuperación ante desastres? Un creador de aplicaciones puede mantener la base de datos terminada en una región y procesar el código fuente, los prompts y la salida de compilación en otra.

Exige al proveedor que identifique por escrito las excepciones. Una excepción limitada puede ser manejable si el comprador entiende los datos, la finalidad, el destino, el plazo de conservación y la garantía aplicable. Una cláusula indefinida como «los datos operativos pueden tratarse globalmente» anula el objetivo, porque los datos operativos suelen contener identificadores de usuario, rutas de solicitudes, fragmentos de prompts y cargas de errores.

La mejor evidencia combina tres capas. El contrato o formulario de pedido indica la región comprometida y el proceso de cambio. La documentación de arquitectura asigna cada clase de datos a un servicio y una ubicación. Un registro técnico, como una respuesta de API o un registro de despliegue, demuestra la configuración del tenant del propio comprador.

Por ejemplo, pide al proveedor que genere un registro del tenant con una estructura estable:

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

Los nombres variarán según el producto. Lo importante es que el registro distinga entre espacio de trabajo, entorno de ejecución, copias de seguridad y política de soporte, en vez de reunirlo todo bajo una insignia verde de «UE». Pregunta quién puede cambiar estos valores, si el comprador puede detectar un cambio y qué sucede con las copias existentes tras un traslado.

Las copias de seguridad necesitan su propia promesa de residencia

Las copias de seguridad deben seguir una política explícita de ubicación, conservación, eliminación y restauración. Son copias independientes, con infraestructura, vías de acceso y ciclos de vida propios. Un proveedor que solo promete dónde residen los «datos de clientes en reposo» quizá no haya comprometido sus bóvedas de copias de seguridad, instantáneas o réplicas de recuperación ante desastres al mismo límite.

Pregunta dónde se guarda cada copia de seguridad, incluidas instantáneas de bases de datos, versiones de objetos, volúmenes replicados, copias de configuración y copias de recuperación gestionadas por el proveedor. Exige que el proveedor indique si la replicación permanece dentro de un país, se mueve entre países del EEE o cruza a un tercer país. La arquitectura de disponibilidad puede justificar una segunda región, pero no vuelve irrelevante esa segunda ubicación.

Las respuestas sobre conservación necesitan cifras y eventos. Compras debe obtener el periodo normal de conservación de copias, cualquier nivel de archivo más prolongado, el tiempo hasta que un medio caducado no pueda recuperarse y el tratamiento de las copias tras la finalización del contrato. «Eliminado conforme a la política» no se puede probar. Un calendario que indique que los puntos de recuperación diarios caducan después de un plazo establecido y que las copias de tenants finalizados se vuelven inaccesibles y caducan según un calendario definido sí puede comprobarse.

La eliminación lógica y la expiración física son distintas. Un registro eliminado puede permanecer dentro de una copia cifrada hasta que caduque ese punto de recuperación. Esto puede ser compatible con un diseño documentado de conservación, pero el proveedor debe explicar cómo evita que una restauración normal reactive silenciosamente datos eliminados. Los procedimientos de restauración maduros reproducen marcadores de eliminación o exigen una conciliación posterior a la restauración antes de devolver el sistema al servicio.

Pide un elemento reciente de prueba de restauración con los detalles sensibles eliminados. Debe identificar la región de la copia de origen, el destino de restauración, las personas o roles de servicio implicados, el registro de aprobación y la eliminación de la copia restaurada. Una política genérica de recuperación ante desastres demuestra que alguien redactó una política. Un registro de restauración demuestra que el proceso operativo sabe dónde fue a parar la copia.

El cifrado no elimina la cuestión de la ubicación. Puede reducir el riesgo, sobre todo cuando las claves y los roles administrativos están separados, pero una copia de seguridad en un tercer país puede seguir siendo una transferencia que necesita un mecanismo válido y una evaluación. Compras debe registrar quién controla las claves, dónde se encuentran, quién puede restaurar y si el personal del proveedor puede obtener datos en texto claro durante la recuperación.

Una lista de subencargados debe describir la cadena real

Un registro útil de subencargados vincula cada empresa con una finalidad, una categoría de datos, una ubicación de tratamiento y una base de transferencia. Una lista de logotipos o nombres legales es un inventario, no una explicación de cómo se mueve la información del comprador. Los creadores de aplicaciones de IA suelen depender de alojamiento en la nube, proveedores de modelos, servicios de observabilidad, envío de correo, autenticación, soporte al cliente y supervisión de abusos. Cada función puede ver una parte diferente de los datos.

El artículo 28 del RGPD exige que un encargado obtenga autorización previa por escrito, específica o general, antes de designar a otro encargado. Con una autorización general, el encargado debe informar al responsable de las altas o sustituciones previstas para que este pueda oponerse. Compras debe convertir esta regla en un requisito operativo: un registro estable, aviso previo a través de un canal que el comprador supervise, un plazo de aviso definido y un proceso de oposición establecido.

El registro debe responder a cinco cuestiones para cada subencargado:

• la entidad jurídica que recibe datos o puede acceder a ellos
• el servicio y la finalidad concreta del tratamiento
• las categorías de datos personales y las funcionalidades de producto afectadas
• los países de almacenamiento y acceso remoto
• el mecanismo de transferencia aplicable y la cadena posterior de subencargados

No aceptes «infraestructura en la nube» como ubicación de un servicio de modelos. Pregunta si los prompts se envían al proveedor del modelo, si este los conserva, si personas pueden revisarlos y si el comprador puede desactivar a un proveedor o elegir un endpoint. Si el creador usa una combinación de modelos, importa la lógica de enrutamiento: la región de proyecto elegida no puede controlar una solicitud que la capa de enrutamiento envía a un endpoint no aprobado.

El aviso de cambio debe llegar antes de que el cambio entre en vigor. Una página web que puede cambiar sin aviso obliga a Compras a realizar una vigilancia manual continua. El contrato debe indicar qué información incluye el aviso y qué sucede tras una oposición justificada. El proveedor no tiene que prometer que su cadena de suministro nunca cambiará, pero el comprador necesita tiempo para evaluar una nueva transferencia antes de que los datos empiecen a circular.

Pide al proveedor que concilie tres elementos durante la diligencia: su registro público, el anexo del DPA y un diagrama actual de arquitectura o flujo de datos. Los nombres y ubicaciones suelen divergir entre documentos tras una migración de proveedor. Una discrepancia no significa automáticamente que el control haya fallado, pero sí que el comprador carece de un registro fiable hasta que el proveedor la resuelva.

El DPA debe convertir la configuración en obligaciones

El acuerdo de tratamiento de datos debe indicar las instrucciones de tratamiento, obligaciones de seguridad, condiciones de eliminación, derechos de auditoría y controles de subencargados aplicables al servicio adquirido. La documentación del producto puede explicar una funcionalidad, pero el DPA y los documentos de pedido determinan lo que el proveedor ha prometido a ese comprador.

El artículo 28, apartado 3, del RGPD enumera los elementos que debe cubrir un contrato entre responsable y encargado, entre ellos el objeto y duración, naturaleza y finalidad, tipos de datos personales, categorías de interesados, confidencialidad, asistencia de seguridad, eliminación o devolución e información necesaria para demostrar el cumplimiento. Las Directrices 07/2020 del Comité Europeo de Protección de Datos añaden una advertencia útil: un acuerdo de tratamiento no debe limitarse a repetir el RGPD. Debe incluir información específica sobre cómo se cumplirán los requisitos y el nivel de seguridad exigido.

Esta precisión importa para la residencia. Adjunta un anexo que identifique las regiones elegidas por el comprador, los entornos cubiertos, los países aprobados para acceso remoto, las ubicaciones de copias de seguridad y los subencargados aprobados. Indica que el proveedor no puede ampliar de forma sustancial esas ubicaciones sin el aviso o procedimiento de cambio acordado. Si el material comercial dice «solo UE» pero el DPA permite tratar datos en cualquier lugar donde operen el proveedor o sus filiales, el contrato prevalece cuando ambos entran en conflicto.

Revisa también la asignación de roles. Para el contenido de clientes usado exclusivamente para prestar el servicio según las instrucciones del comprador, el proveedor suele actuar como encargado. Puede alegar un papel independiente de responsable para facturación, seguridad de cuentas, prevención del fraude u obligaciones legales propias. No rechaces de entrada toda finalidad independiente. Exige que el proveedor identifique esas finalidades, categorías de datos, base jurídica, conservación y comunicaciones, en vez de ocultarlas en un derecho amplio a usar todos los datos del servicio.

El entrenamiento de IA merece una cláusula inequívoca. Pregunta si el proveedor o algún proveedor de modelos usa prompts, datos de aplicaciones, código fuente o resultados para entrenar o mejorar modelos generales. Si la respuesta es no, incluye esa restricción en el DPA o en las condiciones de producto que prevalezcan y extiéndela a los subencargados. Si la respuesta depende de una configuración, registra su valor predeterminado, administrador, alcance y rastro de auditoría.

El lenguaje de auditoría debe producir evidencia útil sin exigir acceso ilimitado a una instalación multiusuario. Los informes de aseguramiento independientes, resúmenes de pruebas de penetración, documentación de seguridad y respuestas escritas específicas pueden resolver las revisiones rutinarias. El comprador debe conservar una vía para obtener información adicional o realizar una auditoría proporcionada cuando esos materiales no resuelvan una preocupación relevante o un incidente ponga en duda el control.

Las CCT resuelven solo la parte contractual de una transferencia

Las Cláusulas Contractuales Tipo pueden aportar un instrumento de transferencia del artículo 46, pero firmarlas no demuestra que cada transferencia sea lícita o esté suficientemente protegida. Los compradores deben elegir el módulo correcto, completar los anexos, trazar las transferencias ulteriores y evaluar si las cláusulas funcionan en la práctica para el destino y los datos.

Las CCT de 2021 de la Comisión Europea emplean cuatro módulos según los roles de las partes. Un cliente típico del EEE que envía datos a un encargado situado fuera del EEE puede usar el módulo 2. Un encargado que envía datos a un subencargado en un tercer país puede necesitar el módulo 3. La elección correcta depende de quién exporta, quién importa y de si el importador ya está sujeto al RGPD para ese tratamiento, por lo que el asesor jurídico debe confirmar la cadena en lugar de pegar el módulo 2 en todos los contratos.

Los anexos completados son evidencia. Deben indicar las partes, interesados, categorías de datos, datos sensibles y garantías, frecuencia de transferencia, finalidad, conservación, autoridad de control competente, medidas técnicas y organizativas, y subencargados. Anexos en blanco, descripciones genéricas como «todos los datos de clientes» o la promesa de completar los detalles después separan las cláusulas del servicio real.

Las Recomendaciones 01/2020 del CEPD proponen un enfoque de seis pasos: conocer las transferencias, identificar el instrumento de transferencia, evaluar la legislación o práctica del tercer país, adoptar medidas complementarias cuando sean necesarias, completar los trámites formales y reevaluar en intervalos adecuados. Las recomendaciones también consideran transferencia el acceso remoto desde un tercer país. Este es el punto que los compradores pasan por alto cuando se concentran en el mapa de almacenamiento.

Una evaluación de impacto de transferencia debe ajustarse al servicio, en lugar de existir como un memorando jurídico genérico. Debe identificar al importador y el destino, los datos y personas afectadas, las vías de acceso, la legislación y prácticas aplicables, el riesgo de acceso gubernamental, las transferencias ulteriores y las medidas complementarias. Registra quién aprobó la evaluación y qué cambio exigiría una nueva revisión.

El cifrado solo ayuda si su diseño aborda el riesgo de acceso. Si un servicio debe descifrar prompts para un agente de soporte o un endpoint de modelo en el país de destino, el cifrado en tránsito no impide que ese destinatario lea los datos. Entre las medidas complementarias útiles pueden estar una segregación estricta de acceso, la seudonimización cuando el destinatario no tiene los datos de reidentificación, claves controladas por el cliente para cargas de trabajo que pueden permanecer opacas, registros de acceso y obligaciones contractuales de impugnación o notificación cuando sea lícito.

Una decisión de adecuación puede cambiar la vía jurídica de un destino, pero no elimina la necesidad de conocer el destino ni de controlar al encargado. Compras debe pedir al proveedor que indique qué transferencias se basan en una decisión de adecuación y cuáles en CCT u otro mecanismo. La respuesta debe figurar en el inventario de transferencias, no en una frase genérica que afirme que el proveedor «cumple el RGPD».

El acceso de soporte se trata donde está el operador

El acceso remoto de soporte desde fuera del EEE es una transferencia de datos cuando el operador puede ver datos personales, aunque la base de datos nunca salga de su región de la UE. Trata la ubicación del soporte, la autorización y la evidencia de sesión como controles de residencia. La ubicación de almacenamiento y la ubicación de acceso humano responden a preguntas distintas.

Pide al proveedor que separe el soporte rutinario del acceso privilegiado de ingeniería. Un agente de primer nivel puede necesitar metadatos de cuenta, pero no contenido de producción. Un ingeniero de guardia puede necesitar acceso temporal durante un incidente grave. El control debe dar a cada función la menor cantidad de datos y el menor tiempo necesarios, con una aprobación más estricta para el acceso a producción.

Compras debe exigir ubicaciones de acceso identificadas o una política regional exigible, no un «soporte global continuo» sin lista de países. El proveedor debe revelar los empleados, filiales y contratistas que pueden obtener acceso a producción, los países desde los que trabajan y el mecanismo de transferencia de cada ruta fuera del EEE. Si el acceso de emergencia puede anular una restricción de ubicación, documenta el detonante, el aprobador, la duración y el aviso al comprador.

Realiza una prueba de acceso de soporte antes de aprobar el servicio o durante una prueba de concepto:

1. Crea un tenant de prueba en la región contratada de la UE y añade un registro sintético único de cliente.
2. Abre un caso de soporte que normalmente requiera inspección, pero no pegues el registro en el ticket.
3. Pide al proveedor que muestre la solicitud de acceso, el aprobador, el país del operador, el rol concedido y la expiración.
4. Confirma que el registro de sesión recoge el tenant, la acción, la marca de tiempo y el motivo sin copiar contenido sensible en el registro.
5. Revoca el acceso y pide después evidencia de que el rol o la sesión ya no pueden acceder al tenant.

Usa datos sintéticos porque una prueba de diligencia no debe crear una nueva exposición. El resultado esperado es un pequeño paquete de evidencia: identificador de ticket, evento de aprobación, permiso temporal, entradas de auditoría de sesión y evento de revocación. Si el proveedor no puede realizar una prueba en vivo en un servicio compartido, pide una muestra reciente anonimizada y una demostración vinculada al control documentado.

El acceso de emergencia requiere el mismo nivel de escrutinio. Puede omitir la aprobación normal para restablecer el servicio, pero nunca debe omitir la identidad, el registro, la expiración y la revisión posterior. Pregunta cómo evita el proveedor que el personal use roles de emergencia para depuración ordinaria y cómo se entera el comprador de que ocurrió ese acceso.

No exijas grabación de pantalla de forma predeterminada. Las grabaciones pueden crear otra copia rica de datos personales y credenciales. Los eventos de auditoría estructurados suelen aportar mejor evidencia con menos exposición: quién accedió a qué tenant, desde qué país, con qué ticket, usando qué rol, durante cuánto tiempo y qué categorías de acciones realizó.

La evidencia debe resistir cambios e incidentes

Compras debe recopilar evidencia con responsable, fecha, alcance y detonante de actualización. Una respuesta pulida durante la revisión comercial queda desfasada cuando el proveedor añade un proveedor de modelos, traslada su equipo de soporte, cambia el diseño de copias de seguridad o lanza una nueva región. Gestionar la evidencia forma parte del control, no es trabajo de archivo posterior a la decisión.

Usa una matriz de controles y evidencias en el registro de aprobación. Da a cada entrada cuatro campos: la afirmación de control, la evidencia contractual, la evidencia técnica y el detonante de actualización.

1. Para las regiones aprobadas de espacio de trabajo y entorno de ejecución, conserva el formulario de pedido y el anexo de ubicación junto al registro de región del tenant y el mapa de flujo de datos. Actualízalos después de un cambio de región o arquitectura.
2. Para las ubicaciones de copias de seguridad, combina el calendario de copias y eliminación con un registro de prueba de restauración. Actualízalos después de un cambio de proveedor de copias o de recuperación ante desastres.
3. Para la cadena de subencargados aprobada, combina la cláusula de autorización del DPA con un registro conciliado con la arquitectura. Revísalo después de un aviso de alta o sustitución.
4. Para las transferencias a terceros países, combina las CCT o una referencia de adecuación con el inventario y la evaluación de transferencias. Revísalos después de un cambio de destino, legislación o acceso.
5. Para la ubicación del soporte, combina el anexo de acceso de soporte con los registros de aprobación, sesión y revocación. Actualízalos después de un cambio de país de soporte o de rol.

Asigna cada fila a una persona de ambas partes. El responsable del proveedor responde a cambios y solicitudes de evidencia. El responsable del comprador decide si un aviso necesita revisión de privacidad, seguridad, ingeniería o asesoramiento jurídico. Un buzón compartido sin revisor responsable no es un control operativo.

Define umbrales de notificación. Un nuevo subencargado que solo envía correos de estado del servicio puede requerir una revisión más ligera que un proveedor de modelos que recibe prompts. Un nuevo país para copias de seguridad, una ampliación de ubicaciones de soporte, un cambio en el uso para entrenamiento o una anulación de la región contratada deben detener los nuevos despliegues sensibles hasta que el comprador termine su evaluación.

La evidencia de incidentes debe mostrar si se mantuvo el límite de residencia. Exige que el proceso de incidentes del proveedor conserve la configuración regional relevante, los cambios administrativos, el acceso de soporte, los eventos de exportación y la participación de subencargados. El DPA debe fijar el deber de notificación y las condiciones de cooperación, mientras que el manual de incidentes debe identificar los registros que pueden responder dónde se almacenaron y visualizaron los datos afectados.

Las certificaciones pueden respaldar este expediente, pero no sustituyen las respuestas específicas del servicio. Un informe de aseguramiento puede probar la gestión de acceso y los controles de copias de seguridad sin decir nada sobre las regiones exactas adquiridas por un tenant. Relaciona el alcance y las excepciones del informe con la fila de control y cubre la brecha restante con evidencia contractual o del tenant.

Los requisitos deben generar respuestas comprobables

Redacta los requisitos de residencia de modo que un proveedor pueda responder sí, no o no aplicable y adjuntar un elemento identificado. Las preguntas amplias invitan a garantías amplias. «Describe tu enfoque respecto al RGPD» producirá varias páginas pulidas y casi ninguna evidencia de aprobación. Un requisito vinculado a datos, ubicación, comportamiento y prueba revela las brechas rápidamente.

Un requisito útil de alojamiento dice: «El proveedor almacenará y tratará el contenido de producción de clientes, los prompts, el código fuente generado y los registros de autenticación únicamente en los países enumerados en el Anexo A, salvo las transferencias enumeradas en el Anexo B». Los anexos importan tanto como la frase. El Anexo A define el límite aprobado. El Anexo B obliga a las partes a nombrar una excepción en vez de apoyarse en un derecho general oculto en otra parte.

Usa requisitos separados para controles separados. Las siguientes solicitudes funcionan bien en una RFP o anexo de seguridad:

• Enumera cada componente de servicio que no hereda la región elegida por el tenant, con sus datos, país, finalidad y conservación.
• Identifica todos los países desde los que el personal puede acceder al contenido de producción y adjunta la norma de aprobación y registro de ese acceso.
• Indica cada ubicación de copias de seguridad y recuperación ante desastres, periodo de conservación, evento de eliminación y destino de restauración permitido.
• Proporciona el registro actual de subencargados e indica qué entidades pueden recibir prompts, código fuente, registros de aplicaciones o archivos adjuntos de soporte.
• Relaciona cada transferencia a un tercer país con una decisión de adecuación, un módulo de CCT u otro mecanismo utilizado, e indica el responsable de la evaluación y la fecha de revisión.

Evita formulaciones absolutas que la arquitectura no pueda cumplir de forma razonable. «Ningún dato sale nunca de Alemania» puede prohibir accidentalmente el envío de un correo al propio administrador del comprador que está en el extranjero o la lectura de la aplicación por un usuario autorizado mientras viaja. Define si el requisito cubre el almacenamiento y tratamiento controlados por el proveedor, el tránsito de red, el acceso de los usuarios del comprador o todos ellos. La precisión refuerza la protección porque todos pueden identificar una infracción.

Separa los controles obligatorios de las preferencias antes de emitir el cuestionario. Si el acceso de soporte solo desde la UE es obligatorio, indícalo y rechaza un diseño incompatible. Si es una preferencia, evalúa una ruta documentada de tercer país con su instrumento de transferencia y garantías. Los proveedores dan respuestas poco fiables cuando los compradores etiquetan todas las preguntas como «críticas» y luego renuncian a la mitad durante la negociación comercial.

Exige que la evidencia esté actualizada. Los diagramas de arquitectura y registros de subencargados deben llevar una fecha de vigencia. Los anexos contractuales deben identificar la versión del servicio u oferta que cubren. Las muestras operativas deben proceder del control actual, no de un sistema retirado. Establece una fecha de vencimiento o una revisión basada en eventos para la evidencia que pueda cambiar, mientras los términos firmados permanentes siguen en el expediente hasta que se modifiquen.

Por último, deja claros los conflictos. El proveedor debe identificar cualquier respuesta que dependa de un nivel premium, una configuración opcional, una acción del cliente o una funcionalidad planificada. Compras puede entonces incluir el requisito previo en el pedido y entregarlo al responsable de implementación. Un control que depende de una configuración falla si nadie sabe quién debe activarla.

Evalúa la afirmación, no el lenguaje comercial

Un comprador puede evaluar la preparación para la residencia preguntando si cada ruta relevante de datos cuenta con las tres formas de prueba: una promesa vinculante, una descripción actual del sistema y evidencia específica del tenant o evidencia operativa reciente. La ausencia de una capa genera un seguimiento preciso en lugar de una discusión vaga sobre si el proveedor «cumple el RGPD».

Usa cuatro estados de decisión:

• Verificado: la evidencia coincide, cubre el servicio adquirido y cuenta con un proceso de actualización.
• Aprobado condicionalmente: una brecha limitada tiene responsable, plazo y control compensatorio.
• Restringido: el servicio solo puede manejar datos que encajen en un caso de uso definido de menor riesgo.
• Rechazado: una ruta relevante de transferencia o acceso sigue siendo desconocida, no delimitada o está permitida contractualmente en contra del requisito del comprador.

Este enfoque también evita dos malos hábitos de compras. El primero es rechazar a cualquier proveedor global solo porque tiene personal fuera de Europa, aunque esas personas no puedan acceder al entorno del comprador. El segundo es aprobar un producto «alojado en la UE» sin comprobar el enrutamiento del modelo o el acceso de soporte. La presencia jurisdiccional aporta contexto. Los flujos reales de datos y los controles exigibles determinan la exposición.

Aplica la evaluación a la edición y configuración exactas que se van a adquirir. Los controles empresariales descritos en una presentación de seguridad quizá no existan en un nivel gratuito o de autoservicio. La elección de región puede aplicarse solo a la producción alojada, mientras que las vistas previas o el espacio de trabajo del creador siguen una ubicación predeterminada. Registra los requisitos previos, restricciones del plan y configuraciones en el formulario de pedido para que el diseño aprobado coincida con lo que los administradores pueden desplegar.

Koder.ai puede ejecutar aplicaciones sobre infraestructura AWS en distintos países, pero el comprador debe seguir exigiendo que el país elegido, los componentes cubiertos y las vías de acceso aparezcan en el paquete de evidencia. La capacidad del producto inicia la conversación; la evidencia de compras la cierra.

No aceptes una promesa de hoja de ruta para un control necesario antes de que los datos personales entren en el servicio. Una hoja de ruta puede respaldar una reevaluación futura. Hasta que la funcionalidad exista y el proveedor pueda obligarse a ella, describirla y demostrarla, restringe la carga de trabajo o elige otro diseño.

El registro de aprobación debe terminar con el riesgo residual, no con un veredicto comercial. Indica cualquier acceso transfronterizo permitido, la vía jurídica, los datos expuestos, las medidas complementarias y la persona que lo aceptó. Ese registro da a los equipos de privacidad algo que pueden defender y a los ingenieros un límite que realmente pueden operar.