Valutare i fornitori di chatbot: DPA, subresponsabili e trasferimenti verso paesi terzi

Un fornitore di chatbot può presentare una demo convincente, una regione UE e un contratto di nomina a responsabile del trattamento (DPA) già pronto – e tuttavia rimangono aperte domande cruciali. Perché non è soltanto il chatbot visibile a elaborare i dati. Spesso API di modelli, hosting, database vettoriali, analisi degli errori, strumenti di supporto, servizi e-mail e backup partecipano all'erogazione del servizio. Per i gestori di siti web conta quindi la catena di trattamento verificabile, non lo slogan sulla privacy presente in una pagina di vendita.

Questa checklist aiuta ad effettuare una verifica strutturata del fornitore prima dell'acquisto e del Go-live. È un orientamento pratico e non costituisce una consulenza legale. Ruoli, basi giuridiche, obblighi di informazione e meccanismi di trasferimento devono essere verificati per il caso d'uso concreto; in presenza di rischi elevati, categorie particolari di dati o questioni contrattuali aperte, è necessario coinvolgere il Responsabile della Protezione dei Dati (DPO) o una consulenza legale qualificata.

Prima comprendere il flusso di dati, poi valutare il contratto

La domanda centrale non è solo "Dove si trova il server?", ma: quali dati personali arrivano a quale persona giuridica, quando, per quale motivo e per quanto tempo? Un visitatore può inserire nella chat nomi, indirizzi e-mail, numeri cliente o testo libero. In aggiunta si generano indirizzi IP, marcatura temporale (timestamp), informazioni sul dispositivo, identificativi di sessione, cronologie della conversazione, valutazioni e log tecnici. Anche da una conversazione presunta anonima può nascere un riferimento personale attraverso la combinazione di più elementi.

Disegnate quindi una mappa semplice del flusso di dati prima di esaminare il contratto. Dovrebbe includere almeno il widget del browser, la piattaforma chatbot, la knowledge base, il fornitore del modello, i servizi di analisi ed errori, gli accessi di supporto, i backup e i percorsi di cancellazione. Per ogni stazione si rilevano gestore, paese, finalità, categorie di dati, durata di conservazione e possibili accessi da remoto. Un'affermazione del tipo "Hosting UE", ad esempio, non risponde alla domanda se un team di supporto al di fuori dello Spazio Economico Europeo possa accedere a log di produzione.

Determinare i ruoli privacy in base alla finalità

Se un fornitore sia un responsabile del trattamento o un titolare autonomo per singole finalità deriva dall'attività effettivamente svolta. Le linee guida 07/2020 del Comitato Europeo per la Protezione dei Dati chiariscono questa distinzione. Un fornitore può ad esempio trattare i dati di conversazione su istruzione documentata, ma rivendicare un ruolo diverso per determinate finalità proprie di sicurezza, fatturazione o miglioramento del prodotto. Chiedete di attribuire esplicitamente ogni finalità al rispettivo ruolo e alla relativa base giuridica. Un DPA non copre automaticamente le finalità autonome del fornitore.

Verificare il DPA: i contenuti obbligatori devono corrispondere al servizio reale

L'Articolo 28 del GDPR richiede che i titolari ricorrano unicamente a responsabili del trattamento che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate. Il contratto deve fissare, tra l'altro, oggetto e durata, natura e finalità, tipo di dati, categorie di interessati nonché diritti e obblighi del titolare. A ciò si aggiungono istruzioni documentate, riservatezza, sicurezza, assistenza per i diritti degli interessati e obblighi di protezione dei dati, cancellazione o restituzione, oltre a informazioni e collaborazione per le verifiche.

Confrontate il DPA non solo con un elenco di controllo standard, ma con la vostra mappa del flusso di dati e con il piano tariffario effettivamente sottoscritto. Un buon contratto descrive in modo comprensibile l'operatività della chat, l'addestramento o l'indicizzazione della knowledge base, la registrazione dei log, gli accessi di supporto e le funzioni opzionali. Termini generici poco chiari come "miglioramento del servizio" dovrebbero essere scomposti in dati concreti, finalità, opzioni e ruoli.

• Istruzioni: È chiaro che i contenuti e i metadati vengono trattati solo per finalità documentate del cliente? Quale configurazione viene considerata come istruzione?
• Utilizzo per i modelli: Prompt, risposte o contenuti caricati vengono utilizzati per l'addestramento generale di modelli o per il miglioramento del prodotto? In caso negativo, ciò deve essere contrattualmente e tecnicamente verificabile; in caso affermativo, il ruolo e la base giuridica devono essere valutati separatamente.
• Cancellazione: Esistono scadenze concrete per la cronologia delle conversazioni, log, indici vettoriali, backup e copie di supporto? Cosa succede alla fine del contratto?
• Sicurezza: Sono descritti i controlli di accesso, l'isolamento tra tenant, la crittografia, la registrazione dei log, la gestione delle vulnerabilità e le procedure di gestione degli incidenti?
• Assistenza: Il DPA regola in modo pratico l'esportazione, la rettifica, la cancellazione, l'accesso, gli incidenti di sicurezza ed eventualmente le valutazioni d'impatto sulla protezione dei dati (DPIA)?
• Prove: I report di audit, le certificazioni o altre prove affidabili sono disponibili e si applicano esattamente ai servizi e alle sedi utilizzati?

I certificati e le relazioni di audit possono fornire indicazioni importanti, ma non sostituiscono né l'esame della concreta operazione di trattamento né clausole contrattuali adeguate. Anche un DPA standardizzato è valido solo nella misura in cui i suoi allegati sono compilati e corrispondono alla realtà tecnica.

Subresponsabili del trattamento: controllare nomi, compiti e modifiche

Ai sensi dell'Articolo 28, paragrafo 2 del GDPR, il responsabile del trattamento non ricorre a un altro responsabile senza previa autorizzazione scritta specifica o generale del titolare del trattamento. In caso di autorizzazione scritta generale, il responsabile deve informare il titolare di eventuali modifiche previste riguardanti l'aggiunta o la sostituzione di altri responsabili, dando al titolare l'opportunità di opporsi. Le Domande e Risposte della Commissione Europea sulle Clausole Contrattuali Tipo chiariscono inoltre che le mere categorie non sono sufficienti: i singoli subresponsabili devono essere nominati.

Richiedete un elenco aggiornato ed esportabile contenente ragione sociale, paese, servizio concreto e dati interessati. Verificate inoltre se un'azienda è solo la controparte contrattuale o se effettivamente effettua il trattamento in più sedi. Particolarmente rilevanti sono i fornitori di modelli ed embedding, cloud hosting, database, CDN, monitoraggio, analisi degli errori, supporto, e-mail e backup. Per ogni voce deve essere chiaro se i dati vengono archiviati, soltanto trasmessi o se possono essere visualizzati dal personale.

Anche la procedura di modifica rientra nella valutazione: come vengono avvisati i clienti, qual è il preavviso e cosa accade in caso di opposizione motivata? Un'e-mail inviata il giorno stesso del cambiamento senza una reazione utilizzabile dal punto di vista tecnico o contrattuale vale poco. Chiarite se sia possibile una configurazione alternativa, la disattivazione della funzione o, in caso di necessità, una risoluzione ordinata del contratto con esportazione dei dati. Per i subresponsabili a valle devono essere trasmessi gli stessi obblighi di protezione dei dati; il primo responsabile del trattamento rimane responsabile nei confronti del titolare per l'adempimento dei loro obblighi.

Trasferimenti verso paesi terzi: verificare il meccanismo e l'efficacia reale

Il Capo V del GDPR si applica ai trasferimenti di dati personali verso paesi terzi e ai successivi trasferimenti. Un trasferimento non si verifica solo tramite archiviazione permanente; anche un accesso amministrativo, un accesso di supporto o una consultazione da parte di un servizio al di fuori dello SEE può essere rilevante. Assegnate quindi a ogni freccia nella mappa del flusso di dati un paese di destinazione, un destinatario e un meccanismo di trasferimento.

1. Decisione di adeguatezza: Verificate sull'elenco costantemente aggiornato della Commissione Europea se la decisione, il territorio, il settore e il destinatario concreto sono coperti. Per i quadri normativi limitati, la semplice presenza di una sede in un paese non è sufficiente.
2. Garanzie adeguate: In mancanza di una decisione di adeguatezza applicabile, a seconda della situazione si possono prendere in considerazione gli strumenti di cui all'Articolo 46 del GDPR. Spesso si utilizzano le Clausole Contrattuali Tipo della Commissione Europea (SCC). Modulo, parti, allegati, descrizione del trasferimento e misure tecniche devono adattarsi alla catena reale.
3. Verifica dell'efficacia: Un documento SCC firmato non conclude automaticamente la verifica. Le raccomandazioni finali 01/2020 dell'EDPB descrivono un processo basato sul rischio: conoscere i trasferimenti, determinare lo strumento, valutare la legislazione e la prassi del paese terzo, stabilire eventualmente misure supplementari, espletare i passaggi formali e rivalutare regolarmente.

Le misure tecniche supplementari devono essere adeguate al rischio specifico. La crittografia, ad esempio, è significativa solo se si tengono in considerazione la gestione delle chiavi, i diritti di accesso e la finalità del trattamento. Un fornitore di modelli che deve elaborare testo in chiaro e può accedere esso stesso alle chiavi rappresenta una situazione diversa rispetto a un mero archivio di backup crittografato. Dichiarazioni generiche come "AES-256" o "conforme al GDPR" non sostituiscono questa analisi. Le deroghe ai sensi dell'Articolo 49 del GDPR non costituiscono una via ordinaria e agevole per trattamenti SaaS pianificati e ricorrenti.

Esempio pratico: regione UE con catena di servizi globale

Supponiamo che un chatbot conservi il proprio database principale a Francoforte. Tuttavia, le risposte vengono generate dall'API di un modello di un'azienda statunitense, le segnalazioni di errore vanno a un ulteriore servizio e un team di supporto globale può aprire i log di conversazione in caso di escalation. In questo caso, "Dati ospitati nell'UE" descrive solo una parte del sistema.

La due diligence separa quattro domande: quali contenuti lasciano lo SEE per la generazione del modello? I prompt vengono memorizzati lì o utilizzati per altre finalità? Le segnalazioni di errore contengono testo in chiaro, identificativi o soltanto dati tecnici minimizzati? In quali condizioni il supporto fuori dallo SEE può accedere? Solo a quel punto è possibile valutare lo strumento di trasferimento, le misure supplementari e l'incertezza residua.

Dal punto di vista tecnico, il gestore del sito web può spesso ridurre il rischio: disattivare i campi di log non necessari, mascherare i dati sensibili negli input prima delle chiamate esterne, impostare tempi di conservazione brevi, separare le aree sensibili dal bot pubblico, isolare le fonti di conoscenza per ciascun tenant e registrare gli accessi di supporto soggetti ad autorizzazione. Come separare nettamente un bot pubblico da un portale clienti viene illustrato nell'articolo Chatbot IA pubblico vs. Portale clienti. Per i file caricati, la checklist su Controllo file, protezione dati e handoff integra la verifica del fornitore.

Decisione con semaforo invece che con l'istinto

Punto di verifica	Verde	Giallo	Rosso
Flusso di dati	Completo, aggiornato e riferito al piano	Singoli accessi o sedi di archiviazione da chiarire	Solo affermazione di marketing sulla regione UE
DPA	Definizione concreta di finalità, dati, scadenze e assistenza	Integrazioni necessarie prima del Go-live	Nessun vincolo chiaro alle istruzioni o alla cancellazione
Subresponsabili	Elenco nominale con paese e compito	Procedura di modifica poco pratica	Solo categorie o catena sconosciuta
Trasferimento extra-UE	Meccanismo, ambito e valutazione comprovati	Misure ancora da verificare	"Server UE" inteso come spiegazione di tutti i trasferimenti
Operatività	Owner, data di review ed exit testati	Prove senza una review fissa	Nessun monitoraggio dopo la firma del contratto

Un punto giallo non deve necessariamente essere un motivo per escludere il fornitore. Richiede tuttavia un responsabile, una data limite e un criterio di accettazione verificabile. Un punto rosso in una catena di trattamento centrale dovrebbe bloccare il lancio in produzione fino all'adeguamento del contratto, della configurazione o della scelta del fornitore. Documentate anche i rischi residui accettati e la persona che ha preso tale decisione.

Checklist compatta per il Go-live per gestori di siti web

• Mappa del flusso di dati e ruoli per ciascuna finalità sono stati approvati.
• DPA e allegati corrispondono a piano, funzionalità, tipi di dati e tempi di conservazione.
• Tutti i subresponsabili del trattamento sono documentati per nome con paese, compito e procedura di modifica.
• Ogni trasferimento verso paesi terzi ha un meccanismo idoneo, attualmente verificato e, se necessario, misure supplementari.
• L'addestramento dei modelli o altri utilizzi propri dei dati di chat sono chiariti e configurati come concordato.
• Registrazione dei log, accesso di supporto, esportazione dati, cancellazione e fine contratto sono stati testati nella pratica.
• L'informativa sulla privacy e l'interfaccia di chat spiegano il trattamento in modo comprensibile; gli utenti non vengono indotti a inserire dati sensibili non necessari.
• È stato verificato se per l'uso concreto sia necessaria una valutazione d'impatto sulla protezione dei dati (DPIA).
• Un owner monitora le modifiche ai subresponsabili, ai meccanismi di trasferimento, alle funzionalità e alle certificazioni di sicurezza.

Inoltre, vale la pena fare un confronto con la panoramica fondamentale Chatbot IA e GDPR e con la guida per un'analytics dei chatbot attenta alla minimizzazione dei dati. In questo modo acquisti, configurazione tecnica e gestione operativa non vengono trattati come progetti separati.

Continuare a verificare dopo la firma del contratto

La due diligence non è una cartella di PDF da consultare una sola volta. Stabilite almeno un ritmo di review fisso e verifiche basate su eventi. I fattori scatenanti sono nuovi subresponsabili del trattamento, un diverso fornitore del modello, nuove funzionalità di prodotto, sedi di archiviazione modificate, un incidente di sicurezza, certificati in scadenza o modifiche a una decisione di adeguatezza. L'elenco attuale dei subresponsabili e le versioni contrattuali centrali dovrebbero essere archiviati con la data, affinché le modifiche successive rimangano tracciabili.

Il parametro pratico è semplice: il vostro team è in grado di spiegare per ogni flusso di dati rilevante chi tratta cosa e perché, dove avviene ciò, per quanto tempo rimangono i dati, quale misura di protezione si applica e come funziona l'uscita (exit)? Quando queste risposte sono comprovate, un'affermazione generica sulla protezione dei dati si trasforma in una decisione d'acquisto solida. Se stazioni centrali rimangono sconosciute, il chatbot non dovrebbe ancora operare con i dati reali dei visitatori.