Palantir y soberanía del dato en Europa: qué decide el cliente
Una lectura técnica de un debate que suele plantearse en términos políticos
Respuesta rápida:
La soberanía de un despliegue de Palantir no se resuelve preguntando de dónde es el proveedor, sino respondiendo a cuatro preguntas concretas: dónde se ejecuta la plataforma, quién controla el acceso al dato, dónde se ejecutan los modelos y cómo se sale si un día hay que salir.
Las tres primeras tienen respuesta documentada. Apollo permite desplegar en la nube, en la nube del cliente o en un entorno aislado sin salida a internet; los controles obligatorios viajan con el dato; y AIP admite modelos autoalojados en la infraestructura del cliente.
La cuarta, la salida, es la que casi nadie negocia a tiempo, y es la que más determina la dependencia real. Conviene diseñarla el primer día, no el último.
Ejecutar en una región europea no es soberanía. Es una casilla marcada en un contrato.
Durante 2026 el debate europeo sobre Palantir se ha vuelto muy visible. La agencia de inteligencia interior francesa anunció en junio que sustituiría sus herramientas por las de un proveedor nacional; Francia y Alemania firmaron en julio una declaración para construir una infraestructura digital europea soberana; y en España circuló la versión de un veto que el ministro responsable desmintió públicamente.
Ese contexto es real y conviene conocerlo. Pero un comité de dirección que evalúa la plataforma no puede decidir con titulares: necesita saber qué decisiones quedan de su lado.
La dependencia no la crea el país del proveedor, sino el diseño del despliegue y el contrato.
Dónde se ejecuta
Palantir describe una arquitectura en la que Apollo gestiona la infraestructura que aloja Foundry y AIP, y orquesta actualizaciones sin interrupción en entornos muy distintos. En la práctica, eso abre tres escenarios:
- Servicio gestionado, con la región elegida por el cliente.
- Despliegue en la infraestructura del cliente, en su propia cuenta de nube.
- Entorno local o aislado, sin conexión a internet, que es lo que hace viable la plataforma en defensa y en parte del sector público.
La pregunta que conviene hacer al proveedor no es «¿tenéis región europea?», sino quién administra el entorno, con qué accesos y bajo qué procedimiento de cambio.
Quién controla el acceso al dato
Aquí la plataforma ofrece un modelo más fuerte que la media del mercado, y merece entenderse bien. Según la documentación de seguridad, los controles obligatorios —markings, control de acceso por clasificación y organizaciones— viajan con cada unidad de dato cuando esta se deriva, apoyados en la procedencia y el linaje. Los controles discrecionales, en cambio, filtran lo que se lee pero no acompañan a lo exportado.
Para una multinacional con filiales en varios países esto tiene una aplicación inmediata: la separación entre filiales o entre jurisdicciones se modela con controles obligatorios, no con vistas filtradas.
Dónde se ejecutan los modelos
En la capa de IA la soberanía se juega en otro sitio: qué modelo procesa el dato y dónde. AIP contempla autoalojar modelos abiertos o propios en la infraestructura del cliente, incluidos entornos aislados, además del catálogo gestionado y la conexión de modelos propios por servicio externo.
La decisión práctica, en un despliegue europeo, suele ser mixta: modelos autoalojados para los flujos con dato personal o sensible, y catálogo gestionado para el resto, con la trazabilidad de qué aplicación usa qué modelo.
RGPD y Reglamento de IA: lo que no resuelve la plataforma
Conviene separar dos planos que se mezclan a menudo:
- Lo que aporta la plataforma: controles de acceso, cifrado, registro de auditoría y linaje, que son insumos directos para demostrar cumplimiento.
- Lo que sigue siendo vuestro: la base jurídica del tratamiento, el análisis de riesgos, la evaluación de impacto cuando procede, la minimización del dato y la clasificación del caso de uso conforme al Reglamento de IA europeo, que depende del uso y no del producto.
Dicho claro: ninguna plataforma os hace cumplidores. Os da las herramientas y las evidencias. Lo tratamos también en gobernanza de la IA generativa.
La pregunta incómoda: cómo se sale
Es la parte que más condiciona la dependencia y la que menos se negocia. Tres frentes concretos:
- Los datos. Deben poder salir en formatos abiertos, y conviene probar la extracción antes de firmar, no después.
- La lógica. Las transformaciones y las funciones son activos vuestros: mantenedlas en repositorios que podáis llevaros.
- El modelo de negocio. Los objetos, enlaces y acciones son accesibles por API y por el SDK de la Ontología, lo que permite reconstruir el modelo fuera. Lo que no se exporta sin trabajo son las aplicaciones construidas dentro de la plataforma.
Nuestra recomendación: una prueba de salida anual, como se hace con la recuperación ante desastres. Si nunca se ha probado, la estrategia de salida no existe.
Cómo lo planteamos en un despliegue europeo
- Clasificar antes de modelar: qué dato no puede salir de qué jurisdicción.
- Elegir el escenario de despliegue por caso de uso, no para toda la empresa.
- Modelar la separación entre filiales con controles obligatorios.
- Decidir por flujo qué modelo se usa y dónde se ejecuta.
- Documentar la salida y probarla.
¿Tenéis que justificar ante un comité o ante un regulador dónde acaba vuestro dato?
En Galde desplegamos Palantir Foundry en corporaciones multinacionales europeas y en administraciones, donde la pregunta por la soberanía no es retórica. Diseñamos el despliegue, los controles y la estrategia de salida con esa exigencia desde el primer día.
Cómo puede ayudar Galde
Desde nuestra consultoría e implementación de Palantir, definimos el escenario de despliegue, la separación por jurisdicciones y la ejecución de modelos según la sensibilidad de cada flujo.
Desde gobernanza de datos, traducimos vuestras obligaciones regulatorias a clasificación, controles obligatorios y evidencias de auditoría.
Y desde data platforms, diseñamos la convivencia con vuestra plataforma actual y la vía de salida, para que la dependencia sea una decisión y no un accidente.
Conclusión
La soberanía no se compra con una región europea ni se pierde por el pasaporte del proveedor. Se decide en cuatro puntos: dónde se ejecuta la plataforma, quién controla el acceso, dónde se ejecutan los modelos y cómo se sale. Palantir documenta opciones sólidas en los tres primeros. El cuarto depende enteramente de vosotros, y por eso es el que conviene poner encima de la mesa antes de firmar.
Palantir®, Foundry® y AIP® son marcas de Palantir Technologies Inc. Galde no es partner oficial de Palantir ni está afiliada a la compañía; implantamos la plataforma para nuestros clientes. Este artículo no constituye asesoramiento jurídico.
Preguntas frecuentes
¿Se puede desplegar Palantir sin que el dato salga de Europa?
Sí. La plataforma admite despliegues en la región elegida, en la infraestructura del cliente o en entornos aislados sin conexión a internet. Lo que conviene concretar es quién administra ese entorno y con qué accesos.
¿Basta con elegir una región europea para cumplir el RGPD?
No. La ubicación es un elemento más. Siguen siendo vuestras la base jurídica, la minimización, la evaluación de impacto cuando proceda y la gestión de los accesos, incluidos los del propio proveedor.
¿Cómo se separan los datos entre filiales de distintos países?
Con controles obligatorios como los markings, el control de acceso por clasificación y las organizaciones, que acompañan al dato cuando se deriva. El filtrado por filas y columnas no viaja con lo que se exporta.
¿Es posible usar modelos de IA que no salgan de nuestra infraestructura?
Sí. La documentación describe el autoalojamiento de modelos abiertos o propios, incluidos entornos sin salida a internet, además del catálogo gestionado para los casos que lo admitan.
¿Qué debe incluir una estrategia de salida?
Exportación de datos en formatos abiertos, control de las transformaciones y funciones en repositorios propios, acceso al modelo por API o por el SDK de la Ontología, y una prueba real de extracción repetida periódicamente.
