Cos'è Palantir Foundry?

Palantir Foundry è la piattaforma dati e AI di Palantir, e la sua differenza sta in una scelta di progetto: al centro non ci sono le tabelle ma l'ontologia, un modello operativo dell'azienda fatto di oggetti (clienti, impianti, ordini, spedizioni), relazioni e azioni possibili. I dati dei sistemi sorgente alimentano gli oggetti, le persone e gli agenti AI (tramite AIP, il layer di intelligenza artificiale) operano sugli oggetti, e le decisioni tornano nei sistemi come azioni. Non a caso è Palantir ad aver reso popolare anche il modello del Forward Deployed Engineer: la piattaforma nasce per essere costruita sul campo, dentro i processi del cliente. Nata da progetti nel settore difesa e intelligence, negli ultimi anni Foundry si è spinta con decisione verso il mercato commerciale, manifatturiero e sanitario, portando con sé la stessa filosofia: i dati contano solo quando sono collegati a un'azione concreta che qualcuno può prendere.

Quando ha senso (e quando no)

Foundry rende dove il problema è operativo e trasversale: supply chain complesse, produzione, manutenzione, scenari dove la domanda non è "fammi un report" ma "aiutami a decidere e ad agire, adesso". Lì la scommessa ontologica paga, perché l'AI opera su concetti di business definiti invece che su tabelle da interpretare. Il rovescio: è un ecosistema proprietario e impegnativo, con costi da giustificare e competenze meno diffuse sul mercato rispetto allo stack aperto. Per l'analitica classica una piattaforma lakehouse (Databricks, Snowflake, BigQuery, Fabric) resta spesso la via più proporzionata; e i concetti che rendono Foundry interessante (ontologia, knowledge graph, azioni governate) si possono costruire anche sullo stack aperto, con più lavoro e più libertà.

Come funziona: l'architettura a quattro livelli

Sotto l'ontologia, Foundry è organizzato in quattro livelli che si passano il testimone. Il livello di integrazione dati collega i sistemi sorgente (ERP, MES, sensori, database legacy) senza richiedere che quei sistemi cambino. Il livello di trasformazione (Pipeline Builder e i Code Repository, che accettano Python, SQL e Java) pulisce e unisce quei dati in dataset governati, con la lineage tracciata passo per passo. Il livello dell'ontologia traduce quei dataset in oggetti di business (un impianto, un ordine, una spedizione), relazioni tra loro e azioni che qualcuno può eseguire su di essi, ciascuna con un log di chi l'ha eseguita e quando. Il livello applicativo costruisce sopra l'ontologia senza dover ripartire dal dato grezzo ogni volta, e offre due strade diverse per farlo: Workshop, low-code, per chi assembla un'interfaccia operativa senza scrivere frontend da zero, e Slate, che richiede scrivere HTML, CSS e JavaScript ma dà libertà totale di personalizzazione, tipicamente per dashboard o applicazioni con requisiti che il low-code non riesce a soddisfare. AIP si inserisce trasversalmente su questa pila: un agente non scrive mai direttamente sul sistema sorgente, propone o esegue un'azione già definita e governata a livello di ontologia, il che è anche la risposta di Foundry al problema dell'agente che agisce fuori perimetro.

Un esempio enterprise

Il caso pubblico più citato è Airbus: dal 2015 Foundry integra dati di procurement, produzione, logistica e controllo qualità sulla linea dell'A350, un aereo assemblato da centinaia di team su otto stabilimenti in quattro paesi a partire da circa 5 milioni di componenti. Il caso è utile perché mostra cosa significa davvero "operativo e trasversale" nella sezione sopra: prima di Foundry, capire perché un lotto di componenti causava difetti a valle richiedeva incrociare a mano dati sparsi su sistemi diversi, e Palantir riporta che l'intervento sull'A350 ha contribuito a un aumento del 33% nel ritmo di consegna dei velivoli (fonte: caso pubblicato da Palantir, palantir.com/impact/airbus). Dopo quel primo caso d'uso, la partnership si è estesa ad altre aree, fino a più di venti casi d'uso diversi tra supply chain, pianificazione e finanza: lo schema tipico di un'adozione Foundry riuscita, un problema operativo circoscritto prima, l'espansione ad altri problemi dopo, non l'inverso.

Il mio punto di vista

La tesi di fondo di Foundry mi convince: collegare l'AI alle decisioni richiede un modello semantico dell'azienda, non solo dati puliti. È lo stesso principio che applico, con strumenti diversi, nei progetti su knowledge graph e ontologie. Sul blog ne ho scritto più volte, inclusa l'analisi su Palantir e la sovranità digitale europea: tecnologia notevole, da valutare con gli occhi aperti anche sul piano geopolitico e contrattuale.