Come scegliere una soluzione di IA per l’assistenza clienti in base all’attività, ai dati e al rischio

Parti dal risultato che vuoi ottenere

Scegliere una soluzione di IA per l’assistenza clienti non significa partire dalla scelta di un modello. Occorre innanzitutto descrivere il lavoro che si vuole modificare e il risultato che si considererà soddisfacente. «Migliorare il supporto» è un obiettivo troppo ampio per orientare una decisione: potrebbe voler dire classificare i messaggi con meno intervento umano, trovare più facilmente informazioni aggiornate, preparare bozze per un operatore oppure completare un’azione richiesta da un cliente. Ogni obiettivo richiede dati, controlli e verifiche diversi.

Delimita il caso rispondendo a cinque domande: quali richieste arrivano, attraverso quali canali e in quali lingue; chi riceve oggi ciascuna richiesta; quale risultato deve produrre il sistema; quali eccezioni restano fuori; e chi interviene quando il sistema non riesce a risolvere il caso. Definisci anche che cosa significa risolvere un contatto: inviare una risposta non equivale necessariamente a fornire una soluzione corretta, e chiudere un ticket non dimostra da solo che l’esigenza sia stata soddisfatta.

Tieni distinto l’obiettivo operativo da quello di automazione. Ridurre il tempo necessario a preparare una risposta può essere utile anche se una persona continua a controllarla. Al contrario, ridurre il numero di operatori coinvolti non dovrebbe essere considerato un successo se aumentano le risposte errate, le rettifiche o i contatti ripetuti. Sono criteri proposti per progettare una valutazione: vanno adattati alle politiche, al servizio e agli impegni di ogni organizzazione.

Classifica l’attività prima di scegliere la tecnologia

Nella stessa conversazione possono comparire più attività, ma conviene valutarle separatamente. Classificare e instradare significa assegnare una categoria o una coda; recuperare informazioni significa trovare contenuti pertinenti; redigere significa proporre una risposta; riassumere significa condensare uno scambio; eseguire un’azione significa modificare qualcosa al di fuori della conversazione, per esempio un account o un sistema di ticket. Più l’attività si avvicina alla modifica dello stato di un account, più diventano importanti l’autorizzazione, la verifica e la possibilità di annullare la modifica.

Non tutte queste attività richiedono la generazione di testo. Se una richiesta si riconosce attraverso campi stabili e regole chiare, un’automazione convenzionale può essere più semplice da testare e mantenere. Un classificatore circoscritto può essere utile quando il linguaggio varia in modi che le regole non gestiscono bene; un sistema generativo può essere pertinente se occorre interpretare una domanda e formulare una risposta. La scelta dipende dal contesto: il fatto che l’interazione avvenga via chat non dimostra, da solo, che un modello generativo sia l’opzione migliore.

Le fonti disponibili trattano l’IA nell’assistenza clienti come un ambito di automazione e supporto, ma le informazioni fornite non confrontano in modo indipendente l’efficacia dei diversi modelli né consentono di affermare che uno sia superiore agli altri. Considera quindi il confronto un’ipotesi da verificare su richieste rappresentative del tuo servizio, non una promessa di risultato.

Adatta il livello di delega alle conseguenze di un errore

Il livello di autonomia non dovrebbe dipendere soltanto dalla difficoltà tecnica. Chiediti che cosa potrebbe accadere se la risposta fosse errata, incompleta o applicata all’account sbagliato. Una spiegazione generale, facile da controllare e senza effetti duraturi non presenta lo stesso tipo di rischio di una decisione che modifica un account, incide su un pagamento o condiziona l’accesso a un servizio. Contano anche la reversibilità, il tempo disponibile per correggere il problema e la reale possibilità che una persona intervenga.

Come quadro operativo, distingui tre livelli. Nel primo, il sistema organizza o cerca informazioni, ma non risponde al cliente né modifica il suo account. Nel secondo, prepara una risposta o una raccomandazione che una persona convalida prima dell’invio. Nel terzo, può rispondere o eseguire azioni entro limiti espliciti. Passare da un livello all’altro richiede prove che quello precedente soddisfi i criteri concordati e controlli adeguati per il successivo; non occorre automatizzare di più per dimostrare che una soluzione è utile.

Prevedi una possibilità visibile di astenersi e di inoltrare il caso. Se mancano dati, la richiesta è ambigua, le fonti non concordano o il cliente contesta una decisione, il sistema dovrebbe poter interrompere la risoluzione automatica. Nei casi delicati, la possibilità per una persona di rivedere il risultato deve essere più di una semplice registrazione: la persona deve disporre di un contesto sufficiente, dell’autorità per correggere il risultato e di una procedura per fermare l’azione.

L’Agenzia spagnola per la protezione dei dati include tra i propri materiali una guida sull’IA agentica, un ambito pertinente quando un sistema può svolgere attività. La nota disponibile ne conferma la pertinenza generale, ma non fornisce dettagli sufficienti per attribuire alla guida regole specifiche su autorizzazione, revisione o progettazione. I controlli di questa sezione sono quindi criteri decisionali proposti e vanno confrontati con le politiche e gli obblighi applicabili al caso.

Esamina i dati prima di collegarli

Fai l’inventario delle fonti che ogni modello utilizzerebbe: messaggi in arrivo, cronologia delle conversazioni, registri degli account, documentazione di supporto, politiche interne o informazioni sui prodotti. Per ciascuna fonte, annota chi ne è responsabile, quando è stata aggiornata, chi è autorizzato a consultarla e se contiene dati personali, riservati o informazioni che non dovrebbero uscire dall’ambiente previsto. Non presumere che una base documentale sia sicura o aggiornata solo perché è già utilizzata dal servizio di assistenza.

Riduci al minimo i dati necessari per l’attività. Per classificare una richiesta potrebbe non essere necessario trasferire l’intera cronologia dell’account; per rispondere sulla base della documentazione potrebbe bastare recuperare il contenuto pertinente, invece di includere grandi quantità di dati nel prompt. Valuta se sia possibile escludere, oscurare o sostituire le informazioni identificative e verifica, sulla base di documentazione primaria aggiornata, quale trattamento preveda ogni servizio esterno preso in considerazione. Le informazioni disponibili qui non consentono di affermare quali siano le politiche specifiche dei fornitori in materia di conservazione, sicurezza o uso dei dati.

Registra anche le condizioni d’uso e le responsabilità interne. La guida alle buone pratiche di PwC individuata tra le fonti tratta questioni di privacy e decisioni sulla raccolta e sull’uso dei dati, ma le prove disponibili consistono in un estratto, non in un esame completo delle sue raccomandazioni. Considerala un’indicazione del fatto che la privacy debba rientrare nella valutazione, non un sostituto di una verifica legale, di sicurezza o delle politiche applicabili all’organizzazione.

Se le informazioni cambiano spesso, assegna a una persona o a un team la responsabilità di rivedere i documenti, le date di validità e i contenuti ritirati. Progetta un test che verifichi non solo se il sistema trova una risposta, ma anche se distingue tra informazioni aggiornate, incomplete e contraddittorie. Se non puoi stabilire quale fonte sia autorevole per ciascun argomento, è prematuro chiedere al sistema di rispondere senza revisione.

Scegli il modello minimo sufficiente per l’attività

Per classificare e instradare, confronta le regole esistenti con un’alternativa basata sulla classificazione. Valuta entrambe su messaggi diversi, inclusi quelli con più questioni, errori di battitura o informazioni insufficienti. La domanda non è soltanto quale percentuale venga assegnata correttamente, ma anche quali categorie concentrino gli errori, come vengano corretti e che cosa succeda quando il sistema non ha sufficiente sicurezza nel risultato. Se le regole risolvono già il problema con chiarezza e a un costo operativo accettabile, sostituirle con la generazione di testo può aggiungere complessità senza apportare un valore dimostrato.

Per cercare risposte nella documentazione, delimita innanzitutto la raccolta consultabile e definisci come riconoscere una risposta supportata dalle fonti. Un test utile include domande la cui risposta è presente nella documentazione, domande che non vi trovano risposta e domande per le quali il contenuto è obsoleto o contraddittorio. Verifica che il sistema possa indicare la fonte utilizzata e astenersi quando non ci sono prove sufficienti. Mostrare una citazione o un estratto non garantisce, da solo, che la risposta sia corretta: una persona deve verificare che la fonte sia pertinente alla domanda e ancora valida.

Per redigere o riassumere, tratta il risultato come una bozza. Definisci che cosa può modificare l’operatore prima dell’invio e controlla gli errori di contesto, le omissioni, il tono inappropriato e le promesse non autorizzate. Se il team non può dedicare tempo alla revisione e alla correzione, il risparmio ipotizzato dal produrre più bozze potrebbe svanire. Misura l’utilità in base al lavoro effettivamente risparmiato e alla qualità, non contando soltanto i testi generati.

Per eseguire azioni, limita le operazioni disponibili e separa l’interpretazione della richiesta dall’autorizzazione a effettuare una modifica. Prima di un’azione, verifica l’identità e le autorizzazioni secondo le procedure vigenti dell’organizzazione. Per un primo test, valuta operazioni reversibili e di portata ridotta, registrando ciò che è stato richiesto, autorizzato ed eseguito. La verifica successiva deve confermare lo stato effettivo del sistema, non limitarsi a fidarsi del messaggio restituito dal modello.

Questi modelli possono essere combinati, ma farlo moltiplica gli aspetti da verificare: recupero delle informazioni, interpretazione, generazione, integrazione ed esecuzione. Inizia con un flusso ridotto, registra dove si verificano gli errori e aggiungi componenti solo se risolvono una carenza osservata.

Confronta costi e condizioni operative

Confronta il costo per caso risolto, non soltanto il prezzo di una chiamata o di una licenza. Se pertinente, includi l’integrazione con il sistema di ticket, l’infrastruttura, la manutenzione delle regole o della documentazione, la supervisione, il tempo dedicato alla revisione umana, la correzione degli errori e la gestione dei casi inoltrati. Misura il costo usando un volume e una definizione di risoluzione comparabili con quelli del processo attuale; altrimenti il confronto potrebbe riguardare attività diverse.

Anche il funzionamento quotidiano condiziona la scelta. Verifica se l’integrazione può mostrare all’operatore il contesto necessario, se la latenza è compatibile con il canale, chi mantiene la base di conoscenza, che cosa accade se una dipendenza non è disponibile e chi è responsabile di rivedere i risultati. Se il servizio è coperto anche fuori orario, definisci chiaramente che cosa può essere risolto senza una persona e che cosa deve attendere o essere inoltrato. Non presumere che «disponibile» significhi «risolto».

La guida aziendale di Softeng individuata tra le fonti affronta casi d’uso, governo dei dati, sicurezza e ritorno. Questa descrizione giustifica l’inclusione di tali dimensioni nella valutazione, ma non fornisce da sola dati comparabili sui costi o sulle prestazioni di un team specifico. Analogamente, il materiale generale di IBM sull’IA nell’assistenza clienti offre un orientamento contestuale, non prove indipendenti dell’efficacia o dei risultati attesi.

Progetta un test che possa cambiare la decisione

Prima della distribuzione, prepara un campione che rispecchi le richieste reali ma includa anche casi difficili: messaggi ambigui, richieste fuori ambito, modifiche alle politiche, conversazioni con più esigenze e assenza di informazioni essenziali. Definisci chi esamina ogni risultato e secondo quali criteri. Se si testano solo esempi semplici, scelti per mostrare il sistema nelle condizioni migliori, il risultato non fornisce un quadro affidabile dell’uso quotidiano.

Concordate in anticipo gli indicatori e le soglie che faranno proseguire, rivedere o interrompere il test. A seconda dell’attività, può essere utile misurare la correttezza della classificazione per categoria, le risposte supportate da fonti aggiornate, gli inoltri appropriati, gli errori gravi, il tempo necessario per arrivare a una risposta utile, il tempo di revisione e il costo per caso risolto. Non trasformare un indicatore generale in una decisione automatica: una media favorevole può nascondere errori concentrati in una categoria o in un gruppo di richieste.

Confronta il test con il processo attuale usando le stesse categorie di richieste e una definizione condivisa di risultato corretto. Registra gli errori e le loro conseguenze, non soltanto la frequenza. Distingui un errore che un operatore può correggere prima dell’invio da un’azione già eseguita che ha modificato un account. In caso di incidenti o risultati inattesi, stabilisci chi decide se sospendere il flusso e come tornare alla procedura precedente.

Una scheda decisionale utile documenta il caso, il modello scelto, i dati consentiti, i casi esclusi, la revisione necessaria, le metriche, le soglie e la persona responsabile. Registra anche ciò che non è ancora noto. In questo modo, confrontare alternative o scoprire nuovi casi d’uso non obbliga a ripartire da zero con le domande su rischi e operatività.

Decidi sulla base delle prove e mantieni aperta la revisione

La scelta non consiste semplicemente nell’adottare o rifiutare l’IA. Può significare mantenere un’automazione convenzionale, testare la classificazione in una sola categoria, usare la ricerca con bozze sottoposte a revisione oppure interrompere l’iniziativa finché i dati e il processo non siano stati messi in ordine. Se la principale incertezza riguarda la qualità della documentazione, un test di ricerca può offrire più indicazioni che automatizzare le risposte. Se non è possibile verificare un’azione o rimediare a un errore, mantieni l’esecuzione sotto controllo umano.

Per esplorare le opzioni, separa tre domande: quale soluzione è adatta all’attività; come si confrontano i modelli possibili a parità di condizioni; e quali altri casi d’uso potrebbero avere senso in seguito. Questa sequenza aiuta a scegliere un ambito concreto, confrontare le alternative con criteri coerenti e individuare opportunità senza confonderle con casi già convalidati.

Le fonti fornite offrono indicazioni contestuali sull’IA aziendale, sull’assistenza clienti, sulla privacy e sui sistemi agentici. Non bastano per determinare quale fornitore soddisfi requisiti specifici, quale sarà il costo di un’implementazione, come un servizio conserverà i dati o quali norme vigenti si applichino a uno specifico settore o Paese. Prima di inviare dati, acquistare un servizio o automatizzare una decisione, verifica questi aspetti nella documentazione primaria e con le funzioni responsabili.

Il criterio pratico finale è semplice: inizia con un’attività circoscritta, conserva l’intervento umano dove le conseguenze lo richiedono e amplia l’uso soltanto quando un test rappresentativo dimostra che il risultato è accettabile, gestibile e sostenibile. Se le prove non sono sufficienti, astenersi o mantenere il processo attuale può essere la scelta giusta.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.