AI privata e locale: perché le aziende dovrebbero riprendere il controllo della propria intelligenza artificiale

Dal cloud globale al computer sulla scrivania: privacy, proprietà intellettuale e continuità del business stanno cambiando il modo in cui progettiamo l’AI

Negli scorsi giorni ho parlato di intelligenza artificiale a Terra Madre, a Torino, partendo da una metafora inevitabilmente legata al contesto: se l’AI fosse una ricetta, quali ingredienti stiamo usando, chi decide come cucinarli e chi paga il conto?

È un modo semplice per introdurre una questione che, per chi come noi costruisce software e sistemi digitali per le aziende, sta diventando molto concreta.

Per alcuni anni abbiamo dato quasi per scontato che usare l’intelligenza artificiale significasse utilizzare un servizio erogato da una grande piattaforma internazionale: inviare una richiesta a un modello estremamente potente ospitato in qualche grande data center e ricevere una risposta.

Oggi, questa è ancora una possibilità, spesso eccellente. Ma non è più l’unica.

Sta emergendo un ecosistema di modelli open weight sempre più capaci, hardware più potente ed economico e infrastrutture europee che permette di progettare un sistema di AI in modi molto diversi.

Un modello può girare:

• sul computer dell’utente;
• su una workstation o un server all’interno dell’azienda;
• nel data center privato del cliente;
• in un’infrastruttura dedicata presso un provider italiano;
• in un cloud europeo;
• oppure, naturalmente, attraverso i grandi provider globali.

Tra questi estremi esiste ormai un continuum di possibilità.

Ed è proprio qui che secondo noi sta avvenendo uno dei cambiamenti più interessanti dell’intelligenza artificiale aziendale.

La domanda sta diventando meno “Qual è il modello più potente?” e molto più “Dove vogliamo che viva la nostra intelligenza artificiale?”.

---

Il cloud ha reso tutto semplice. Forse anche troppo.

Il cloud computing ha avuto un merito enorme: trasformare infrastrutture complesse in servizi acquistabili con una carta di credito.

L’intelligenza artificiale generativa ha seguito esattamente la stessa strada.

Con poche righe di codice possiamo accedere a modelli che hanno richiesto miliardi di dollari di investimenti per essere addestrati.

È qualcosa di straordinario.

Ma questa semplicità nasconde alcune decisioni architetturali molto importanti.

Quando un dipendente invia a un modello esterno:

• un contratto;
• un’offerta commerciale;
• il codice sorgente di un prodotto;
• il verbale di una riunione;
• la documentazione di un cliente;
• un database;
• un curriculum;
• un documento sanitario;
• o semplicemente una domanda contenente informazioni riservate,

quei dati stanno lasciando il perimetro informatico dell’organizzazione.

A seconda del servizio utilizzato, del contratto, della configurazione e della geografia dell’infrastruttura, possono essere elaborati da sistemi appartenenti a un soggetto terzo e potenzialmente trasferiti fuori dall’Unione Europea.

Questo non significa automaticamente che l’utilizzo sia illecito o insicuro, significa però che l’architettura dell’AI diventa anche un problema di governance del dato.

Ed è il primo motivo per cui stiamo lavorando sempre più spesso su sistemi di AI privata.

Il GDPR esisteva molto prima dell’esplosione dell’intelligenza artificiale generativa, ma molti dei suoi principi diventano particolarmente rilevanti quando iniziamo a utilizzare modelli linguistici.

---

1. Privacy e controllo del dato

• Dove vengono elaborati i dati?
• Per quanto tempo vengono conservati?
• Chi può accedervi?
• Sono utilizzati per migliorare il servizio?
• Esistono subprocessor?
• In quali paesi si trovano?
• Qual è la base giuridica del trattamento?
• Cosa succede quando un prompt contiene dati personali?

Sono domande che un’impresa deve porsi indipendentemente dalla qualità del modello utilizzato.

L’European Data Protection Board ha affrontato esplicitamente il tema dei modelli di AI nel proprio parere 28/2024. Tra le questioni analizzate ci sono la possibilità che un modello possa essere considerato anonimo, l’utilizzo dell’interesse legittimo come base giuridica e le conseguenze dell’utilizzo di dati personali trattati illecitamente durante lo sviluppo di un modello. L’EDPB sottolinea inoltre che l’anonimato di un modello deve essere valutato caso per caso.

Il punto interessante è che esiste una soluzione architetturale molto semplice a una parte del problema: non far uscire il dato.

Se il modello gira all’interno dell’infrastruttura dell’organizzazione, il prompt, i documenti e le informazioni utilizzate per generare una risposta possono rimanere completamente nel perimetro aziendale.

Immaginiamo, per esempio, un assistente che consenta ai dipendenti di interrogare:

• manuali tecnici;
• documentazione interna;
• CRM;- procedure;
• contratti;
• knowledge base;
• ticket di assistenza.

Con un’architettura tradizionale basata su API esterne, parte di queste informazioni viene necessariamente trasmessa a un provider.

Con un modello locale possiamo costruire l’intero processo all’interno dell’infrastruttura del cliente.

Il database rimane lì.

Gli embedding possono rimanere lì.

Il vector database rimane lì.

Il modello rimane lì.

Le conversazioni rimangono lì.

Questo riduce radicalmente la superficie di esposizione.

Naturalmente locale non significa automaticamente conforme al GDPR. Rimangono fondamentali controllo degli accessi, logging, retention, cifratura, gestione dei permessi, minimizzazione del dato e tutte le normali misure di sicurezza.

Ma cambia un elemento fondamentale: l’azienda riacquista il controllo fisico e logico del flusso dei propri dati.

---

Dall’on-premise al cloud europeo

Quando diciamo “AI privata” non intendiamo necessariamente un server chiuso in uno sgabuzzino aziendale.
Esistono diversi livelli.

On-device

Il modello gira direttamente sul notebook, sullo smartphone o sulla workstation dell’utente.
È la soluzione con il massimo livello di località.
Per alcune attività è già oggi sorprendentemente efficace: classificazione, estrazione di informazioni, sintesi, elaborazione di documenti, piccoli agenti, analisi del codice.

On-premise

L’azienda possiede uno o più server dedicati all’AI.
Il modello viene eseguito internamente e può essere messo a disposizione di decine o centinaia di utenti.
In questo scenario l’AI diventa una vera infrastruttura aziendale, paragonabile a un database o a un application server.

Private cloud

L’infrastruttura può trovarsi presso un provider esterno, ma essere dedicata al cliente e collocata in Italia o nell’Unione Europea.
Si mantengono molti dei vantaggi operativi del cloud senza necessariamente affidare l’intero stack AI a un hyperscaler extraeuropeo.

Hybrid AI

Probabilmente sarà lo scenario più comune: alcuni task vengono eseguiti localmente, altri invece vengono affidati a modelli di frontiera.

L’applicazione decide dinamicamente quale modello utilizzare in base a:

• sensibilità dei dati;
• complessità della richiesta;
• latenza;
• costo;
• prestazioni richieste.

Ed è forse questa la parte più interessante.
Non bisogna scegliere tra cloud e locale una volta per tutte. Possiamo progettare sistemi capaci di scegliere.

---

2. Proprietà intellettuale: cosa succede alle idee che affidiamo a un’AI?

C’è poi un problema meno evidente.

Ogni volta che utilizziamo un sistema di AI come strumento di lavoro, gli forniamo informazioni: a volte si tratta di dati banali, altre volte stiamo invece condividendo qualcosa di molto prezioso:

• un algoritmo;
• un’idea di prodotto;
• una ricerca ancora non pubblicata;
• una strategia commerciale;
• un’invenzione;
• codice proprietario;
• un risultato scientifico.

E questo apre una questione enorme: dove finisce la proprietà intellettuale quando il processo creativo passa attraverso una piattaforma AI?

Una vicenda molto recente nel mondo della matematica lo rende particolarmente evidente.

I matematici Tristan Buckmaster della New York University e Levent Alpöge di Harvard stavano lavorando su un aspetto del problema di Navier-Stokes, uno dei celebri Millennium Prize Problems.

Secondo quanto riportato da Nature, Buckmaster utilizzava da tempo strumenti di OpenAI e Anthropic durante le proprie ricerche. Quando OpenAI ha annunciato risultati sullo stesso problema, i ricercatori hanno sollevato il dubbio che parte del loro lavoro potesse aver contribuito indirettamente al sistema.

OpenAI ha respinto questa interpretazione dopo un’indagine interna, affermando che gli input degli utenti successivi a una determinata data non avrebbero potuto influenzare il sistema utilizzato e che il team non aveva avuto accesso al lavoro non pubblicato dei ricercatori. La vicenda resta quindi controversa.

Il punto interessante, per un’impresa, va oltre questo singolo caso.

La semplice esistenza della controversia evidenzia una domanda che fino a pochi anni fa probabilmente non ci saremmo posti:

se utilizziamo un sistema AI per sviluppare qualcosa di nuovo, quanto siamo sicuri del confine tra ciò che appartiene a noi e ciò che entra nell’ecosistema del provider?

Le condizioni contrattuali dei servizi enterprise offrono generalmente tutele molto maggiori rispetto ai prodotti consumer, ed è importante distinguere i due contesti.

Ma dal punto di vista architetturale esiste ancora una volta una soluzione estremamente forte:un modello che gira nella nostra infrastruttura non deve ricevere le nostre idee attraverso un servizio esterno.

Per alcune organizzazioni questo potrebbe diventare importante quanto tenere il codice sorgente in un repository privato.

---

Open weight non significa necessariamente open source

Qui serve una precisazione.

Quando parliamo di modelli locali utilizziamo spesso impropriamente la parola “open source”.

In molti casi è più corretto parlare di open weight.

Significa che i pesi del modello possono essere scaricati ed eseguiti sulla propria infrastruttura.

Licenza, dataset di training, codice utilizzato per l’addestramento e possibilità di modifica possono invece avere condizioni molto diverse da modello a modello.

È una distinzione importante anche dal punto di vista normativo.

L’AI Act europeo prevede alcune esenzioni per modelli general-purpose distribuiti con licenze realmente free e open source e con pesi, architettura e informazioni d’uso pubblicamente disponibili. Rimangono comunque alcuni obblighi, tra cui quelli relativi al copyright e alla pubblicazione di informazioni sui contenuti utilizzati per il training.

Quindi scegliere un modello significa valutare anche la licenza con cui viene distribuito.

---

3. Continuità del business e dipendenza dal provider

C’è infine una terza questione che secondo me viene sottovalutata.

Che cosa succede se costruiamo una parte importante del nostro business sopra un modello che non controlliamo?

Oggi un’API può essere disponibile.

Domani il provider può:

• modificare il prezzo;
• cambiare i limiti di utilizzo;
• ritirare un modello;
• modificare le condizioni contrattuali;
• eliminare una funzionalità;
• cambiare le policy;
• limitare l’accesso da una determinata area geografica.

Questo fa parte della normale evoluzione di qualsiasi servizio cloud.

Diventa però molto più delicato quando l’intelligenza artificiale smette di essere una funzione accessoria e diventa parte centrale di un processo aziendale.

Immaginiamo un’impresa che automatizzi il 40% del proprio customer care utilizzando un singolo modello.

Oppure un software SaaS il cui servizio principale dipenda completamente da un’API esterna.

In quel momento l’AI provider diventa di fatto parte della supply chain.

Esattamente come un fornitore industriale.

Solo che può trovarsi dall’altra parte dell’oceano ed essere sostituibile con difficoltà.

---

Il lock-in dell’intelligenza artificiale

Nel cloud tradizionale conosciamo bene il concetto di vendor lock-in.

Con l’AI potrebbe essere ancora più forte. Perché il sistema non dipende soltanto dall’infrastruttura, può dipendere dal comportamento specifico di un modello.

I prompt sono stati ottimizzati per quel modello.

Gli agenti funzionano con quel modello.

I test sono stati costruiti su quel modello.

La qualità delle risposte è stata calibrata su quel modello.

Cambiarlo può significare dover riprogettare una parte importante del prodotto.

L’Europa si sta muovendo anche sul problema generale del lock-in cloud. Il Data Act impone ai provider misure per facilitare il passaggio verso altri servizi e prevede l’eliminazione completa delle switching charges e delle data egress charges dal 12 gennaio 2027.

La Commissione Europea, nelle proprie strategie di procurement, ha inoltre iniziato a parlare esplicitamente di cloud sovereignty, diversificazione dei provider e resilienza come obiettivi strategici. In una gara del 2026 ha scelto più fornitori proprio per evitare la dipendenza da un singolo provider.

Lo stesso principio secondo noi dovrebbe iniziare a essere applicato all’intelligenza artificiale.

---

L’AI dovrebbe essere sostituibile

Una delle idee che stiamo cercando di applicare nei sistemi che progettiamo è molto semplice:

il modello dovrebbe essere una componente sostituibile dell’architettura.

L’applicazione non dovrebbe sapere necessariamente se dietro una richiesta c’è:

• un modello OpenAI;
• Anthropic;
• Google;
• Mistral;
• Llama;
• Qwen;
• DeepSeek;
• o un modello eseguito nel data center del cliente.

Serve uno strato di orchestrazione.

Serve misurare qualità, costo e latenza.

Serve poter effettuare routing.

Serve poter sostituire un modello.

In altre parole, dobbiamo trattare l’AI come abbiamo imparato a trattare altre componenti software.

Con astrazione.

Interoperabilità.

Fallback.

Observability.

E possibilità di migrazione.

Questo permette anche scenari molto interessanti.

Il modello locale gestisce l’80% delle richieste quotidiane.

Le richieste particolarmente complesse vengono inviate a un modello frontier.

I documenti classificati come sensibili non possono mai uscire dal perimetro aziendale.

Se un provider diventa indisponibile, il traffico viene automaticamente spostato su un altro.

Se cambia radicalmente il prezzo, possiamo modificare il routing.

Questo trasforma il controllo dell’AI in una scelta architetturale anziché in una promessa contrattuale.

---

4. Il modello più grande non è sempre il modello giusto

Per molti anni l’evoluzione dell’AI sembrava seguire una regola abbastanza semplice:

• più parametri;
• più dati;
• più GPU;
• prestazioni migliori.

Quella dinamica continua a esistere.

I modelli frontier rimangono strumenti straordinariamente potenti.

Ma contemporaneamente sta succedendo qualcos’altro.

I modelli più piccoli stanno migliorando molto rapidamente.

Quantizzazione, distillazione, mixture of experts, fine tuning e miglioramenti nelle architetture permettono oggi a modelli relativamente piccoli di svolgere compiti che pochi anni fa richiedevano infrastrutture enormi.

E questo cambia completamente l’economia dell’AI privata.

Non serve necessariamente costruire un mini data center.

Per alcuni use case può bastare una workstation.

Per altri un singolo server GPU.

Per altri ancora perfino il computer dell’utente.

Da qui nasce una domanda che cerchiamo di porci sempre più spesso nei progetti:

qual è il modello più piccolo che risolve bene questo problema?

È una domanda tecnica.

Ma è anche economica.

Energetica.

E strategica.

---

5. Dal “one model fits all” a un’architettura di modelli

Probabilmente il futuro delle applicazioni AI aziendali sarà meno monolitico di quanto immaginiamo oggi.

Non avremo necessariamente un’unica grande intelligenza artificiale che fa tutto.

Potremmo avere decine di modelli specializzati.

Un modello molto piccolo classifica una mail.

Uno estrae dati da una fattura.

Uno analizza codice.

Uno interroga la knowledge base.

Uno genera testo.

Uno riconosce immagini.

Un modello di frontiera interviene soltanto sui problemi che richiedono maggiore capacità di ragionamento.

Dal punto di vista software assomiglia molto a quello che è già successo con le architetture distribuite.

Abbiamo smesso di pensare a un unico enorme computer centrale.

Potremmo progressivamente smettere di pensare anche a un unico enorme modello centrale.

---

6. La nostra idea di Private AI

È esattamente la direzione sulla quale stiamo lavorando in Synesthesia.

Quando progettiamo un sistema AI vogliamo poter valutare insieme al cliente quanto vicino ai suoi dati debba vivere il modello.

Possiamo immaginare una scala.

Livello 1: AI sul device

Il modello gira sul computer o sul dispositivo dell’utente.

Livello 2: AI aziendale

Il modello gira su infrastruttura interna del cliente.

Livello 3: AI privata in Italia

Server dedicati o infrastruttura gestita all’interno di data center italiani.

Livello 4: AI europea

Cloud e infrastrutture collocate nell’Unione Europea.

Livello 5: AI globale

Accesso ai modelli frontier dei principali provider internazionali.

Non esiste un livello giusto in assoluto, ma esisteil livello giusto per ogni applicazione.

Un chatbot pubblico di marketing potrebbe tranquillamente utilizzare un modello frontier,n sistema che analizza documentazione R&D riservata potrebbe meritare un modello completamente interno, oun’applicazione complessa potrebbe utilizzare entrambi.

Il nostro obiettivo è costruire l’architettura che permetta di scegliere.

---

Sovranità AI significa possibilità di scelta

La parola “sovranità” rischia a volte di diventare uno slogan.

Dal punto di vista tecnologico per noi ha invece un significato molto pratico.

Significa poter decidere:

• dove vengono elaborati i dati;
• chi può accedervi;
• quale modello utilizzare;
• dove viene eseguito;
• quanto costa;
• quando sostituirlo;
• come aggiornarlo;
• cosa succede se un fornitore scompare.

La sovranità tecnologica non richiede necessariamente di costruire tutto in casa.

Richiede però di conservare la possibilità di scegliere.

Ed è forse questa la caratteristica più importante di una buona architettura AI.

---

Il prossimo passo dell’intelligenza artificiale aziendale

La prima fase dell’AI generativa è stata inevitabilmente dominata dalla meraviglia.

Abbiamo scoperto che una macchina poteva scrivere un testo, generare un’immagine, programmare, sintetizzare un documento, ragionare su un problema.

La seconda fase sarà probabilmente molto più pragmatica.

Le aziende inizieranno a chiedersi:

• quanto costa?
• dove sono i dati?
• chi controlla il modello?
• come lo integriamo nei processi?
• cosa succede se il provider cambia?
• quali rischi introduce?
• possiamo farlo funzionare nella nostra infrastruttura?

È il passaggio dalla sperimentazione all’ingegneria.

E forse anche dalla semplice adozione dell’intelligenza artificiale alla sua vera industrializzazione.

Da questo punto di vista, l’AI privata e locale non rappresenta un ritorno al passato.

È una nuova possibilità progettuale.

Possiamo usare il cloud quando ci serve.

Possiamo usare modelli frontier quando portano un vantaggio reale.

Possiamo utilizzare modelli locali quando privacy, proprietà intellettuale, costo o continuità lo rendono preferibile.

E possiamo costruire sistemi capaci di combinare tutte queste possibilità.

La domanda quindi non sarà più semplicemente:

“Quale AI utilizziamo?”

Diventerà:

“Quale AI utilizziamo, per quale dato, per quale problema e in quale luogo?”

Ed è probabilmente da questa domanda che inizieranno i sistemi di intelligenza artificiale davvero maturi.