C’è un momento che segna il passaggio da un progetto di AI sperimentale a un progetto destinato a entrare davvero nell’operatività aziendale.

All’inizio l’attenzione è quasi tutta sulla tecnologia: il modello da utilizzare, l’architettura da costruire, i repository da collegare, la qualità del retrieval, il modo in cui le fonti vengono recuperate e usate per generare una risposta.

Poi arrivano i primi test con gli utenti e, quasi sempre, la conversazione cambia.

Il sistema recupera i documenti, li interpreta, costruisce una risposta coerente e, dal punto di vista tecnico, sembra fare esattamente ciò per cui è stato progettato. Eppure qualcosa non torna. La risposta è plausibile, talvolta anche formalmente corretta, ma manca un dettaglio che per chi lavora ogni giorno in azienda è evidente, oppure mette sullo stesso piano informazioni che, nella pratica, hanno pesi molto diversi. È in quel momento che ci si accorge che il tema non riguarda più soltanto l’AI, ma il modo in cui l’organizzazione ha scritto, mantenuto e tramandato la propria conoscenza nel tempo.

Questo accade in modo particolarmente evidente nei progetti basati su RAG, dove l’AI non risponde solo sulla base del modello, ma utilizza documenti, procedure, policy e knowledge base aziendali per costruire risposte più aderenti al contesto reale dell’organizzazione.

Ed è proprio qui che emerge una domanda spesso sottovalutata: quei contenuti sono davvero pronti per essere letti dall’AI?

Per anni abbiamo prodotto documenti pensando alle persone. Procedure, manuali, istruzioni operative, policy e knowledge base sono spesso stati scritti dando per scontato che chi li avrebbe letti conoscesse già il contesto, sapesse distinguere una regola generale da un’eccezione, fosse in grado di interpretare un riferimento implicito o potesse chiedere chiarimenti a un collega più esperto.

Con l’AI, questo presupposto cambia. Quei documenti non vengono più letti solo da persone capaci di colmare i vuoti con esperienza e contesto, ma diventano parte della base di conoscenza attraverso cui un sistema costruisce risposte che possono orientare attività, decisioni e processi.

Immaginiamo, per esempio, un’azienda manifatturiera con più stabilimenti in Paesi diversi.

Un tecnico chiede al chatbot interno quale procedura seguire per autorizzare la sostituzione di un componente difettoso. Il sistema recupera una procedura globale di qualità aggiornata pochi mesi prima, una procedura locale dello stabilimento italiano che prevede alcune deroghe operative e un vecchio documento di manutenzione ancora presente nel repository, mai formalmente archiviato.

Dal punto di vista tecnico, il sistema ha lavorato bene: ha trovato contenuti pertinenti, coerenti con la domanda e vicini al tema richiesto.

Dal punto di vista aziendale, però, la situazione è molto diversa, perché quei tre documenti non hanno lo stesso valore. Uno definisce la regola ufficiale, uno descrive un’eccezione valida solo in un certo contesto, uno racconta una prassi che forse ha funzionato in passato ma che oggi non dovrebbe più essere seguita.

Un tecnico esperto lo capisce subito. Sa quale fonte considerare autorevole, riconosce una deroga locale, intuisce quando un documento appartiene alla memoria storica dell’organizzazione più che alla sua operatività attuale.

Un sistema AI, invece, non può dedurlo se queste differenze non sono state rese esplicite.

Ed è qui che l’AI costringe a guardare la documentazione con occhi diversi.

Non basta più che un documento sia “presente” o genericamente corretto. Deve essere comprensibile anche fuori dal contesto implicito in cui è nato. Deve chiarire a quale processo si applica, per quale Paese o funzione è valido, da quando è in vigore, chi ne è responsabile e quale relazione ha con altre fonti. In altre parole, l’AI non cambia solo il modo in cui interroghiamo la conoscenza aziendale, cambia anche il modo in cui dovremmo produrla.

Molte organizzazioni scopriranno che parte della documentazione non dovrà essere rivista perché “non piace all’AI”, ma perché si basa su troppi sottintesi: rimandi non chiari, eccezioni non formalizzate, versioni non dismesse, passaggi comprensibili solo a chi conosce già la storia del processo. E forse questo è uno degli aspetti più interessanti.

L’AI non ci sta chiedendo di scrivere per una macchina, ma ci sta mostrando dove la nostra conoscenza non è abbastanza esplicita nemmeno per le persone che arriveranno domani. Una documentazione più chiara, contestualizzata e governata non serve solo a far funzionare meglio una soluzione AI. Serve a migliorare l’onboarding, rendere più semplice il passaggio di consegne, ridurre la dipendenza dalla conoscenza tacita e rendere i processi più uniformi.

Per questo, quando si parla di AI enterprise, la domanda non dovrebbe essere solo: “quali documenti possiamo collegare al sistema?”.

La domanda più utile è: “quali documenti sono scritti in modo tale da poter essere davvero usati con fiducia?”.

Perché alla fine l’AI non ci obbliga solo a rendere la conoscenza interrogabile, ci obbliga a renderla più chiara, più responsabile e più pronta a essere condivisa.