Molte aziende svizzere fanno girare silenziosamente agenti AI che trattano dati personali di soggetti UE — qualificano richieste in entrata, gestiscono ticket di supporto clienti, smistano candidature. La maggior parte non ha verificato se tutto ciò sia difendibile ai sensi del GDPR.
È una lacuna che si può colmare con relativa facilità, a patto di sapere quali domande fare prima del deployment — e non dopo aver ricevuto una lettera dall’autorità di controllo.
Questo articolo mappa le principali obbligazioni GDPR rispetto ai deployment di agenti più comuni nelle aziende svizzere, e mostra come appare in pratica un sistema “built to comply”.
Perché “azienda svizzera” non significa “il GDPR non si applica”
La Svizzera non è nell’UE. Ma l’ambito territoriale del GDPR (art. 3) si estende a qualsiasi organizzazione che tratti dati personali di persone fisiche situate nell’UE nell’ambito dell’offerta di beni o servizi, o del monitoraggio del comportamento. Se il tuo agente gestisce richieste da prospect tedeschi o francesi, processa ordini di clienti italiani, o conduce outreach in qualsiasi mercato UE, il GDPR si applica — indipendentemente da dove si trovano i tuoi server.
La nLPD svizzera opera in parallelo e riguarda specificamente i residenti in Svizzera. nLPD e GDPR condividono i principi di minimizzazione dei dati e limitazione della finalità, ma c’è una differenza strutturale importante: la nLPD non richiede ai titolari del settore privato di identificare una base giuridica specifica per ogni attività di trattamento — il trattamento è generalmente lecito a meno che non leda i diritti della personalità. Progettare per la conformità al GDPR copre quindi la maggior parte degli obblighi nLPD, ma è consigliabile affiancare una revisione dedicata. Approfondimenti sulla nLPD si trovano nell’articolo complementare sulla protezione dei dati in Svizzera.
Per ora: considera che il GDPR si applica al tuo agente se tocca dati di soggetti UE. La domanda è cosa significa operativamente.
Cosa significa “trattare dati personali” all’interno di un agente
Un agente AI tratta dati personali ogni volta che legge email, record CRM o trascrizioni di chat contenenti nomi e identificatori; genera output che fanno riferimento a persone fisiche; memorizza dati in memoria, vector store o log; oppure chiama API di terze parti che ricevono quei dati.
Ciascuna di queste azioni è “trattamento” ai sensi dell’art. 4(2) del GDPR. Il regolamento non distingue se avviene intenzionalmente o incidentalmente — un agente di supporto che registra ogni conversazione è soggetto alle stesse regole di un database mantenuto manualmente.
La maggior parte dei deployment di agenti ne fa almeno tre contemporaneamente. Questo non è un motivo per evitare gli agenti. È un motivo per progettarli con consapevolezza.
Le quattro obbligazioni più rilevanti per i deployment di agenti AI
1. Base giuridica — sapere perché sei autorizzato a trattare
Ogni istanza di trattamento necessita di una base giuridica ai sensi dell’art. 6. Per gli agenti AI in ambito business, le tre basi rilevanti sono:
- Legittimo interesse (art. 6(1)(f)) — la base più comune per i casi d’uso B2B. Richiede una Valutazione del Legittimo Interesse (LIA) che bilanci i tuoi interessi con i diritti dell’interessato. Generalmente difendibile per l’outreach commerciale B2B e gli agenti per le operazioni interne.
- Esecuzione del contratto (art. 6(1)(b)) — quando il trattamento è necessario per erogare un servizio contrattualizzato (es. un agente ordini che tratta l’indirizzo del cliente per evadere un acquisto).
- Consenso (art. 6(1)(a)) — necessario per il marketing B2C dove si applica la direttiva ePrivacy, e per i casi d’uso particolarmente sensibili. Deve essere liberamente espresso, specifico e revocabile.
L’errore tipico è usare un’unica base generica (“legittimo interesse”) per ogni attività di trattamento senza condurre la LIA. Non regge a un controllo. Ogni workflow dell’agente con input e output di dati distinti dovrebbe avere la propria base giuridica documentata separatamente.
2. Accordi di trattamento dei dati con ogni fornitore AI nella catena
Quando il tuo agente invia dati personali a un’API LLM — OpenAI, Anthropic, Google o qualsiasi altro — quel fornitore diventa un responsabile del trattamento ai sensi dell’art. 28. Sei obbligato ad avere un Data Processing Agreement (DPA) firmato con loro prima che qualsiasi dato personale fluisca verso di loro.
La maggior parte dei principali fornitori LLM offre un DPA, ma spesso occorre richiederlo attivamente o aderire al livello di servizio corretto. I termini API consumer standard generalmente non sono sufficienti. Verifica che il DPA copra le tue tipologie di dati, includa gli elenchi dei sub-responsabili e che la politica di retention degli input del fornitore sia allineata alla tua.
Questo si estende all’intera catena dei responsabili. Piattaforme di orchestrazione, database vettoriali di terze parti e servizi gestiti per le chiamate agli strumenti necessitano ciascuno di un DPA se ricevono dati personali — o di una motivazione documentata per cui non lo richiedono (tipicamente perché hai anonimizzato i dati a monte).
3. Residenza dei dati — dove vivono effettivamente i dati del tuo agente
Svizzera e UE beneficiano di una decisione di adeguatezza (confermata da ultimo il 15 gennaio 2024) che consente il flusso libero di dati dall’UE/SEE verso la Svizzera senza salvaguardie aggiuntive. I trasferimenti tra i due sono generalmente non problematici. Ma se la tua infrastruttura gira su servizi cloud statunitensi o chiama API LLM statunitensi, stai effettuando trasferimenti internazionali verso un paese terzo — e ciascuno di essi necessita di un meccanismo di trasferimento, tipicamente Clausole Contrattuali Standard incorporate nel DPA.
I passi pratici: mappa dove fluiscono i dati personali dall’ingestione attraverso ogni chiamata API e livello di storage; verifica che ogni passaggio transfrontaliero disponga di una decisione di adeguatezza, SCC o Binding Corporate Rules; e documentalo. Se un’autorità di controllo ti chiede di dimostrare la conformità, quella mappa dei flussi di dati è la prima cosa che vogliono vedere.
Ospitare l’infrastruttura dell’agente in Svizzera o nell’UE elimina gran parte di questa complessità — uno dei motivi per cui i clienti con requisiti di trattamento dati sensibili preferiscono spesso deployment in Svizzera o nella regione UE rispetto ai default statunitensi.
4. DPIA — quando serve una valutazione formale del rischio
Una Valutazione d’Impatto sulla Protezione dei Dati (DPIA) è obbligatoria ai sensi dell’art. 35 ogni volta che il trattamento “presenta un rischio elevato per i diritti e le libertà delle persone fisiche”. Per i deployment di agenti AI, i trigger includono:
- Decisioni automatizzate con effetti significativi sulle persone (art. 22) — un agente di screening per le assunzioni che classifica o rifiuta candidati, o qualsiasi agente relativo al credito
- Dati di categoria speciale su larga scala (salute, biometrici, opinioni politiche)
- Monitoraggio sistematico del comportamento delle persone
- Trattamento di dati personali su larga scala
Condotta correttamente, una DPIA ti obbliga ad articolare rischi specifici e le misure che li mitigano. La questione dell’art. 22 merita particolare attenzione. Quando una decisione automatizzata produce effetti giuridici o analoghi su una persona, questa ha generalmente il diritto di non essere soggetta a un trattamento esclusivamente automatizzato. Ai sensi dell’art. 22(3), anche quando si applicano eccezioni — necessità contrattuale, autorizzazione legale o consenso esplicito — sono obbligatorie salvaguardie adeguate, incluso il diritto per la persona di ottenere l’intervento umano, esprimere la propria opinione e contestare la decisione. Per la maggior parte dei contesti di deployment, integrare un passaggio di revisione umana è il modo più semplice per soddisfare questo requisito.
Chi è responsabile: titolare, responsabile o entrambi?
Se deploi un agente per le tue operazioni, sei il titolare del trattamento — determini la finalità e i mezzi del trattamento. I fornitori LLM e gli altri servizi che chiami sono tuoi responsabili.
Se sei un service provider che deploya un agente per conto di un cliente, la distinzione titolare/responsabile dipende dalla struttura contrattuale. Questo conta perché i titolari portano la responsabilità GDPR primaria — rispondere alle richieste degli interessati, notificare le autorità di controllo in caso di violazioni. Formalizzalo per iscritto. Un accordo di co-titolarità ai sensi dell’art. 26 è spesso trascurato nei progetti con agenti e comporta obbligazioni proprie.
Come appare un’architettura di agente conforme
Una buona conformità GDPR per un agente AI non riguarda principalmente i documenti legali. È incorporata nel design del sistema:
- Minimizza i dati all’ingestione. Elimina o pseudonimizza gli identificatori personali prima che raggiungano l’LLM, dove il caso d’uso lo consente. Un agente di triage del supporto spesso non ha bisogno del nome completo del cliente per classificare un ticket.
- Registra con criterio. I framework per agenti che registrano ogni prompt e risposta per default creano passività in termini di retention. Configura finestre di retention e decidi in anticipo quali log sono operativamente necessari.
- Documenta i flussi di dati prima di costruire. Un diagramma di una pagina che mostra cosa entra nell’agente, quali API chiama, cosa memorizza e dove vanno gli output è sia un documento di progettazione sia il fondamento dei tuoi registri delle attività di trattamento ai sensi dell’art. 30.
- Integra checkpoint di revisione umana ogni volta che l’output dell’agente influisce significativamente su una persona. È particolarmente importante per i casi d’uso nelle assunzioni, nel credito e in sanità.
La conformità GDPR si inserisce nel quadro più ampio della governance degli agenti AI — come supervisioni gli agenti in produzione, gestisci gli aggiornamenti del modello e gestisci i guasti. I controlli di sicurezza che prevengono l’esfiltrazione di dati o il prompt injection sono direttamente rilevanti; vedi l’articolo correlato sui rischi di sicurezza degli agenti AI.
Il GDPR non è l’unica normativa in gioco
L’EU AI Act aggiunge un quadro di rischio a livelli che riguarda certi deployment indipendentemente dalla normativa sulla protezione dei dati — in particolare i sistemi utilizzati nelle assunzioni, nel credito o nelle forze dell’ordine. Per un’analisi operativa di cosa significa, l’articolo sull’EU AI Act e gli agenti AI copre la logica di classificazione e la timeline di conformità.
I progetti di agenti AI costruiti con una struttura normativa dall’inizio sono più veloci da deployare, più facili da auditare e molto meno soggetti a costose rielaborazioni successive.
Cosa richiede concretamente un deployment difendibile
Il posture GDPR minimo indispensabile per un agente AI che tocca dati personali UE:
- Una base giuridica documentata per ogni attività di trattamento distinta
- Un DPA firmato con ogni fornitore AI e sub-responsabile che riceve dati personali
- Una mappa dei flussi di dati che copre ingestione, trattamento, storage e trasferimento
- Una DPIA dove il trattamento è ad alto rischio (decisioni automatizzate, dati di categoria speciale, larga scala)
- Una politica di retention applicata a log, memoria e output
- Revisione umana integrata in qualsiasi workflow con decisioni significative a livello individuale
Nulla di tutto ciò è straordinario. Richiede però di trattare la conformità come una fase di progettazione e non come una revisione post-lancio.
Pronto a costruire un agente che il tuo team legale può approvare?
Orange ITS sviluppa agenti AI personalizzati per aziende svizzere ed europee — l’architettura di conformità fa parte di ogni progetto, non è un optional. Se stai valutando un deployment e vuoi un quadro chiaro di dove si trovano le esposizioni GDPR, prenota una call di 30 minuti con il nostro team. Mapperemo il tuo caso d’uso rispetto alle obbligazioni rilevanti e ti diremo onestamente cosa deve essere in ordine prima di andare live.