Gobierno del dato en Palantir Foundry: markings, linaje y calidad
Cómo se traducen vuestras políticas a controles que la plataforma ejecuta sola
Respuesta rápida:
En Foundry, el gobierno del dato no es un módulo aparte: son cuatro mecanismos que se aplican al modelar. Los controles obligatorios —markings, control por clasificación y organizaciones— que viajan con el dato cuando se deriva. Los controles discrecionales, que filtran lo que alguien lee pero no acompañan a una exportación. El linaje, que permite responder a «si cambio esto, ¿a quién afecta?». Y la vigilancia de la calidad, que avisa antes de que lo note el negocio.
La decisión importante no es técnica, sino de diseño: qué se protege con un control obligatorio y qué con uno discrecional. Confundirlos es el error que hemos visto costar más caro en despliegues regulados.
Y sigue habiendo una parte que la plataforma no resuelve: alguien tiene que decidir la clasificación, los dueños y los umbrales de calidad.
La plataforma ejecuta la política. Escribirla sigue siendo vuestro trabajo.
En una multinacional con filiales en varios países, la conversación de gobierno se repite en cada proyecto: qué datos pueden ver los equipos de otra filial, quién autoriza una excepción y cómo se demuestra ante un auditor. Normalmente esa conversación acaba en un documento y en una hoja de permisos que se desincroniza en tres meses.
Foundry cambia el sitio donde ocurre: los controles se declaran una vez sobre el dato y el modelo, y la plataforma los aplica en cada consulta, cada aplicación y cada agente.
Una política que hay que recordar aplicar no es una política. Es una intención.
Obligatorio o discrecional: la decisión que lo condiciona todo
La documentación de seguridad de Palantir distingue dos familias, y conviene tenerlas muy claras:
- Obligatorios: markings, control de acceso por clasificación y organizaciones. Se aplican a la unidad de dato y la acompañan cuando esta se deriva, apoyándose en la procedencia y el linaje de la plataforma.
- Discrecionales: roles sobre recursos —propietario, editor, lector— y filtrado por filas y columnas mediante vistas restringidas y políticas sobre objetos y propiedades. Determinan lo que se puede leer, pero no se extienden a lo que se exporta después.
La regla que aplicamos al diseñar: si el dato no puede aparecer en un fichero que alguien descargue, necesita un control obligatorio. La vista filtrada es excelente para adaptar la experiencia de trabajo, no para contener información sensible.
Organizaciones: cómo se separan las filiales
Las organizaciones son el mecanismo natural para separar entornos entre filiales o jurisdicciones. En nuestros despliegues, el patrón que funciona es combinar tres capas: la organización marca la pertenencia, el marking protege las categorías sensibles —datos personales, información financiera, secreto industrial— y los roles reparten el trabajo dentro de cada dominio.
Cuando esas tres capas se diseñan juntas, la pregunta «¿puede este usuario de la filial francesa ver el coste de la planta alemana?» tiene una respuesta verificable en lugar de una respuesta política.
Linaje: responder antes de romper nada
El linaje sostiene dos preguntas que en la mayoría de las organizaciones se contestan preguntando por el pasillo:
- Análisis de impacto: si cambio esta fuente o este objeto, ¿qué aplicaciones, informes y agentes dejan de funcionar?
- Causa raíz: este número que no cuadra, ¿de dónde viene?
Es el mismo problema que tratamos fuera de Palantir en linaje de datos en entornos multi-cloud, con una diferencia: aquí no hay que construirlo, viene con la plataforma, y además es lo que hace que los controles obligatorios se propaguen.
Calidad: avisar antes que el negocio
De poco sirve un objeto bien gobernado si sus datos llegan tarde o incompletos. La plataforma incluye vigilancia de la salud del dato y reglas de monitorización, documentadas en su sección de monitorización, con comprobaciones sobre las construcciones y alertas cuando algo se degrada.
Nuestra recomendación: definir para cada objeto crítico tres umbrales —frescura máxima, completitud mínima y volumen esperado— y que la alerta llegue al dueño del dominio, no al equipo de plataforma.
Quién decide qué
El gobierno se cae cuando la plataforma decide sola. El reparto que funciona es el que describimos en gobierno de datos federado: un grupo común define la clasificación y los estándares mínimos; cada dominio decide sus objetos, sus acciones y sus umbrales; y la plataforma solo ejecuta.
Lista de comprobación para un despliegue regulado
- ¿Está escrita la clasificación antes de modelar el primer objeto?
- ¿Qué categorías se protegen con controles obligatorios y cuáles con vistas?
- ¿Cómo se separan las filiales, y quién aprueba una excepción?
- ¿Cada objeto crítico tiene dueño, umbrales y destinatario de la alerta?
- ¿Sabéis reconstruir, para una acción concreta, quién la ejecutó y con qué dato?
¿Vuestro gobierno del dato vive en un documento y los permisos en una hoja de cálculo?
En Galde implantamos Palantir Foundry en corporaciones multinacionales de sectores regulados y en administraciones, donde el gobierno no es un adorno: traducimos vuestras políticas a controles que la plataforma aplica en cada consulta.
Cómo puede ayudar Galde
Desde nuestra consultoría e implementación de Palantir, diseñamos la clasificación, la separación entre filiales y los controles obligatorios antes de modelar, que es cuando cuesta barato.
Desde gobernanza de datos, definimos dueños, umbrales de calidad y procedimiento de excepciones, y los dejamos documentados donde se usan.
Y desde data platforms, conectamos las fuentes y montamos las alertas que sostienen esos umbrales sin intervención manual.
Conclusión
Foundry no os da un gobierno del dato hecho: os da un sitio donde el gobierno se ejecuta. La diferencia entre un despliegue que pasa una auditoría y otro que no está en tres decisiones tomadas al principio: qué se protege con controles obligatorios, cómo se separan las filiales y quién recibe la alerta cuando la calidad cae. Nada de eso es un módulo que se activa; es diseño.
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.
Preguntas frecuentes
¿Qué diferencia hay entre un marking y una vista restringida?
El marking es un control obligatorio: acompaña al dato cuando este se deriva o se copia. La vista restringida filtra lo que un usuario lee, pero ese filtro no viaja con lo que después se exporta.
¿Cómo se separan los datos entre filiales de distintos países?
Con organizaciones para la pertenencia, markings o control por clasificación para las categorías sensibles y roles para el trabajo diario dentro de cada dominio. Las tres capas se diseñan juntas.
¿El linaje de Foundry sirve para análisis de impacto?
Sí. Permite ver qué depende de una fuente o de un objeto antes de cambiarlo, y rastrear el origen de un dato que no cuadra. Además es lo que hace posible que los controles obligatorios se propaguen.
¿Cómo se vigila la calidad de los datos?
Con comprobaciones y reglas de monitorización sobre las construcciones y los conjuntos de datos. Lo útil es fijar por objeto crítico umbrales de frescura, completitud y volumen, y dirigir la alerta al dueño del dominio.
¿Hace falta un equipo de gobierno dedicado?
Hace falta un grupo pequeño que fije la clasificación y los estándares mínimos, y dueños en cada dominio que decidan sobre sus objetos. Un equipo central que decida por todos se convierte en el cuello de botella.
