Cómo evitar la dependencia de Palantir: portabilidad y estrategia de salida

Respuesta rápida:

Toda plataforma operativa genera dependencia, y Palantir no es una excepción. La pregunta útil no es cómo evitarla del todo —no se puede sin renunciar al valor—, sino cuánta dependencia estáis aceptando y a cambio de qué.

En la práctica, se lleva: los datos, exportables en formatos abiertos; la lógica, si mantenéis transformaciones y funciones en repositorios propios; y el modelo de negocio, accesible por API y por el SDK de la Ontología. Se rehace: las aplicaciones construidas dentro de la plataforma, las automatizaciones y el modelo de permisos equivalente.

Y hay una prueba que casi nadie hace: una extracción real, una vez al año. Si nunca se ha probado, la estrategia de salida no existe.

No se trata de no depender. Se trata de saber exactamente de qué dependéis.

En los comités donde se aprueba una plataforma así, la pregunta por la dependencia llega tarde y mal: se plantea como un argumento en contra, no como un requisito de diseño. El resultado es que nadie la convierte en tareas concretas, y tres años después la organización descubre que su modelo de negocio vive en un sitio del que no sabe cómo sacarlo.

Es exactamente el mismo problema que con un ERP, un almacén de datos o una nube. La diferencia está en tratarlo pronto.

Lo caro no es la dependencia. Es descubrirla el día que hace falta salir.

Qué se lleva y qué se rehace

Se lleva

• Los datos. Deben poder salir en formatos abiertos y con su estructura, no como un volcado ilegible.
• La lógica. Las transformaciones y funciones que escribís son vuestras si viven en repositorios que controláis.
• El modelo de negocio. Objetos, enlaces y acciones son accesibles mediante las APIs de la plataforma y el SDK de la Ontología, lo que permite reconstruir el modelo en otro sitio sin partir de cero.

Se rehace

• Las aplicaciones construidas dentro de la plataforma, porque su interfaz y su comportamiento son propios de ella.
• Las automatizaciones que disparan acciones según condiciones o calendarios.
• El modelo de permisos, que habría que reproducir con los mecanismos equivalentes de la plataforma destino, normalmente más débiles.

Ese reparto es la respuesta honesta a la pregunta del comité: se lleva el activo —dato, lógica y modelo— y se rehace la experiencia.

Cinco prácticas que reducen la dependencia desde el primer día

• Código en vuestros repositorios. Las transformaciones y funciones, versionadas fuera de la plataforma siempre que la plataforma lo permita.
• Documentar el modelo como contrato. Objetos, propiedades, enlaces y acciones descritos en un documento vivo, independiente de la herramienta.
• No esconder reglas de negocio en la interfaz. Si una regla vive solo en la configuración de una pantalla, no se puede llevar a ninguna parte.
• Mantener la fuente de la verdad fuera cuando no haya motivo para moverla. El acceso sin copia a vuestro lago o almacén reduce la superficie de salida, como comentamos en Palantir, Databricks o Snowflake.
• Usar interfaces documentadas. Lo que se construye contra la cadena de herramientas de desarrollo y el SDK es más portable que lo que se construye a mano dentro.

Qué negociar en el contrato

Cuatro cláusulas que conviene tratar antes de firmar, porque después pierden fuerza:

• Exportación: formato, alcance y plazo de una extracción completa a petición.
• Asistencia a la salida: obligación de colaborar en una transición y durante cuánto tiempo.
• Preaviso y renovación: plazos y condiciones de revisión de precio.
• Propiedad: dejar claro por escrito que el modelo, la lógica y los datos derivados son vuestros.

La prueba de salida anual

Lo que funciona, y casi nadie hace, es tratar la salida como se trata la recuperación ante desastres: una prueba real, una vez al año, con tres objetivos medibles.

• Extraer los datos de un dominio y verificar que se pueden leer y cargar en otro sitio.
• Reconstruir un objeto y una acción fuera de la plataforma, aunque sea a escala reducida.
• Cronometrar cuánto tardaría el equipo en rehacer una aplicación concreta.

Con esos tres números, el comité deja de discutir sobre dependencia en abstracto.

El contrapunto honesto

Reducir la dependencia tiene un coste. Si no usáis las aplicaciones de la plataforma ni sus automatizaciones, estaréis pagando por capacidades que no utilizáis y perdiendo justo la parte que justifica la compra, como explicamos en qué es Palantir. La estrategia sensata no es minimizar la dependencia a toda costa, sino concentrarla donde aporta y mantener portables el dato, la lógica y el modelo.

Cómo puede ayudar Galde

Desde nuestra consultoría e implementación de Palantir, definimos qué se construye dentro, qué se mantiene fuera y cómo se documenta el modelo para que sea portable.

Desde data platforms, mantenemos la fuente de la verdad y las tuberías en vuestra arquitectura cuando no hay razón para moverlas.

Y desde gobernanza de datos, dejamos por escrito la propiedad, la clasificación y el procedimiento de extracción que exige un auditor.

Conclusión

La dependencia de una plataforma operativa no se evita con una cláusula, sino con decisiones de diseño repetidas: el código en vuestros repositorios, el modelo documentado, las reglas fuera de la interfaz y una extracción que se prueba cada año. Con eso, la conversación sobre salir de Palantir deja de ser una discusión de principios y pasa a ser un plan con plazos. Que es justo lo que un comité necesita para decidir con tranquilidad.

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 ni contractual.