Perché la sovranità dei dati è fondamentale per l'IA aziendale
I numeri parlano da soli
dei principali fornitori di LLM statunitensi addestra i modelli sui dati degli utenti per impostazione predefinita
King et al., 2025dei CIO europei prevede di aumentare la dipendenza da fornitori IA locali
Gartner, 2025opportunità annuale dell'IA sovrana in Europa entro il 2030
McKinseyIl problema: i vostri dati vengono utilizzati per addestrare modelli di IA
Ogni volta che un dipendente incolla una clausola contrattuale in ChatGPT, carica una cartella clinica su un assistente IA cloud, o chiede a un LLM di riassumere un verbale del consiglio di amministrazione, quei dati entrano in una pipeline che l’organizzazione non controlla. La domanda non è più se i provider di IA utilizzino i propri dati — è quanto, per quanto tempo, e con quali conseguenze.
Uno studio fondamentale di King et al. (2025), pubblicato con il titolo “User Privacy and Large Language Models,” ha esaminato le pratiche in materia di privacy di sei tra i principali provider di LLM: OpenAI, Google, Anthropic, Meta, Mistral e Cohere. I risultati sono inequivocabili. Tutti e sei addestrano i propri modelli sui dati delle chat degli utenti per impostazione predefinita. Gli utenti devono individuare autonomamente e attivare i meccanismi di opt-out — meccanismi sepolti nelle pagine delle impostazioni, descritti con un linguaggio ambiguo, o soggetti a modifiche senza preavviso.
Il quadro relativo alla conservazione dei dati è altrettanto preoccupante. Diversi provider trattengono i dati delle conversazioni a tempo indeterminato, senza scadenza automatica né calendari di cancellazione. Anche laddove le finestre di conservazione sono documentate, le policy specificano raramente se i dati conservati siano già stati incorporati nei pesi del modello — un processo che è, a tutti gli effetti pratici, irreversibile.
King et al. hanno rilevato che le categorie di dati sensibili — informazioni sanitarie, identificatori biometrici, dettagli finanziari — divulgati durante le conversazioni non vengono escluse dalle pipeline di addestramento. Non esiste alcun filtro basato sul contenuto che intercetti una diagnosi medica o un codice fiscale prima che raggiunga il corpus di addestramento. Gli utenti costituiscono l’unico filtro, e non vengono informati di ciò in modo esplicito.
Forse l’aspetto più allarmante è che quattro dei sei provider includono i dati di minori nei loro dataset di addestramento. Nonostante i controlli sull’età e le restrizioni nei termini di servizio, la realtà tecnica è che nessun meccanismo robusto impedisce alle conversazioni dei minori di entrare nella pipeline di addestramento. Le implicazioni normative derivanti dalle specifiche tutele del GDPR per i minori (articolo 8) e dalla legge statunitense sulla protezione della privacy dei bambini online (COPPA) sono significative e in gran parte non affrontate.
Lo studio ha inoltre rivelato lacune sistematiche nella trasparenza delle policy sulla privacy. Le informazioni critiche — quali dati vengono raccolti, come vengono utilizzati, con chi vengono condivisi e per quanto tempo vengono conservati — vengono frequentemente omesse o descritte in termini così generici da risultare privi di significato. La policy di un provider si attribuisce il diritto di utilizzare i “contenuti” di “tutti i prodotti e servizi” per il miglioramento del modello, cancellando il confine tra una conversazione in chat e i dati provenienti da prodotti del tutto estranei.
Anche i dati dei clienti provenienti da prodotti correlati vengono incorporati nelle pipeline di addestramento. Se si utilizza il servizio di posta elettronica, l’archiviazione cloud o la suite per la produttività di un provider insieme alla sua offerta di IA, il confine dei dati tra tali prodotti potrebbe essere molto più sottile di quanto si supponga. Le clausole sull’utilizzo dei dati tra prodotti sono comuni e raramente vengono messe in evidenza durante il processo di onboarding.
La conclusione è chiara: quando si utilizza un LLM ospitato nel cloud, non si è soltanto un cliente. Si è un contributore di dati al modello di terzi — e si ha quasi nessun controllo su come tale contributo venga utilizzato, conservato o condiviso.
Il quadro normativo
I regolatori europei hanno risposto al problema della sovranità dei dati nell’IA con tre framework normativi interconnessi. Insieme, creano obblighi difficili — e in alcuni casi impossibili — da soddisfare quando ci si affida a provider di LLM ospitati negli Stati Uniti.
Regolamento europeo sull’IA (2024)
Il Regolamento europeo sull’IA stabilisce un sistema di classificazione basato sul rischio per i sistemi di IA. I sistemi che trattano dati personali per prendere decisioni che incidono sugli individui — strumenti di selezione del personale, scoring creditizio, diagnostica medica — rientrano nella categoria ad alto rischio ai sensi dell’articolo 6. I sistemi ad alto rischio sono soggetti a requisiti obbligatori: documentazione tecnica, valutazioni di conformità, monitoraggio post-commercializzazione e obblighi di trasparenza ai sensi dell’articolo 13.
Per le organizzazioni che utilizzano LLM ospitati nel cloud, la sfida è strutturale. Non è possibile produrre la documentazione tecnica richiesta dall’articolo 9 (gestione del rischio) o dall’articolo 10 (governance dei dati) quando l’architettura del modello, i dati di addestramento e la logica decisionale sono proprietari. Si sta distribuendo un sistema che non è possibile descrivere in modo completo, in un contesto normativo che lo richiede integralmente.
L’articolo 52 impone obblighi di trasparenza a tutti i sistemi di IA che interagiscono con persone fisiche. Gli utenti devono essere informati del fatto che stanno interagendo con un’IA, e il responsabile della distribuzione deve essere in grado di spiegare cosa fa il sistema e come lo fa. Con un’API black-box, la risposta al “come” è impossibile da fornire.
GDPR
Il Regolamento Generale sulla Protezione dei Dati crea una tensione fondamentale con l’addestramento degli LLM basato sul cloud. L’articolo 17 riconosce agli interessati il diritto alla cancellazione — ma una volta che i dati personali sono stati incorporati nei pesi del modello attraverso l’addestramento, non è possibile rimuoverli selettivamente. Ciò crea un divario di conformità che nessuna formulazione normativa può colmare.
La limitazione delle finalità (articolo 5) impone che i dati raccolti per uno scopo non vengano riutilizzati per finalità diverse senza un’adeguata base giuridica. Quando un dipendente utilizza un LLM cloud per redigere un’e-mail, la finalità è la redazione dell’e-mail — non l’addestramento del modello. Tuttavia, i termini del provider ridefiniscono tale interazione come un contributo all’addestramento, estendendo il principio di limitazione delle finalità oltre ogni ragionevolezza.
Le organizzazioni devono individuare una base giuridica per il trattamento ai sensi dell’articolo 6 e, per i sistemi di IA che trattano dati personali su larga scala, è obbligatoria una Valutazione d’Impatto sulla Protezione dei Dati (DPIA) ai sensi dell’articolo 35. Completare una DPIA per un sistema di cui non è possibile esaminare il funzionamento interno equivale a un esercizio di supposizioni.
Direttiva NIS2
La Direttiva NIS2, che si applica ai soggetti essenziali e importanti in tutta l’UE, aggiunge un terzo livello. Le organizzazioni che gestiscono infrastrutture critiche — energia, trasporti, sanità, finanza — e che incorporano l’IA nelle proprie operazioni sono soggette a requisiti di sicurezza rafforzati: segnalazione degli incidenti entro 24 ore, gestione del rischio nella catena di approvvigionamento e responsabilità a livello di organo di governance per la sicurezza informatica.
Quando l’inferenza IA viene eseguita tramite l’API di un provider statunitense, tale provider diventa un anello critico della catena di approvvigionamento. La loro indisponibilità è la propria indisponibilità. La loro violazione è la propria violazione. NIS2 attribuisce la responsabilità per i rischi presenti in sistemi che non si controllano.
Il divario di conformità non è teorico. È strutturale, e cresce con ogni nuova normativa.
Residenza dei dati non è sovranità dei dati
| Aspetto | Residenza dei dati | Sovranità dei dati | Controllo effettivo |
|---|---|---|---|
| Definizione | I dati sono fisicamente archiviati in un paese specifico | I dati sono soggetti a una giurisdizione legale specifica | Tutta l'elaborazione, i metadati e i backup sotto la vostra giurisdizione |
| Protezione giuridica | La legge del paese ospitante si applica all'archiviazione, ma il fornitore può essere soggetto a leggi straniere (es. US CLOUD Act) | Nessun governo straniero può obbligare l'accesso ai dati | Nessun governo straniero può obbligare l'accesso e nessun terzo elabora i vostri dati |
| Addestramento dei modelli | Il fornitore può comunque addestrare i modelli sui vostri dati | Il fornitore non può addestrare i modelli sui vostri dati senza consenso | I vostri dati non lasciano mai la vostra infrastruttura |
| Esempio | ChatGPT con data centre nell'UE | Fornitore cloud UE con DPA conforme al GDPR | LLM open-source self-hosted sul vostro cluster |
L’opportunità dell’IA sovrana
Il passaggio verso l’IA sovrana non è semplicemente un esercizio di conformità normativa — è un’opportunità economica di proporzioni storiche. Secondo l’analisi di McKinsey, le infrastrutture di IA sovrana potrebbero sbloccare un valore annuo di 480 miliardi di euro nell’UE entro il 2030, trainate dalle organizzazioni che portano le capacità di IA internamente anziché noleggiarle da provider stranieri.
L’appetito delle imprese è già misurabile. Secondo la CIO and Technology Executive Survey 2025 di Gartner, il 61% dei CIO dell’Europa occidentale sta aumentando gli investimenti nelle infrastrutture IA locali, e entro il 2027, il 33% delle imprese europee eseguirà l’IA su piattaforme localizzate — rispetto ad appena il 5% attuale. Si tratta di un aumento di sei volte in tre anni, che rappresenta una delle transizioni infrastrutturali più rapide nella storia dell’IT aziendale.
I settori che guidano questo cambiamento sono quelli che hanno più da perdere dall’esposizione dei dati: le organizzazioni del settore pubblico che gestiscono i dati dei cittadini, i provider sanitari vincolati dalla riservatezza dei pazienti, le istituzioni finanziarie soggette ad audit normativi e i fornitori della difesa che operano nel rispetto dei vincoli di sicurezza nazionale. Per questi settori, la sovranità non è una preferenza — è una precondizione per l’adozione dell’IA.
L’iniziativa EuroStack — il programma strategico dell’UE per la costruzione di infrastrutture digitali sovrane — segnala un impegno politico al massimo livello, indirizzando i finanziamenti verso le infrastrutture cloud europee, i modelli di IA open-source e la capacità di calcolo sovrana. Non si tratta di un programma di ricerca — è una politica industriale progettata per ridurre la dipendenza dagli hyperscaler statunitensi per i carichi di lavoro IA.
I venti normativi favorevoli sono inconfondibili. Il Regolamento europeo sull’IA, il GDPR e NIS2 creano insieme un contesto in cui la distribuzione sovrana non è soltanto auspicabile, ma sempre più necessaria. Le organizzazioni che si muoveranno per prime incorporeranno la conformità nella propria architettura fin dal primo giorno. Chi ritarderà dovrà affrontare costi di adeguamento, esposizione agli audit e svantaggio competitivo man mano che la normativa si inasprisce.
La finestra per il vantaggio del first mover è aperta adesso. Quando l’applicazione integrale del Regolamento europeo sull’IA entrerà in vigore, le organizzazioni che avranno già sviluppato capacità di IA sovrana saranno operative, mentre i loro concorrenti saranno ancora in fase di migrazione.
Le organizzazioni che trattano la sovranità come una capacità — un asset che possiedono e controllano — scopriranno che conformità, performance ed efficienza dei costi si allineano anziché confliggere.
Come si presenta uno stack di IA sovrana?
Una distribuzione di IA sovrana non significa costruire tutto da zero. Significa assemblare componenti open-source collaudati in un’architettura interamente di proprietà e sotto il proprio controllo.
I modelli open-source hanno raggiunto la parità con le alternative proprietarie. Le famiglie di modelli Llama, Mistral e Qwen offrono prestazioni paragonabili a GPT-4 e Claude nei benchmark più rilevanti per i casi d’uso aziendali — riepilogo, classificazione, generazione di codice ed estrazione strutturata. Poiché questi modelli sono open-weight, le loro architetture e la documentazione sull’addestramento possono essere sottoposte ad audit indipendente indipendentemente dall’origine. Molti utilizzano architetture Mixture-of-Experts che offrono prestazioni di frontiera a una frazione del costo computazionale. Non è più necessario rinunciare alle capacità in favore della sovranità.
Il livello di inferenza funziona su infrastrutture Kubernetes-native. I server di modelli containerizzati — come llama.cpp, un motore di inferenza C++ ad alte prestazioni — forniscono distribuzioni scalabili e riproducibili che possono essere gestite con controllo di versione, ripristinate e sottoposte ad audit come qualsiasi altro carico di lavoro. Ogni modifica alla configurazione viene tracciata in un Helm chart. Ogni distribuzione è dichiarativa e ripetibile.
Le scelte infrastrutturali rimangono all’interno della giurisdizione europea. Il bare metal on-premises garantisce il massimo controllo per i carichi di lavoro classificati o altamente regolamentati. I provider cloud con sede nell’UE — OVHcloud, Hetzner, Scaleway, tra gli altri — offrono macchine virtuali dotate di GPU nell’ambito del diritto europeo, senza la portata giurisdizionale del CLOUD Act statunitense. Si sceglie il livello di controllo appropriato al proprio profilo di rischio.
Il modello operativo cambia radicalmente. Ogni richiesta di inferenza è registrata localmente. Ogni versione del modello è tracciata. Ogni accesso è verificabile. Non esistono chiamate API opache a data center stranieri — soltanto richieste alla propria infrastruttura, disciplinate dalle proprie policy, archiviate nei propri log.
Questa architettura elimina un’intera categoria di oneri legali. Non sono necessari accordi di trattamento dati con terze parti perché non esiste alcuna terza parte. Nessuna Clausola Contrattuale Standard da negoziare. Nessuna Valutazione d’Impatto sul Trasferimento da effettuare. Nessuna dipendenza da decisioni di adeguatezza che possono essere invalidate dall’oggi al domani, come ha dimostrato la sentenza Schrems II.
La maturità operativa di questo stack non è più in discussione. Migliaia di organizzazioni già eseguono Kubernetes in produzione. Gli LLM open-source sono distribuiti su larga scala da imprese in ogni settore. Il tassello mancante non era la tecnologia — era l’integrazione. Uno stack di IA sovrana necessita di qualcuno che assembli i componenti, collaudi le configurazioni e pubblichi l’automazione. Questo è ciò che Prositronic fornisce.
Come Prositronic risolve il problema
Prositronic è uno stack di IA sovrana open-source e pronto per la produzione che si allinea direttamente ai requisiti di conformità che le organizzazioni europee si trovano ad affrontare. Non è un concetto né una roadmap — è un’infrastruttura distribuibile.
La conformità al GDPR è architettonica, non contrattuale. I dati non abbandonano mai la propria infrastruttura. Non esiste alcun responsabile del trattamento terzo, nessun trasferimento transfrontaliero, nessuna clausola di condivisione dei dati ambigua. Quando un utente interagisce con il proprio sistema di IA, la conversazione rimane sui propri server, sotto la propria giurisdizione, soggetta alle proprie policy di conservazione. Il diritto alla cancellazione è un’operazione di database, non una negoziazione legale.
La trasparenza richiesta dal Regolamento europeo sull’IA è integrata. Prositronic distribuisce modelli open-source — Llama, Mistral, Qwen — le cui architetture, la documentazione sui dati di addestramento e le capacità sono sottoponibili ad audit pubblico. Non esiste alcuna black box. Quando un regolatore chiede come funziona il proprio sistema di IA, è possibile indicare la scheda del modello, il codice sorgente e la configurazione di distribuzione. Gli articoli 9, 10 e 13 diventano esercizi di documentazione, non sfide di reverse engineering.
Il rischio nella catena di approvvigionamento richiesto da NIS2 viene eliminato. L’inferenza self-hosted significa nessuna dipendenza dall’uptime, dalla postura di sicurezza o dai cambiamenti di policy di un provider statunitense. La disponibilità dell’IA è propria responsabilità — ed è esattamente ciò che NIS2 richiede. Nessun SLA di terze parti si interpone tra l’organizzazione e i propri obblighi.
Il modello di distribuzione è Kubernetes-native. Prositronic funziona su qualsiasi cluster Kubernetes — bare metal on-prem, VM cloud UE o configurazioni ibride. I Helm chart e l’automazione Ansible significano che una distribuzione in produzione richiede settimane, non trimestri. L’infrastructure-as-code garantisce che ogni ambiente sia riproducibile e verificabile.
Il supporto multi-modello consente di scegliere il modello più adatto a ciascun caso d’uso. Un modello leggero con 8 miliardi di parametri per la chat interna. Un modello da 70 miliardi per l’analisi di documenti complessi. Un modello specializzato nel codice per i tool degli sviluppatori. Consultare i profili hardware disponibili per indicazioni sul dimensionamento delle GPU. Tutto funziona sulla stessa infrastruttura, gestita attraverso la stessa interfaccia, disciplinata dalle stesse policy.
Il costo totale di proprietà si sposta a proprio favore con la crescita dell’utilizzo. Non esistono tariffe API per token, nessuna sorpresa nei prezzi basati sull’utilizzo, nessun vendor lock-in. Si investe in un’infrastruttura propria, si eseguono modelli che si controllano, con ogni guadagno di efficienza che matura a favore della propria organizzazione anziché di un provider terzo.
Ottieni il manuale normativo completo
Scarica l'analisi completa di 20 pagine con approfondimento normativo, checklist di implementazione e framework di valutazione dei rischi.