L’AI Act entra sempre più concretamente nei processi di Customer Service. Dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell’articolo 50 del Regolamento europeo sull’intelligenza artificiale, che interessano anche i sistemi progettati per interagire direttamente con le persone. Il principio è chiaro: l’interlocutore deve essere informato che sta dialogando con un sistema AI, salvo che la natura dell’interazione risulti evidente in base alle circostanze e al contesto. A luglio 2026 la Commissione europea ha pubblicato anche le linee guida dedicate all’applicazione di questi obblighi.
Nel servizio clienti, però, informare l’utente è soltanto l’inizio. L’AI può elaborare dati personali, accedere a basi di conoscenza aziendali, attraversare infrastrutture e servizi differenti, suggerire risposte agli operatori oppure dialogare autonomamente con il cliente. Ogni passaggio porta con sé scelte su accessi, sicurezza, responsabilità e controlli. “L’impatto più concreto riguarda la trasparenza e quindi la consapevolezza dell’utente che sta interagendo con un sistema di intelligenza artificiale”, spiega Simona Bellarmino, Legal Compliance and Regulatory Manager di BDP. “Ma nel Customer Service entrano in gioco anche il trattamento dei dati personali, la sicurezza, la qualità del dato, la gestione dei fornitori e la responsabilità organizzativa”.
Il punto, prosegue Bellarmino, è rendere operativi requisiti che sulla carta possono apparire generali: “Bisogna capire quali dati si possono utilizzare, quali risposte possono essere fornite autonomamente, come gestire gli errori e come monitorare le performance nel tempo. È questo il passaggio dalla compliance alla governance dell’AI”.
Indice degli argomenti
AI Act e Customer Service: capire quale ruolo affidare all’AI
Nel Customer Service l’intelligenza artificiale può occupare posizioni molto diverse. Può rivolgersi direttamente al cliente oppure lavorare dietro le quinte, assistendo l’operatore nella ricerca delle informazioni, nella sintesi di una conversazione o nella preparazione di una risposta. “Abbiamo due lati della medaglia”, osserva Andrea Bocerani, Chief Operations Officer e Chief Information Security Officer di BDP. “Da una parte c’è la relazione dell’azienda con il cliente, dall’altra l’utilizzo delle tecnologie di AI da parte degli operatori del Customer Service. Parliamo quindi di bot rivolti al pubblico e di strumenti interni a supporto dell’operatore”.
La differenza incide direttamente sulle scelte di progetto. Se l’AI suggerisce una risposta, resta una persona a valutarla prima che raggiunga il cliente. Se il sistema gestisce autonomamente la conversazione, occorre definire con maggiore precisione il perimetro entro il quale può agire e i casi nei quali deve cedere la gestione a un operatore.
C’è poi una complessità meno visibile all’utente. Dietro una singola conversazione possono lavorare più componenti: riconoscimento vocale, trascrizione, interpretazione del linguaggio, motore generativo, knowledge base, sintesi vocale e collegamenti con applicazioni aziendali. “Un voicebot può utilizzare diversi strumenti di intelligenza artificiale”, precisa Bocerani. “Posso avere un componente che trascrive la voce in testo, uno che interpreta il testo e raccoglie l’informazione e un altro che si occupa della sintesi vocale. Questo ha un impatto sui dati che attraversano i vari componenti: bisogna sapere dove vengono conservati, chi può accedervi e per quanto tempo”. Governare l’AI significa quindi ricostruire il percorso dell’informazione anche quando, agli occhi del cliente, il servizio appare come un’unica interfaccia.
Risposte plausibili ma errate: di chi è la responsabilità?
Con l’AI generativa emerge un rischio specifico: ottenere contenuti linguisticamente credibili che non corrispondono ai fatti. Nel Customer Service un errore di questo tipo può produrre conseguenze immediate, perché la risposta arriva attraverso un canale riconducibile all’azienda.
“Il rischio principale è pensare che il rischio sia soltanto tecnologico”, sottolinea Bellarmino. “Un sistema può produrre risposte errate, utilizzare dati in modo non appropriato, generare discriminazioni o comportamenti non allineati con le regole aziendali. Poi c’è la questione dell’accountability: chi risponde quando il sistema fornisce un’informazione sbagliata al cliente?”.
La domanda ha già trovato riscontro nella giurisprudenza. Nel caso Moffatt v. Air Canada, deciso nel 2024, un chatbot aveva fornito indicazioni errate a un cliente sulle condizioni per ottenere una tariffa agevolata. Il Civil Resolution Tribunal della British Columbia ha ritenuto la compagnia responsabile dell’informazione resa attraverso il proprio servizio automatizzato. Il caso mostra quanto sia difficile separare, agli occhi del cliente e sul piano della responsabilità, la risposta del bot dal servizio erogato dall’organizzazione.
Un orientamento significativo è arrivato anche dalla Germania. Il 28 maggio 2026 il Tribunale regionale di Monaco I ha stabilito che Google poteva essere ritenuta direttamente responsabile per informazioni scorrette contenute nelle proprie AI Overviews, considerando il testo generato dal sistema come una dichiarazione propria e non come una semplice riproposizione di risultati di terzi.
Bocerani richiama anche un secondo rischio, meno evidente: la possibilità che il sistema renda accessibili informazioni che non dovrebbero uscire dal perimetro previsto. “Se costruisco un bot devo stare molto attento a come viene definito il dominio di conoscenza. Potrei mettere a disposizione di concorrenti o soggetti con finalità malevole informazioni che non voglio vengano diffuse”. Il controllo, di conseguenza, deve riguardare sia la correttezza dell’output sia le fonti che il sistema può interrogare, i dati che può recuperare e le condizioni nelle quali può restituirli.
Provider e deployer, una responsabilità distribuita
Uno degli errori più frequenti consiste nel far coincidere la conformità del fornitore con quella del progetto. “La scelta di un fornitore compliant non dà automaticamente come risultato un utilizzo compliant della tecnologia”, osserva Bellarmino. Per stabilire le responsabilità occorre entrare nel caso d’uso concreto e ricostruire ruoli, obblighi e punti di accountability.
L’AI Act distingue, tra gli altri, il provider, che sviluppa un sistema AI o lo fa sviluppare e lo immette sul mercato con il proprio nome o marchio, e il deployer, che lo utilizza sotto la propria autorità, con le eccezioni previste dal Regolamento. Il rapporto può diventare articolato quando il progetto comprende più tecnologie, un integratore e uno o più fornitori di modelli.
“Il fornitore deve garantire ciò che rientra nelle sue competenze: caratteristiche del sistema, documentazione, informazioni sui limiti delle prestazioni, misure tecniche e gli eventuali adempimenti previsti come provider”, chiarisce Bellarmino. “L’azienda che usa il sistema deve invece sapere perché lo utilizza, con quali finalità, con quali dati, quali rischi corre e quali controlli mette in atto”. Inoltre la divisione delle responsabilità va aggiornata quando cambia il progetto. “Questo processo continua per tutta la vita del servizio”, aggiunge Bocerani. “Si può partire facendo un’analisi molto accurata e poi trascurarla durante l’evoluzione del progetto. Con l’AI anche cambiamenti che sembrano piccoli possono avere un impatto considerevole”.
Dalla norma al progetto: la trasparenza deve diventare verificabile
Dire che un sistema deve essere trasparente serve poco a chi deve progettarlo. La conformità diventa concreta quando il principio normativo viene trasformato in una condizione che può essere implementata e verificata. “Il requisito di progetto non può essere ‘il sistema deve essere trasparente’”, spiega Simona Bellarmino. “Bisogna stabilire come informiamo l’utente, in quale momento e con quali modalità. Se il rischio riguarda la protezione dei dati, bisogna definire quali dati sono utilizzabili, chi vi accede, quanto vengono conservati e quando vengono cancellati”.
L’articolo 50 offre un esempio immediato: l’obbligo di rendere consapevole la persona dell’interazione con un sistema AI richiede una scelta concreta sull’interfaccia e sul momento della comunicazione. Le linee guida pubblicate dalla Commissione il 20 luglio 2026 puntano proprio a chiarire il perimetro di questi obblighi per provider e deployer.
Lo stesso metodo può essere applicato alla supervisione, alla sicurezza e alla gestione delle anomalie. Significa stabilire a monte quali richieste può trattare l’AI, quando un output richiede verifica, che cosa deve generare un’escalation e chi ha il potere di bloccare il processo. Per Bellarmino, da qui deriva la necessità di far entrare compliance, legal, privacy e sicurezza nel progetto fin dalla progettazione, mantenendole coinvolte anche durante l’esercizio.
Human oversight: esserci non basta
La presenza di un operatore nel processo non garantisce da sola una supervisione efficace. Per i sistemi ad alto rischio, l’AI Act richiede che l’human oversight sia affidato a persone con competenza, formazione, autorità e supporto adeguati. Il Regolamento prevede inoltre che chi esercita la supervisione possa comprendere capacità e limiti del sistema, interpretarne gli output, individuare anomalie, ignorare o ribaltare un risultato e, quando necessario, interromperne il funzionamento.
La Legal Manager di BDP propone di estendere questa logica anche oltre le fattispecie espressamente classificate ad alto rischio. “La persona coinvolta deve capire le caratteristiche e i limiti del sistema, riconoscere un output anomalo e avere l’autorità per correggere o interrompere il processo. La domanda da farsi non è se c’è un essere umano coinvolto, ma se quell’essere umano è davvero in grado di esercitare un controllo significativo“.
Nel Customer Service questa scelta prende forma nelle regole di escalation. Si può passare a un operatore perché l’AI non comprende correttamente una richiesta, ma anche perché l’azienda decide che alcune questioni, per rilevanza o delicatezza, debbano essere gestite da una persona. Il passaggio deve però preservare ciò che è già avvenuto nella conversazione. “L’operatore deve avere contezza di tutto il dialogo precedente”, osserva il COO Bocerani. “Non possiamo ricreare il problema dei vecchi sistemi automatici, in cui il cliente arrivava all’operatore e doveva ricominciare da capo. Verifica, controllo e correzione delle interazioni automatizzate devono entrare stabilmente nel flusso operativo”.
AI literacy, la formazione deve seguire ruoli e rischi
La governance dell’AI passa anche dalle competenze. L’articolo 4 dell’AI Act richiede a provider e deployer di adottare misure a sostegno dell’AI literacy del personale e delle altre persone che utilizzano i sistemi per loro conto. Dopo le modifiche entrate in vigore nel luglio 2026, la disposizione non impone un livello individuale uniforme: le misure devono tenere conto delle conoscenze tecniche, dell’esperienza, della formazione e del contesto nel quale l’AI viene utilizzata.
“L’AI non riguarda soltanto l’IT”, osserva Bellarmino. “Coinvolge legal e compliance, operations, privacy, security, HR, procurement, business e naturalmente il management”. BDP, ad esempio, ha affrontato questo passaggio adottando una policy interna sull’utilizzo dell’intelligenza artificiale, portata all’approvazione del consiglio di amministrazione. La policy considera l’uso quotidiano degli strumenti AI, il loro impiego nelle attività di sviluppo e i prodotti o servizi che incorporano componenti di intelligenza artificiale.
Formazione, peraltro, non significa necessariamente concedere lo stesso accesso agli stessi strumenti a tutte le persone. La manager porta l’esempio delle risorse junior: in alcune attività l’organizzazione potrebbe decidere un utilizzo controllato dell’AI, perché cercare le informazioni, verificarle e rielaborarle autonomamente fa parte del processo di apprendimento. “Bisogna capire come massimizzare l’aiuto che può dare l’intelligenza artificiale e, contemporaneamente, chiedersi quando sia meglio che una persona svolga da sola un’attività per costruire competenze e consapevolezza”.
Governance dell’AI: partire dall’inventario dei casi d’uso
Per passare dalla conformità alla governance occorre prima di tutto sapere dove l’AI è già presente. “La prima cosa è costruire un inventario dei sistemi e dei casi d’uso presenti in azienda, compresi quelli introdotti dalle singole funzioni o attraverso fornitori esterni”, spiega Bellarmino. “È un momento importante, perché spesso proprio attraverso la mappatura emergono utilizzi che non erano stati considerati a livello centrale”.
Dopo l’inventario viene la classificazione del rischio. Guardare esclusivamente alle categorie dell’AI Act sarebbe riduttivo: l’analisi deve comprendere anche privacy, cybersecurity, diritti delle persone, reputazione e impatto sul business. A quel punto si può definire il sistema di governance: chi approva un nuovo caso d’uso, chi ne è responsabile, quali controlli sono richiesti e con quale frequenza devono essere riesaminati.
Il quarto passaggio riguarda il ciclo di vita. Modelli, fornitori, dati e modalità di utilizzo cambiano rapidamente. Il go live segna quindi l’inizio della fase di controllo, non la sua fine. “Non devo chiedermi soltanto se il processo, il prodotto o il servizio sono conformi alla normativa”, sintetizza Bellarmino. “Devo chiedermi se sono in grado di governarli nel tempo”. A questa esigenza il COO Bocerani aggiunge quella della velocità decisionale. “La governance non deve rallentare l’adozione di strumenti che sono in continua evoluzione. I processi devono essere snelli, ma tutti devono avere chiari i rischi e sapere quali meccanismi aziendali attivare quando vogliono introdurre un nuovo strumento o estendere quello esistente a un altro caso d’uso”.
È questo, in definitiva, il cambio di prospettiva richiesto alle organizzazioni. La compliance fotografa un requisito in un determinato momento, mentre la governance deve seguirne l’evoluzione operativa. Nel Customer Service significa conoscere i sistemi utilizzati, i dati che attraversano, l’autonomia concessa all’AI, le responsabilità dei diversi attori e le condizioni che richiedono l’intervento di una persona. Un lavoro continuo, perché continuo è il cambiamento di modelli, processi e modalità d’uso.
Articolo realizzato in collaborazione con Base Digitale Platform
Partecipa alla community