Preguntas al equipo de plataforma dónde corre el modelo y te contestan con una región: «Frankfurt». Respiras. Esa misma noche, para resolver el caso de un cliente, el agente consulta un CRM en la nube de un tercero, llama a una herramienta de búsqueda externa, pasa el texto por un servidor MCP que alguien instaló en marzo y, cuando el proveedor principal se satura, reintenta contra otro modelo en otra región. Frankfurt era un salto de cinco.
La tesis en una línea: la soberanía del dato de un agente no la decide dónde corre el modelo; la decide cada salto de la cadena que ese agente recorre para hacer su trabajo. Un perímetro que solo mira el modelo es un candado en una puerta con cuatro ventanas abiertas.
Soberanía de datos con agentes de IA: la decide cada llamada, no el modelo
Un chatbot clásico tenía una frontera fácil de dibujar: el usuario escribe, el modelo contesta y el dato va y vuelve por un único sitio. Un agente rompe esa geometría porque actúa: lee en un sistema, escribe en otro, pide ayuda a una herramienta, guarda memoria. Cada una de esas acciones es una llamada de red, y cada llamada de red es una decisión sobre a dónde va el dato, quién lo procesa y cuánto tiempo lo conserva. «¿Dónde vive nuestro agente?» no tiene respuesta útil. La que sí la tiene es: «¿a dónde va cada byte de esta ejecución?».
Si la ejecución contiene datos personales, cada destino es, en protección de datos, un tratamiento con su proveedor, su contrato de encargado y, si sale del Espacio Económico Europeo, su base de transferencia. Un agente no cambia las reglas: multiplica los sitios donde hay que aplicarlas. Ya contamos en IA generativa y RGPD: lo que tu proveedor no te cuenta por qué la etiqueta «enterprise» no es una garantía; con agentes, el problema deja de ser un contrato y pasa a ser un recorrido.
Los cinco saltos de una cadena de agente y qué sale en cada uno
| Salto | Qué puede salir | Pregunta que decide |
|---|---|---|
| Modelo principal | El prompt completo: instrucciones, contexto recuperado y datos del caso | ¿En qué región se procesa y se conserva, y bajo qué contrato? |
| Herramientas y APIs | Los parámetros de cada llamada: nombres, importes, identificadores | ¿Qué campos recibe de verdad la herramienta y los necesita todos? |
| Servidores MCP y conectores | Lo que el servidor pida y lo que el agente le entregue, a veces a un tercero | ¿Quién lo opera, dónde corre y quién lo aprobó? |
| Modelo de respaldo | La misma petición reenviada a otro proveedor u otra región cuando falla el principal | ¿Tu política permite ese respaldo o se activa solo? |
| Memoria, trazas y embeddings | Copias del dato en vectores, registros y herramientas de observabilidad | ¿Quién ve las trazas, cuánto se conservan y dónde viven? |
MCP merece una línea aparte. Es el estándar que conecta un agente con herramientas y datos mediante servidores, y esos servidores pueden ser tuyos, de un proveedor o de un tercero que alguien instaló por comodidad (explicamos qué es MCP y por qué cambia los agentes de empresa). Un servidor remoto recibe lo que el agente le mande. Tratarlo como «un plugin» es tratar a un subencargado como una extensión del navegador.
Los dos saltos que más se escapan son el cuarto y el quinto, y por la misma razón: funcionan cuando no los ves. El modelo de respaldo es una red de seguridad útil: el principal devuelve un error, el enrutador reintenta contra el siguiente de la lista y el usuario no nota nada. Tampoco lo nota tu política de datos, que decía «solo región UE» y acaba de enviar el mismo prompt a otra. Las trazas son igual de silenciosas: la herramienta que te ayuda a depurar guarda, si no lo has configurado a propósito, una copia literal de cada conversación.
¿Y el marco legal de las transferencias? Tampoco es una constante
Parte de la respuesta a «¿puedo mandar esto a un proveedor estadounidense?» descansa en el Marco de Privacidad de Datos UE-EE. UU. El Tribunal General de la UE confirmó su validez el 3 de septiembre de 2025, al rechazar el recurso de Philippe Latombe, y Latombe recurrió ante el Tribunal de Justicia el 31 de octubre de 2025 (fuente: WilmerHale, diciembre de 2025). Ámbito: Derecho de la UE; importa para datos personales que salen del EEE hacia empresas estadounidenses certificadas y no se extrapola a otros regímenes.
Cómo auditar la soberanía de un agente sin equipo de plataforma
No hace falta un proyecto de seis meses. Hace falta una ejecución real y una hora:
- Coge una petición real, de las que llevan datos de cliente, y ejecútala con el registro de red o las trazas del agente activados.
- Apunta cada destino al que sale tráfico: dominio, proveedor y región si la conoces. Lo normal es que salgan más de los que esperabas.
- Marca los que llevan datos personales o confidenciales y, para cada uno, escribe tres cosas: contrato, región y plazo de conservación. Donde no sepas rellenar una, ese es tu hallazgo.
- Decide por salto: cortar, minimizar (enviar solo los campos necesarios), seudonimizar antes de salir o cambiar de proveedor.
- Deja el resultado como mapa vivo: una página con los destinos aprobados. Cualquier salto nuevo —una herramienta, un servidor MCP, un respaldo— entra en el mapa antes de entrar en producción.
Dos piezas lo hacen más fácil de lo que parece. La primera son los permisos de un agente de IA: un agente con identidad propia y alcance por tarea ya limita qué datos llegan a cada herramienta. La segunda es elegir qué modelo usar en un agente con la región y el contrato sobre la mesa y no solo la precisión. Y si tu respuesta a «¿lo alojamos nosotros?» es sí, lee antes cuándo compensa el self-host y qué resuelve de verdad: alojar el motor no cierra los otros cuatro saltos.
Cuando el mapa tiene más destinos de los que tu equipo puede revisar, es trabajo de gobierno del dato, y la parte que demuestra qué pasó en cada ejecución es la trazabilidad de decisiones de IA.
¿Cuándo no hace falta tanto?
Si tu agente solo toca información pública o no personal —uno que resume documentación abierta, por ejemplo— y no escribe en ningún sistema, el mapa de cinco saltos es excesivo: basta con saber qué proveedor lo ejecuta. Y alojarlo todo en casa no es la solución automática: un modelo en tu infraestructura que entrega el dato completo a una herramienta externa sigue teniendo la fuga; solo ha cambiado de salto. Todo esto es criterio operativo, no asesoramiento jurídico: la base legal de cada transferencia la valida tu DPO o tu asesor.
La frase para llevarse: no preguntes dónde corre el modelo, pregunta a dónde va cada llamada. La primera pregunta tiene una respuesta cómoda. La segunda tiene una lista, y esa lista es lo que tienes que poder enseñar.