Apri il sito di un qualunque fornitore di Intelligenza Artificiale. In fondo alla home, o nella pagina "Security", troverai quasi sempre le stesse tre sigle - "GDPR compliant", "ISO 27001 certified", "AI Act ready". Sono certificazioni serie, che richiedono investimenti reali e processi continuativi, e oggi rappresentano una soglia di accesso al mercato enterprise. Sono però il punto di partenza, non quello di arrivo.
Tra le domande che un'azienda pone quando valuta sul serio un fornitore di AI non c’è solo "avete queste certificazioni", ma anche una molto più ruvida. "Cosa significano concretamente per la gestione dei dati dei miei clienti, quando alle 3 di notte qualcosa va storto?"
C'è una differenza profonda tra "essere conformi" e "rendere la conformità verificabile". Le certificazioni attestano la prima cosa. Un ente terzo, in un certo momento e su un certo perimetro, ha verificato la presenza di un sistema di controlli. Quello che però accade ogni giorno in produzione non è racchiuso in un timbro PDF. Vive nei log, nelle policy di retention, nei contratti con i sub-processor, nei runbook di incident response. Se un fornitore non sa, o non vuole, mostrarti queste cose, la certificazione resta un'etichetta sulla scatola. Proviamo a tradurre ogni sigla in scelte architetturali riconoscibili.
GDPR in termini operativi
Il GDPR si applica da otto anni. Per chiunque venda servizi cloud in Europa non è più un argomento, ma uno standard di accesso. La conformità si gioca tutta sui dettagli operativi.
Data residency e sub-processor
La prima domanda è geografica. Dove vivono fisicamente i dati delle conversazioni? In quali data center? Replicati dove? Una piattaforma di Agenti AI tocca, nel suo ciclo di vita, almeno quattro categorie di dato - transcript della conversazione, metadati, embedding semantici usati dai sistemi RAG, log tecnici. Per ciascuna, una piattaforma matura sa rispondere con il nome della regione e del provider.
C'è poi un punto che quasi nessuno mette nero su bianco. Nessun fornitore AI è davvero “indipendente”. I modelli linguistici vengono spesso erogati da terze parti come OpenAI, Anthropic, Google, fornitori specializzati di Speech-to-Text e Text-to-Speech. Ognuno di questi è, ai sensi del GDPR, un sub-processor. In una postura matura sono elencati nominalmente, con regione di processing, ruolo nel flusso dati e base contrattuale.
Retention, diritto all'oblio e propagazione delle cancellazioni
Le conversazioni sono dati personali. Anche quando l'utente non si è identificato, il transcript contiene spesso elementi che lo rendono identificabile in combinazione con altri dati. La retention policy di una piattaforma matura è esplicita, configurabile per workspace e applicata di default, con periodi di conservazione (retention) distinti per le diverse categorie: trascrizioni, embedding, metriche aggregate.
Le cancellazioni sono effettive, non solo logiche, e lasciano traccia documentale: in caso di ispezione il DPO deve poter dimostrare l'avvenuta cancellazione. I dati presenti nei backup escono per scadenza naturale, secondo finestre di retention dichiarate. Per il diritto all'oblio, una piattaforma matura gestisce le richieste degli interessati con evidenza tracciabile e la affianca alla cancellazione automatica allo scadere della retention configurata, così che l'esercizio del diritto non dipenda da un processo opaco gestito caso per caso.
Notifica breach entro 72 ore
L'articolo 33 del GDPR impone al titolare di notificare un data breach all'autorità entro 72 ore. Il fornitore, in qualità di responsabile, deve rilevare l'incidente e segnalarlo al titolare con un margine sufficiente a rispettare quelle 72 ore. In pratica, un commitment contrattuale dell'ordine di poche ore, sostenuto da un'infrastruttura di rilevamento operativa. I fornitori più maturi sono in grado di dichiarare come è strutturato il proprio SOC (Security Operations Center), il tempo medio di rilevamento storico, il contatto avvisato per primo nel team del cliente.
ISO 27001 in termini operativi
ISO/IEC 27001 è uno standard internazionale per i sistemi di gestione della sicurezza delle informazioni. La sua versione attuale, ISO/IEC 27001:2022, organizza 93 controlli in quattro categorie. Avere la certificazione significa che un ente accreditato terzo ha verificato che l'organizzazione possiede un ISMS (Information Security Management System) funzionante. Ma "funzionante" è una parola sottile.
ISO 27001 non certifica un prodotto, certifica un sistema di gestione. Una piattaforma di Agenti AI può essere certificata sull'intero perimetro che eroga il servizio (sviluppo, infrastruttura, operations, supporto), oppure su un perimetro ridotto. Il primo passo, per chi compra, è chiedere lo Statement of Applicability (SoA) e leggere qual è esattamente lo scope.
Un SoA che esclude lo sviluppo software o l'infrastruttura cloud, in una piattaforma SaaS, rende la certificazione poco rilevante. Il ciclo, inoltre, prevede un audit iniziale, audit di sorveglianza annuali e una ricertificazione completa ogni tre anni. Il certificato che vedi sul sito può quindi avere fino a tre anni di vita - mitigato dagli audit di sorveglianza intermedi, che per definizione sono però più leggeri della certificazione iniziale o della ricertificazione.
C'è poi una domanda che pochi pongono, e che separa i fornitori seri dagli altri. Cosa succede in caso di breach durante il periodo di validità? Un incidente non invalida automaticamente la certificazione. Esiste una procedura che prevede notifica all'ente, root cause analysis, azioni correttive, dimostrazione nell'audit successivo che i controlli sono stati rafforzati. È del tutto possibile, e legittimo, che un fornitore certificato abbia avuto un incidente. La differenza la fa la trasparenza - cosa è successo, cosa è stato fatto, cosa è cambiato.
AI Act in termini operativi per chi acquista
L'AI Act, formalmente Regolamento (UE) 2024/1689, è entrato in vigore il 1° agosto 2024 e si applica per fasi. Le pratiche proibite e gli obblighi sull'alfabetizzazione AI sono in vigore dal 2 febbraio 2025; gli obblighi sui modelli General-Purpose AI dal 2 agosto 2025. L'accordo politico provvisorio sul 'Digital Omnibus' del 7 maggio 2026 - in attesa di adozione formale e pubblicazione in Gazzetta Ufficiale - sposta l'enforcement dei sistemi ad alto rischio dell'Allegato III al 2 dicembre 2027, e gli obblighi di watermarking per i contenuti sintetici dell'articolo 50(2) al 2 dicembre 2026. L'obbligo di disclosure verso gli utenti finali dell'articolo 50(1), che riguarda direttamente gli Agenti AI conversazionali, resta applicabile dal 2 agosto 2026. Le date si muovono, gli obblighi sostanziali no.
Per chi acquista una soluzione di Agenti AI, le aree concrete da presidiare sono tre.
La classificazione del rischio
L'AI Act prevede quattro livelli - pratiche proibite, alto rischio (sistemi che decidono su accesso al credito, assunzioni, istruzione, accesso a servizi essenziali e altri ambiti dell'Allegato III), rischio limitato (sistemi che interagiscono con persone, soggetti a obblighi di trasparenza), rischio minimo.
Un Agente AI che gestisce richieste di assistenza, prenotazioni o follow-up commerciali ricade tipicamente nel rischio limitato. Ma se lo stesso Agente prende decisioni vincolanti sull'erogazione di un servizio essenziale o sull'accesso al credito, il regime cambia radicalmente. La responsabilità primaria della classificazione e della conformity assessment spetta al provider del sistema, che produce la documentazione tecnica necessaria; il deployer deve a sua volta verificare e documentare la categoria di rischio del sistema che adotta, soprattutto quando il proprio uso ne può modificare la classificazione.
Gli obblighi di trasparenza verso gli utenti finali
L'articolo 50(1), applicabile dal 2 agosto 2026, impone che gli utenti siano informati di essere in interazione con un sistema di Intelligenza Artificiale. L'Agente AI deve poter dichiarare la propria natura in modo configurabile, sia nei canali vocali sia in quelli testuali, con un wording coerente con la policy del brand. È una configurazione che il fornitore espone e che resta attiva anche quando l'Agente viene clonato in nuovi workspace o in altre lingue.
La documentazione tecnica
Se il sistema rientra nell'alto rischio, il deployer deve poter accedere a una documentazione articolata - descrizione del sistema, finalità d'uso, dataset di addestramento e validazione, metriche, misure di mitigazione, procedure di sorveglianza umana. Parte di questa documentazione, in particolare le model card, è curata dai fornitori dei modelli; quello che un fornitore di Agenti AI serio garantisce è la dichiarazione puntuale dei modelli utilizzati e una documentazione di sistema riferita alla singola soluzione, non un documento generico per l'intera piattaforma.
Privacy-by-design nell'architettura
I principi normativi non si fermano alle policy, si incarnano in scelte tecniche. Privacy-by-design significa che la riservatezza del dato è una proprietà strutturale del sistema, non un controllo applicato a posteriori. Tre aree dove la differenza emerge nettamente.
1. Rilevamento delle PII e minimizzazione del dato
In una conversazione tipica con un Agente AI, l'utente nomina spontaneamente codice fiscale, IBAN, numero di polizza, indirizzo, telefono. Una piattaforma matura riconosce la presenza di questi dati sensibili tramite guardrail dedicati e consente all'Agente di reagire, per esempio bloccando o deviando il flusso. C'è poi un principio che fa la differenza: i messaggi completi degli utenti restano confinati nell'infrastruttura del fornitore, e ai provider dei modelli arrivano solo i frammenti strettamente necessari all'elaborazione. Quando un dato sensibile transita comunque dal modello, è essenziale che il sub-processor sia coperto da un DPA esplicito e che il flusso sia documentato. È il principio di data minimization, centrale nel GDPR, che premia chi riduce il dato esposto ai sottolivelli della pipeline.
2. Workspace isolation tra clienti
Una piattaforma SaaS multi-tenant matura garantisce che i dati di un cliente non finiscano mai, neanche per errore, nel workspace di un altro. È un requisito tecnico non banale, che coinvolge isolamento a livello di database, vector store, cache, logging, ambienti di sviluppo e test. Per i clienti più regolamentati (banking, healthcare, settore pubblico) sono disponibili anche opzioni di tenancy dedicata o di deployment in private cloud.
3. Controllo granulare degli accessi
La domanda è banale. Chi nel team del fornitore può vedere le conversazioni dei miei utenti? Nelle piattaforme mature la risposta è precisa - ruoli definiti, accessi tracciati, audit log immutabile. Idealmente esiste una modalità in cui anche il team di supporto del fornitore non vede il contenuto dei transcript salvo esplicita autorizzazione del cliente, tracciata e a scadenza.
Auditabilità e Trust Center come strumenti operativi
L'auditabilità è il punto in cui le policy diventano verificabili. Un sistema che non si lascia auditare chiede di essere creduto sulla parola, e in ambito enterprise non basta. Quattro componenti caratterizzano un'auditabilità seria - log integrale delle conversazioni accessibile al cliente ed esportabile in formato strutturato, tracing distribuito delle chiamate API verso i sistemi esterni, funzione di export per ispezione regolamentare in caso di richiesta di un'autorità, accesso controllato agli audit trail con immutabilità e tracciamento degli accessi privilegiati.
Tutto questo configura un'esigenza precisa per il fornitore - rendere disponibili in un'unica posizione, e in autonomia, le informazioni che i team di security, privacy e governance del dato cercano nelle prime fasi di valutazione.
È la funzione del Trust Center. Un Trust Center maturo punta a coprire una serie di aree riconoscibili - certificati attivi con scope e date di validità, scope della certificazione ISO, lista dei sub-processor con regione e ruolo, mappa della data residency, policy di retention di default, modello di responsabilità condivisa, procedure di incident response e tempi di notifica, dichiarazione dei modelli utilizzati, Data Processing Addendum standard scaricabile.
Quando un fornitore non ha un Trust Center pubblico, o ne ha uno che rimanda al commerciale per ogni informazione, è un segnale operativo importante. Significa che ogni vendita enterprise richiederà un ciclo di Q&A privato di settimane, e che il fornitore non ha ancora industrializzato la propria postura di security.
I tratti di una piattaforma davvero pronta per l'enterprise
Tutto quanto sopra converge in pochi tratti che distinguono le piattaforme che hanno fatto i compiti da quelle che stanno ancora studiando. Sono i tratti che permettono a un security team di chiudere una valutazione in due o tre settimane, e non in tre o quattro mesi.
Il primo è la trasparenza geografica. Per ogni categoria di dato, il fornitore sa dire dove vive il dato, chi lo processa e quale opzione esiste per restare entro un perimetro europeo. Risposte con nomi propri, non formule come "cloud sicuro".
Il secondo è la specificità della documentazione. Lo Statement of Applicability ISO copre sviluppo, infrastruttura e operations. L’AI System Card è declinata sul singolo use case, non generica.
Il terzo è la profondità della privacy-by-design: rilevamento delle PII tramite guardrail, data minimization verso i provider dei modelli, multi-tenancy descritta con il livello di isolamento applicato, e una modalità in cui anche il supporto del fornitore non accede al contenuto dei transcript senza autorizzazione tracciata del cliente.
Il quarto è l'auditabilità di default - log accessibili, tracing API disponibile, audit trail immutabili.
Il quinto è la postura di incident response - commitment alla notifica in ore, non in formule, contatto nominato, post-mortem strutturati condivisi con i clienti impattati.
Quando questi cinque tratti sono presenti, la conversazione tra fornitore e security team smette di essere un'estrazione faticosa di documenti e diventa una verifica di coerenza. È questa la differenza tra un fornitore pronto per l'enterprise e uno che dichiara di esserlo.
La sicurezza non è un capitolo a parte, è un livello dell'architettura. Le sigle (GDPR, ISO 27001, AI Act) sono il vocabolario condiviso, ma il valore reale sta nelle scelte ingegneristiche con cui quelle parole diventano comportamenti del sistema in produzione: rilevamento delle PII, workspace isolati, log auditabili, sub-processor dichiarati, Trust Center accessibile. La velocità con cui un fornitore si fa approvare dal security team è essa stessa una metrica di maturità. La differenza, per chi compra, è tra avere un progetto AI in produzione l'anno prossimo e restare bloccati nel limbo del procurement.
FAQ
Che differenza c'è tra "GDPR compliant" e GDPR conforme nei fatti?
"GDPR compliant" è un'autodichiarazione del fornitore. La conformità reale si misura sulle scelte operative verificabili - dove vivono i dati, chi sono i sub-processor, quanto è effettiva la retention, quanto è veloce la notifica in caso di breach, come funziona il diritto all'oblio. Un fornitore può dichiararsi conforme e, a un'analisi tecnica, risultare incompleto su uno o più di questi punti.
L'AI Act si applica anche a un Agente AI usato solo per il customer service?
Sì, in regime di rischio limitato. Gli Agenti AI per il customer service rientrano tipicamente nell'articolo 50(1), che impone obblighi di disclosure - l'utente deve sapere di interagire con un sistema di Intelligenza Artificiale. L'obbligo è applicabile dal 2 agosto 2026 e non è stato posticipato dall'Omnibus del 7 maggio 2026, che ha invece dilazionato al 2 dicembre 2026 il solo articolo 50(2), relativo al watermarking dei contenuti sintetici. Il regime cambia significativamente solo se l'Agente prende decisioni vincolanti su ambiti dell'Allegato III, come l'accesso al credito o l'erogazione di servizi essenziali.
Quanto tempo richiede mediamente un audit di security su un fornitore AI?
Dipende quasi interamente dalla preparazione del fornitore. Con un Trust Center popolato, documentazione tecnica disponibile e un referente dedicato, una valutazione security/legal si chiude in due o tre settimane. La parte che dipende dal fornitore, rispondere ai questionari e fornire le evidenze, si chiude in pochi giorni quando il Trust Center è popolato; il resto dipende dai tempi interni di chi acquista. Senza il Trust Center, con documentazione frammentaria e processi non standardizzati, lo stesso percorso può richiedere tre o quattro mesi.
