Resumen

  • La afirmación técnica duradera de Palantir no es que sus modelos sean inherentemente mejores que los demás. Es que una ontología puede unir datos, lógica, permisos y acciones de manera suficientemente estrecha para que organizaciones delicadas conviertan hechos operativos confusos en decisiones repetibles.
  • La evidencia respalda un punto de inflexión real del negocio: Palantir reportó ingresos del primer trimestre de 2026 de 1.633 mil millones de dólares, un crecimiento interanual del 85 por ciento, y una rápida expansión comercial en EE. UU. Estas cifras son resultados financieros del proveedor, no pruebas de que cada implementación haya superado sus costos de limpieza de datos, auditoría y adopción.
  • Los límites del producto son importantes. Palantir suministra Foundry, Gotham, AIP, herramientas de ontología, aplicaciones de flujo de trabajo y servicios de implementación sobre el terreno; los clientes siguen siendo dueños de los datos, las decisiones políticas, la autoridad legal, el riesgo de adquisición, los procedimientos operativos y muchos de los modelos o sistemas que se conectan.
  • La cuestión sin resolver es el mantenimiento. Palantir gana si sus clientes pueden mantener ontologías, controles de acceso, registros de acciones, evaluaciones y aprobaciones humanas actualizadas a medida que cambian las organizaciones, los modelos y los flujos de trabajo. Pierde valor cuando las implementaciones se vuelven intensivas en servicios, políticamente restringidas, difíciles de abandonar o incapaces de demostrar que las decisiones más rápidas fueron mejores decisiones.

La promesa operativa es una acción gobernada, no una respuesta más inteligente

La historia de producto más importante de Palantir no es la de un chatbot. Un chatbot puede responder una pregunta y aún así dejar a la organización incapaz de actuar. Un hospital podría preguntar qué quirófanos pueden utilizarse la próxima semana, un fabricante podría preguntar qué escasez de piezas detendrá una línea de montaje, un personal militar podría preguntar qué recursos pueden moverse sin crear una nueva vulnerabilidad, y un banco podría preguntar qué revisión de cliente necesita escalar. En cada caso, la parte costosa no es solo clasificar opciones. La parte costosa es saber qué datos son autorizados, qué personas están autorizadas a verlos, qué supuestos están vigentes, qué sistema posterior se tocará y qué registro sobrevivirá cuando la decisión se revise más tarde.

Por eso la pregunta asignada sobre Palantir debe comenzar con la ontología. En la propiadescripción general de la arquitectura AIPde Palantir, la ontología se describe como la capa que integra datos, lógica, acción y seguridad en una representación unificada de la toma de decisiones empresariales. La misma página de arquitectura enfatiza la observabilidad sobre los flujos de trabajo impulsados por IA, incluyendo la monitorización de los flujos de datos que alimentan la ontología, el registro de las acciones realizadas por usuarios humanos o agentes de IA, el rastreo de ejecuciones encadenadas de flujos de trabajo y el seguimiento del uso de recursos. La afirmación práctica es que la IA operativa debe residir dentro de un modelo operativo gobernado, no junto a él.

Es fácil perder esta distinción en el mercado actual de la IA. Los proveedores de modelos pueden mejorar el razonamiento, las ventanas de contexto, la entrada multimodal y el uso de herramientas sin resolver el problema de autoridad interna del cliente. Los proveedores de la nube pueden ofrecer sólidos almacenes de datos, búsqueda vectorial, orquestación de flujos de trabajo y servicios de alojamiento de modelos sin garantizar que una acción operativa particular esté autorizada en el lenguaje del negocio. Los integradores de sistemas pueden unir flujos de datos y aplicaciones, pero el resultado puede convertirse en un proyecto local en lugar de una capa institucional reutilizable. La apuesta de Palantir es que muchas grandes organizaciones desean una capa con criterio que mapee su mundo en objetos, relaciones, aplicaciones y acciones, y luego mantenga ese mapa lo suficientemente cerca de las operaciones en vivo para ser útil.

El argumento es persuasivo donde el trabajo es repetido, costoso y de altas consecuencias. Un simple panel puede mostrar envíos tardíos. No puede, por sí mismo, decidir quién puede cambiar la prioridad de un envío, si una pieza sustituta está aprobada, si una promesa contractual hace que un cliente sea más urgente que otro, o por qué un gerente anuló una recomendación automatizada. El modelo de ontología y acción de Palantir está diseñado para ese terreno más pesado. También es donde reside el riesgo de la empresa, porque cuanto más afirme una plataforma codificar significado y autoridad, más daño pueden causar la deriva de la ontología, los permisos obsoletos y el mapeo deficiente de fuentes.

Lo que es Palantir, y lo que no es

El límite de la empresa importa porque a menudo se habla de Palantir como si fuera sinónimo de las misiones que ejecutan sus clientes. Eso es demasiado amplio. Palantir vende y da soporte a plataformas de software y servicios de implementación: Foundry para integración de datos empresariales y aplicaciones, Gotham para flujos de trabajo de defensa e inteligencia, AIP para flujos de trabajo habilitados por IA, y un conjunto más amplio de herramientas de ontología, acción, evaluación, construcción de aplicaciones e integración. También proporciona mano de obra de ingeniería e implementación sobre el terreno. No es automáticamente dueña de los datos subyacentes del cliente, la base legal de un programa gubernamental, los proveedores de modelos conectados a AIP, la infraestructura de nube bajo cada implementación, o la decisión operativa que un cliente toma dentro del sistema.

La Plataforma de Datos Federados del NHS ilustra el límite. Elexplicador del contratodel NHS England dice que un consorcio liderado por Palantir recibió el contrato en noviembre de 2023, con financiación para hasta 240 organizaciones del NHS durante un posible período de siete años. También afirma que Palantir es un procesador según la ley de protección de datos, que las organizaciones usuarias del NHS controlan el acceso a sus propias instancias de la plataforma, que la plataforma aplica controles de acceso basados en roles y propósitos, y que los datos personales en la FDP y el entorno de tecnología que mejora la privacidad se almacenan y procesan en centros de datos del Reino Unido. El explicador añade que Palantir no puede comercializar los datos del NHS ni utilizarlos para desarrollar nuevos productos de proveedor, como entrenar un modelo de IA con datos del NHS.

Esas declaraciones contractuales no determinan si el NHS debería seguir usando Palantir. Pero aclaran el marco analítico. Si el sistema ayuda a los pacientes a recibir atención más rápido, Palantir puede afirmar que su software contribuyó a un mejor flujo de trabajo operativo. Si el sistema enfrenta desconfianza pública, beneficios cuestionados, baja calidad de datos o una decisión política de no prorrogar el contrato, el entorno del cliente y las decisiones de gobernanza son parte del resultado. La misma separación se aplica en implementaciones comerciales y de defensa. El producto de Palantir puede hacer técnicamente posible un flujo de trabajo, pero el cliente sigue proporcionando la autoridad, la doctrina, la gobernanza de datos, el comportamiento del personal y la tolerancia institucional al resultado.

Ese límite funciona en ambos sentidos. Evita afirmaciones exageradas de que Palantir ha resuelto todo un problema de servicio público o militar simplemente instalando software. También evita descartar fácilmente a la empresa como un mero proveedor de paneles. El software está destinado a operar cerca del punto donde los datos fragmentados se convierten en una acción autorizada. Esa es una superficie de producto más trascendental que la analítica ordinaria, y requiere un estándar de evidencia más estricto.

La ontología es una palanca económica y una responsabilidad de mantenimiento

La ontología de Palantir es valiosa porque puede convertir una difícil integración local en una capa operativa reutilizable. En ladescripción general de tipos de acción de Foundry, una acción es una transacción que cambia las propiedades de los objetos, los enlaces o los efectos secundarios relacionados según una lógica definida por el usuario. El ejemplo es simple, pero el principio es amplio: un usuario autorizado debe poder realizar una acción empresarial en términos del objetivo empresarial en lugar de editar filas y campos desconectados. La documentación de Palantir dice que la ontología mapea conceptos con los datos reales de una organización y puede capturar decisiones del usuario como ediciones que fluyen de vuelta a las aplicaciones orientadas al usuario.

Esa es la palanca. Si una aerolínea, hospital, fábrica o comando militar puede definir un vocabulario de objetos común y exponer acciones gobernadas sobre él, las aplicaciones se vuelven más fáciles de reutilizar. Un planificador de mantenimiento, jefe de operaciones, analista y revisor de cumplimiento pueden trabajar desde la misma representación estructurada en lugar de conciliar hojas de cálculo, tickets y paneles locales. Se pueden adjuntar nuevas capacidades de IA a la misma capa de contexto. Por eso la ontología es central en el discurso comercial de Palantir: la plataforma no es solo un lugar para almacenar datos, sino un lugar para codificar el significado institucional.

También es la responsabilidad. El significado cambia. Los departamentos se reorganizan. Las cadenas de suministro cambian. Las vías clínicas cambian. La doctrina militar evoluciona. Los reguladores alteran las expectativas de informes. Un modelo que era útil en un flujo de trabajo se vuelve poco fiable en otro. Un campo que era seguro exponer a un equipo se vuelve sensible después de una fusión o cambio de política. Si la ontología no cambia con la institución, los usuarios la evitarán. Si cambia sin disciplina, los usuarios dejarán de confiar en ella. Por lo tanto, Palantir tiene que ganar el largo juego del mantenimiento, no solo la demostración inicial.

El modo de fallo no es dramático. Puede ser un mapeo obsoleto de un sistema fuente. Puede ser una propiedad que parece precisa pero que dos sitios rellenan de manera diferente. Puede ser un permiso que refleja la estructura del equipo del año pasado. Puede ser una acción de flujo de trabajo cuyo efecto secundario ya no es aceptado por un sistema externo. Puede ser un asistente de IA que recupera objetos que son técnicamente relevantes pero operativamente obsoletos. Meses después, la organización puede tener todavía una plataforma impresionante y una respuesta débil a la pregunta central: ¿por qué fue legítima esta acción?

Los permisos no son un envoltorio

La gestión de permisos es uno de los lugares donde la documentación pública de Palantir muestra por qué el producto es más que una interfaz de modelo. Ladescripción general de permisos de objetossepara los recursos de ontología, como tipos de objeto, tipos de enlace y tipos de acción, de los datos en sí, lo que significa que la capa de definición de recursos y las instancias reales de objetos tienen diferentes cuestiones de seguridad. La documentación depermisos de ontologíadice que los recursos de ontología se gestionan a través de proyectos, y que un usuario puede tener permiso para ver un tipo de objeto sin necesariamente tener permiso para ver los datos subyacentes del objeto. La misma página señala que ver objetos reales también requiere acceso a los datos a través de la configuración de seguridad del objeto.

La página degestión de seguridad de objetosva más allá, describiendo políticas de seguridad de objetos y propiedades que pueden establecer permisos de visualización en instancias de objetos y propiedades individuales, incluyendo controles a nivel de fila, columna y celda. También advierte que algunos valores de propiedad pueden referirse a recursos fuera de la ontología, como medios almacenados en un conjunto de medios, y que los permisos en esos recursos externos deben configurarse por separado. Esa advertencia es importante. Muestra el tipo de caso límite que puede derrotar una historia limpia de gobernanza: un usuario puede estar bloqueado de una propiedad pero aún así poder obtener un activo referenciado si el recurso de respaldo es más laxo.

Aquí es donde la fortaleza del producto de Palantir y la carga del cliente se encuentran. Los controles detallados son útiles solo si la organización sabe qué debe protegerse, mantiene actualizados los grupos de identidad, entiende dónde cambia el acceso el linaje de datos y audita las excepciones. Palantir puede proporcionar la maquinaria. No puede, por sí misma, decidir qué enfermero, analista, ingeniero, contratista, comandante, auditor o aplicación debe poder ver cada dato en cada circunstancia. Esa decisión pertenece al cliente y debe mantenerse a medida que la organización cambia.

Lo mismo se aplica en la capa de aplicación. La documentación depermisos de Workshopde Palantir dice que el permiso para abrir o editar un módulo es independiente del permiso para acceder a los datos, acciones o funciones dentro de ese módulo. Su documentación depermisos de tipo de accióndice que aplicar una acción depende de los tipos de objeto y enlace que se editan, la capacidad del usuario para ver los recursos editados y las fuentes de datos, y cualquier criterio de envío. Estos detalles importan porque las operaciones reales rara vez fallan en una sola capa. Un flujo de trabajo puede parecer disponible mientras la acción subyacente no lo está; un usuario puede editar un módulo sin poder ver los datos necesarios para usarlo; una persona puede estar autorizada a ver un registro pero no a realizar la acción que lo cambia.

La auditabilidad tiene que sobrevivir al trabajo normal

La documentación pública de auditoría de Palantir es inusualmente explícita sobre el compromiso práctico en los sistemas de auditoría. Ladescripción general de registros de auditoríadescribe los registros de auditoría como un registro completo de acciones en Foundry, pero también como un registro destilado donde demasiada verbosidad puede dificultar el razonamiento sobre los registros. Dice que los registros de auditoría responden quién realizó una acción, qué acción ocurrió, cuándo sucedió y dónde ocurrió, advirtiendo que los registros de auditoría pueden contener información sensible y puede ser necesario analizarlos en el propio sistema de monitorización de seguridad del cliente.

Ese encuadre es útil. Una plataforma que registra todo sin ayudar a los investigadores a razonar sobre ello puede aún así fallar una auditoría. La página decategorías de registros de auditoríade Palantir describe categorías que permiten a los analistas consultar acciones de alto nivel como carga de datos, exportación o intentos de autenticación sin rastrear cada nombre de evento específico del servicio. Esa abstracción es valiosa porque los nombres de los servicios cambian y aparecen nuevas funcionalidades. También es un recordatorio de que la auditabilidad es un objetivo de diseño, no un subproducto natural del uso de la IA.

El registro de acciones está más cerca del corazón operativo del producto. La documentación delregistro de accionesdice que los tipos de objeto de registro de acciones modelan los envíos como objetos de ontología para que puedan analizarse y mostrarse en herramientas conscientes de objetos. Una acción enviada puede producir un objeto de registro vinculado a todos los objetos editados y puede almacenar metadatos como identificadores de acción, versión del tipo de acción, marca de tiempo, ID de usuario, objetos editados y valores de parámetros. La página enmarca explícitamente la línea de tiempo en torno a las preguntas "¿qué cambió, quién y cuándo?"

Esas mecánicas son exactamente lo que una organización regulada necesita si una acción va a ser cuestionada más tarde. Sin embargo, la parte difícil no es la existencia de una función de registro. La parte difícil es asegurarse de que la acción en sí estaba bien definida, que se almacenó el contexto relevante, que se requirió la aprobación de los usuarios adecuados, que los datos de origen estaban actualizados, que el sistema posterior recibió el cambio previsto y que el rastro de auditoría sigue siendo interpretable después de que se revise el tipo de acción. Un registro de auditoría que dice que el usuario autorizado equivocado tomó una acción mal especificada no es un control exitoso. Es un registro limpio de un proceso débil.

AIP traslada el punto de fallo de la predicción al control de cambios

AIP le da a Palantir una forma de conectar modelos de lenguaje grandes y otras capacidades de IA a la capa de ontología y aplicación. Ladescripción general de AIPdice que AIP proporciona pistas de auditoría, explicaciones y evaluaciones para las decisiones de los modelos, con disponibilidad de funciones sujeta a diferencias entre clientes. La documentación deética y gobernanza de la IAenfatiza el soporte de decisiones basado en ontología, flujos de trabajo de supervisión humana, procesos de aprobación, bucles de retroalimentación, puntos de control y mecanismos de respaldo. Ladescripción general de AIP Evalspresenta las evaluaciones como un entorno de prueba para funciones de AIP Logic, funciones de chatbot y funciones creadas con código, diseñado para manejar la naturaleza no determinista de los LLM comparando las salidas con casos de prueba y versiones anteriores.

Esta es la dirección correcta para la IA operativa. La respuesta de un modelo no es lo suficientemente estable como para confiar en ella solo porque parecía plausible. Si el modelo recomendará acciones, producirá borradores, clasificará trabajos o llamará a herramientas, la organización necesita casos de prueba, funciones de evaluación, verificaciones de varianza, comparaciones de versiones, puntos de aprobación y comportamiento de reversión. La documentación de Palantir reconoce que los flujos de trabajo de IA en producción requieren estos controles.

Pero la existencia de AIP Evals no prueba que el flujo de trabajo de producción de un cliente sea fiable. Un conjunto de evaluaciones es tan bueno como sus casos de prueba y umbrales de fallo. Un paso de aprobación humana es tan fuerte como la experiencia, el tiempo y los incentivos del revisor. Un bucle de retroalimentación puede mejorar un flujo de trabajo o fijar un comportamiento local sesgado. Un mecanismo de respaldo puede preservar la agencia humana o convertirse en una vía de escape poco utilizada. Palantir puede proporcionar un entorno donde estos controles sean más fáciles de construir; la organización aún debe elegir y mantener los controles que coincidan con las consecuencias de la acción.

El mismo riesgo aparece en la recuperación y las conexiones de herramientas externas. La documentación delcontexto de recuperaciónde Palantir dice que los chatbots de AIP pueden incluir contexto respaldado por ontología, documentos y funciones que se ejecuta de manera determinista con cada nuevo mensaje del usuario. Su anuncio de documentación de mayo de 2026 paraOntology MCPdice que los agentes de IA externos pueden conectarse como clientes MCP para leer tipos de objeto, ejecutar tipos de acción predefinidos y ejecutar funciones de consulta dentro de los permisos configurados. Estas capacidades podrían hacer que los agentes de IA sean más útiles operativamente. También amplían la superficie de control. Si un agente externo puede ver tipos de objeto y ejecutar acciones predefinidas, el alcance de los permisos, las descripciones de herramientas, los requisitos de aprobación y la monitorización se convierten en parte de la historia de fiabilidad del producto.

En otras palabras, AIP no elimina el problema de la ontología. Aumenta la recompensa por resolverlo y eleva el costo de equivocarse.

La evidencia de clientes muestra por qué importa el denominador

La evidencia pública de clientes es lo suficientemente sólida para mostrar demanda, pero no para establecer el retorno de la inversión en todas las implementaciones. El anuncio delacuerdo de servicios empresarialesdel Ejército de los EE. UU. de julio de 2025 dice que el Ejército consolidó 75 contratos, incluidos 15 contratos principales y 60 contratos relacionados, en un solo acuerdo con un valor potencial que no excederá los 10 mil millones de dólares en hasta 10 años. El mismo anuncio afirma que esta cantidad es un valor potencial máximo, no una obligación o compromiso específico. Esa advertencia no es una nota al pie. Es central para evaluar la economía de Palantir. Un techo alto muestra un camino de adquisición y confianza institucional, pero el valor realizado depende de los pedidos, la adopción, la ejecución del contrato y el costo de la implementación.

La evidencia del Sistema Inteligente Maven apunta en la misma dirección. Elanuncio de contratodel Departamento de Defensa de mayo de 2024 dice que Palantir USG recibió un contrato de precio fijo firme de 480 millones de dólares para el prototipo del Sistema Inteligente Maven, con ubicaciones de trabajo y financiación determinadas por orden. Breaking Defense informó que el nuevo contrato estaba destinado a expandir el acceso a Maven de cientos de usuarios a miles y citó a Palantir describiendo la necesidad de integrar sistemas de datos y nuevas capacidades de IA. La línea más reveladora en ese informe no es la expansión de usuarios. Es la descripción del tedioso trabajo detrás de ello: obtener acceso a conjuntos de datos, limpiar errores y artefactos, reformatear datos y construir flujos de datos duraderos. Ese es el denominador. Cuanto más valiosa es la misión, más costosa se vuelve la base de datos.

DefenseScoop informó más tarde que los líderes del Pentágono aumentaron el techo del contrato Maven en 795 millones de dólares hasta casi 1.300 millones de dólares hasta 2029, citando la creciente demanda de los comandos combatientes, mientras señalaban preguntas sin respuesta sobre los planes de implementación y la expansión de usuarios. Para Palantir, esto es una evidencia comercialmente atractiva de la demanda de defensa. Para los evaluadores, también es un recordatorio de que el crecimiento en la capacidad de licencias y los techos de contrato no revela la calidad operativa de cada flujo de trabajo, la doctrina en torno a las decisiones asistidas por IA, o la carga de capacitación para los usuarios.

La atención médica es aún más sensible porque la confianza pública es parte del sistema operativo. El explicador del NHS England presenta la FDP como una plataforma gobernada con control de acceso local, procesamiento en el Reino Unido y mecanismos de revisión de contratos. The Guardian, en un informe de julio de 2026 sobre el escrutinio parlamentario, describió llamamientos multipartidistas para cancelar el contrato del NHS con Palantir, citando desconfianza pública y médica, beneficios cuestionados, preocupaciones de privacidad y la disponibilidad de alternativas. Palantir y los funcionarios del Reino Unido citaron beneficios operativos, incluyendo operaciones adicionales y reducción de retrasos, mientras que los críticos cuestionaron la evidencia y el ajuste institucional. Los hechos no se reducen a "el software funciona" o "el software falla". Muestran que la propuesta de valor de Palantir es inseparable de la legitimidad, la gobernanza de datos y la capacidad del cliente para demostrar beneficios de manera creíble.

La curva financiera es real, pero no equivale a prueba de resultados repetibles

El crecimiento de Palantir le da a la empresa margen para argumentar que el mercado está validando su modelo operativo. En sucomunicado de resultados del primer trimestre de 2026, Palantir reportó ingresos de 1.633 mil millones de dólares, un aumento del 85 por ciento interanual y del 16 por ciento trimestral. Los ingresos en EE. UU. crecieron un 104 por ciento interanual hasta 1.282 mil millones de dólares. Los ingresos comerciales en EE. UU. crecieron un 133 por ciento interanual hasta 595 millones de dólares, y los ingresos gubernamentales en EE. UU. crecieron un 84 por ciento interanual hasta 687 millones de dólares. La empresa también dijo que cerró 206 acuerdos de al menos 1 millón de dólares, 72 acuerdos de al menos 5 millones y 47 acuerdos de al menos 10 millones.

ElFormulario 10-Q del primer trimestre de 2026añade textura útil. Los ingresos gubernamentales fueron de 858 millones de dólares y los ingresos comerciales fueron de 774 millones de dólares para el trimestre, con ingresos totales un 85 por ciento superiores a los del primer trimestre de 2025. Palantir reportó un margen bruto del 87 por ciento para el trimestre, frente al 80 por ciento del año anterior, incluso cuando el costo de los ingresos aumentó en parte debido a los servicios de alojamiento en la nube de terceros. También reportó 8.000 millones de dólares en efectivo, equivalentes de efectivo y valores del Tesoro de EE.UU. a corto plazo al 31 de marzo de 2026, sin saldos de deuda pendientes, y 899 millones de dólares en flujo de caja operativo para el trimestre.

Estas son finanzas sólidas de empresa de software. No responden a la pregunta sobre la calidad de la implementación. Un alto margen bruto puede coexistir con altos costos de implementación del lado del cliente. El rápido crecimiento comercial en EE. UU. puede coexistir con resultados desiguales por industria. Los grandes recuentos de acuerdos pueden incluir expansiones, pilotos, vehículos de adquisición y compromisos plurianuales con diferentes perfiles de riesgo. Las finanzas prueban que Palantir ha encontrado demanda y monetización a escala. No prueban que cada ontología siga siendo precisa, que cada acción siga siendo auditable, que cada usuario adopte el flujo de trabajo, o que cada cliente supere el costo total de los sustitutos.

La presentación anual mantiene visible esa distinción. En suFormulario 10-K de 2025, Palantir reportó un valor total restante de acuerdos de 11.200 millones de dólares al 31 de diciembre de 2025, incluyendo 6.800 millones de clientes comerciales y 4.400 millones de clientes gubernamentales. También reveló que muchos contratos están sujetos a disposiciones de terminación, incluida la terminación por conveniencia, y que las opciones de contratos del gobierno federal de EE. UU. no pueden ejercerse con más de un año de anticipación. Palantir dijo por separado que se le habían adjudicado contratos IDIQ por un total de 12.300 millones de dólares que fueron excluidos del valor restante de acuerdos porque la financiación no había sido determinada o garantizada.

Ese lenguaje importa porque la pregunta comercial de Palantir no es "¿están interesados los clientes?" La respuesta es claramente sí. La pregunta es si las decisiones operativas más rápidas y las aplicaciones reutilizables superan los costos de ingeniería sobre el terreno, limpieza de datos, mantenimiento de ontologías, adquisiciones, licencias, revisión de modelos y cambio a lo largo del tiempo. La respuesta puede ser sí en muchos entornos de alto valor. Aún tiene que ganarse implementación por implementación.

La mano de obra de servicios es parte del producto, incluso cuando el margen parece de software

El modelo de implementación sobre el terreno de Palantir es una fortaleza porque los clientes objetivo de la empresa son difíciles de atender solo con software de autoservicio. Las organizaciones sensibles tienen sistemas heredados, definiciones de datos inusuales, entornos clasificados o regulados, partes interesadas políticas, restricciones de seguridad y expertos del dominio que no hablan en tablas de bases de datos. Un movimiento genérico de crecimiento impulsado por el producto no es suficiente. Alguien tiene que entender el problema operativo, mapear los datos, construir la ontología, diseñar acciones, conectar aplicaciones, gestionar permisos y persuadir a los usuarios para que cambien rutinas.

Ese trabajo puede crear un foso. Una ontología bien construida incorpora el conocimiento del cliente de una manera que es difícil de desplazar rápidamente por los competidores. Las aplicaciones construidas sobre ella pueden volverse reutilizables. Si los ingenieros de Palantir ayudan a un cliente a pasar de un panel único a un modelo operativo gobernado, el cliente puede expandirse en lugar de cambiar. La expansión de ingresos del primer trimestre de clientes existentes, descrita en el 10-Q como adopción de productos y servicios dentro de las organizaciones, es consistente con ese patrón.

También puede convertirse en un lastre. Si cada implementación de alto valor requiere ingeniería a medida, talleres con el cliente, corrección de datos, debates de gobernanza local y mantenimiento continuo, la plataforma puede parecer software en el estado de resultados de Palantir, pero intensiva en servicios en el costo real del cliente. Eso no lo convierte en un mal negocio. Hace que el denominador sea más grande. Un fabricante podría ahorrar lo suficiente por menos paradas de línea para justificarlo. Un hospital podría ahorrar suficiente capacidad si los flujos de trabajo de programación y altas realmente mejoran. Una agencia de defensa podría justificar el costo si la fusión de datos cambia el tempo operativo. Pero el valor debe medirse contra el costo total del programa, no solo el precio de la licencia.

Aquí es donde la retórica de la empresa sobre el software "de carga" debe ser probada. Los sistemas de carga no se juzgan por demostraciones. Se juzgan por la fiabilidad aburrida: transferencias que funcionan, excepciones que son visibles, permisos que se actualizan, acciones que se registran, usuarios que no mantienen hojas de cálculo paralelas y rutas de recuperación que se practican. La propia documentación de Palantir señala muchos de esos controles. La evidencia pública rara vez muestra si los clientes los mantienen bien.

La soberanía de datos es una característica del producto solo si toda la cadena la respeta

El tema asignado incluye la soberanía y localidad de los datos, y la base de clientes de Palantir lo hace inevitable. Los sistemas de salud, las agencias de defensa y las industrias críticas no pueden tratar los flujos de trabajo de IA como características genéricas de la nube. Necesitan saber dónde se almacenan los datos, quién puede acceder a ellos, qué jurisdicción legal se aplica, si los proveedores pueden reutilizar los datos y cómo se mueven los atributos sensibles a través del sistema.

El explicador del contrato del NHS proporciona un ejemplo público: almacenamiento y procesamiento solo en el Reino Unido para datos personales en la FDP y el entorno de tecnología que mejora la privacidad, límites contractuales al uso de los datos del NHS por parte de Palantir, y control local por parte de las organizaciones usuarias del NHS. La documentación de seguridad de objetos de Palantir proporciona un ejemplo del lado del producto: políticas de objetos y propiedades, políticas de fuentes de datos y advertencias sobre recursos referenciados externos. La documentación de arquitectura AIP añade la idea de que las garantías de integración de datos, seguridad y procedencia deben permanecer cohesivas en los modos por lotes, en tiempo real y de transmisión.

El riesgo es que la soberanía se reduzca a una afirmación de alojamiento. La ubicación del alojamiento importa, pero no es toda la cadena de control. Un flujo de trabajo puede exponer datos a través de una aplicación mal configurada, un conjunto de datos derivado, una referencia a medios, una acción permisiva, una instrucción de modelo, una ruta de exportación, una herramienta externa o un proceso humano fuera de la plataforma. Un cliente también puede cumplir con las reglas de localidad de datos y aún así perder la confianza pública si la gente cree que el proveedor o el programa gubernamental es inapropiado. La ventaja de Palantir en mercados sensibles depende de hacer que la gobernanza sea legible tanto para los administradores técnicos como para las partes interesadas institucionales.

El anuncio de Ontology MCP de mayo de 2026 agudiza este punto. Los agentes de IA externos pueden ser útiles si operan a través de herramientas con alcance y acciones predefinidas. También pueden crear nuevas preguntas de gobernanza porque el límite entre la aplicación interna, el agente externo y la acción operativa se vuelve más complejo. La pregunta relevante no es si MCP es moderno. Es si la organización puede demostrar exactamente qué podía ver un agente, qué podía hacer, qué aprobaciones se requerían, qué registros se produjeron y qué controles fallarían en modo seguro.

Los sustitutos están mejorando, pero resuelven un primer problema diferente

Palantir no compite solo con una empresa. Compite con equipos internos de plataformas de datos, pilas de IA en la nube, software de flujo de trabajo, integradores de sistemas, contratistas de defensa, plataformas de análisis, almacenes de datos, lakehouses y la decisión de no hacer nada. Cada sustituto parte de una premisa diferente. Un proveedor de nube puede partir de la infraestructura y el acceso a modelos. Un proveedor de lakehouse puede partir de datos gobernados y análisis. Un proveedor de flujo de trabajo puede partir de la automatización de procesos de negocio. Un integrador de sistemas puede partir de la entrega personalizada. Un equipo interno puede partir del conocimiento institucional y una menor dependencia del proveedor.

La ventaja de Palantir es la integración de esas preocupaciones en torno a la acción operativa. Si el cliente necesita principalmente almacenamiento, informes o alojamiento de modelos, Palantir puede parecer pesado y caro. Si el cliente necesita unir datos confusos con autoridad, flujo de trabajo, registro de acciones y aplicaciones específicas del dominio, el peso de Palantir puede convertirse en el punto. La empresa es más fuerte donde las decisiones son repetidas, multifuncionales, sensibles y lo suficientemente costosas como para que la carga de mantenimiento de la ontología esté justificada.

La cuestión de la dependencia sigue naturalmente. La ontología, las acciones, las aplicaciones y las rutinas operativas de un cliente pueden quedar profundamente ligadas a Palantir. Eso puede ser aceptable si la plataforma se convierte en una capa operativa duradera y la economía del contrato se mantiene razonable. Se convierte en un riesgo si un cliente no puede mover flujos de trabajo, historial de auditoría, lógica de negocio o modelos de dominio sin altos costos de cambio. El explicador del NHS England señala que el NHS posee el modelo de datos canónico encargado y los productos o componentes construidos, mientras que Palantir retiene los derechos sobre Foundry en sí. Esa distinción es importante, pero la salida práctica depende de más que el lenguaje de propiedad intelectual. Depende de la documentación, la exportación de datos, la portabilidad de procesos, las habilidades del personal y los reemplazos disponibles.

Por eso también una implementación de Palantir debe auditarse como un modelo operativo vivo en lugar de como una instalación de software terminada. El paquete de evidencia apunta a páginas de evaluación, páginas de documentación de acciones, material de producto AIP, divulgaciones de clientes y explicaciones de control del sector público, pero esas fuentes describen principalmente los mecanismos y resultados seleccionados. Un comprador aún tiene que muestrear el trabajo ordinario después de la puesta en marcha: quién cambió un grupo de permisos, qué campo fuente alimentó una acción, qué evaluación cubrió un flujo de trabajo revisado, cómo se registró una recomendación rechazada y si los usuarios de primera línea pueden explicar la regla que están aplicando. Esas muestras mundanas son donde una plataforma operativa se gana la confianza o se vuelve opaca.

La evidencia que cambiaría el juicio

La evidencia pública respalda una tesis acotada: Palantir ha construido una plataforma operativa seria para trabajos de datos a acción de alto riesgo, y los clientes la están comprando a escala acelerada. La misma evidencia no prueba que la plataforma supere consistentemente sus pruebas de mantenimiento más difíciles. Para cambiar el juicio de manera decisiva, los observadores externos necesitarían más evidencia a nivel de implementación.

Primero, necesitarían medidas de antes y después vinculadas a denominadores: tiempo de ciclo, tasa de error, costo de servicio, horas de personal, tiempo de recuperación, hallazgos de auditoría, adopción de usuarios y volumen de excepciones, no solo anécdotas o recuentos brutos de actividad. Segundo, necesitarían evidencia de que los flujos de trabajo habilitados por IA se evalúan bajo casos límite realistas, con cobertura de pruebas actualizada después de cambios en modelos, datos y flujos de trabajo. Tercero, necesitarían pruebas de que los cambios de permisos, cambios organizativos y cambios en los sistemas fuente se reflejan rápidamente en la ontología y las aplicaciones posteriores. Cuarto, necesitarían muestras de auditoría que muestren que los registros de acciones siguen siendo interpretables después de revisiones de tipos de acción y cambios del sistema. Quinto, necesitarían evidencia creíble de salida y portabilidad, especialmente para implementaciones del sector público donde el control democrático y la confianza pública son parte del requisito operativo.

Parte de esta evidencia nunca será pública porque Palantir trabaja en entornos sensibles. Esa limitación no debe usarse para asumir el fracaso. Tampoco debe usarse para aceptar afirmaciones del proveedor sin crítica. En mercados sensibles, la opacidad a veces es necesaria, pero eleva el listón para la gobernanza independiente, la supervisión del cliente y las afirmaciones públicas limitadas.

La lectura más conservadora es que la tecnología de Palantir se ajusta bien al problema que dice resolver, mientras que el costo real y la fiabilidad de cada implementación siguen siendo específicos del cliente. La empresa tiene sólidos documentos de arquitectura, una base de ingresos de rápido crecimiento, compromisos públicos con clientes y primitivas de producto creíbles para auditabilidad, permisos, acciones y evaluaciones. El riesgo no resuelto es si esas primitivas permanecen disciplinadas después de que el equipo de implementación inicial se va, la organización del cliente cambia y la capa de IA se vuelve más agéntica.

Conclusión final

El problema difícil de Palantir no es generar una respuesta. El mercado tiene muchas formas de generar respuestas. El problema difícil de Palantir es mantener una representación operativa del cliente veraz, autorizada y revisable mucho después del primer flujo de trabajo exitoso. Eso significa mantener la ontología, el linaje de datos, la seguridad de objetos, las definiciones de acciones, las aprobaciones humanas, las evaluaciones, los registros de auditoría y el comportamiento del usuario a medida que la institución cambia.

Si Palantir puede hacer eso repetidamente, sus productos se convierten en una categoría rara de infraestructura empresarial: software que convierte datos fragmentados en acción gobernada para organizaciones que no pueden permitirse una automatización casual. Si no puede, la misma arquitectura se convierte en una fuente de dependencia frágil, alto costo de cambio y exposición política. La evidencia hasta la fecha favorece tomar a Palantir en serio, pero no aceptar sus afirmaciones más fuertes por fe. La prueba adecuada es si la acción todavía puede explicarse meses después, después de que el modelo cambió, los permisos cambiaron, el flujo de trabajo cambió y la institución aún tiene que respaldar la decisión.