OKF: Google ha scelto il Markdown per le knowledge base dell'AI

Il 12 giugno 2026 Google Cloud ha pubblicato una specifica chiamata Open Knowledge Format, in breve OKF. È passata quasi in sordina rispetto ai lanci di modelli, ma per chi costruisce basi di conoscenza per l'AI è probabilmente la notizia più interessante dell'anno.

Il motivo è la scelta di fondo. Per rappresentare quello che un'organizzazione sa (le sue metriche, le sue tabelle, le sue procedure) Google non ha inventato un database, né un formato binario, né un servizio cloud proprietario. Ha scelto una cartella di file Markdown.

Il problema che prova a risolvere

Chiunque abbia provato a mettere un assistente AI al servizio di un'azienda ha visto come la conoscenza che serve al modello esiste, ma è sparsa: un po' in un wiki interno, un po' in una cartella Drive, un po' nella testa di tre persone, un po' in commenti dentro le dashboard. Ogni strumento la conserva in un formato suo, e spostarla da un sistema all'altro significa riscriverla.

E ogni volta che cambi piattaforma ti tocca ricominciare a mettere insieme i pezzi. La base di conoscenza, che dovrebbe essere l'asset, si fa quindi fatica a costruirla compiutamente proprio a causa di questa dispersione.

OKF nasce proprio da questa esigenza ed è dichiaratamente vendor-neutral: se sai aprire un file di testo, sai leggere OKF. E aprire un file di testo lo sanno fare tutti i tool.

Com'è fatto

La specifica è volutamente minima, e questa è la sua qualità migliore.

Un "bundle" OKF è una cartella di file .md. Ogni file descrive un concetto: una tabella di database, una metrica di business, un dataset, un'API, una procedura operativa, un playbook. Ogni concetto ha il suo file, una cosa che sarebbe un incubo per un essere umano anche solo per cercare e trovare quello che serve. Ma ormai il lavoro si sta spostando, e la domanda giusta è come uomo e macchina lavorano insieme in modo efficace. Questo modello per una macchina è facilissimo da leggere, e all'umano basta puntare la lettura dei file nella direzione che serve.

Ogni file ha due parti:

1. un blocco frontmatter in YAML, delimitato da ---, con i pochi campi che devono essere leggibili da una macchina;
2. il corpo in Markdown normale, cioè prosa libera per tutto il resto.

Così:

---
type: metric
title: Margine lordo
description: Definizione ufficiale del margine lordo usata nei report mensili
tags: [finance, kpi]
---

Il margine lordo si calcola come ricavi meno costo del venduto,
al netto degli sconti commerciali.

Non include i costi di struttura. Per il margine di contribuzione
vedi [Margine di contribuzione](margine-contribuzione.md).

L'unico campo obbligatorio è type. Gli altri campi riservati (title, description, resource, tags, timestamp) sono consigliati ma opzionali. I concetti si collegano tra loro con normali link Markdown, come in un wiki. Un index.md e un log.md opzionali fanno da indice e da diario delle modifiche, e un manifest elenca cosa contiene il bundle.

È tutto: nessuna curva di apprendimento, nessun tooling obbligatorio e non lo devi nemmeno fare tu a mano. Puoi chiederlo direttamente alla tua AI, qualunque essa sia: la specifica OKF è aperta e la trovi qui. Ti basta scaricare quel file markdown e darlo in input alla chat in cui stai lavorando, insieme ai file da catalogare e ai criteri che vuoi usare (puoi anche chiedere all'AI stessa quali criteri abbiano senso per il progetto che stai sviluppando).

Perché è interessante per una knowledge base

Perché è portabile davvero. Un bundle OKF è una cartella. La copi, la mandi via mail, la metti su Git, la sposti da un agente all'altro senza perdere nulla per strada. La conoscenza smette di essere un lock-in.

Perché è leggibile da entrambe le parti. Lo stesso file lo legge un agente AI e lo rilegge un collega umano che deve verificare se una definizione è ancora giusta. È una proprietà che i database vettoriali non hanno: quando un chatbot aziendale dà una risposta sbagliata, con OKF puoi aprire il file responsabile e correggerlo a mano.

Perché la granularità è quella giusta. Un file per concetto significa che l'agente recupera la definizione di "margine lordo" senza doversi ingoiare il report da 80 pagine in cui quella definizione era sepolta. Meno contesto inutile, risposte più precise, meno token spesi.

Perché si versiona. Trattandosi di testo, ogni modifica alla conoscenza aziendale diventa un diff leggibile. Chi ha cambiato la definizione di quel KPI, quando, e perché: è la stessa disciplina che gli sviluppatori applicano al codice, applicata alle informazioni.

La versione 0.2 aggiunge la parte che serve alle aziende

Sei settimane dopo, il 25 luglio 2026, è arrivata la v0.2 con cinque campi opzionali dedicati alla fiducia. Sono l'aggiunta più significativa, perché affrontano il vero problema delle knowledge base aziendali: non archiviare le informazioni, ma sapere se sono ancora vere e chi lo garantisce.

• Provenienza (sources): da quali materiali deriva un concetto, con dettagli come autore e ultima modifica. Chi consuma il bundle si fa un'idea della credibilità senza dover credere a un punteggio unico.
• Fiducia (generated e verified): come è stato prodotto il contenuto attuale e quando è cambiato l'ultima volta, più le conferme fatte da una persona o da un sistema.
• Scadenza (stale_after): una data assoluta oltre la quale il concetto va considerato vecchio. Scelta deliberata al posto di una durata relativa, così verificare la freschezza è un semplice confronto tra date.
• Ciclo di vita (status): draft, stable, deprecated. Se il campo manca, il concetto è considerato stabile.
• Attestazione: un nuovo tipo di concetto pensato per dichiarare che un certo numero è stato calcolato con un metodo approvato, e non con una query improvvisata.

Anche in v0.2 type resta l'unico campo obbligatorio: le aggiunte sono opzionali, e i bundle scritti per la v0.1 continuano a funzionare.

Questa è la parte da guardare con attenzione. Un'AI che risponde citando un numero è utile solo se puoi risalire a chi ha prodotto quel numero, con quale metodo e quando scade. OKF prova a rendere quella catena esplicita dentro il file stesso, invece che in un sistema di governance separato.

Cosa non è

Vale la pena essere onesti su due punti.

Google stessa definisce la v0.1 "un punto di partenza, non uno standard finito". È giovane, l'adozione fuori dall'ecosistema Google Cloud è tutta da vedere, e come tutti gli standard aperti vivrà o morirà a seconda di chi lo implementa.

E non è un trucco per posizionarsi meglio su Google. OKF è pensato per gli agenti AI che devono lavorare su conoscenza curata, non per il ranking di ricerca. Chi lo presenta come la prossima leva SEO sta vendendo altro.

Cosa significa in pratica per te

Anche senza adottare formalmente la specifica, la direzione è chiara e conviene leggerla così: il formato in cui conserverai la conoscenza destinata all'AI è il testo strutturato.

Il che sposta il problema di un passo indietro, dove è sempre stato. Il materiale che oggi hai (verbali, manuali, ricerche, deck dei clienti, contratti) è nato per essere letto da persone. Prima di poter diventare un concetto per bene in una base di conoscenza, deve diventare testo pulito: titoli riconoscibili, elenchi ordinati, tabelle ancora intere.

Quel passaggio è il collo di bottiglia vero, ed è noioso da fare a mano. Se non sai bene da dove si comincia, qui spieghiamo cos'è un file Markdown in parole semplici.

E quando devi trasformare i tuoi documenti in testo pronto per l'AI, md anything lo fa in pochi secondi.

Fonti: annuncio su Google Cloud Blog, specifica OKF su GitHub, nota sulla v0.2.