IA con datos que no salen de Europa: RAG en infraestructura europea

Cuando una empresa empieza a consultar sus documentos con un asistente de IA, alguien acaba preguntando adónde van esos documentos. Suele ser el departamento legal o un cliente que está rellenando el cuestionario de proveedores, y la pregunta casi siempre llega cuando el prototipo ya funciona. Nos lo preguntan a menudo en conversaciones sobre desarrollo de IA a medida, y para contestar hay que repasar varios proveedores.

Si el requisito es que ningún dato salga de Europa, hoy se puede cumplir con modelos abiertos servidos en Europa y la misma arquitectura RAG que usaríamos en cualquier otro sitio. Tiene un coste en comodidad y en trabajo de operación, y hay proyectos en los que no compensa pagarlo.

RAG (generación aumentada por recuperación) significa que, antes de responder, el sistema busca en tus documentos los fragmentos que tienen que ver con la pregunta y se los pasa al modelo junto a ella, de modo que la respuesta sale de tus fuentes y puede citarlas. Para encontrar fragmentos por su significado aunque no compartan palabras, cada trozo de texto se convierte en un embedding, una lista de números que representa de qué trata Contamos el proceso completo y sus límites en el artículo sobre RAG corporativo con la documentación de tu empresa.

• El servidor donde corre la aplicación y la base de datos donde se guardan los documentos, sus fragmentos y los embeddings.

• El modelo de embeddings. Por él pasa cada documento que indexas y cada pregunta que hace un usuario. Se configura al principio del proyecto y es fácil no volver a revisar dónde se ejecuta.

• El modelo que genera las respuestas. En cada consulta, la pregunta y los fragmentos recuperados viajan al sitio donde se hace la inferencia.

• Las copias de seguridad. En algunos servicios, dónde se guardan es un ajuste distinto de la región de la base de datos.

• Los registros y la monitorización. Los registros de la aplicación suelen incluir la pregunta del usuario tal cual, y la herramienta de monitorización puede ser de otra empresa.

• El correo transaccional y los pagos, que manejan nombres, direcciones de correo y facturas.

Al llevar Softime, nuestra herramienta de control de horas, a un proveedor europeo, vimos que la pasarela de pago tenía su entidad europea en Dublín pero pertenecía a un grupo estadounidense, así que la cambiamos por una neerlandesa. [CONFIRMAR: estado de la migración de Softime y si se puede mencionar antes del lanzamiento]

Para el RGPD, cada uno de estos proveedores es un encargado o un subencargado del tratamiento, con su contrato y su ubicación. Si uno solo está fuera de Europa, ya no se puede decir que los datos no salen de Europa.

También importa la ley a la que responde el proveedor. Una empresa estadounidense con un centro de datos en Fráncfort guarda tus datos en Fráncfort, pero la CLOUD Act de EE. UU. permite a sus autoridades pedir datos a empresas bajo su jurisdicción con independencia de dónde estén almacenados (Departamento de Justicia de EE. UU.). Cómo te afecta depende del tipo de datos que manejes, y es una pregunta para tu equipo legal y para cada proveedor: si puede recibir requerimientos de autoridades de fuera de la UE y qué haría con ellos. 

En septiembre reconstruimos nuestra infraestructura habitual en Scaleway, un proveedor de nube francés, y la escribimos entera en Terraform. Terraform describe la infraestructura como código: la misma receta da el mismo entorno, así que se puede destruir y volver a crear sin ir pulsando botones en una consola, y el siguiente proyecto parte de algo ya probado. La dividimos en recetas separadas para la infraestructura base, el despliegue de la aplicación y la monitorización, de forma que cada parte puede cambiar sin tocar las demás.

Todas las piezas están en la región de París.

• Una red privada con una base de datos PostgreSQL gestionada y cifrada a la que solo se llega desde dentro. El PostgreSQL gestionado de Scaleway admite pgvector, la extensión que usamos para guardar y buscar embeddings en nuestros proyectos de RAG, así que documentos, fragmentos y vectores viven en la misma base de datos.

• La aplicación en contenedores serverless, que escalan con el tráfico y no obligan a gestionar servidores.

• La monitorización con el servicio de métricas y registros del propio proveedor y paneles de Grafana, así que los datos de monitorización también se quedan en el mismo proveedor.

• Las credenciales tratadas de forma que nunca quedan escritas en los ficheros de estado de Terraform.

Para los modelos, las Generative APIs de Scaleway sirven modelos abiertos (Mistral, Llama, Qwen, Gemma y gpt-oss, entre otros) y 2 modelos de embeddings. El proveedor afirma que los aloja todos en un centro de datos de París y que no recoge, lee, reutiliza ni analiza tus prompts ni las respuestas generadas (Scaleway Generative APIs, consultado en octubre de 2026).

La base de datos con pgvector, la forma de trocear los documentos, la búsqueda semántica y las instrucciones que obligan al modelo a ceñirse a los fragmentos recuperados son las mismas que usaríamos en Google Cloud. Solo cambia el servicio al que se piden los embeddings y las respuestas.  Cuando montamos nuestro chatbot interno que consulta nuestros documentos en Google Cloud con Gemini, dejamos el modelo y el almacenamiento intercambiables, así que un cambio así no obliga a rehacer la aplicación.

La prueba de septiembre cubrió la infraestructura. Los contenedores que desplegamos eran aplicaciones de muestra, todavía sin un asistente RAG encima. Poco después llevamos Softime al mismo proveedor, y con eso ya tenemos una aplicación real funcionando allí.

Al principio los paneles de Grafana salían vacíos. Las métricas y los registros se recogían, pero las fuentes de datos no se habían sincronizado con Grafana y el panel de los contenedores no sabía de dónde leer. Forzamos la sincronización y añadimos a la receta de monitorización un paso que la repite cada vez que cambian las fuentes, para que no vuelva a pasar en el siguiente entorno.

Tampoco había reglas de alerta preconfiguradas para la base de datos ni para los contenedores, así que el sistema de alertas quedó activado y sin ninguna regla. Aquí hay que escribirlas y decidir a quién avisan, algo que en los proveedores grandes suele venir con valores por defecto razonables.

En general hay menos servicios gestionados, así que parte de lo que un proveedor grande te da hecho lo tiene que montar y mantener tu equipo mientras el sistema esté en marcha. El catálogo de modelos también es más corto: en una infraestructura solo europea no vas a encontrar los grandes modelos propietarios de los laboratorios estadounidenses. Para responder con tus propios documentos, un modelo abierto mediano suele bastar, pero yo lo probaría con tus documentos y tus preguntas reales antes de decidir, porque en algunos casos la diferencia con un modelo grande se nota.

Una infraestructura solo europea tiene sentido cuando un contrato o un cliente exige proveedores europeos, cuando los documentos llevan datos personales delicados (salud, recursos humanos, expedientes legales), cuando trabajas en un sector regulado o cuando «¿dónde están nuestros datos?» se repite en tus ventas y quieres una respuesta que quepa en una frase.

Cuesta más justificarla si los documentos no contienen datos personales, si un proveedor grande con región europea y un buen contrato de encargado cubre todo lo que pide tu equipo legal, si necesitas el mejor modelo disponible para una tarea exigente o si no hay nadie para operar las piezas de más. En esos casos nos iríamos a la región europea del proveedor grande y dedicaríamos el esfuerzo a los permisos, a la evaluación y a dejar por escrito qué proveedor ve qué.

También hay un término medio: aplicación, base de datos y embeddings en Europa, y el modelo de generación a través de un proveedor que procese en una región europea, con esa decisión documentada y explicada a quien pregunte. En muchos proyectos con esto es suficiente.

El RGPD no obliga a que los datos personales se queden en Europa. Pide una base jurídica para el tratamiento, un contrato con cada encargado que fije qué puede hacer con los datos y cuándo puede recurrir a subencargados (artículo 28 del RGPD) y, si los datos salen del Espacio Económico Europeo, un mecanismo de transferencia válido según el capítulo V. Con toda la cadena en Europa te ahorras el análisis de transferencias internacionales; los contratos, la base jurídica y los permisos de acceso hay que revisarlos igual.  

El AI Act regula qué hace un sistema de IA y cómo se usa, y deja al RGPD la cuestión de dónde están los datos. Las obligaciones de transparencia del artículo 50, como avisar de que se está hablando con una IA, se aplican desde el 2 de agosto de 2026. Las de los sistemas de alto riesgo del anexo III se aplazaron al 2 de diciembre de 2027 con el Reglamento (UE) 2026/1744 (cronología de FPF). Un asistente que responde con documentación interna no suele ser de alto riesgo. Repasamos las fechas en qué exige ya el artículo 50 del AI Act y qué llega en diciembre, y la parte de trazabilidad en gobernanza de IA sin cajas negras.

En nuestros proyectos de IA a medida repasamos contigo la cadena, proveedor a proveedor, y te decimos si te compensa una infraestructura solo europea. cuéntanos tu caso.