La Ontología de Palantir explicada desde el gobierno del dato
Por qué la pieza central de Foundry se entiende mejor como una política ejecutable que como un modelo de datos
Respuesta rápida:
La Ontología de Palantir Foundry es un modelo del negocio hecho de objetos, enlaces, acciones y permisos. Vista desde el gobierno del dato, es algo más interesante que un modelo: es el sitio donde las reglas dejan de estar en un documento y pasan a ejecutarse.
Una definición común deja de ser un glosario y se convierte en un tipo de objeto. Una política de «quién puede modificar un pedido» deja de ser un procedimiento y se convierte en una acción con permisos. Y los controles más sensibles viajan con el dato a medida que este se deriva, en lugar de quedarse en la consulta que lo leyó.
Eso no hace el gobierno automático. Sigue haciendo falta que alguien del negocio decida cómo se llama cada cosa y quién puede cambiarla. Pero cambia dónde vive esa decisión: dentro de la plataforma, no en un Confluence que nadie abre.
Un glosario describe lo que debería pasar. Una ontología decide lo que puede pasar.
En la mayoría de las organizaciones con las que trabajamos, el gobierno del dato existe sobre el papel. Hay un glosario, hay una matriz de propiedad, hay una política de acceso. Y, a la vez, hay un informe que dice que los clientes activos son 41.200 y otro que dice 38.700, porque cada uno aplicó una definición distinta.
El problema no suele ser la falta de reglas, sino la distancia entre la regla y el sitio donde alguien hace su trabajo. Ya lo tratamos al hablar de gobierno del dato operativo frente al modelo de madurez. La Ontología es, en la práctica, una forma de cerrar esa distancia.
El gobierno que no se ejecuta en la operación es documentación.
Los cuatro elementos, leídos en clave de gobierno
La documentación de la Ontología los describe en términos de producto. Esta es su lectura desde la gobernanza:
Objetos: la definición común, en un sitio solo
Un objeto —un cliente, un pedido, una turbina— es la definición compartida hecha ejecutable. Si «cliente activo» es un tipo de objeto con sus propiedades, deja de haber dos informes con dos cifras: hay una definición y, si alguien no está de acuerdo, la discusión ocurre antes, sobre el modelo.
Enlaces: las relaciones que nadie documenta
El enlace entre un pedido y la planta que lo sirve, o entre un expediente y su titular, suele vivir en la cabeza de tres personas. Modelarlo lo convierte en algo consultable y auditable.
Acciones: la política, convertida en código
Aquí está la diferencia real con una capa semántica de analítica. Una acción define qué se puede hacer sobre un objeto y quién puede hacerlo, con permisos evaluados en el momento de ejecutarla. Aprobar un cambio de proveedor deja de ser un correo y pasa a ser una operación registrada.
Permisos: parte del modelo, no un anexo
El control de acceso no se diseña después. Forma parte de la definición del objeto y de la acción, que es como debería haber funcionado siempre el gobierno del dato.
Los controles que viajan con el dato
Para una empresa regulada, este es el punto que más conviene entender bien. La documentación de seguridad de Palantir separa dos familias de controles:
- 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 y filtrado por filas o columnas mediante vistas restringidas y políticas de seguridad sobre objetos y propiedades. Filtran lo que un usuario puede leer, pero no se extienden a lo que se exporta después.
La consecuencia práctica es una regla de diseño: un dato verdaderamente sensible se protege con controles obligatorios, no solo con una vista filtrada. La propia documentación del SDK de la Ontología lo recuerda al advertir que los controles de fila y columna no se extienden a lo que la aplicación hace después con los datos, y recomienda combinarlos con markings o clasificación.
Quién es dueño de un objeto
La pregunta que decide el éxito de una implantación no es técnica: ¿quién decide cómo se modela «pedido»?. Si la respuesta es «el equipo de la plataforma», el modelo acabará pareciéndose al esquema del ERP.
Lo que funciona en corporaciones grandes es el reparto que describimos en gobierno de datos federado: cada dominio es dueño de sus objetos y de sus acciones, y un grupo común decide solo los estándares mínimos, como la identificación de entidades compartidas o los criterios de clasificación.
Tres errores que vemos al modelar
- Copiar el esquema del origen. Si el objeto «proveedor» tiene los 74 campos de la tabla de SAP, nadie del negocio lo reconoce. El objeto debe reflejar cómo mira la organización, no cómo guarda el sistema.
- Modelar la empresa entera antes de entregar algo. La Ontología útil crece desde un proceso concreto. La que se diseña en pizarra durante seis meses llega tarde.
- Tratar el modelo como definitivo. Cuando entra el dato real aparecen campos vacíos y reglas que no se cumplían. El modelo se corrige, y las aplicaciones construidas encima heredan esa corrección.
Cómo empezar: un objeto, un proceso, una acción
En nuestras implantaciones el arranque que mejor funciona es deliberadamente pequeño: un proceso que cruce al menos dos sistemas, los objetos mínimos para sostenerlo, una sola acción que hoy se haga por correo y el control de acceso que esa acción exige. Con eso ya hay algo en producción, y la conversación sobre gobierno pasa a tener un caso real delante.
¿Tenéis un glosario que nadie usa y dos cifras para el mismo indicador?
En Galde modelamos ontologías de Palantir Foundry en corporaciones multinacionales de sectores regulados, partiendo de las definiciones que ya discute el negocio y convirtiéndolas en objetos, acciones y permisos que se ejecutan.
Cómo puede ayudar Galde con la Ontología
Desde nuestra consultoría e implementación de Palantir, diseñamos la Ontología con los dueños de cada dominio y la conectamos a los sistemas de origen sin duplicar la plataforma de datos existente.
Desde gobernanza de datos, traducimos vuestras políticas a controles de la plataforma: qué es obligatorio, qué es discrecional y qué debe quedar registrado.
Y desde data platforms, sostenemos las tuberías que alimentan esos objetos y las alertas que avisan cuando dejan de ser fiables.
Conclusión
La Ontología es la razón por la que Palantir se explica mal como plataforma de datos y bien como plataforma de operación. Para un responsable de gobierno del dato, su valor no está en el modelado, sino en que las definiciones, las políticas y los permisos dejan de vivir en documentos y pasan a ejecutarse donde la gente trabaja. A cambio exige lo de siempre: que alguien del negocio se haga dueño de cada objeto.
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
¿En qué se diferencia la Ontología de una capa semántica de BI?
Una capa semántica permite consultar con definiciones compartidas. La Ontología añade acciones y permisos: además de leer, permite ejecutar operaciones sobre los sistemas con trazabilidad de quién hizo qué y bajo qué condiciones.
¿La Ontología sustituye a nuestro catálogo de datos?
No necesariamente. El catálogo sigue sirviendo para descubrir y documentar activos de toda la organización. La Ontología es donde se ejecutan las definiciones y las políticas del proceso que se ha modelado.
¿Qué controles protegen de verdad un dato sensible en Foundry?
Los controles obligatorios, como los markings y el control de acceso por clasificación, porque acompañan al dato cuando se deriva. El filtrado por filas y columnas limita lo que se lee, pero no viaja con lo que se exporta.
¿Quién debería ser dueño de cada objeto de la Ontología?
El dominio de negocio que genera o gestiona esa información, no el equipo de la plataforma. Un grupo común define solo los estándares mínimos compartidos entre dominios.
¿Cuántos objetos hacen falta para empezar?
Los mínimos para sostener un proceso concreto, que suelen ser menos de diez. Modelar la organización completa antes de entregar algo es el error más frecuente y el más caro.
