Scaricare un modello e farlo girare su un computer o su un server aziendale sembra offrire una risposta semplice alla riservatezza: se il modello è “in casa”, i dati non escono. È un vantaggio possibile, ma non una garanzia automatica. Un sistema AI comprende runtime, interfacce, documenti, database vettoriali, log, backup, librerie, aggiornamenti e integrazioni. Per capire se i dati restano davvero sotto controllo bisogna osservare l’intero flusso, non soltanto dove sono memorizzati i pesi del modello.

Perché l’AI locale è tornata al centro

Le famiglie di modelli open-weight hanno reso l’inferenza locale più accessibile. OpenAI descrive gpt-oss-20b come un modello eseguibile anche su sistemi con 16 GB di memoria, mentre Google mette a disposizione varianti Gemma e strumenti per eseguirle su workstation, server e dispositivi. La scelta non è più limitata ai grandi data center, anche se prestazioni e requisiti cambiano molto in base a modello, quantizzazione e carico reale.

Per un’azienda, l’interesse nasce da esigenze concrete: residenza dei dati, documentazione riservata, funzionamento senza connessione, latenza prevedibile, personalizzazione e minore dipendenza da un singolo fornitore. Questi vantaggi vanno confrontati con hardware, energia, aggiornamenti, sicurezza, monitoraggio e competenze operative. “Scaricabile gratuitamente” non significa “senza costi” né “pronto per la produzione”.

Open source e open-weight non sono sinonimi

Nel linguaggio commerciale molti modelli vengono chiamati open source perché i pesi possono essere scaricati. La Open Source AI Definition dell’Open Source Initiative richiede però libertà effettive di uso, studio, modifica e condivisione, insieme alla forma necessaria per intervenire sul sistema, comprese informazioni sufficienti sui dati e sul processo di addestramento.

Un modello open-weight rende disponibili i parametri finali, spesso con una licenza permissiva, ma può non pubblicare dataset, pipeline di training o tutti i componenti necessari a riprodurlo. Questa distinzione non decide da sola la qualità del modello, ma incide su trasparenza, modificabilità, licenze e dipendenza dal fornitore. Prima dell’adozione vanno controllati licenza, policy d’uso, provenienza, model card, componenti software e condizioni dei runtime utilizzati.

“Locale” può indicare architetture molto diverse

Un modello può girare sul portatile di un singolo utente, su un server nella rete aziendale, in un data center gestito, in un private cloud o presso un provider che espone un’istanza dedicata. Sono tutte soluzioni spesso descritte come private, ma presentano confini, responsabilità e superfici di attacco differenti.

On-premise indica che l’infrastruttura è sotto il controllo diretto dell’organizzazione; private cloud descrive un ambiente cloud isolato logicamente o fisicamente; self-hosted indica chi gestisce l’applicazione, non necessariamente dove risiedono server e dati. Prima di parlare di privacy servono quindi un diagramma dei flussi, l’elenco dei soggetti coinvolti e la posizione di prompt, file, embedding, log, backup e copie temporanee.

Dove viaggiano davvero prompt, documenti e log

Anche quando l’inferenza avviene in locale, l’applicazione può contattare servizi esterni per telemetria, aggiornamenti, autenticazione, ricerca web, conversione dei documenti o strumenti collegati. Un’interfaccia installata internamente può inoltre usare API remote senza renderlo evidente all’utente. Firewall, proxy e monitoraggio delle connessioni devono verificare il comportamento effettivo, non soltanto la configurazione dichiarata.

Nei sistemi RAG, i documenti vengono estratti, suddivisi e trasformati in rappresentazioni numeriche, dette embedding, conservate in un database vettoriale. Embedding, indici e metadati sono dati derivati, non automaticamente anonimi. Anche cronologia delle conversazioni, cache, output, prompt di sistema e log applicativi possono contenere informazioni riservate. Conservazione, cifratura, autorizzazioni e cancellazione devono coprire l’intera pipeline.

Anche il modello può rientrare nel perimetro dei dati personali

L’EDPB chiarisce che l’eventuale anonimato di un modello AI deve essere valutato caso per caso. Se è ragionevolmente possibile identificare persone presenti nei dati di addestramento oppure estrarre informazioni personali mediante interrogazioni o accesso ai parametri, il modello non può essere considerato anonimo per semplice dichiarazione.

Eseguire il modello internamente può ridurre la comunicazione di dati a terzi, ma non risolve origine e liceità dei dati, minimizzazione, finalità, diritti degli interessati o rischio che informazioni memorizzate riemergano negli output. Sono aspetti da valutare con chi presidia protezione dei dati, sicurezza e processo aziendale. L’architettura tecnica sostiene queste decisioni, ma non sostituisce la valutazione giuridica e organizzativa.

Più controllo significa più responsabilità operativa

Con un servizio gestito, una parte di patch, capacità, monitoraggio e continuità è affidata al fornitore. Nel self-hosting queste responsabilità ritornano all’organizzazione: autenticazione, separazione degli accessi, cifratura, gestione dei segreti, aggiornamenti, vulnerabilità delle dipendenze, backup, ripristino, limiti di utilizzo e registrazione degli eventi.

Anche il modello e i runtime fanno parte della supply chain. Pesi, container e pacchetti devono provenire da fonti verificate; versioni e configurazioni vanno bloccate e testate prima del rilascio. Un server locale esposto senza protezioni può essere meno sicuro di un servizio cloud ben governato. Il vero vantaggio non è la posizione fisica in sé, ma la capacità di applicare controlli coerenti e verificarli nel tempo.

Cloud, locale o ibrido: scegliere sul caso d’uso

Le API cloud sono adatte quando servono avvio rapido, elasticità e modelli avanzati, purché dati, contratto, conservazione, regione e subfornitori siano compatibili con il caso d’uso. L’on-premise è interessante per carichi stabili, dati sensibili, requisiti offline o forte controllo infrastrutturale, ma richiede capacità tecniche e operative interne. Il private cloud occupa una posizione intermedia, senza eliminare la necessità di valutare gestore e configurazione.

Un’architettura ibrida può mantenere localmente classificazione, anonimizzazione, ricerca documentale o attività sensibili e usare un servizio remoto soltanto per input autorizzati e minimizzati. Non è automaticamente la soluzione migliore: aumenta componenti, integrazioni e punti da monitorare. La scelta deve confrontare qualità, latenza, volumi, costi totali, dati ammessi, disponibilità e conseguenze di un errore.

Partire da un pilota che misuri anche la privacy

Un pilota utile parte da un solo processo, un insieme di dati autorizzato e criteri osservabili. Prima dell’installazione si disegna il flusso dei dati, si individuano tutte le connessioni esterne, si definiscono conservazione e ruoli e si stabilisce quali informazioni non devono mai entrare nel sistema. Dati sintetici o minimizzati permettono di verificare l’architettura prima di usare contenuti reali.

Durante la prova vanno misurati qualità delle risposte, errori, latenza, consumo di memoria, costo operativo e interventi umani. Test di autorizzazione, isolamento, backup, ripristino e aggiornamento contano quanto il benchmark del modello. Solo dopo questa verifica ha senso decidere se estendere il sistema, adottare un modello diverso o mantenere una combinazione controllata di locale e cloud.

FONTI UFFICIALI

Per approfondire.