Skip to content
Appunti personali
9 min di lettura

Un’ontologia non è un knowledge graph: a cosa serve davvero nell’AI aziendale

Dove passa il confine tra ontologia, knowledge graph, schema di database, workflow e agente — e perché credo che un’azienda non debba costruire un’ontologia globale dall’alto, ma ricavarla a ritroso dalle azioni che i suoi agenti sono autorizzati a compiere.

Scrivendo di Glean ero arrivato a questa conclusione: nell’AI aziendale il fossato non è il modello, sono i permessi e il contesto. Una domanda però mi è rimasta. Uno strato di contesto risolve «l’AI lo trova», ma quello che mi blocca davvero mentre costruisco un runtime per agenti è il passo successivo: l’AI ha trovato il record, e adesso? In base a cosa sa se quel record si può modificare, o se quell’azione si può eseguire?

Un livello più sotto si trova una parola che gira da vent’anni e che all’improvviso è tornata di moda: ontologia.

Nel dibattito attuale ontologia, knowledge graph, schema di database e workflow vengono usati quasi come sinonimi. Quindi prima i confini, poi le mie due tesi: cosa è cambiato per le ontologie nell’era dell’AI, e come dovrebbe costruirle un’azienda — soprattutto, come non dovrebbe.

Separare le parole che si sovrappongono

La definizione più citata in informatica è quella di Tom Gruber (1993): un’ontologia è «una specifica esplicita di una concettualizzazione». Astratta, ma la parola che porta il peso è esplicita — mettere per iscritto, in una forma leggibile da una macchina, gli accordi concettuali che vivono nelle teste delle persone e nelle consuetudini.

Cosa Domanda a cui risponde Forma tipica
Schema di database Come sono memorizzati i dati? Tabelle, colonne, chiavi esterne
Knowledge graph Cosa è successo nel mondo? (fatti) Istanze, triple
Ontologia Cosa esiste e cosa può diventare? (definizioni) Tipi di oggetto, relazioni, stati, azioni, vincoli, permessi
Workflow Dove si va adesso? Diagrammi di flusso, macchine a stati
Motore di regole Cosa fare quando una condizione è vera IF / THEN
Digital twin Come stanno le cose ora? Specchio dello stato in tempo reale
Agente Come porto a termine questo compito? Pianificazione e chiamate a strumenti
Prompt Che contesto porto in questo turno? Semantica che dura pochi secondi

La coppia che si confonde più spesso è ontologia e knowledge graph. L’ontologia definisce i tipi, il knowledge graph registra le istanze: l’ontologia dice «esiste una classe Cliente che può entrare in relazione Effettua-Ordine con un Ordine», il grafo dice «Huawei ha effettuato questo ordine il 4 marzo». Uno dovrebbe essere stabile, l’altro cambia ogni giorno.

Con lo schema la differenza è più sottile. La stessa riga customer è un acquirente nel sistema vendite, un fornitore negli acquisti, una controparte contrattuale nei contratti. Lo schema può memorizzare quel campo, non può memorizzare la distinzione. E per un agente che sta per agire al posto tuo, quella distinzione è la differenza tra chi paghi e chi ti paga.

Vent’anni in sordina: perché proprio adesso

Non è roba nuova. OWL 2 è Raccomandazione W3C dal 2009, con una seconda edizione nel 2012; RDF, Protégé e l’intero stack del Semantic Web sono completi da oltre un decennio. Il software aziendale mainstream non li ha mai adottati davvero.

Secondo me la ragione non è tecnica. Finora l’utente di un’ontologia era una persona, e le persone hanno una capacità che ai modelli manca: davanti a un vuoto semantico si fermano e chiedono. Un campo chiamato status: una persona si domanda se sia lo stato dell’ordine o dell’approvazione, e va a leggere il codice o a chiedere a un collega. Per gli esseri umani, quindi, una semantica rigorosa offriva poco vantaggio a un costo molto concreto.

Gli LLM ribaltano esattamente questa proprietà. L’ambiguità per una persona è attrito, per un modello probabilistico è un grado di libertà. Un LLM che incontra status non si ferma: sceglie la lettura più plausibile, prosegue il ragionamento, e lo fa con totale sicurezza e senza lasciare traccia. Non ricevi un errore: ricevi una conclusione sbagliata dall’aria molto ragionevole.

L’utente è cambiato. L’ontologia è passata dall’«aiutare le persone a capire i dati» al «togliere gradi di libertà al modello». È questo, non un progresso tecnico, ad averla riportata a galla.

Lo spartiacque: ontologie descrittive e ontologie eseguibili

Detto ciò, identificare le ontologie aziendali di oggi con OWL è un’altra lettura sbagliata. Le due generazioni puntano a cose diverse.

Le ontologie del Semantic Web servono a inferenza e verifica di coerenza. Sanno dirti che A è un tipo di B; non sanno dirti se quest’ordine possa essere riprogrammato adesso. Producono un’ontologia descrittiva: in sostanza, un documento molto rigoroso.

Il modello di riferimento oggi è Palantir Foundry. Secondo la sua documentazione pubblica l’ontologia è divisa in due metà: elementi semantici (tipi di oggetto, proprietà, link) ed elementi cinetici (tipi di azione, funzioni, sicurezza dinamica). Cioè: azioni e permessi sono cittadini di prima classe dell’ontologia, non logica applicativa appiccicata sopra.

Lo spartiacque è qui, non nella precisione del modello:

Un’ontologia che sa rispondere solo a «cos’è un ordine» è un documento. Quella che sa rispondere a «chi, in quale stato, può riprogrammare quest’ordine, dove viene riscritta la modifica e che traccia lascia» fa parte del runtime.

Il che riporta esattamente alla terza conclusione del pezzo su Glean: il collo di bottiglia degli agenti in produzione si è spostato dalla capacità all’autorizzazione. E tutto ciò che serve per decidere un’autorizzazione — che oggetto è, che azione è, chi è autorizzato, dove atterra la scrittura, chi ne risponde — non sta nei pesi del modello né in un vector store. Va scritto in modo esplicito da qualche parte, e quel posto è l’ontologia.

Dove non sono d’accordo: niente ontologia globale dall’alto

Circola una narrazione seducente: l’azienda dovrebbe prima costruire un modello unificato del proprio mondo di business. Suona giusto, e credo che i progetti impostati così moriranno esattamente dove morivano vent’anni fa.

Master data management e modelli dati aziendali hanno già provato l’unificazione globale. Raramente sono falliti sulla tecnica di modellazione: sono falliti perché il modello non aveva consumatori. Un modello che nessuno — persona o programma — invoca ogni giorno si scolla dalla realtà; e una volta scollato smette di essere un patrimonio e diventa un debito, perché resta lì, sembra autorevole ed è sbagliato.

Nel MBSE è ormai senso comune: il valore di un modello non sta nella completezza della copertura, ma nel fatto che si trovi sul percorso di consegna. Un modello fuori da quel percorso è un documento usa-e-getta, per quanto bello, e comincia a marcire appena finita la revisione. Le ontologie aziendali sono la stessa trappola con persone nuove che ci camminano dentro.

Quindi il mio approccio è ricavare l’ontologia a ritroso dalle azioni: prima si decide quali azioni un agente è autorizzato a compiere, poi si risale agli oggetti, agli stati, alle precondizioni e ai permessi che quelle azioni richiedono — e si modella solo quello.

Action: reschedule_order
  oggetto:       Order (identità presa dall’order_no dell’ERP)
  precondizione: confermato E non ancora spedito
  vincolo:       la nuova data non può superare l’SLA contrattuale;
                 oltre 3 giorni di slittamento serve l’approvazione del responsabile
  permesso:      il commerciale titolare, o il responsabile vendite di area
  riscrittura:   campo data di consegna in ERP + traccia della modifica
  provenienza:   SLA dal sistema contratti, permessi dalle linee gerarchiche HR

Nessuna riga qui sopra è deducibile da un LLM: è tutta conoscenza privata dell’azienda. E la sua dimensione non dipende da quante tabelle hai, ma da quante cose lasci fare a un agente.

Il perimetro dell’ontologia va deciso dal perimetro delle autorizzazioni, non da un inventario degli asset di dati. È la tesi su cui sono più sicuro, ed è la direzione verso cui sto convergendo nel mio runtime per agenti: per quanto solido sia il runtime, se non sa rispondere a «questa azione va permessa?» in azienda è inutilizzabile — e quella risposta non può inventarsela da solo.

Il costo vero è la governance, non la modellazione

Uno: entity resolution, il lavoro più sporco. Huawei / HUA001 / 华为技术有限公司 / Huawei Technologies sono lo stesso oggetto. Non esiste una soluzione elegante: regole, revisione manuale, manutenzione continua. È la stessa famiglia dei connettori di Glean — lavoro ingrato, quindi un fossato, e anche l’alibi perfetto per rimandare.

Due: proprietà semantica. Chi ha il diritto di cambiare la definizione di «cliente strategico»? Senza ontologia il problema non esiste, perché ogni sistema interpreta per conto suo e i muri tra reparti assorbono il conflitto. Una volta unificata, la definizione diventa un bene comune e serve qualcuno che ne risponda. È questo passaggio a bloccare la maggior parte dei progetti, non gli strumenti di modellazione.

Tre: deriva semantica, il guasto che temo di più. Cambi una definizione e tutti gli agenti che ne dipendono cambiano comportamento insieme, senza sollevare alcun errore: iniziano semplicemente a prendere decisioni leggermente diverse. Nessuno stack trace, nessun alert: solo metriche che si deformano piano. Perciò un’ontologia va gestita come un’API pubblica: versioni, finestre di deprecazione, revisione delle modifiche.

Quando non farla

  • Solo domande e risposte su documenti, senza operazioni di scrittura. Basta il RAG: il beneficio non copre il costo di governance.
  • Le regole di business stanno già in uno o due sistemi, senza conflitti semantici tra sistemi.
  • Nessuno in azienda può decidere sulle definizioni. La più critica: si può costruire, ma non la manterrà nessuno.
  • Qualità dei dati troppo bassa per l’entity resolution. Prima i dati anagrafici: un’ontologia su identificatori sbagliati amplifica l’errore e gli dà autorevolezza.

Il segnale che invece vale la pena è netto: hai già agenti o automazioni che scrivono attraverso più sistemi, e almeno una volta hanno modificato qualcosa che non dovevano.

Quello che non ho ancora capito

  • Se regga la divisione in due strati — un’ontologia canonica aziendale a evoluzione lenta e una effimera, costruita al volo dall’agente. Ci credo, ma non so chi dovrebbe revisionare la parte effimera né se vada conservata.
  • Se un LLM possa estrarre da solo un’ontologia. Generare tipi candidati da documenti e schemi è già fattibile, ma la parte di valore — chi è autorizzato a fare cosa — non è scritta in nessun documento. L’estrazione dà lo scheletro, non il giudizio.
  • Se ontologie e definizioni di strumenti MCP convergeranno. Una buona definizione di strumento (nome, parametri, precondizioni, effetti collaterali, permessi) è già una voce di ontologia impoverita.

In sintesi

Il pezzo precedente concludeva che il fossato non è il modello, sono i permessi e il contesto. Questo scende di un livello: anche permessi e contesto devono essere definiti esplicitamente da qualche parte, e quel posto è l’ontologia.

Ma non va trattata come tre anni di lavoro fondativo da completare prima di usare qualsiasi cosa. L’LLM decide se l’AI capisce quello che dici; l’ontologia decide se ci si può fidare a lasciarle toccare un ordine reale — e l’unica parte di mondo che devi definire è quella che l’AI è autorizzata a toccare.

Riferimenti

I contenuti fattuali vengono dalle fonti pubbliche qui sotto; i giudizi sono miei.