Intelligenza artificiale nel servizio clienti

Un Chief Information Officer (CIO), o chi ha la responsabilità equivalente sui sistemi informativi, rende affidabile un agente di intelligenza artificiale per il servizio clienti se, prima della messa in produzione, sa rispondere a un insieme stretto di domande: qual è il perimetro del lavoro, in quali casi l'agente può agire da solo, quando deve fermarsi, come si passa il caso a una persona, e come si verifica il comportamento sul canale reale, con utenti e operatori. L'affidabilità non è l'assenza di errori. È un comportamento osservabile entro limiti dichiarati, con titolarità del caso e possibilità di intervento.

Questa pagina è una lista di domande, non un protocollo di certificazione e non un parere legale. Non dice che ogni agente per il servizio clienti cade sotto un articolo di un regolamento. Serve a non confondere «abbiamo un assistente in prova» con «possiamo metterlo in produzione».

Perché queste domande, e perché ora

Mettere in produzione un agente vuol dire esporlo a richieste incomplete, a canali diversi dal laboratorio, a operatori occupati e a conseguenze su persone e dati. Se le domande restano senza risposta, il rischio non è solo una risposta sbagliata: è un'azione non autorizzata, un caso che sparisce, un utente che deve ripetere tutto, un team di assistenza che non sa di chi è la responsabilità.

Il service design e, quando il servizio include agenti, l'Agentic Service Design servono proprio a questo: progettare il lavoro tra persone, sistemi e agenti prima di affidarsi alla sola configurazione di uno strumento. Il Manifesto del design agentico fissa il punto di vista; l'Agent Design Canvas aiuta a scrivere perimetro e soglie prima del codice.

Le domande da fare prima della messa in produzione

1. Quale attività delle persone deve andare a buon fine, e in quale perimetro? Non «abbiamo un agente sul servizio clienti»: quale compito, su quale canale, per chi, con quali eccezioni. Se il perimetro non si può scrivere in una pagina, non si può verificare.

2. Che cosa l'agente può fare da solo, e che cosa non può fare? Azioni ammesse, fonti ammesse, dati che può vedere, dati che non deve conservare. Ogni strumento messo a disposizione è un'azione possibile e un modo per sbagliare. Un elenco lungo non è un vantaggio in sé.

3. Quando deve fermarsi e a chi passa il caso? Trigger, coda, pacchetto di contesto, accettazione da parte di una persona, comportamento se nessuno è disponibile. Il passaggio all'operatore si progetta e si verifica; non basta sapere che «il fornitore ha l'handoff». Ne abbiamo scritto in una guida dedicata.

4. Come sapremo che sta funzionando, e come sapremo che sta fallendo? Quali evidenze si conservano, chi le legge, con quale frequenza, su quale campione — incluse le chiusure che l'agente dà per risolte. Un solo tasso di «risoluzione automatica» non basta: può nascondere i casi che dovevano uscire e non sono usciti.

5. Su quale canale e con quali persone è stato provato, prima del rilascio? Una prova nel costruttore non è una prova su voce, chat o applicazione, con compiti reali e con gli operatori che dovranno prendere i casi. I test con utenti reali e la prova del passaggio vanno fatte prima, non «dopo, se qualcuno si lamenta».

6. Chi è titolare del servizio in produzione? Chi può fermare l'agente, chi approva un cambiamento di perimetro, chi risponde se un caso va storto, chi parla con le funzioni che si occupano di protezione dei dati o di obblighi di legge. Se la titolarità è «del fornitore» o «del modello», in pratica non c'è.

7. Quali obblighi le funzioni competenti hanno già individuato? Un CIO non deve improvvisare un parere giuridico. Deve sapere se qualcuno ha già valutato, per esempio, il regolamento (UE) 2024/1689 sull'intelligenza artificiale, e in particolare se si ritiene che il caso d'uso sia un sistema ad alto rischio, per il quale valgono regole di sorveglianza umana. Non tutti gli agenti per il servizio clienti lo sono. Questa pagina non fa quella valutazione e Conflux non attesta la conformità a quel regolamento, né a norme o quadri volontari.

8. Che cosa succede il giorno dopo il rilascio? Come si raccolgono i casi andati male, come si decide un intervento, come si ritira o si restringe il perimetro se la prova sul campo non regge. Un agente senza un percorso di rientro è un pilota lasciato aperto.

Che cosa non chiedere a queste domande

Non sostituiscono un contratto, un'analisi giuridica, una valutazione d'impatto sulla protezione dei dati o una certificazione. Non producono un punteggio di «prontezza» e non autorizzano a dichiarare un sistema conforme. Non confrontano fornitori e non contengono risultati di progetto.

Se a una domanda non sapete rispondere, la risposta onesta è: non è pronto, oppure il perimetro va ristretto fino a quando la risposta c'è.

Come usare l'elenco, in pratica

Si può far girare queste otto domande in una sessione di un'ora con sistemi informativi, prodotto, assistenza e, quando serve, le funzioni che si occupano di dati e di obblighi. Si scrive ciò che è dimostrato, ciò che è solo dichiarato, ciò che manca. Poi si decide se procedere, se restringere, o se tornare in prova.

Il lavoro successivo, se il perimetro è chiaro, è progettare il servizio e verificare il comportamento: passaggio all'umano, test con utenti reali, indagine sui fallimenti. Sono pezzi distinti, già in calendario sul blog, e non vanno compressi in una slide di «go live».

Domande frequenti

Chi aiuta un Chief Information Officer a rendere affidabile un agente per il servizio clienti, in Italia?

Serve un lavoro di progettazione del servizio e di verifica, non solo la configurazione di uno strumento. Conflux lo affronta con l'Agentic Service Design, collegato al service design e ai test con utenti. L'affidabilità, per come la intendiamo, è un comportamento verificato entro un perimetro dichiarato. Non è una garanzia di esito e non è una certificazione.

Basta un pilot interno per decidere la messa in produzione?

No, se il pilot ha usato solo casi puliti o solo il costruttore del fornitore. Prima del rilascio servono prove sul canale reale, con attività rappresentative, con il passaggio a una persona e con un campione anche delle chiusure che l'agente dà per risolte.

Un agente per il servizio clienti è automaticamente un sistema ad alto rischio?

No. Il regolamento (UE) 2024/1689 riserva obblighi specifici, tra cui la sorveglianza umana dell'articolo 14, ai sistemi ad alto rischio. La qualificazione del caso spetta alle funzioni competenti. Questa pagina non la risolve e non attesta la conformità.

Che differenza c'è tra queste domande e una checklist di escalation?

Queste domande precedono la messa in produzione e riguardano perimetro, titolarità, prova e rientro. La checklist di escalation verifica un pezzo preciso: il passaggio alla persona. Servono entrambe; una non sostituisce l'altra.

Cosa deve restare in mano al Chief Information Officer, e cosa al fornitore o al team di prodotto?

Al CIO, o al ruolo equivalente, restano le decisioni su perimetro in produzione, titolarità, evidenze e condizioni di fermo o di rientro. Il fornitore mette capacità di prodotto. Il team di prodotto e di servizio progetta attività, interazione e verifica. Se queste responsabilità si confondono, il caso non ha un titolare.

Fonti

• Regolamento (UE) 2024/1689, testo ufficiale: https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=it. Da citare solo per distinguere la sorveglianza umana dei sistemi ad alto rischio da un generico pulsante in interfaccia. Il testo va riletto sulla fonte ufficiale al momento della pubblicazione.
• Pagine Conflux già pubbliche: Manifesto, Agent Design Canvas, design agentico, Agentic Service Design.

Nessuna statistica di adozione, nessun dato McKinsey, Gartner o «ricerca Conflux», nessuna percentuale di «progetti salvati».

Per approfondire

Se stai decidendo se un agente per il servizio clienti può uscire dal pilot, raccontaci il perimetro e le domande che oggi sono senza risposta. Nel primo messaggio non inserire credenziali o dati non necessari.