--- title: "Tutelare il dato nell'uso dell'AI: le scelte che precedono l'architettura" url: https://zerofive.ai/blog/compliance/tutela-dato-ai-scelte-prima-architettura canonical: https://zerofive.ai/blog/compliance/tutela-dato-ai-scelte-prima-architettura language: it published: 2026-11-02 updated: 2026-10-29 author: "ZeroFive.AI" tags: tutela del dato, classificazione dei dati, NIS2, GDPR, AI gateway, AI Rating abstract: "Classificazione, destinazioni, rischio residuo e responsabilità: le scelte da fare prima di instradare i dati verso i modelli AI, tra GDPR, NIS2 e AI Act." --- # Tutelare il dato nell'uso dell'AI: le scelte che precedono l'architettura **In sintesi.** Uno schema che instrada ogni richiesta verso modelli diversi in base alla classe del dato funziona solo se l'azienda ha già deciso come classificare i dati, dove ciascuna classe può essere elaborata, quale rischio residuo accetta e chi lo approva. Il GDPR e la NIS2 non impongono di elaborare i dati in Italia, per cui il perimetro nazionale per i dati critici è una scelta di rischio da motivare per iscritto. Il controllo riguarda tutto il contesto che arriva al modello, documenti recuperati compresi, e prosegue su risposte e log. Quando chiediamo a un'azienda come protegge i dati che finiscono dentro un modello di intelligenza artificiale, la risposta che sentiamo più spesso è il nome di uno strumento, la licenza dell'assistente integrato nella suite di produttività o il contratto con un fornitore che promette l'elaborazione in Europa. Sono informazioni utili, che però descrivono con cosa si lavora e lasciano scoperto il passaggio che viene prima, cioè chi ha deciso quali dati possono entrare in quale modello, con quale criterio, e chi si assume il rischio di ciò che passa lo stesso. Se guardate il registro dei trattamenti di molte aziende che usano l'AI ogni giorno, i fornitori dei modelli spesso non compaiono, e quando compaiono manca la finalità per cui ricevono i dati. È una distanza che conosciamo anche dall'interno, perché nei primi mesi in cui usavamo modelli diversi per lavori diversi anche da noi le regole su cosa mandare dove stavano nella testa di chi lavorava, e una regola che vive nella testa di qualcuno non si verifica e non si registra. Lo schema di instradamento che proponiamo ai clienti enterprise, quello che manda ogni richiesta verso modelli diversi in base alla classe del dato, è la parte visibile del lavoro e si costruisce in fretta quando le decisioni a monte sono state prese. Sono quelle decisioni a richiedere tempo, e spettano all'azienda e al suo board. Copiare l'architettura senza averle fatte porta allo stesso risultato di chi risponde con il nome della licenza, con una spesa più alta. ## La classificazione del dato Tutto parte da una classificazione, ed è una decisione di business prima che tecnica, perché a stabilire che un contratto con un fornitore è riservato o che l'anagrafica dei pazienti non può uscire da un certo perimetro deve essere chi risponde di quei dati, mentre all'IT spetta applicare la regola in modo che non dipenda dalla memoria delle persone. Nei progetti usiamo tre classi, ciascuna con un colore, perché devono essere comprensibili a chi le applica ogni giorno senza aprire un manuale. Verde sono i dati pubblici o destinati a esserlo, come i materiali di marketing, la documentazione già pubblicata, i testi normativi. Giallo sono le informazioni interne riservate, comprese quelle che contengono dati personali comuni (un nome, un indirizzo email, un ruolo citato in un verbale), che possono uscire dal perimetro solo dopo che quei dati sono stati mascherati. Rosso sono i dati che dal perimetro scelto non escono mai: le categorie particolari dell'articolo 9 del GDPR come i dati sanitari, i dati giudiziari, le informazioni finanziarie su clienti identificati, i segreti industriali e le informazioni sulla sicurezza dei sistemi, che per un soggetto NIS2 sono a loro volta un bersaglio. Il confine tra giallo e rosso è dove la maggior parte delle classificazioni diventa vaga, e va scritto con esempi presi dai documenti reali dell'azienda, un verbale del consiglio, una pratica di sinistro, un'offerta commerciale, un ticket dell'assistenza, ognuno assegnato a una classe con la motivazione accanto. Due persone che leggono la policy devono arrivare alla stessa classe per lo stesso documento. La classe va attaccata alla fonte, cioè al repository, alla cartella o al sistema da cui il dato proviene. Chiedere a chi scrive la richiesta di etichettarla ogni volta significa affidare la tutela alla sua attenzione del momento, e l'attenzione del momento è la prima cosa che cede in una giornata piena. ## Le destinazioni e il quadro normativo Per ogni classe va deciso dove può essere elaborata, e su questo vediamo errori in due direzioni opposte, chi pensa che il contratto con un grande fornitore copra tutto e chi è convinto che la legge imponga di tenere ogni dato in Italia. Il GDPR chiede che i dati personali stiano nello Spazio economico europeo oppure che il trasferimento verso l'esterno abbia una base adeguata, e non distingue tra un data center a Milano e uno a Francoforte. La NIS2, recepita con il D.Lgs. 138/2024, non contiene obblighi di localizzazione: all'articolo 24, comma 2, lettera d), chiede misure di gestione del rischio che comprendono la sicurezza della catena di approvvigionamento, e i fornitori di modelli fanno parte di quella catena come qualsiasi altro fornitore ICT. La legge italiana sull'AI, la 132/2025, durante il passaggio parlamentare ha perso la norma che obbligava i sistemi usati dalla pubblica amministrazione a girare su server in Italia, e oggi prevede che negli acquisti pubblici possano essere privilegiate le soluzioni che localizzano i dati strategici in data center sul territorio nazionale. Il perimetro italiano è quindi una scelta di rischio, e come ogni scelta di rischio va motivata per iscritto. Le ragioni per farla esistono e sono solide: i fornitori con sede negli Stati Uniti sono soggetti al CLOUD Act del 2018, che consente alle autorità americane di chiedere dati gestiti da società americane anche quando sono conservati all'estero; alcuni settori ricevono indicazioni dalle autorità di vigilanza o hanno clausole con i propri clienti che spingono in quella direzione; per un soggetto essenziale NIS2 ridurre il numero di giurisdizioni coinvolte semplifica la gestione di un incidente. La scelta ha un costo. I modelli frontier si usano per lo più attraverso le grandi piattaforme cloud, mentre l'infrastruttura italiana offre modelli open weight su GPU dedicate o servizi di inferenza a conservazione zero, con prestazioni che cambiano molto a seconda del compito. Lo schema a classi esiste per pagare quel costo soltanto sui dati che lo giustificano: verde e giallo possono usare il modello frontier con elaborazione limitata alle regioni europee, il rosso va soltanto sull'infrastruttura in Italia. ## Il rischio residuo e chi lo accetta Nessuna di queste scelte porta il rischio a zero, e una parte del lavoro consiste nel descrivere quello che rimane e nel farlo accettare formalmente da chi ne ha l'autorità. Il mascheramento dei dati personali nel flusso giallo si basa su sistemi di riconoscimento che sbagliano, e un nome scritto in modo insolito o un codice cliente in un formato inatteso possono passare in chiaro. Anche quando funziona, il dato mascherato è un dato pseudonimizzato, e la Corte di giustizia dell'Unione europea, con la sentenza del 4 settembre 2025 nella causa C-413/23 P, ha chiarito che resta personale per il titolare che conserva la chiave per ricollegarlo alla persona, mentre per il destinatario che non ha mezzi ragionevoli per farlo può non esserlo. Per l'azienda il flusso giallo è quindi un trattamento a tutti gli effetti, con il fornitore nominato responsabile, il registro aggiornato e l'informativa che lo indica tra i destinatari, ed è la stessa sentenza a offrire l'argomento per sostenere che ciò che arriva al fornitore non identifica nessuno. Il profilo europeo delle piattaforme cloud assicura che l'elaborazione avvenga in regioni dell'Unione, ma la richiesta può essere servita da una qualsiasi di esse, e il dato giallo può passare per Dublino, Francoforte o Stoccolma. Chi ha promesso ai propri clienti l'elaborazione in Italia deve saperlo prima di firmare. Per un soggetto essenziale o importante la domanda su chi accetta questo residuo ha già una risposta nella legge, perché il D.Lgs. 138/2024 assegna agli organi di amministrazione e direttivi l'approvazione delle misure di gestione del rischio e la supervisione sulla loro attuazione, con responsabilità dirette per chi siede in quegli organi. Gli altri ruoli vanno scritti con la stessa precisione: chi possiede il dato decide la classe, il DPO verifica la coerenza con il GDPR, il CISO risponde della sicurezza del gateway e dei fornitori, il CAIO, dove esiste, tiene insieme le regole di instradamento e le porta in consiglio quando cambiano. Una matrice di responsabilità su una pagina vale più di molte procedure, perché il giorno di un incidente la prima domanda è chi doveva decidere. ## Contesto, risposta e log di una richiesta Quasi tutti gli schemi di tutela del dato, compresa la prima versione del nostro, ragionano sulla domanda dell'utente, eppure nei sistemi che le aziende usano ogni giorno la domanda è la parte meno rischiosa di ciò che arriva al modello. Un assistente collegato all'archivio documentale aggiunge alla domanda i passaggi recuperati dai documenti, un agente ci aggiunge i risultati degli strumenti che chiama, e una conversazione lunga si porta dietro tutto ciò che è stato scritto prima, così una domanda innocua sul calendario delle ferie può viaggiare insieme a un estratto del fascicolo di un dipendente. Il gateway deve classificare il contesto composto, quello che parte davvero verso il modello dopo il recupero dei documenti e le chiamate agli strumenti, assegnandogli la classe più alta tra quelle delle fonti coinvolte. La stessa attenzione serve sulla risposta, che può riportare in chiaro un dato rosso recuperato da una fonte e finire in un canale con regole più deboli, una mail verso l'esterno o un ticket condiviso con un fornitore. Il log del gateway, che serve per gli audit e per la notifica degli incidenti, contiene per costruzione i dati che il sistema protegge. Va trattato con la classe più alta che registra, quindi conservato nel perimetro italiano, con accessi limitati a chi ne ha bisogno e tempi di conservazione decisi prima di accenderlo. ## Registri, monitoraggio e persone Una regola di instradamento invecchia appena l'azienda collega un nuovo archivio o adotta un modello diverso, e con l'AI succede spesso. Il gateway alimenta per questo due registri da tenere allineati: il registro dei trattamenti previsto dal GDPR, che deve riportare i nuovi fornitori e le nuove finalità, e un registro dei sistemi AI con caso d'uso, classe dei dati, destinazione ammessa e responsabile. Il secondo diventa la base anche per l'AI Act, quando un caso d'uso ricade tra quelli ad alto rischio dell'Allegato III, i cui obblighi si applicano dal 2 dicembre 2027 e prevedono per chi usa questi sistemi la conservazione dei log per almeno sei mesi. Accanto ai registri serve una revisione periodica, con una cadenza approvata dal board, in cui si guardano le richieste bloccate e i falsi negativi trovati nei controlli a campione, e si decide sulle nuove fonti da collegare. È il momento in cui la classificazione si aggiorna sui documenti nuovi che nel frattempo sono entrati nei flussi. Il gateway protegge solo i flussi che ci passano. Chi trova lo strumento autorizzato scomodo apre il proprio account personale su un servizio consumer, e lì nessuna classificazione si applica. L'articolo 4 dell'AI Act, riscritto dal Digital Omnibus (regolamento UE 2026/1744), chiede a fornitori e deployer di adottare misure che sostengano l'alfabetizzazione del personale, senza imporre un livello specifico da garantire. Una policy che spiega a ciascuno quali dati può usare con quale strumento, accompagnata da una formazione costruita sui casi reali del suo lavoro, è la misura più concreta che un'azienda possa documentare, mentre una policy che le persone non capiscono genera AI non autorizzata, cioè l'unico flusso di cui il log non saprà mai niente. ## Lo schema che ne deriva Con queste scelte fatte, l'architettura si disegna quasi da sola, ed è quella che proponiamo ai clienti enterprise che trattano dati regolati. ![Il dato rosso non attraversa il confine: instradamento per classe di dato tra perimetro italiano e regioni UE, con AI gateway, mascheramento del giallo e log nel perimetro](/schema-instradamento-dato-it.png) Ogni richiesta arriva al gateway con il contesto già composto, il gateway legge la classe delle fonti, cerca i dati personali e applica la regola. Verde e giallo possono andare su entrambe le destinazioni, con il giallo che verso il modello frontier parte solo dopo il mascheramento, mentre il rosso ha una sola strada, l'infrastruttura in Italia su GPU dedicate o con un servizio di inferenza a conservazione zero. Il log sta nel perimetro italiano e alimenta i registri. La costruzione del gateway è un lavoro tecnico che si valida con un prototipo e si affida a chi lo sa fare. Le decisioni che lo configurano si verificano con poche domande da fare al proprio CAIO, o a chi in azienda ne svolge il ruolo: - Chi ha deciso quali dati possono entrare in un modello esterno all'azienda, e dove è scritto? - La classe viene dalla fonte del dato o dalla scelta di chi scrive la richiesta? - Il controllo guarda la sola domanda o tutto il contesto che arriva al modello, documenti recuperati compresi? - In quali regioni vengono elaborate le richieste, e corrisponde a quanto promesso ai nostri clienti? - Chi ha accettato formalmente il rischio residuo, e quando lo ha rivisto l'ultima volta? - Dove sta il log, e chi può leggerlo? Quando le risposte arrivano in fretta e con un documento in mano, lo schema è una conseguenza. Quando arrivano con il nome di un prodotto, c'è una conversazione da aprire in consiglio prima che la apra un'ispezione o un incidente. Nella dimensione Risk dell'AI Rating sono tra le prime domande che facciamo, e se volete partire da qui potete [prenotare una call](https://calendly.com/fabiolalli/zerofive) o scriverci a hello@zerofive.ai.