Era il marzo 2023 quando Samsung si trovò suo malgrado a occupare le prime pagine di mezzo mondo tech. Alcuni dipendenti del colosso sudcoreano avevano incollato su ChatGPT porzioni di codice sorgente proprietario, note interne riservate, verbali di riunioni. L’azienda aveva reagito vietando l’uso dei chatbot AI sui dispositivi aziendali. Ma il danno, almeno potenzialmente, era già fatto.
Quel caso è diventato il riferimento obbligato in ogni discussione sulla sicurezza dell’AI in azienda. E in un certo senso ha contribuito a cristallizzare una narrativa che da allora si è diffusa nelle stanze dei Chief Information Security Officer di mezza Europa: i modelli commerciali sono una falla aperta, l’open source installato in casa è la risposta sicura.
Il problema è che questa narrativa è sbagliata. O meglio, è parzialmente vera in entrambe le direzioni, il che la rende fuorviante proprio quando serve chiarezza.
Indice degli argomenti
La scelta che sembra tecnica
Oggi le aziende che vogliono integrare l’intelligenza artificiale nei propri processi si trovano davanti a due strade principali: la prima è affidarsi ai grandi fornitori di servizi in cloud, come OpenAI con GPT, Google con Gemini, Anthropic con Claude e Microsoft con Copilot, che offrono potenza computazionale, aggiornamenti continui e interfacce già pronte, in cambio dell’invio dei dati ai loro server; la seconda è scaricare e installare internamente un modello open source, come Llama di Meta, Mistral, DeepSeek e Falcon, mantenendo i dati all’interno del perimetro aziendale ma assumendosi tutta la responsabilità tecnica e di sicurezza.
La scelta viene spesso presentata come un compromesso semplice: comodità contro controllo, velocità contro riservatezza. Ma il profilo di rischio delle due opzioni è radicalmente diverso. Non migliore o peggiore in assoluto, diverso. E confondere i due piani porta a decisioni sbagliate.
Lo inquadra bene Mirco Marchetti, professore associato al dipartimento di ingegneria Enzo Ferrari dell’Università di Modena e Reggio Emilia, direttore del Centro di Ricerca Interdipartimentale sulla Sicurezza e la Prevenzione dei Rischi (CRIS) e delegato per la cybersecurity di ateneo: “Una volta il dato era mio, stava nei miei server, quattro macchine che conoscevo, nell’interrato che si allagava ogni due anni. Adesso siamo abituati al tutto-come-servizio e non abbiamo più idea di dove siano fisicamente i dati”. Partire da questa consapevolezza, dice Marchetti, è il primo passo per ragionare con onestà sui rischi dell’AI in azienda.
Quando deleghi, deleghi tutto
Con un’AI commerciale in modalità di servizio, il rischio principale non è quello che l’azienda percepisce per primo. Non è il fornitore che “legge i tuoi dati” nel senso malevolo del termine: è un problema più sottile di opacità e dipendenza strutturale.
Il primo nodo è la politica sul trattamento dei dati, che cambia nel tempo, spesso senza che le aziende si accorgano degli aggiornamenti nei termini di servizio. “Questi fornitori, quando possono, meno ci dicono su come trattano i nostri dati, meglio è per loro”, osserva Marchetti. “Non perché abbiano necessariamente intenzioni malevole: semplicemente si tengono le mani libere di fare un po’ quello che vogliono”.
Cosa succede alle mail inviate? Vengono usati per addestrare ulteriormente il modello? Per quanto tempo vengono conservati? Le risposte variano da fornitore a fornitore, cambiano tra i piani tariffari e si aggiornano con una cadenza che nessun contratto enterprise standard riesce a inseguire.
Qui emerge un elemento che Marchetti considera la vera discontinuità rispetto a qualsiasi altro servizio in cloud. “Con un CRM come Salesforce ero già abituato a dare i miei dati a un fornitore esterno. La differenza con i modelli di AI commerciali è la possibilità che il motore utilizzi i messaggi che gli mando e le nostre interazioni per addestrare i modelli successivi. Chi usa account gratuiti probabilmente non ha la più pallida idea del termine di servizio che sta accettando; chi paga una licenza enterprise può ottenere garanzie più stringenti, ma deve pretenderle esplicitamente”.
Il secondo nodo è la giurisdizione. I server di OpenAI sono negli Stati Uniti. Quelli di Google anche. La questione Schrems II, che ha già invalidato due accordi transatlantici sul trasferimento dei dati, è tecnicamente risolta con il Data Privacy Framework del 2023, ma la sua tenuta giuridica resta contestata.
Per le aziende che trattano dati soggetti al GDPR, questo non è un dettaglio: è un rischio legale concreto. Marchetti fa un esempio diretto: “Se l’unico fornitore usa un data center negli Stati Uniti e io gli mando dati sanitari di pazienti italiani, nel termine di servizio deve esserci qualcosa che garantisca che i dati rimangano nei confini europei. Non lo si può dare per scontato”.
Il terzo nodo è quello meno discusso: la dipendenza strutturale dal fornitore come fattore di rischio operativo. Su questo punto Marchetti va oltre la questione delle interruzioni di servizio, che pure esistono: “I modelli commerciali possono da un giorno all’altro sparire, o cambiare radicalmente le condizioni di prezzo. Se mi sono costruito un modello di business che dipende da un certo volume di chiamate a un certo costo mensile, e improvvisamente quel costo cambia di uno o due ordini di grandezza, il mio modello di business va completamente all’aria”. Un rischio che le organizzazioni tendono a sottovalutare finché non succede.
I vantaggi però vanno riconosciuti: protezioni di sicurezza già integrate, aggiornamenti automatici, infrastruttura completamente esternalizzata. Per chi non ha un team di sicurezza strutturato, questa rimane un’opzione concretamente difendibile.
Quando fai da solo, sei solo
L’open source rovescia il problema. Il dato non esce dall’azienda: questo è il vantaggio principale, ed è genuino. Ma non significa che il dato sia al sicuro.
Il rischio più sottovalutato riguarda l’integrità del modello stesso. E qui Marchetti introduce una distinzione tecnica che troppo spesso si perde nel dibattito: open weights e open source non sono la stessa cosa. “Un’applicazione open source è qualcosa che posso prendere, modificare, ispezionare nel codice. Un modello con pesi aperti è diverso: i pesi mi vengono dati, certo. Ma i dati su cui è stato addestrato, le scelte fatte durante il training, come sono stati costruiti i meccanismi di allineamento; tutto questo rimane opaco. Allo stato attuale della ricerca, nulla di quello che viene dichiarato è verificabile. Semplicemente ci si fida”.
Il problema della catena di fornitura del software, che il settore conosce bene da anni, vale integralmente anche per i modelli AI. Con una differenza: la verifica è strutturalmente impossibile con gli strumenti disponibili oggi.
C’è poi il tema delle protezioni integrate. I modelli open source, spesso distribuiti senza i meccanismi di sicurezza implementati dai fornitori commerciali, sono strutturalmente più esposti ad attacchi di tipo prompt injection e a tecniche di jailbreak. Chi li installa internamente deve costruire questi strati di protezione da zero, o affidarsi a soluzioni di terze parti.
Ma qui si incontra un problema di fondo che Marchetti descrive con precisione: “I modelli sono scatole nere. Quando ricevono un input producono un output, ma non è chiaro perché abbiano prodotto esattamente quell’output. Anche se so qual è l’input che ha causato un comportamento anomalo, l’unica cosa che posso fare è aggiungere al messaggio di sistema un’istruzione per ignorarlo. Non ho mai la certezza che input leggermente diversi non producano lo stesso effetto”.
Il problema si combina con la difficoltà di reperire le competenze necessarie, un nodo che con l’open source è più acuto. Marchetti cita un dato significativo: “Si prevede che ogni anno manchino sul mercato del lavoro circa 5mila figure con formazione in informatica e ingegneria informatica rispetto a quelle che le università italiane producono. Non è un problema risolvibile in tempi brevi”. Installare un modello in produzione su dati sensibili senza le competenze adeguate non è una scelta di controllo: è una scelta di rischio non gestito.
Il caso DeepSeek: quando “open” non significa “trasparente”
In questo contesto va inserita la questione DeepSeek, che ha agitato il mercato all’inizio del 2025. Il modello cinese, distribuito con licenza open source, ha mostrato prestazioni competitive con i migliori modelli commerciali a una frazione del costo dichiarato di addestramento. In molte organizzazioni si è aperta immediatamente la discussione: perché non usarlo?
Il problema è esattamente la distinzione che Marchetti ha illustrato: i pesi sono pubblici e ispezionabili, ma i dati su cui il modello è stato addestrato, le scelte operate durante il training, i criteri con cui sono stati costruiti i meccanismi di allineamento non sono noti. E per un modello sviluppato in un contesto geopolitico sensibile, con obblighi legali locali che possono includere la cooperazione con le autorità governative, questa opacità non è un dettaglio tecnico: è parte integrante del profilo di rischio. “Esistono anche piattaforme che dichiarano di farti usare modelli allo stato dell’arte a un prezzo più basso rispetto alle piattaforme originali”, aggiunge Marchetti. “Chi lo sa: magari funzionano bene, ma magari ogni tanto usano un modello molto più semplice e tu non lo sai.” La verificabilità, in questo campo, resta un problema irrisolto.
I rischi che non dipendono dalla scelta
Ci sono vettori di rischio che esistono indipendentemente da dove gira il modello. Lo Shadow AI è uno di questi. I dipendenti che usano strumenti AI non approvati rappresentano un problema strutturale che nessuna scelta architetturale risolve da sola. Una politica chiara sull’uso dell’AI è precondizione di qualsiasi strategia di sicurezza, prima ancora di decidere quale modello adottare.
Un secondo elemento, ancora più insidioso, emerge quando l’AI diventa agentica: quando cioè al modello vengono assegnati i permessi tecnici per agire autonomamente su sistemi aziendali. Marchetti descrive il problema con un esempio concreto: “Do al modello i diritti di operare sul mio account di posta elettronica, sul mio calendario, sui file del mio sistema. E poi magari tra le mail che legge ce n’è una con un messaggio costruito apposta per dirgli di fare cose chiaramente dannose per me. Per esempio, inviare a qualcuno tutti i contatti della mia rubrica”.
Non è uno scenario teorico: i meccanismi di prompt injection indiretta su sistemi agentivi sono documentati e la loro diffusione crescerà con l’adozione degli agenti AI.
C’è poi una dimensione che riguarda il settore della sicurezza nel suo complesso. L’AI ha cambiato il costo di un attacco informatico. “La quantità di vulnerabilità software identificate ogni giorno grazie all’intelligenza artificiale è qualcosa di molto superiore rispetto a quanto si era visto prima”, osserva Marchetti.
“Questo è positivo: vengono trovate e corrette vulnerabilità che magari esistevano da anni. Ma di converso, anche chi fa un attacco informatico usando questi strumenti è molto più rapido e investe molto meno. Stiamo abbassando la soglia di accesso a un attacco sofisticato”.
La conclusione è netta: “L’intelligenza artificiale è uno strumento utilizzabile sia dagli attaccanti sia dai difensori. Quello che sappiamo è che gli attaccanti che non usano questi strumenti presto andranno fuori mercato. E lo stesso vale per i difensori”.
Una bussola per chi decide
La domanda giusta che un CISO dovrebbe porsi non è “commerciale o open source?”. È: quali dati sto trattando, in quale contesto, e chi voglio che si assuma la responsabilità della loro sicurezza?
Marchetti offre un’indicazione precisa: “Più che la dimensione aziendale, guarderei il contesto applicativo di ogni singola applicazione. Ci possono essere piccole e medie imprese che forniscono servizi sanitari e trattano dati sensibili: in quel caso bisogna stare attenti a prescindere dalla dimensione. La dimensione conta quando porta con sé obblighi normativi specifici, come quelli derivanti da NIS2, ma non è la variabile principale”.
Per le organizzazioni che si trovano a scegliere, Marchetti suggerisce anche un criterio spesso trascurato: il valore della proprietà intellettuale. “Se sono un’azienda innovativa con progetti importanti, ha senso accollarsi il rischio di portare questi dati verso l’esterno fidandosi dei termini di servizio di un fornitore? O è meglio investire in qualcosa di locale che magari non è performante quanto i grandi modelli, ma mi consente di mantenere la governance del dato?”. Anche in assenza di obblighi normativi, questa può essere una scelta razionale.
Se i dati sono sensibili ma le competenze interne sono limitate, la scelta più difendibile è un accordo in cloud con contratto di trattamento dati solido, livelli di servizio espliciti e clausole di audit. Se le competenze ci sono e i dati non possono uscire dall’organizzazione, l’open source installato internamente ha senso, a patto di investire sull’infrastruttura di sicurezza.
Sul percorso concreto, Marchetti dà un consiglio pratico: “Appoggiarsi a una soluzione commerciale già pronta ha perfettamente senso soprattutto in fase prototipale: devo davvero spendere decine di migliaia di euro per comprare macchine e metterle in casa prima ancora di sapere se l’idea funziona? Ha senso affidarsi a un fornitore esterno per verificare se l’idea regge, e poi valutare l’investimento in una soluzione interna”. L’approccio ibrido, sempre più diffuso tra le organizzazioni mature, prevede modelli commerciali per gli usi generali e open source installato internamente per i dati che non possono lasciare il perimetro. Non è la soluzione più elegante, ma risponde con più onestà alla complessità del problema.
Il quadro normativo chiude il cerchio
L’EU AI Act distingue tra chi sviluppa il modello e chi lo mette in produzione. Nel caso dei modelli commerciali, molte responsabilità restano in capo al fornitore. Nel caso dell’open source, chi lo installa assume gli obblighi di chi lo ha sviluppato. In pratica: un’azienda che mette in produzione Llama per un’applicazione ad alto rischio è, agli occhi della normativa, equiparata a chi quel modello lo ha creato. È un’implicazione che molti stanno ancora sottovalutando.
Sul fronte GDPR la situazione si specchia: con l’open source installato internamente, l’azienda è l’unico titolare del trattamento. Più controllo, certo. Ma anche più esposizione formale in caso di violazione.
Per Marchetti l’ispirazione dell’AI Act è chiara: “In alcuni contesti mission critical bisogna applicare un principio di precauzione. Non che non si riconosca che questi sistemi funzionino, ma che hanno rischi non eliminabili, intrinseci, che non sappiamo ancora come gestire pienamente. Per cui, in certi contesti non li usiamo, oppure li usiamo, ma i risultati devono essere supervisionati da un essere umano”.
NIS2, infine, aggiunge un ulteriore livello per le organizzazioni che operano in settori critici: la scelta del modello AI entra nella valutazione di rischio della catena di fornitura digitale, con tutti gli obblighi di controllo che ne conseguono.
La vera variabile: politica e cultura aziendale
Alla fine il punto è uno solo: la sicurezza dell’AI in azienda non dipende primariamente dal modello scelto, ma dalla governance che ci si costruisce intorno. Su questo Marchetti è diretto: “Avere la supervisione umana nella catena consente di rimettere la responsabilità e l’accountability in testa a un essere umano, senza perdere del tutto i vantaggi di queste tecnologie. Certo, i vantaggi vengono attenuati: a noi piacerebbe avere qualcosa che funziona da solo, e invece dobbiamo rimetterci in mezzo”. Non è la risposta più comoda. Ma è quella più onesta.
Samsung non ha avuto un problema con ChatGPT. Ha avuto un problema di politica e cultura aziendale. La risposta giusta non era vietare i chatbot: era capire perché i dipendenti li usavano in quel modo e costruire un insieme di regole che permettesse di farlo in sicurezza. Quella lezione vale ancora oggi. Ed è più urgente che mai.
Partecipa alla community