Palantir costruirà il gemello digitale di Mercury Systems: di chi è l’ontologia?

Il 3 agosto 2026 Mercury Systems (NASDAQ: MRCY) e Palantir Technologies hanno annunciato, con un comunicato su GlobeNewswire delle 08:30 ET, «a strategic agreement to enhance the automation of material planning and factory operations to accelerate the delivery of processing technologies for U.S. military programs» — un accordo strategico per automatizzare pianificazione dei materiali e operazioni di fabbrica, e accelerare la consegna delle tecnologie di elaborazione dei programmi militari statunitensi. Una frase sola, più avanti, regge tutto il resto: «Palantir will also help Mercury build an enterprise ontology that serves as a digital twin of the company’s operations and business practices» — Palantir aiuterà Mercury a costruire un’ontologia aziendale che funge da gemello digitale delle operazioni e delle pratiche di business dell’azienda. Non è una notizia su un software venduto. È una notizia su chi costruisce, e per conto di chi, il modello di come funziona un’impresa quotata della difesa.

Due firme pubbliche, due flussi di lavoro

Il comunicato descrive l’accordo attraverso «two initial workflows»: Mercury userà l’AI di Palantir per «streamline material planning, reduce manual workloads, and improve the ability to deliver at increased capacity across its factories» — snellire la pianificazione dei materiali, ridurre il lavoro manuale, aumentare la capacità di consegna delle fabbriche. Bill Ballhaus, amministratore delegato di Mercury: «Partnering with Palantir will enable Mercury to further drive automation and efficiency in our supply chain and manufacturing operations» — la partnership permetterà a Mercury di spingere automazione ed efficienza nella catena di fornitura e nelle operazioni di produzione. Mike Gallagher, a capo della divisione difesa di Palantir: «By integrating numerous data sources within a shared operational layer, Mercury will be positioned to deliver vital processing technologies» — integrando numerose fonti di dati in uno strato operativo condiviso, Mercury sarà nella posizione di consegnare tecnologie di elaborazione vitali. E una frase, nel comunicato, dice che Mercury non è un caso isolato: «In support of the U.S. Department of War, Palantir is working with key U.S. defense industrial base suppliers to increase throughput and reduce delivery timelines» — Palantir sta lavorando con fornitori chiave della base industriale della difesa statunitense per aumentare la produzione e accorciare i tempi di consegna. Non un accordo, quindi: un modo di procedere. («Department of War» è la denominazione che il Dipartimento usa nei propri comunicati, war.gov, accanto a quella di Department of Defense ancora corrente negli atti del Congresso.) Nessun valore economico, nessuna durata, nessun perimetro: né qui, né altrove.

L’ontologia non è il software, è il modello dell’azienda

Che cos’è, di preciso, un’«enterprise ontology»? È lo schema con cui un sistema rappresenta il mestiere di un’azienda: che cosa è un ordine, un lotto, un fornitore, una linea, un ritardo — e come queste cose si legano fra loro. Non è il dato: quante unità, quale fornitore, quale ritardo restano, ovviamente, di Mercury. È la struttura che dice come i dati si mettono in relazione — ed è questa struttura, non un programma installato, a fare da «digital twin»: una rappresentazione formale di come l’azienda funziona davvero, non un cruscotto che la descrive dall’esterno. Costruirla richiede di insegnare al sistema l’intera grammatica operativa dell’impresa — processi, vincoli, eccezioni: un lavoro fatto a quattro mani, non un prodotto chiavi in mano. Per questo la domanda su chi ne resta titolare non è oziosa.

Le domande da porsi prima di firmare

Da qui nascono le domande che un direttore operativo o un CIO dovrebbero porsi prima di firmare — il valore di questo pezzo sta qui, non nel comunicato.

Di chi è l’ontologia? I dati restano del cliente, per prassi quasi universale. Ma lo schema — entità, relazioni, regole, imparato lavorando fianco a fianco con il fornitore — è un’opera costruita insieme. Il contratto dice esplicitamente a chi appartiene, o lascia la domanda dove di solito si perdono le tutele sul know-how mai messe alla prova?

Dove gira, e chi può leggerla? Un modello fedele dell’operatività di un fornitore della difesa è di per sé informazione sensibile: dice dove sono i colli di bottiglia e da chi si dipende.

Che cosa resta se cambia il fornitore? L’ontologia si esporta in un formato che un altro impianto può leggere e far girare, o si ricomincia da zero?

Quanto dura, e quanto costa? Il comunicato non lo dice. E nemmeno l’unico deposito pubblico che dovrebbe seguire un annuncio di questa portata — perché quel deposito, semplicemente, non esiste.

Un accordo, non un evento rilevante

Qui arriva il fatto verificabile. Mercury Systems deposita alla SEC con CIK 0001049521. Alla verifica odierna su data.sec.gov/submissions/CIK0001049521.json, i depositi più recenti sono: uno Schedule 13G del 31 luglio 2026, un 13G/A del 29 luglio e un modulo 4 del 20 luglio. Nessun 8-K dopo l’annuncio del 3 agosto: l’ultimo in archivio resta datato 5 maggio 2026. Non è un’accusa: è una misura. Un 8-K si deposita entro quattro giorni lavorativi per gli eventi che l’emittente giudica rilevanti per gli investitori. Un accordo raccontato con un comunicato e non con un 8-K è un accordo che Mercury, a oggi, non ha trattato come tale — non un giudizio sulla sua importanza industriale. È lo stesso metodo con cui abbiamo letto un altro annuncio di partnership della difesa europea: separare ciò che è firmato da ciò che è solo annunciato.

Il Tradewind Prototype Agreement: quello che si può dire

Il comunicato chiude con una riga tecnica: «Effort sponsored by the U.S. Government under the Tradewind Prototype Agreement» — l’iniziativa è sponsorizzata dal governo statunitense nell’ambito del Tradewind Prototype Agreement. Tradewind è un’iniziativa del Chief Digital and Artificial Intelligence Office (CDAO) del Dipartimento della Difesa, avviata nel 2021 con un accordo other-transaction con l’organizzazione oggi nota come Applied Research Institute per, secondo una pubblicazione ufficiale dell’Army Acquisition Support Center, «set up and manage a prototype business process that streamlines rapid procurement and agile delivery of AI capabilities»: gestire un’acquisizione prototipale che accelera la consegna delle capacità AI. In pratica: uno strumento di Other Transaction Authority, la via con cui il Pentagono stipula accordi di prototipazione fuori dal Federal Acquisition Regulation — più veloce, meno oneri di gara, meno garanzie procedurali di un contratto FAR. Non abbiamo trovato, su fonte primaria .mil o .gov, la dicitura «Tradewind Prototype Agreement» come categoria formale distinta: la riportiamo perché compare nel comunicato, non perché verificata come tale.

Il rovescio, doveroso

Non è una critica a Mercury né a Palantir. Un produttore quotato della difesa che affida a un fornitore esterno l’automazione della pianificazione dei materiali si comporta in modo prudente e ordinario: usa uno strumento pubblico di prototipazione, mette per iscritto i nomi dei dirigenti coinvolti, non promette risultati che non può ancora misurare. È semmai la dimostrazione più netta della tesi di questo pezzo: se un’azienda quotata fa costruire a un terzo il proprio gemello digitale, il valore non stava nel software — stava, e sta, nella propria ontologia, nei propri dati, nei propri processi. Lo dimostra l’accordo stesso, meglio di ogni nostra affermazione.

La lezione operativa

Scrivete in contratto la titolarità dell’ontologia, non solo quella dei dati: schema, regole, relazioni — chi le possiede se il rapporto finisce.
Chiedete un formato di esportazione verificato, non promesso: provatelo prima di firmare, non dopo la prima fattura.
Tenete un registro di chi ha visto e modificato il modello — quando, con quale effetto — esportabile ed esibibile a un’ispezione: per chi lavora in filiera difesa è già, di fatto, un requisito.
Aprite il deposito, non solo il comunicato: un accordo senza 8-K, senza durata, senza perimetro dichiarato è un’intesa da rileggere a ogni trimestre, non un fatto acquisito.

L’ontologia di un’azienda — impianti, fornitori, lotti, ritardi, in un modello unico — è esattamente quello che Mercury sta comprando da un fornitore esterno. Ed è quello che costruiamo con i nostri clienti nella manifattura e nella difesa, con una differenza sola: chi tiene la chiave. Un registro di chi ha visto e modificato l’ontologia, con data ed effetto, è il controllo che mettiamo in esercizio — pronto da esibire a un’ispezione, non un audit fatto una volta e archiviato. Ed è lo stesso impianto multimodello che tiene insieme gli altri dati sparsi dell’organizzazione — archivi, gestionali, sensori, documenti — in un modello operativo unico, su cui agenti AI eseguono decisioni con un operatore al comando, per grandi imprese, difesa, pubblica amministrazione e sanità: l’ontologia resta vostra, anche se un giorno cambiate noi. On-premise, su macchine autonome senza integrazione profonda nella vostra rete, oppure cloud dedicato con data center in Italia — sempre con gestione condivisa.

Volete sapere chi terrebbe la chiave del gemello digitale della vostra azienda, prima di firmare qualcosa di simile? Mezz’ora con un nostro tecnico.