Intelligenza artificiale e dati aziendali: il perimetro che i contratti non possono proteggere

Il mercato dei modelli di intelligenza artificiale si è strutturato in due livelli distinti, e la divisione è ormai permanente. Da un lato i modelli chiusi, accessibili via API: si inviano dati, arrivano risposte, si paga a consumo. Dall'altro i modelli a pesi aperti, scaricabili e installabili sull'infrastruttura propria: il file del modello è in casa, l'elaborazione avviene localmente, i dati non escono. Due economie diverse, due modelli di controllo radicalmente diversi, due livelli di rischio non comparabili quando in gioco ci sono informazioni riservate.

La mossa di Google con Gemma 4 — rilasciata ad aprile 2026 con licenza Apache 2.0, che elimina ogni vincolo all'uso commerciale — ha reso questa biforcazione ancora più evidente. Per la prima volta, un laboratorio di primissimo piano offre modelli aperti con prestazioni vicine ai prodotti proprietari di punta, su hardware accessibile, senza restrizioni legali. La stessa dinamica coinvolge Meta con Llama, Mistral dall'Europa, Alibaba con Qwen. L'alternativa al cloud esiste, è matura e funziona. La domanda rilevante per un'impresa cambia di conseguenza: quando è ragionevole usare l'una o l'altra opzione, e perché la risposta dipende quasi sempre dalla natura dei dati trattati.

Tre problemi distinti, spesso confusi in uno

Il dibattito sulla sicurezza dei dati con i modelli AI cloud tende a concentrarsi sull'addestramento: i dati vengono usati per migliorare il modello? Su questo punto i fornitori enterprise — OpenAI, Anthropic, Google, Microsoft — offrono garanzie contrattuali esplicite. Per i clienti business, l'addestramento sui dati trasmessi è escluso per impostazione predefinita. Su questo punto specifico, i contratti funzionano.

Ma l'addestramento è uno solo dei tre piani del problema. Gli altri due vengono quasi sempre ignorati nel momento in cui un'azienda valuta l'adozione di strumenti AI cloud.

Il secondo piano è la retention. Anche escludendo l'addestramento, i dati trasmessi via API vengono conservati sui server del fornitore per finalità di monitoraggio degli abusi. Il periodo standard per OpenAI è trenta giorni; al termine, gli input e gli output vengono rimossi dai log — salvo obblighi legali sopravvenuti. La clausola è rilevante: nel maggio 2025 un tribunale federale statunitense ha ordinato a OpenAI di conservare indefinitamente tutte le conversazioni degli utenti consumer, comprese quelle già cancellate, nell'ambito di un contenzioso sul copyright. L'ordine è stato successivamente ridimensionato e OpenAI ha ripristinato le proprie politiche standard nel settembre 2025, ma l'episodio documenta che la retention può essere modificata unilateralmente da obblighi giudiziari terzi, indipendentemente dai termini contrattuali con il cliente. Esiste una modalità Zero Data Retention (ZDR) che esclude qualsiasi conservazione degli input e degli output, ma non è automatica: va richiesta esplicitamente, è disponibile solo per clienti con use case qualificati, richiede negoziazione diretta con il team commerciale e non è accessibile su tutti gli endpoint. Per la maggior parte delle piccole imprese che usano le API standard, la ZDR non è un'opzione concretamente disponibile.

Il terzo piano — il più sottovalutato — è la trasmissione in sé. Ed è strutturalmente diverso da qualsiasi altra forma di fornitura IT che un'azienda abbia mai gestito.

Perché l'AI cloud è diversa da qualsiasi altro fornitore IT

Con un qualsiasi fornitore IT tradizionale — un provider di housing, un gestore di backup, un sistema di archiviazione documentale — i dati vengono trasmessi e conservati in forma opaca. Il fornitore custodisce file, record, pacchetti cifrati. Li archivia, li replica, li protegge. Ma non li comprende. Un contratto, un audit, un sistema di crittografia end-to-end possono garantire che nessun operatore acceda a quei file senza autorizzazione esplicita, caso per caso.

Con un modello linguistico di grandi dimensioni il meccanismo è radicalmente diverso. Quando un prompt raggiunge un LLM via API, il modello lo elabora semanticamente: comprende il contesto, estrae relazioni tra concetti, riconosce entità, produce inferenze. Non archivia un file — interpreta un contenuto. Un contratto riservato che viene inviato a un LLM per una sintesi non è più un documento opaco custodito da un server: è un testo che una macchina ha letto, compreso e dal quale ha estratto significato. Quella comprensione, in forma aggregata o sintetica, può poi essere accessibile a operatori umani del fornitore nell'ambito delle attività di monitoraggio contrattualmente previste. OpenAI lo esplicita nella propria documentazione enterprise: dipendenti autorizzati possono accedere ai dati conservati per finalità di engineering support, investigazione di potenziali abusi e conformità legale; in alcuni casi, contractor terzi vincolati da obblighi di riservatezza possono esaminare le conversazioni per identificare usi impropri.

La differenza con il passato è quindi qualitativa, non solo quantitativa. Prima dell'AI, il rischio di un fornitore cloud era l'accesso non autorizzato a file archiviati — un problema governabile con crittografia, contratti e policy di accesso. Con l'AI cloud, il dato viene consegnato a un sistema che lo comprende per funzione, non per errore o intrusione. Il fattore umano rimane il vettore più sottovalutato nella gestione del perimetro di sicurezza, e il LayerX AI Security Report 2025 lo conferma con dati precisi: il 77% degli utenti aziendali copia e incolla dati direttamente nei chatbot, spesso da account personali non gestiti, e le analisi di Cyberhaven mostrano che i dati sensibili rappresentano circa il 35% di tutto ciò che i dipendenti incollano su piattaforme AI esterne. Non comportamenti devianti: uso normale, quotidiano, di strumenti percepiti come produttivi.

Il segreto professionale, il know-how proprietario, le informazioni coperte da accordi di riservatezza con clienti o fornitori: nessuno di questi elementi può essere adeguatamente tutelato da un Data Processing Agreement se il flusso di lavoro prevede che transitino attraverso un sistema che li elabora semanticamente su infrastrutture esterne. La conformità al GDPR e all'AI Act europeo, entrato in vigore con obblighi progressivi dal 2025, aggrava ulteriormente questa esposizione: il trattamento di dati personali su server extra-UE richiede garanzie specifiche che molti contratti standard non soddisfano nella pratica operativa.

Dove l'inferenza locale risolve il problema alla radice

L'inferenza locale con modelli a pesi aperti chiude la questione in modo strutturale. Il modello gira su un server aziendale o su un'infrastruttura privata controllata dall'azienda stessa. L'elaborazione semantica avviene dentro il perimetro. I dati non escono, non transitano, non raggiungono nessun sistema esterno. La protezione non dipende da clausole contrattuali né dalla buona fede del provider: dipende dall'architettura del sistema, che per costruzione non prevede trasmissione.

Per attività che non trattano informazioni riservate — elaborazione di testi pubblici, supporto alla comunicazione esterna, analisi di contenuti già depurati da riferimenti sensibili — le API cloud rimangono una scelta efficiente. La distinzione tra dati che possono uscire dal perimetro e dati che non devono farlo è lo stesso principio che governa la gestione corretta dei dispositivi mobili aziendali: non si tratta di bloccare tutto, ma di sapere cosa classificare e come.

Pseudonimizzazione, minimizzazione e i limiti dell'approccio ibrido

Esiste un livello intermedio, architetturalmente più complesso: un sistema che elabora i documenti prima che raggiungano un modello esterno, sostituendo automaticamente i riferimenti sensibili con token o alias neutrali prima che il prompt esca dal perimetro aziendale. Il documento trasformato raggiunge il modello cloud; gli identificatori originali restano dentro.

Questo approccio si chiama correttamente pseudonimizzazione, non anonimizzazione. La distinzione è tecnica e legalmente rilevante. L'anonimizzazione vera implica l'irreversibilità: il dato viene alterato in modo tale da rendere impossibile, anche con risorse aggiuntive, il collegamento all'individuo o all'entità originaria. La pseudonimizzazione sostituisce gli identificatori con alias mantenendo una mappatura separata che consente la ricostruzione — il che la rende reversibile e, secondo le linee guida EDPB 01/2025, ancora soggetta al perimetro normativo del GDPR. L'anonimizzazione vera su testi ricchi di contesto è nella pratica quasi impossibile: un documento contrattuale che descrive una trattativa specifica rimane riconoscibile anche dopo la rimozione di nomi e date, perché il contesto stesso è identificante.

Al principio di pseudonimizzazione si affianca quello di minimizzazione: trasmettere al modello esterno solo i dati strettamente necessari per il compito richiesto, escludendo tutto ciò che non contribuisce alla qualità dell'output. La minimizzazione opera sulla selezione del contesto prima della trasmissione. È un principio corretto e applicabile — con un limite importante: i modelli linguistici producono output tanto più precisi e utili quanto più il contesto fornito è ricco e coerente. Una query eccessivamente minimizzata produce risposte generiche. La minimizzazione deve quindi operare sulla selezione delle informazioni pertinenti, non sulla loro riduzione indiscriminata: si esclude ciò che non serve, non ciò che potrebbe servire.

L'approccio ibrido — pseudonimizzazione locale come layer intermedio prima dell'invio a un modello cloud — è praticabile e in certi contesti opportuno. Richiede però progettazione accurata: un sistema di pseudonimizzazione mal calibrato lascia passare contesti identificanti anche in assenza di dati nominativi espliciti. La sua implementazione corretta è parte integrante dell'architettura AI, non un modulo aggiuntivo da innestare a posteriori.

Il mercato dei modelli aperti nel 2026: la materia prima c'è

La disponibilità tecnica per l'inferenza locale in azienda è oggi concreta. Fino a due anni fa, i modelli aperti soffrivano di un divario di qualità significativo rispetto ai migliori modelli proprietari. Quel divario si è sostanzialmente chiuso.

Gemma 4 di Google ha ottenuto il terzo posto nella classifica Arena AI con la variante da 31 miliardi di parametri, battendo sistemi con fino a venti volte più parametri. I modelli compatti della stessa famiglia — E2B ed E4B — girano direttamente su smartphone, con velocità quattro volte superiore alla generazione precedente e consumo energetico ridotto del 60%. Mistral, sviluppato in Europa con attenzione specifica alle esigenze di sovranità dei dati, offre modelli ottimizzati per l'inferenza su risorse limitate. Llama 4 di Meta dispone di finestre di contesto da dieci milioni di token, utili per elaborare grandi corpus documentali in una singola sessione. Qwen 3 di Alibaba domina su compiti di coding e ragionamento strutturato.

La competizione tra questi laboratori ha compresso i cicli di rilascio da semestri a settimane. Per la prima volta, la scelta dell'inferenza locale non comporta un sacrificio significativo sulle prestazioni. Sul fronte infrastrutturale, le stime di settore riportate da Agenda Digitale collocano il costo di un server dedicato con due GPU tra i 60.000 e i 100.000 euro per configurazioni di fascia alta. Per realtà più piccole, soluzioni su cloud privato europeo rappresentano un punto di equilibrio praticabile tra controllo e costi di infrastruttura.

La domanda architettonica che viene prima di tutto

Quando EBM Solution progetta sistemi AI per clienti che trattano informazioni riservate — studi professionali, imprese manifatturiere con know-how proprietario, aziende del settore edilizio o immobiliare con dati sensibili su committenti e fornitori, realtà del retail con archivi clienti strutturati — la prima domanda non riguarda quale modello usare. Riguarda dove gira l'inferenza.

Questa scelta determina l'architettura dell'intero sistema: la pipeline di elaborazione dei documenti, la gestione dell'autenticazione, la classificazione dei dati prima che entrino nel flusso AI, la progettazione di eventuali layer di pseudonimizzazione per i casi in cui componenti cloud siano comunque necessari. I rischi degli investimenti AI per le piccole imprese non sono solo economici: includono l'esposizione a vulnerabilità che emergono mesi dopo l'implementazione, quando l'architettura è già consolidata e costosa da modificare.

Il mercato dei modelli AI ha oggi la profondità tecnica per supportare questa scelta in modo concreto. La complessità sta nell'integrazione: hardware o cloud privato, modello, pipeline, sicurezza perimetrale, formazione degli utenti, governance interna sull'uso. Sono scelte che si ripercuotono sulla postura di sicurezza aziendale per anni e che, prese senza una valutazione accurata, producono esattamente il tipo di esposizione che si voleva evitare.