Una domanda agli IT manager: qual è il containment reale del vostro agente AI? Intendo la percentuale di richieste che l'agente riesce a chiudere senza passare a un operatore umano.
Nelle aziende con cui parliamo è quasi sempre più basso di quello promesso, o atteso. E la conclusione è quasi sempre la stessa:
"l'AI non era pronta". In realtà la tecnologia oggi è matura.
Quello che molto più spesso non è pronto è la base di conoscenza che mettiamo a disposizione dell'agente.
Un agente AI impara da quello che trova nei ticket, nelle policy, nei runbook, nelle mail di supporto. Se il 30% dei ticket chiusi riporta solo "problema risolto", senza descrivere la soluzione, quel 30% è conoscenza che l'agente non potrà mai recuperare. Se il 70% dei testi liberi contiene email, numeri di telefono, nominativi o altre informazioni personali, quel materiale non può finire in produzione solo con un semplice lavoro di bonifica. Sono due esempi semplici. La realtà, di solito, è più complessa.
Il risultato lo conoscete. L'agente non risponde, oppure risponde con generalità imbarazzanti. L'utente capisce nelle prime due battute che sta parlando con un sistema impreparato e torna a chiamare il numero verde.
Il containment promesso al 60% si stabilizza al 15%. La direzione si chiede se ha sbagliato vendor. Il vendor si chiede se ha sbagliato modello. Nessuno guarda dove andrebbe guardato: nei dati.
Come lavoriamo sulla knowledge base
Per questo, in Gruppo Trade, prima di costruire un
agente AIMOKA lavoriamo su due piani. Da un lato produciamo nuovi documenti, nuove Q&A, nuovi esempi e nuove istruzioni operative. Dall'altro facciamo una revisione completa della documentazione esistente, partendo dallo storico reale delle richieste contenute nei sistemi aziendali: ticketing, CRM, mail di supporto.
Da quello storico lasciamo che un nostro agente AI ricavi una mappa degli argomenti effettivamente trattati dagli utenti. Poi, su quella mappa, misuriamo tutta la documentazione disponibile: soluzioni archiviate, casi gestiti, policy, runbook. La misuriamo su 10 dimensioni, da 0 a 100: completezza, qualità semantica, privacy, classificabilità e altre sei. Da lì escono uno score e un livello di maturità:
Raw Data, Analytics Ready, KB Candidate, KB Ready, AI Certified.
Naturalmente questo è solo lo strato visibile del metodo. Il vero know-how è altrove: nei pesi specifici delle 10 dimensioni, nell'uso delle ontologie con SHACL, nel motore in TypeScript e Python, nelle regole euristiche, nei vocabolari controllati per dominio. È lì che una semplice analisi documentale diventa un processo industriale per capire se una knowledge base può davvero sostenere un agente AI in produzione.
Perché non basta un'analisi statistica
Vale la pena spiegare meglio questo punto, perché è la differenza tra una normale analisi documentale e un assessment realmente utilizzabile per progettare un agente AI. Un approccio puramente statistico può dirci, ad esempio, che un certo numero di ticket contiene una categoria, una nota di risoluzione o un campo compilato. È un'informazione utile, ma non basta.
La domanda vera non è solo se quel dato esiste, ma se è coerente con il dominio, se appartiene alla tassonomia corretta, se contiene una relazione utile, se può essere recuperato dall'agente senza generare ambiguità o rischi.
Le ontologie servono esattamente a questo: definiscono in modo formale i concetti rilevanti di un dominio, le relazioni tra questi concetti e i vincoli che devono essere rispettati. Nel caso di un service desk, per esempio, un ticket non è semplicemente una riga in un CRM. È un'entità che può avere una categoria, una sottocategoria, una priorità, uno stato, una sede, un gruppo di assegnazione, una nota di risoluzione, una relazione con una policy o con una procedura tecnica. Quando questa struttura viene rappresentata formalmente, la knowledge base smette di essere un archivio di testi e diventa un sistema di conoscenza interrogabile.
SHACL aggiunge un ulteriore livello di controllo. Non lavora per sensazioni o per medie statistiche, ma per vincoli verificabili record per record.
"Ogni ticket deve avere uno stato",
"la categoria deve appartenere alla tassonomia attiva",
"una nota di risoluzione deve contenere almeno problema, azione ed esito",
"un contenuto con dati personali non deve essere indicizzato in un corpus destinato all'utente finale": queste non sono raccomandazioni generiche, ma regole che il sistema può verificare in modo puntuale. Il risultato non è soltanto uno score, ma
un audit trail della qualità strutturale del corpus: ripetibile, confrontabile nel tempo e utile per orientare gli interventi di remediation.
Un caso reale
Un caso recente: 4.750 ticket di un service desk IT estratti da un CRM. Score globale: 62. Livello: Analytics Ready. Tradotto: ottimo materiale per fare business intelligence, ma ancora non pronto per alimentare un chatbot conversazionale verso l'utente finale. I due freni principali erano la qualità delle note di risoluzione e la presenza di dati personali nei testi liberi.
Prima di vendere al cliente un agente che lo avrebbe probabilmente deluso, abbiamo concordato cinque azioni di remediation, con impatto stimato sullo score e use case sbloccati a ogni step.
Obiettivo a tre mesi: 80. Cioè KB Ready. A quel punto si parte con l'agente, non prima.
È meno spettacolare che annunciare un nuovo modello. Ma è più onesto. E soprattutto aumenta la probabilità che i numeri di containment reggano davvero in produzione.
Chiara, l'agente service desk che stiamo costruendo, non parte dai dati che abbiamo. Parte dai dati che abbiamo certificato.
