Policy per agenti AI: dalla knowledge base alle regole

La gestione delle policy degli agenti AI è il modo in cui un team di assistenza fa sì che le regole seguite da un agente AI (che cosa può fare, i suoi limiti, le sue eccezioni e quando deve passare la conversazione a un operatore) siano scritte una volta sola, abbiano un responsabile, siano versionate e allineate con ciò che viene detto ai suoi operatori. Una knowledge base dà all’agente i fatti. Un centro delle policy gli dice che cosa ha il permesso di farne.

In breve

• Gli articoli di aiuto sono scritti per persone che colmano le lacune con il buon senso; un agente AI ripete su larga scala le loro eccezioni implicite, le versioni superate e le contraddizioni.
• Separi la knowledge (i fatti), la policy (che cosa può fare l’agente, i limiti, le eccezioni, l’escalation) e la procedura (i passaggi): ognuna fallisce in modo diverso e ha un responsabile diverso.
• Tenga una scheda per ogni regola, con un responsabile, una versione, una data di revisione, gli articoli collegati e i casi di test, e faccia sì che sia la macro degli operatori sia l’istruzione dell’agente AI rimandino a quella scheda.
• Tratti ogni modifica di policy come un rilascio: un approvatore nominato in base al livello di rischio, una data di entrata in vigore, una nuova esecuzione dei casi di test collegati e una settimana di revisione più stretta.
• Chiuda il cerchio: classifichi ogni conversazione fallita dell’AI per causa, mandi le cause di policy al responsabile della scheda e rivaluti dopo la correzione.

Questa guida è il punto di riferimento su policy e knowledge nella nostra serie sulla governance degli agenti AI, scritta per l’Head of Support o il responsabile AI il cui agente continua a dare risposte che erano “tecnicamente nel centro assistenza”.

Perché una knowledge base scritta per le persone non funziona per gli agenti AI?

Una knowledge base scritta per le persone non funziona per gli agenti AI perché le persone leggono tra le righe e un agente AI no. Gli operatori sanno quale articolo è superato, quale eccezione il team leader concede e quali due pagine si contraddicono. L’agente recupera ciò che corrisponde meglio e lo afferma con sicurezza, ogni volta.

Quattro schemi di errore coprono la maggior parte di ciò che va storto:

La guida di Intercom sulle knowledge base per chatbot (in inglese) descrive il rischio senza giri di parole: un agente AI recupererà fedelmente un articolo superato e darà una risposta sicura e sbagliata. Il costo non è astratto. Nel caso Moffatt v. Air Canada (2024 BCCRT 149), un chatbot ha suggerito a un cliente in lutto che poteva chiedere una tariffa per lutto dopo il viaggio. Air Canada ha sostenuto che l’informazione corretta era sulla sua pagina dedicata alle tariffe per lutto, collegata nella stessa risposta, e che il chatbot era un’entità giuridica separata, responsabile delle proprie azioni. Il tribunale della British Columbia ha respinto questo argomento, come spiega questa sintesi di WeirFoulds (in inglese). La risposta era dell’azienda.

Molte “allucinazioni” nell’assistenza sono problemi di contenuto. La nostra guida sulle allucinazioni degli agenti AI mostra come distinguere una risposta inventata da una risposta sbagliata ripetuta fedelmente, e perché le conversazioni con l’AI falliscono scompone ulteriormente le cause.

Qual è la differenza tra knowledge e policy per un agente AI?

La knowledge è ciò che è vero: prezzi, finestre di reso, tempi di spedizione, come funziona una funzionalità. La policy è ciò che l’agente AI può fare al riguardo: quali azioni può compiere, fino a quale limite, con quali eccezioni e quando deve passare la conversazione a un operatore. La procedura è l’ordine dei passaggi. Mescolare le tre cose in un solo articolo è all’origine della maggior parte delle derive.

Le piattaforme di agenti tracciano già questa linea. Intercom controlla la guidance di Fin prima che Fin cerchi una risposta nei suoi contenuti di aiuto (in inglese), e le sue Fin Procedures (in inglese) aggiungono condizioni e passaggi a un team. Decagon descrive le sue Agent Operating Procedures (in inglese) come istruzioni in linguaggio naturale supportate dal codice, scritte più o meno come si formerebbe il personale sulle procedure operative. Ogni piattaforma le offre un posto in cui scrivere istruzioni. Nessuna decide quale regola sia quella in vigore. Questo è il compito di un centro delle policy.

Come si prepara una knowledge base per un agente AI?

Per preparare una knowledge base per un agente AI, parta dagli intenti che l’agente gestirà, non dall’intero centro assistenza. Per ogni intento trovi tutti gli articoli che lo toccano, elimini duplicati e contraddizioni, scriva le condizioni in modo esplicito e sposti ogni regola che cambia un esito in una scheda della policy a cui l’articolo rimanda.

1. Elenchi gli intenti principali per il primo trimestre dell’agente, ordinati per volume e rischio (denaro, idoneità, formulazioni legali).
2. Raccolga ogni fonte che risponde a ciascun intento: articoli di aiuto, macro, pagine wiki, risposte salvate, messaggi fissati in Slack.
3. Classifichi ogni frase come knowledge, policy o procedura. Le frasi di policy contengono parole come “può”, “deve”, “fino a”, “solo se”, “tranne” e “ci contatti”.
4. Risolva i conflitti prima del lancio. Se due fonti non concordano, decide il responsabile della policy, una scheda registra la risposta e la pagina perdente viene riscritta o tolta dalle fonti dell’agente.
5. Scriva le condizioni per esteso. “Se ha il piano annuale” è meglio di “a seconda del piano”. La guida di Intercom raccomanda una domanda per articolo e condizioni esplicite per lo stesso motivo.
6. Delimiti le varianti. Le varianti per regione, piano e prodotto hanno ciascuna la propria scheda o il proprio pubblico.
7. Colleghi, non copi. Gli articoli di aiuto e le istruzioni dell’agente rimandano alla scheda; non riformulano mai il limite con parole proprie.

Per il centro assistenza in sé, la nostra guida alla creazione di una knowledge base per il servizio clienti (in inglese) tratta la struttura e le regole di scrittura per i lettori umani.

Che cosa deve contenere la scheda di una policy per agenti AI?

La scheda di una policy per agenti AI deve contenere la policy in una frase, il suo ambito, le azioni consentite e i limiti, le eccezioni, la regola di escalation, un responsabile, una data di revisione, gli articoli di aiuto collegati e i casi di test che dimostrano che l’agente la segue. Aggiunga una versione e una data di entrata in vigore, così che operatori e agente cambino insieme.

Ecco il modello, compilato per il rimborso di un articolo danneggiato. Lo copi in un foglio di calcolo o in una wiki, una scheda per policy.

Due regole mantengono la scheda affidabile. Ogni limite compare in un solo posto, la scheda, e l’articolo, la macro e l’istruzione dell’agente vi rimandano. E una scheda senza casi di test non è finita. La nostra guida al test degli agenti AI contiene il modello di caso di test che corrisponde agli ultimi campi di questa scheda.

Come si tengono procedure degli operatori e istruzioni dell’agente AI in un’unica fonte di verità?

Faccia della scheda della policy l’unico posto in cui una regola è definita, e colleghi a essa sia la macro degli operatori sia l’istruzione dell’agente AI. Quando la scheda cambia, entrambe cambiano nello stesso rilascio, e nessuno modifica un limite direttamente dentro un prompt o una macro.

La fonte di verità non è un nuovo strumento. È una disciplina su dove vive il testo:

Due abitudini lo fanno funzionare. Dia alle istruzioni il nome dell’ID della scheda, così che una ricerca di “RF-DMG-02” trovi ogni posto che ne dipende. E confronti gli esiti, non i testi: una volta al mese verifichi che un operatore e l’agente AI arrivino allo stesso risultato sullo stesso tipo di caso. Se non succede, uno dei due lavora con una versione vecchia.

Le istruzioni da sole non ritirano una fonte. La guida di Intercom osserva che Fin può comunque far emergere contenuti che le sue regole di guidance gli dicono di evitare, e raccomanda di rimuovere quei contenuti o di limitarli per pubblico. Togliere un vecchio articolo dalle fonti dell’agente fa parte di ogni modifica di policy.

Chi approva una modifica di policy, e come arriva all’agente AI?

Una modifica di policy la approva il responsabile di business della policy, con altri approvatori man mano che il rischio cresce. Arriva all’agente AI nello stesso rilascio della macro degli operatori e dell’articolo di aiuto: scheda aggiornata, fonti ritirate, istruzione aggiornata, casi di test rieseguiti, data di entrata in vigore fissata, poi una settimana di revisione più stretta.

Leghi il percorso di approvazione a ciò che la modifica fa all’esito per il cliente:

Il livello C è il punto in cui la policy incontra l’autonomia. Decidere quali azioni un agente può compiere da solo è il tema della nostra guida ai livelli di autonomia degli agenti AI, e i limiti rigidi che valgono a prescindere dalle istruzioni sono il tema della nostra guida ai guardrail per agenti AI.

È la stessa logica della gestione generale del rischio AI: l’AI Risk Management Framework del NIST chiede policy e procedure trasparenti, revisioni periodiche pianificate e ruoli chiaramente definiti (in inglese). Una scheda della policy con un responsabile, una data di revisione e un registro delle modifiche applica questo principio a una singola regola di rimborso.

Il passaggio che la maggior parte dei team salta è la data di entrata in vigore. Una policy che cambia il 1° dicembre dovrebbe arrivare all’agente il 1° dicembre, non il 20 novembre né il 5 dicembre, nello stesso momento in cui cambia il team di operatori.

Come diventano correzioni di policy le conversazioni fallite?

Le conversazioni fallite diventano correzioni di policy quando ogni errore viene classificato per causa, le cause di policy vanno al responsabile della scheda e la correzione viene verificata rivalutando lo stesso intento in seguito. Senza classificazione, ogni errore sembra un problema dell’AI, e il team ritocca i prompt mentre la vera causa sta in un articolo superato. Il ciclo:

1. Valuti le conversazioni dell’agente AI con criteri che separano i tipi di errore: accuratezza rispetto ai suoi contenuti, fedeltà alla policy, perimetro ed escalation.
2. Classifichi la causa di ogni errore: versione superata della policy, eccezione mancante, fonti in conflitto, istruzione non seguita, accesso a strumenti o dati mancante, oppure un bug di prodotto. La nostra guida su errore dell’operatore o errore di processo (in inglese) propone la stessa distinzione per gli operatori.
3. Instradi ogni causa al suo responsabile: le cause di policy al responsabile della scheda, le cause di istruzione al responsabile AI, le cause di accesso all’ingegneria.
4. Corregga prima la scheda, poi gli articoli, la macro e l’istruzione che vi rimandano.
5. Aggiunga un caso di test dalla conversazione che ha messo in luce la lacuna, e lo colleghi alla scheda.
6. Rivaluti l’intento la settimana successiva e confronti il tasso di errore con quello della settimana prima.

Correggere un agente AI non è la stessa cosa che fare coaching a una persona; veda coaching delle persone e correzione degli agenti AI.

Un esempio pratico (illustrazione, non dati di clienti)

Un agente AI gestisce 20.000 conversazioni al mese, 3.000 delle quali su rimborsi e resi. Valutarle tutte mostra un tasso di errore del 3% sulla fedeltà alla policy per quell’intento: 90 conversazioni. Il responsabile QA le classifica:

Due correzioni di contenuto (ritirare la vecchia FAQ, scrivere l’eccezione per i deperibili sulla scheda) risolvono 65 dei 90 errori, cioè il 72%. Aggiungendo la correzione degli articoli in conflitto si arriva a 79 su 90, cioè l’88%. Solo 7 errori, l’8%, sono un problema di prompt: un team che avesse iniziato riscrivendo il prompt avrebbe toccato la fetta più piccola. I punteggi della settimana successiva mostrano se le correzioni hanno retto.

Come si individua la deriva delle policy prima che se ne accorgano i clienti?

La deriva delle policy si individua verificando, con una cadenza fissa, che ogni policy sia definita una sola volta, abbia un responsabile, sia aggiornata e venga applicata allo stesso modo dagli operatori e dall’agente AI. La deriva si manifesta come un lento aumento delle escalation etichettate “poco chiaro” o come operatori e agente che arrivano a esiti diversi sullo stesso caso.

Copi questa checklist sulla deriva nella sua revisione mensile delle policy:

I controlli 7, 8 e 9 richiedono dati sulle conversazioni, non una revisione di documenti: una deriva che tocca il 2% di un intento è invisibile in un campione di 50 e lampante in una settimana intera di punteggi. Il nostro audit del tasso di risoluzione degli agenti AI mostra come verificare se le conversazioni “risolte” sono state risolte davvero correttamente.

Dove si inserisce Kaizo

Kaizo copre il lato delle prove del ciclo: la valutazione, gli schemi di errore e la nuova valutazione dopo una correzione. AutoPilot valuta ogni conversazione risolta con la sua scheda di valutazione.

Con il controllo qualità degli agenti AI, aggiunge i criteri su cui un bot sbaglia (accuratezza dei fatti, fedeltà alla policy, perimetro ed escalation), scritti con le sue parole, e collega la sua knowledge base così che l’AI giudichi rispetto ai suoi contenuti. Ogni punteggio rimanda alle prove nella conversazione. L’analisi della causa radice raggruppa gli errori dietro un calo, così dieci risposte sbagliate che vengono da un solo articolo diventano una sola correzione. Rivaluti dopo ogni modifica per confermare che la correzione ha retto.

Lo veda sulle sue conversazioni. Prenoti una demo e porti un intento su cui il suo agente AI e il suo team non sono d’accordo.

Quando un centro delle policy è più di quanto le serve?

Un centro delle policy completo non fa ancora per lei quando il suo agente AI risponde solo a domande a partire da un piccolo centro assistenza, non compie azioni e gestisce qualche centinaio di conversazioni al mese. In quel caso bastano un responsabile per articolo, una data di revisione e una lettura mensile delle conversazioni dell’agente. I segnali che quella configurazione leggera non basta più:

• L’agente compie azioni (rimborsi, disdette, modifiche dell’account) invece di limitarsi a rispondere.
• Le sue policy cambiano per regione, piano o prodotto.
• Le policy cambiano più di una volta a trimestre, o con una data di entrata in vigore fissa.
• Gli operatori concedono eccezioni che poi i clienti chiedono all’agente AI.
• Più di un agente AI risponde agli stessi clienti. Ognuno deve rimandare alla stessa scheda, ed è parte del passaggio in sicurezza all’assistenza clienti agentica.

Come iniziare questa settimana

Inizi con un intento, non con l’intero centro assistenza. Una settimana basta per scrivere una sola scheda della policy, ripulire le fonti intorno a essa e iniziare a misurare se l’agente AI la segue.

1. Scelga un intento che coinvolge denaro, di solito rimborsi o disdette.
2. Raccolga ogni fonte che vi risponde: articoli, macro, pagine wiki, messaggi fissati in Slack, le istruzioni dell’agente.
3. Scriva una scheda della policy con il modello qui sopra, e faccia firmare limiti ed eccezioni al responsabile di business.
4. Ritiri o riscriva ogni fonte in disaccordo con la scheda, e tolga le pagine ritirate dalle fonti dell’agente.
5. Trasformi tre conversazioni fallite del passato in casi di test collegati alla scheda.
6. Valuti quell’intento per due settimane, classifichi ogni errore per causa e passi la checklist sulla deriva prima di iniziare la seconda scheda.

Domande frequenti

Che cos’è una knowledge base nel servizio clienti?

Una knowledge base è una raccolta di risposte che i suoi clienti e i suoi operatori possono consultare, come un centro assistenza con articoli del tipo “Come restituisco un articolo?”. Diventa la knowledge base di un agente AI quando l’agente recupera quegli articoli per rispondere ai clienti, ed è per questo che articoli superati o in conflitto si trasformano in risposte sbagliate su larga scala. Le regole che stanno dietro appartengono a schede della policy a cui gli articoli rimandano.

Le policy di un agente AI devono stare nel prompt o nella knowledge base?

In nessuno dei due da solo. I fatti appartengono alla knowledge base, le regole a una scheda della policy con un responsabile e una versione, e l’istruzione dell’agente dovrebbe rimandare a quella scheda invece di incollarne il testo. Un limite copiato in un prompt è la prima cosa che diventa obsoleta.

Un’azienda è responsabile quando il suo chatbot sbaglia una policy?

Può esserlo. Nel caso Moffatt v. Air Canada (2024 BCCRT 149), un tribunale della British Columbia ha ritenuto la compagnia aerea responsabile di ciò che il suo chatbot aveva detto a un cliente e ha respinto l’argomento secondo cui il chatbot era un’entità giuridica separata. Tratti ogni risposta di un agente AI come una dichiarazione della sua policy, e chieda una consulenza legale per il suo mercato.

Ogni quanto vanno riviste le policy di un agente AI?

Riveda ogni scheda a una data fissa stabilita in base al rischio (ogni mese per le regole su denaro e idoneità, ogni trimestre per le altre) e subito quando cambia la regola di business. Ogni settimana controlli per scheda gli errori di fedeltà alla policy e le escalation “policy poco chiara”.

Qual è la differenza tra un chatbot e un agente AI che compie azioni?

Un chatbot risponde alle domande a partire dai suoi contenuti. Un agente AI agisce anche: consulta l’ordine, applica la policy, emette il rimborso. Per questo un agente ha bisogno di policy con limiti, eccezioni e regole di escalation, non solo di articoli accurati.