Ecco perché hai bisogno di ontologia (e non solo di prompt)

L’AI non allucina. Immagina.

C’è un momento preciso in cui ho capito il problema.

Stavo guardando il talk di Frank Coyle, docente a Berkeley, al recente AI Summit. Una frase mi è rimasta piantata in testa:

“Gli LLM non possono fare nulla. Tutto ciò che possono fare è darci la parola successiva con un’alta probabilità.”

Non è una limitazione. È un dato strutturale. E fa esplodere quasi tutto quello che diamo per scontato quando parliamo di “agenti AI”.

Perché se un LLM è solo una macchina probabilistica che produce il prossimo token più probabile — come può diventare un agente che prende decisioni, interagisce con sistemi reali, coordina flussi di lavoro?

La risposta di Coyle — e quello che voglio condividere qui — è che serve un ontologia. Non come esercizio accademico.

Come infrastruttura operativa.

Come i binari su cui far scorrere il treno probabilistico.

Due lignaggi che oggi si incontrano

Coyle racconta la storia parallela di due mondi che si stavano sviluppando separatamente e che oggi convergono.

Da una parte gli agenti. Il concetto nasce con John McCarthy, Marvin Minsky, Oliver Selfridge — gente che già negli anni ’50 immaginava entità software capaci di percepire, decidere e agire.

Oggi, con i loop (Böhm-Jacopini, 1966: sequenza + condizionali + iterazione), gli agenti sono Turing-completi. Possono eseguire qualsiasi cosa calcolabile.

Dall’altra le ontologie. Aristotele fu il primo, con le sue Categorie dell’Essere.

Poi Quine, poi Gruber nel 1993, che dà la definizione che ancora oggi usiamo: “specifica formale di una concettualizzazione condivisa”. In pratica: un grafo di entità, proprietà e relazioni che descrive come funziona un dominio.

Questi due mondi — il probabilistico e il formale — si incontrano nell’IA neuro-simbolica.

Ed è lì che succede qualcosa di interessante.

Le allucinazioni non sono bug. Sono feature.

Coyle lo dice senza mezzi termini:

“Le allucinazioni sono una caratteristica degli LLM. È ciò che sono. In un certo senso anche noi alluciniamo — immaginiamo cose che potrebbero non esistere e poi le trasformiamo in realtà.”

Il problema non è l’allucinazione. Il problema è non avere un sistema che la intercetti e la corregga.

Qui entra l’ontologia.

Nel ciclo agente classico — prompt → LLM → tool_call → esecuzione → validazione — l’ontologia vive nella fase di validazione.

È il guardrail che controlla se l’output dell’LLM ha senso nel dominio in cui opera.

Esempi concretissimi:

Proprietà funzionale OWL (solo uno): se l’agente cerca di emettere un secondo rimborso sullo stesso ordine, l’ontologia lo blocca.
Proprietà disgiunta: se un pagamento viene indirizzato al supporto clienti invece che all’acquirente, l’ontologia dice “queste due entità sono separate — errore.”
Vincolo di valore: “probabilmente spedito” non è un valore valido in un dominio che ammette solo pagato/spedito/rimborsato.

Tutto questo non vive nel prompt. Vive nel grafo.

Come si costruisce un’ontologia? (E cosa abbiamo imparato dagli anni ’80)

Qui c’è una lezione storica che vale la pena ricordare.

Negli anni ’80 i sistemi esperti erano considerati la via maestra per l’IA. Il Giappone lanciò un progetto mastodontico. Aziende americane spesero milioni. Mio figlio — dice Coyle — studiava giapponese a scuola perché sembrava il futuro.

Cosa fallì? L’approccio top-down. Riunivi gli esperti del dominio, definivi tutte le entità e le relazioni una volta per tutte, scrivevi le regole. Il sistema diventava rigido, non scalabile, costosissimo da mantenere.

Poi arrivarono le GPU di Nvidia — costruite per i videogiochi — e qualcuno disse: “affidiamo queste cose alle reti neurali.”

La lezione per oggi è chiara:

L’ontologia non si costruisce dall’alto. Si estrae dal basso. Partendo dalle interazioni reali: reazioni dei clienti, transazioni, eventi operativi. E si arricchisce nel tempo.

In più, non serve reinventare la ruota. Esistono già tassonomie consolidate:

schema.org — un intero set di termini e relazioni pronte all’uso
FOAF (Friend of a Friend) — per modellare relazioni sociali
Dublin Core — metadati per articoli e libri
DBPedia — l’ontologia su cui Wikipedia interroga il suo database a grafo

RDFS e OWL: i motori di inferenza che rendono l’ontologia viva

Un’ontologia non è un elenco statico. È un sistema che produce nuova conoscenza per inferenza.

RDFS (Resource Description Framework Schema) ti dà dominio e codominio. Esempio: se definisci che “insegna” ha dominio “insegnante” e codominio “studente”, allora dalla frase “Bob insegna a Scooter” il sistema deduce che Bob è un insegnante, Scooter è uno studente, e — se hai detto che tutti gli insegnanti sono persone — anche che Bob è una persona.

OWL (Web Ontology Language) aggiunge proprietà più potenti:

Transitiva: se Sue è antenata di Mary e Mary è antenata di Anne, allora Sue è antenata di Anne. Nessuno ha scritto questa relazione nel grafo originale — è emersa per inferenza.
Funzionale: “ha padre” è una proprietà funzionale. Se dici che Bob è padre di Jim e BB è padre di Jim, il sistema inferisce che Bob e BB sono la stessa persona.

Questo tipo di inferenza non è parafrasi. È logica formale che parte da dati strutturati e produce nuovi fatti verificabili.

L’architettura che tiene tutto insieme

Coyle propone un’architettura chiara per l’agente ontologicamente guidato:

while True:
    1. LLM riceve prompt + strumenti
    2. LLM restituisce una tool_call (non può eseguirla — è chiuso nella scatola)
    3. Il sistema esegue lo strumento
    4. Validatore ontologico controlla il risultato ← ONTOLOGIA
    5. Se valido → procedi
    6. Se non valido → torna all'LLM o coinvolgi un umano

E un pattern collaudato: Pydantic all’ingresso, ontologia all’uscita.

Pydantic all’ingresso: type-checking dei parametri che l’LLM passa al tool.
Ontologia all’uscita: validazione semantica del risultato prima che entri nel sistema.
Agenti puri: nessun effetto collaterale finché l’ontologia non ha dato il via libera.

Gli agenti non devono scrivere nel database prima che l’ontologia abbia validato il risultato. Sembra ovvio. Non lo è nella pratica.

Quello che questo significa per chi progetta organizzazioni

Se fai organizational design, HR, change management o AI strategy — questo discorso ti riguarda direttamente. Per tre ragioni.

Primo: l’organizzazione è un dominio. Ha le sue entità (ruoli, team, decisioni, promesse, processi), le sue relazioni (chi riporta a chi, chi dipende da chi, chi promette cosa a chi), le sue proprietà (capacità, responsabilità, confini). Un’ontologia organizzativa è esattamente quello che abbiamo chiamato Company as Code o company manifest nelle newsletter precedenti.

Secondo: gli agenti opereranno nel dominio organizzativo. Non solo per rispondere a domande, ma per eseguire azioni: aprire un ticket, assegnare un task, approvare un flusso, notificare un decisore. Senza un’ontologia che definisca cosa è lecito, ogni azione diventa un potenziale errore.

Terzo: il contesto che diamo agli agenti è una scelta di design. Non è una questione tecnica. È una questione di modello del mondo: cosa l’agente sa dell’organizzazione, come lo rappresenta, quali relazioni conosce, quali vincoli rispetta. Questo è esattamente il lavoro di context engineering di cui parlavamo.

Ovvero: l’ontologia è il nuovo layer di progettazione

Nel mio lavoro chiamo questo Design Ontology Spec (DOS). Nel vault del libro in cui sto lavorando, è il layer che sta tra l’interfaccia e la strategia — esattamente come dice Jens Jorgenson nel suo Ontology Layer of Design (2026).

Concreto:

Problemi (P1–P6): cosa risolviamo? (es. P2 = confusione decisionale, P4 = silos informativi)
Interventi (I1–I6): cosa facciamo? (es. I3 = mappatura semantica, I5 = context engineering)
Framework (F1–F6): con cosa? (es. F1 = Boundaryless Platform Design, F4 = Company as Code)
Manifesto AI: 10 principi che nessuna proposta può violare

Quando un agente AI opera nel mio dominio consulenziale, sa qual è il problema del cliente, sa quale intervento è appropriato, sa quali vincoli etici rispettare. Non perché gliel’ho scritto nel prompt. Perché l’ontologia glielo dice. E perché un validatore ontologico controlla che non sfori.

Tre domande per chi legge

Se arrivi a leggere fin qui, ho tre domande che secondo me valgono più di qualsiasi framework:

Il tuo dominio ha un’ontologia esplicita? Non un glossario, non una slide. Un grafo machine-readable di entità, relazioni e vincoli che un agente AI possa validare.
I tuoi agenti hanno binari o volano a vista? Se non c’è un validatore ontologico dopo ogni tool_call, stai affidando azioni reali a un generatore di testo probabilistico — è solo questione di tempo prima che “immagini” qualcosa di sbagliato.
Chi decide cosa entra nell’ontologia? Questo è il punto più delicato. Perché definire le entità e le relazioni di un dominio significa definire la realtà operativa dell’organizzazione. È una scelta di potere. Va gestita come tale.

What’s next

Il talk di Coyle non dice nulla di rivoluzionario. Ma dice qualcosa che spesso dimentichiamo nella corsa agli agenti:

“Nothing is a mistake. You don’t win. You don’t lose. You just create.”

L’IA neuro-simbolica — agenti + ontologie — non è un prodotto da comprare. È un approccio da costruire, pezzo per pezzo, dal basso.

Partendo da domande scomode su cosa è reale nel nostro dominio. Su quali regole non negoziabili vogliamo che l’AI rispetti. Su come teniamo insieme la potenza generativa della probabilità con la precisione della logica.

Se lavori su questi temi — AI adoption, organizational design, HR transformation — mi piacerebbe sapere: stai già lavorando a un’ontologia per il tuo dominio? O è ancora tutto affidato al prompt?

Ispirato da

🔗 Frank Coyle — Agents and Ontologies (Berkeley AI Summit, 2026) — Video

🔗 Gruber (1993) — A translation approach to portable ontology specifications

🔗 Jens Jorgenson (2026) — Ontology Layer of Design