TL;DR. Palantir Foundry es una plataforma operativa de datos enterprise que no compite por almacenamiento sino por la capa de ontología y la app layer. Modela el negocio como objetos (clientes, pedidos, activos) y permite desplegar LLMs y agentes nativos sobre esos datos vía AIP. En Q1 2026 Palantir reportó 1.007 clientes comerciales globales (+31% interanual) y crecimiento de +133% en US Commercial Revenue.1 El 75% de empresas que probaron IA no reporta impacto material todavía (BCG, enero 2025);2 la diferencia suele estar en la última milla operativa, no en el modelo.
Palantir Foundry: la categoría que Palantir creó
Foundry no es un data warehouse. Tampoco un lakehouse. Es una plataforma operativa que sienta el negocio sobre una capa semántica llamada Ontology, donde los datos pasan a ser objetos reales (un cliente, un pedido, una turbina) en vez de filas en una tabla.
Esa diferencia es la que confunde en las primeras reuniones. Snowflake y Databricks resuelven almacenamiento, cómputo y, recientemente, IA. Foundry coge ese sustrato y añade dos cosas que el resto no aporta de serie: la ontología semántica de negocio y la posibilidad de devolver acciones al sistema origen desde apps construidas sobre los propios datos.
El segundo gran bloque es AIP, la Artificial Intelligence Platform. Permite desplegar LLMs y agentes sobre los datos de la ontología con guardrails y trazabilidad. Es la pieza que conecta el dato consolidado con la operación diaria, justo donde fracasan la mayoría de pilotos IA enterprise.
Por qué Foundry está acelerando ahora
Los datos de la SEC del Q1 2026 son útiles para calibrar. Palantir cerró el trimestre con 1.007 clientes comerciales (+31% interanual), ingresos de 1.630 millones de dólares (+85% interanual) y un crecimiento del 133% en US Commercial Revenue, cerrando logos como Airbus, Bain, GE Aerospace y Stellantis.1 El TCV del trimestre llegó a 1.180 millones de dólares solo en US Commercial.
Esto no es ruido. Es la categoría enterprise validándose en industrias muy distintas: aerolíneas, manufactura industrial, automoción, consultoría estratégica. La adopción real coincide con un mercado donde los CIOs ya tienen presupuesto IA y empiezan a separar piloto eterno de despliegue operativo.
Hay un dato adicional relevante. Airbus renovó la relación con Palantir en un acuerdo multi-año para la plataforma Skywise, con más de 50.000 usuarios activos en diseño, producción, cadena de suministro y operaciones de aerolíneas.3 Cuando un cliente con esa escala renueva, está votando por la plataforma como infraestructura, no como herramienta auxiliar.
Cómo funciona Foundry en tres minutos
Hay tres bloques que conviene entender antes de cualquier conversación de implementación.
Capa 1: Ontology. El núcleo. Modelas los objetos de negocio una vez, con sus relaciones, y todo el resto de la plataforma habla ese idioma. Un ingeniero de datos, un analista y un agente IA acceden a "Pedido" como entidad, no a una tabla en un schema.
Capa 2: Pipelines y código. Pipeline Builder ingesta datos desde sistemas legacy, ERPs y cloud (SAP, Oracle, AWS, Azure, GCP, Microsoft Fabric). Code Workbook permite transformaciones en Python, SQL y PySpark nativo. La ontología se alimenta de estas tuberías y se mantiene con linaje y versionado.
Capa 3: AIP y apps. Sobre la ontología viven Object Explorer (exploración visual en tiempo real), Workshop (apps operativas sin código) y Quiver (análisis ad hoc). AIP añade despliegue de LLMs y agentes con guardrails. Apollo gestiona los despliegues y las actualizaciones continuas.
Lo más útil para una conversación inicial: Foundry permite que un usuario de negocio escriba de vuelta al sistema origen desde la app. No es solo lectura. Esa propiedad es la que abre la puerta a casos de uso operativos con IA, no solo analíticos.
Foundry vs Databricks vs Snowflake vs Microsoft Fabric
La pregunta no es cuál es mejor en abstracto. Es cuál encaja con la arquitectura que ya tienes y con el problema que quieres resolver. Tabla de decisión:
| Dimensión | Palantir Foundry | Databricks | Snowflake | Microsoft Fabric |
|---|---|---|---|---|
| Modelo principal | Plataforma operativa con ontología | Lakehouse + IA | Data warehouse cloud | SaaS analítico integrado en M365 |
| Capa semántica nativa | Ontology, built-in | Unity Catalog (técnico, no de negocio) | Semantic Views | OneLake + semantic models |
| App layer para usuarios negocio | Workshop, drag-and-drop | Vía Databricks Apps + terceros | Vía Streamlit + terceros | Power BI, Power Apps |
| IA / LLM nativo | AIP con guardrails | Mosaic AI, Genie | Cortex AI | Copilot + Azure OpenAI |
| Acción de vuelta al sistema origen | Sí, nativa | Limitada | Limitada | Vía Power Automate |
| Modelo comercial | Licencia enterprise plurianual | Consumo + suscripción | Consumo | Licencia M365 + capacity |
| Encaja mejor cuando | Negocio complejo, fuentes legacy heterogéneas, IA operacional | Equipos data engineering maduros, lakehouse abierto | Cargas SQL puras, analítica estructurada | Stack Microsoft profundo, usuarios negocio en M365 |
Conviven con frecuencia. Es habitual ver Foundry como plataforma operativa principal con Databricks o Snowflake debajo aportando capacidad de cómputo y almacenamiento, o conectando Foundry a Microsoft Fabric como puente al stack Office.
El 75% de empresas probó IA, el 25% reportó impacto: aplicado a Foundry
Boston Consulting Group publicó en enero de 2025 una de las estadísticas más citadas del año: el 75% de las grandes empresas ha hecho experimentos con IA, pero solo el 25% reporta impacto material en negocio.2 Ese gap del 50% no se cierra con más modelos. Se cierra con plataforma operativa, talento certificado y procesos de adopción reales.
En Foundry esto es muy concreto. Los pilotos que se quedan en piloto suelen fallar en tres frentes específicos: ontología modelada como mapa de tablas en vez de objetos de negocio, AIP usado como playground sin conectar con flujos productivos, y nadie con propiedad clara sobre el dominio una vez el consultor externo se va.
Aquí es donde encaja la lógica blended team. Talento certificado en Foundry y AIP, integrado con el equipo interno, con agentes IA orquestados sobre la ontología. No es vender horas. Es cerrar la última milla entre dato consolidado y operación diaria.
Roadmap 90 días: del kickoff a un primer dominio en producción
Este es un esqueleto realista. Las semanas se mueven según la complejidad de las fuentes y el grado de governance previo.
| Hito | Semanas | Entregable concreto | Señal de éxito |
|---|---|---|---|
| Selección de dominio piloto | 1-2 | 1 dominio acotado (logística, mantenimiento, riesgo), KPI medible | Sponsor de negocio firmando el alcance |
| Ontology MVP | 3-6 | 3-7 objetos modelados con relaciones, sin atributos secundarios | Una query de negocio devolviendo resultado consistente |
| Pipeline productivo | 4-8 | Ingest desde 2-3 fuentes core con linaje y tests de calidad | Reconciliación con sistema origen pasa al primer intento |
| App operativa | 6-10 | 1 app en Workshop con 5-10 usuarios reales de negocio | Adopción medida por sesiones recurrentes, no por demos |
| AIP en un caso de uso | 8-12 | 1 LLM o agente operando sobre la ontología con guardrails | Decisión humana asistida por el modelo, no automatización ciega |
| Governance baseline | 10-12 | Roles, permisos, política de retención y auditoría operativos | Auditor interno puede reconstruir cualquier acción del trimestre |
Los proyectos que cumplen este patrón consolidan adopción. Los que se saltan los hitos 1, 4 o 6 entran en pilot purgatory.
Qué pide el mercado: el perfil enterprise real
Estos son los requisitos hard que aparecen en briefings actuales para "Ingeniero/a de Datos Palantir Foundry y Habilitación AIP" en empresas españolas con stack enterprise:
- 5+ años en ciencia de datos, analítica avanzada o ML aplicado.
- Experiencia práctica en análisis exploratorio, modelado estadístico y análisis de causa raíz.
- Dominio de Python y SQL.
- Librerías ML: Scikit-learn, XGBoost, TensorFlow o PyTorch.
- Bases sólidas de estadística, probabilidad y diseño experimental.
- Experiencia con datasets a gran escala a nivel enterprise.
- Experiencia hands-on en Palantir Foundry; AIP como valorable fuerte.
- Trayectoria en entornos customer-facing, consultoría o equipos cliente-proveedor.
- Habilidades de comunicación para explicar conceptos analíticos complejos a stakeholders no técnicos.
Hay un punto que se pasa por alto y que es decisivo: Foundry vive en la frontera entre datos, modelo y negocio. Un perfil que solo programa no escala. Las habilidades customer-facing y la capacidad de explicar trade-offs a stakeholders son tan filtrantes como la experiencia técnica.
Palantir ofrece un programa de certificación oficial sobre Foundry, que es una señal útil. No sustituye la trayectoria en proyectos reales, pero combinada con referencias verificables acorta el ciclo de selección.
Cinco anti-patterns que matan proyectos Foundry
Patrones observados en revisiones de proyectos que se atascan. Cada uno tiene un test sencillo para detectarlo.
1. Ontología modelada como mapa de tablas. Los objetos copian los nombres del schema relacional en vez de los del negocio. Test: pide a un usuario de negocio sin acceso al data warehouse que lea la lista de objetos; si pregunta qué significa cada uno, el modelado falló.
2. AIP como playground sin conexión a flujo productivo. Hay un dashboard con un LLM, pero ningún proceso productivo depende de él. Test: pregunta qué pasaría mañana si AIP no estuviese disponible. Si la respuesta es "nada", aún no hay caso de uso.
3. Sin dueño claro del dominio post-implementación. El consultor externo lo construye, lo entrega y desaparece. Test: identifica al "ontology owner" interno del dominio. Si no hay nombre y apellidos, el roadmap está en riesgo.
4. Foundry como almacén único sin pensar el coste a 3 años. El equipo ingesta absolutamente todo sin política de retención ni de cómputo. Test: revisa el ratio entre datos ingestados y datos efectivamente consumidos por apps u objetos.
5. Equipo en formación continua sin entrega operativa. Tres trimestres aprendiendo Foundry, cero apps en producción. Test: cuántos usuarios de negocio no técnicos usan Workshop a diario. Si la respuesta es menos de 10, hay que revisar prioridades antes de seguir.
Coste real: licencia, implementación y talento
Tres componentes y cada uno con sus rangos. Los números aquí son orientativos y dependen mucho del vertical y la escala.
Licencia Foundry. El framework G-Cloud del gobierno del Reino Unido publica referencia de 3M£ por licencia para uso enterprise.4 En España las negociaciones varían con escala, dominios cubiertos y uso de AIP. Lo razonable es asumir compromisos plurianuales para obtener condiciones competitivas.
Implementación inicial. Para un primer dominio operativo en 90 días con un equipo de 3-5 personas, los rangos típicos están entre 250.000 y 700.000 euros incluyendo discovery, ontology, pipeline productivo, app y AIP en un caso de uso. Las consultoras tradicionales aplican un uplift del 50-100% sobre las tarifas internas; los blended teams certificados acortan esa diferencia.
Talento. Las bandas indicativas para perfiles freelance en España 2026: junior 380-450 €/día, mid 500-650, senior 650-850, lead 900-1.200 €/día. El multiplicador habitual sobre salario anual gross es 1,5-1,8x para cubrir RETA, IRPF y margen.
Preguntas frecuentes
¿Foundry sustituye a mi data warehouse?
Normalmente no. Convive. Foundry suele apoyarse en un warehouse para cómputo y almacenamiento mientras añade la capa de ontología y app. Forzar la sustitución completa solo tiene sentido en casos muy específicos.
¿Cuánto tarda un equipo en ser autosuficiente en Foundry?
Con un perfil senior certificado liderando, 6-9 meses para autonomía operativa en un dominio. Sin liderazgo experimentado, el plazo se duplica y aumenta el riesgo de anti-patterns.
¿Vale la pena AIP si ya tengo modelos en Vertex AI o Azure OpenAI?
Depende. Si los datos críticos están en Foundry, AIP aporta guardrails, trazabilidad y conexión nativa. Si los modelos viven fuera y los datos están separados, evalúa por caso de uso antes de migrar.
¿Foundry encaja en sectores regulados (banca, salud, defensa)?
Sí, es uno de los terrenos donde más adopción tiene. La trazabilidad nativa y los controles de acceso granulares facilitan auditorías; el resto depende de cómo se diseñe la governance.
¿Cuál es el principal motivo de fracaso documentado en pilotos Foundry?
Falta de propiedad clara del dominio una vez termina la implementación inicial. Es el patrón que aparece con más frecuencia en revisiones post-mortem.
¿Necesito un equipo full-time o puede ser blended team?
Para arrancar y para AIP enablement, los blended teams certificados aceleran. Para operación recurrente, lo habitual es un mix: ownership interno del dominio más capacidad certificada externa cuando hay picos.
Siguiente paso
Si tienes Foundry desplegado y un caso de uso atascado en piloto, lo más útil es una conversación de 30 minutos para diagnosticar dónde está exactamente el bloqueo. Si todavía estás decidiendo si Foundry encaja en tu stack, la comparativa de la sección 4 y el roadmap de 90 días deberían darte material para una primera reunión interna.
Conocer perfiles certificados en Palantir Foundry y AIP
Fuentes
- Palantir Technologies. Form 10-Q Q1 2026 y earnings release del 5 de mayo de 2026. investors.palantir.com
- Boston Consulting Group. "Where's the Value in AI?", enero 2025. bcg.com
- Palantir Technologies. Q1 2026 Business Update, mayo 2026. investors.palantir.com
- UK Government Digital Marketplace, G-Cloud 14. Ficha "Palantir Platform: Foundry & AIP". applytosupply.digitalmarketplace.service.gov.uk
