Desarrollar sobre Palantir: OSDK, consola de desarrollo y MCP

Respuesta rápida:

No todo lo que se hace con Palantir se construye dentro de Palantir. El SDK de la Ontología permite que una aplicación vuestra —React, un servicio propio o una herramienta externa— lea y escriba sobre los mismos objetos y acciones, con un token limitado a lo autorizado y respetando los permisos del usuario.

Alrededor hay tres piezas más: la consola de desarrollo, desde la que se generan y gestionan esas aplicaciones; las APIs de plataforma, para datos, orquestación, conectividad y administración; y Palantir MCP, que conecta un IDE o un agente de programación con el contexto y las herramientas de la plataforma.

La regla que aplicamos: dentro, lo que se beneficia del modelo y los permisos; fuera, lo que es producto propio. Y en ambos casos, la lógica vive en repositorios vuestros.

La Ontología no obliga a usar sus pantallas. Obliga a respetar sus permisos.

En cuanto una implantación pasa del primer proceso, aparece la pregunta del equipo técnico: ¿tenemos que hacerlo todo con las herramientas de la plataforma? La respuesta corta es no. La respuesta útil es saber qué se gana y qué se pierde en cada frontera.

Construir fuera no es salirse del modelo. Es usarlo desde otro sitio.

El SDK de la Ontología

El SDK de la Ontología trata la plataforma como un backend: vuestra aplicación consulta objetos, sigue enlaces y ejecuta acciones con las mismas garantías que una pantalla construida dentro. Dos propiedades importan especialmente:

• Token con alcance: la aplicación solo accede a las entidades de la Ontología que se le han autorizado, además de los permisos propios del usuario.
• Controles de fila y columna: filtran lo que el usuario puede leer, pero la documentación advierte de que no se extienden a lo que la aplicación hace después con esos datos, y recomienda combinarlos con markings o clasificación. Es la misma distinción que explicamos en gobierno del dato en Foundry.

El SDK se distribuye por los gestores de paquetes habituales, de modo que el equipo trabaja con sus herramientas y su ciclo de vida.

La consola de desarrollo y las APIs

La consola de desarrollo es donde se crean las aplicaciones OSDK, se eligen las entidades que van a usar y se gestionan los clientes de autenticación. Junto a ella, la cadena de herramientas de desarrollo describe las APIs de plataforma para conjuntos de datos, sistema de archivos, administración, orquestación, conectividad y consultas SQL, además de los módulos de cómputo, que permiten traer vuestro propio código o un modelo en un contenedor y ejecutarlo dentro.

Esa última pieza es la que suele desbloquear los casos difíciles: un modelo propietario, una librería específica o un proceso que no se quiere reescribir.

Palantir MCP: cuando quien programa es un agente

Palantir documenta su propia implementación del Model Context Protocol, Palantir MCP, que da a un IDE o a un agente de programación dos cosas: contexto sobre vuestro repositorio y la arquitectura de la plataforma, y herramientas para explorar la Ontología, consultar documentación o actuar sobre proyectos.

Es la misma idea que el AI FDE dentro de la plataforma, que propone sus cambios en una rama o una revisión para que alguien los apruebe. Y ahí está la práctica que recomendamos a nuestros clientes: que el agente proponga y una persona revise, con el mismo flujo de ramas y revisiones que ya usáis para el código.

Dentro o fuera: cómo decidimos

• Dentro cuando el valor está en el modelo y los permisos: pantallas operativas para usuarios internos, flujos con acciones gobernadas, casos que cambiarán a menudo con el negocio.
• Fuera cuando es producto propio: una aplicación para clientes, una interfaz muy específica, o algo que debe vivir en vuestro ciclo de despliegue.
• Siempre fuera: el código fuente de transformaciones y funciones, versionado en vuestros repositorios. Es una de las prácticas que reducen la dependencia, como detallamos en cómo evitar la dependencia de Palantir.

Cuatro errores que vemos en equipos de desarrollo

• Reimplementar los permisos. Si la aplicación consulta con una identidad de servicio y filtra después, habéis creado un agujero.
• Copiar objetos a una base de datos propia «por rendimiento», y acabar con dos modelos que divergen.
• Esconder reglas en la interfaz, que después no se pueden reutilizar ni migrar.
• Dejar al agente aplicar cambios sin revisión, que es rápido hasta el día que no lo es.

Cómo puede ayudar Galde

Desde nuestra consultoría e implementación de Palantir, decidimos con vosotros la frontera entre lo que se construye dentro y lo que se construye fuera, y montamos ambas partes.

Desde data platforms, integramos esas aplicaciones con el resto de vuestra arquitectura y su ciclo de despliegue.

Y desde IA generativa, definimos cómo trabajan los agentes de programación en vuestro entorno: qué pueden proponer, quién revisa y qué queda registrado.

Conclusión

Desarrollar sobre Palantir no obliga a vivir dentro de sus pantallas. El SDK de la Ontología y las APIs permiten construir producto propio sobre el mismo modelo y los mismos permisos, y el MCP acerca ese trabajo a los agentes de programación que ya usan vuestros equipos. Lo que no cambia en ninguno de los dos caminos es la disciplina: permisos del usuario, código en vuestros repositorios y revisión humana antes de aplicar un cambio.

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.