Sovranità del dato nell’AI: dove finiscono davvero i tuoi dati?

Usare l’AI in azienda non significa solo scegliere il modello migliore. Significa capire dove vengono elaborati i dati, sotto quale giurisdizione e con quale livello di controllo. Dal cloud ai modelli locali, vediamo rischi, alternative e costi reali di un’infrastruttura AI privata.

Quando un’azienda decide di introdurre l’AI, la discussione parte quasi sempre dal modello.

Qual è il migliore? Quanto è veloce? Quanto costa? Quanto è bravo nel reasoning?

Ma quando iniziamo a parlare di documenti aziendali, proprietà intellettuale, dati dei clienti o informazioni strategiche, c’è una domanda che viene prima:

dove finiscono questi dati?

È una delle prime domande che affrontiamo quando progettiamo sistemi AI per aziende. Perché il modello si può sostituire. Il modo in cui decidiamo di gestire il dato, invece, è una scelta architetturale.

Privacy e sovranità non sono la stessa cosa

Il primo livello del problema è abbastanza semplice.

Esistono servizi AI che non forniscono condizioni contrattuali adeguate al trattamento di informazioni aziendali.

In quel caso la scelta è altrettanto semplice: determinati dati lì non dovrebbero arrivare.

Poi ci sono i servizi enterprise.

DPA, condizioni specifiche sul trattamento, esclusione dal training, regioni europee, controlli sulla retention.

Molto meglio.

Ma il DPA risolve principalmente il rapporto tra cliente e fornitore. Non elimina automaticamente un altro problema: da quale infrastruttura, società e ordinamento giuridico dipende il servizio?

Un dato può essere fisicamente conservato in Europa e allo stesso tempo attraversare una catena tecnologica controllata da soggetti extraeuropei.

Ed è qui che dalla semplice privacy passiamo al concetto di sovranità del dato.

Quando entra in gioco la geopolitica

Il problema non è immaginare scenari da film.

È riconoscere una cosa molto più banale: le regole cambiano.

Cambiano i governi, cambiano le normative, cambiano gli accordi internazionali, cambiano le restrizioni commerciali e le condizioni con cui determinate tecnologie possono essere fornite.

Anche gli attuali meccanismi che regolano alcuni trasferimenti internazionali di dati sono soggetti a verifiche e revisioni periodiche.

Questo non significa che utilizzare servizi extraeuropei sia necessariamente sbagliato.

Significa che quella dipendenza fa parte del rischio architetturale.

E nell’AI il tema pesa particolarmente, perché non stiamo affidando a un fornitore soltanto CPU e storage.

Possiamo inviargli contratti, procedure interne, documentazione tecnica, dati dei clienti e una parte significativa della conoscenza aziendale.

L’alternativa: portare il modello vicino al dato

Una possibilità è ribaltare il paradigma.

Invece di portare continuamente i dati verso il modello, portiamo il modello dove si trovano i dati.

Un LLM open-weight può essere eseguito su infrastruttura dedicata, in datacenter, private cloud oppure direttamente nella rete dell’azienda.

In questo modo possiamo controllare direttamente:

• accessi e autenticazione;
• log e audit;
• retention;
• integrazioni;
• documenti indicizzati;
• aggiornamenti;
• modello utilizzato.

Ma soprattutto il modello torna ad essere un componente sostituibile dell’architettura.

Non tutto, però, richiede un datacenter pieno di GPU. E qui arriviamo alla parte economicamente interessante.

Caso 1: AI privata per documenti e agenti semplici

Pensiamo a un’azienda che vuole utilizzare l’AI per attività interne non mission-critical.

Ad esempio:

• interrogare procedure e documentazione aziendale;
• realizzare una knowledge base con RAG;
• sintetizzare report, verbali e documenti;
• confrontare contratti o versioni differenti dello stesso documento;
• classificare documenti ed email;
• estrarre dati da testi semi-strutturati;
• preparare bozze e documentazione interna;
• analizzare ticket di assistenza;
• interrogare database e API attraverso semplici agenti;
• automatizzare alcune attività di back-office.

Per workload di questo tipo può essere sufficiente un modello nell’ordine dei 15-30 miliardi di parametri, opportunamente scelto e quantizzato, eseguito su una singola GPU da circa 24 GB.

Non stiamo cercando il modello più intelligente disponibile al mondo.

Stiamo cercando un modello abbastanza capace per quel lavoro, mantenendo i dati sotto il controllo dell’azienda.

Un esempio di offerta

Una soluzione di questo tipo può comprendere:

• workstation o piccolo server GPU;
• runtime LLM;
• modello locale;
• RAG sui documenti aziendali;
• autenticazione;
• uno o più agenti;
• integrazione con API o database;
• logging e monitoring;
• installazione e configurazione.

Ordine di grandezza del progetto: 15.000-25.000 €.

Per molte PMI significa poter introdurre un sistema AI privato con un investimento paragonabile a quello di altri progetti software aziendali, senza costruire il piccolo CERN personale che spesso viene evocato quando si parla di AI locale.

Caso 2: modello frontier per un processo mission-critical

Cambiamo completamente scenario.

L’AI entra in un processo ad alto valore economico e deve affrontare reasoning complesso, contesti molto grandi, numerose integrazioni e richieste concorrenti.

Magari coordina diversi agenti, analizza grandi volumi di informazioni o supporta attività in cui una riduzione significativa della qualità del modello produce conseguenze operative reali.

Qui usare un modello piccolo soltanto per risparmiare sull’hardware può non avere alcun senso.

Possiamo allora progettare un’infrastruttura dedicata per eseguire modelli open-weight di fascia frontier, utilizzando server multi-GPU con acceleratori datacenter della classe H200.

Una H200 dispone, per esempio, di 141 GB di memoria HBM3e ed è progettata specificamente anche per carichi LLM di grandi dimensioni.

Il salto economico è importante.

Un server 8-GPU H200, da solo, può oggi trovarsi nell’ordine delle diverse centinaia di migliaia di euro, prima ancora di considerare progettazione, networking, storage, deployment, sicurezza e integrazione applicativa.

Un esempio di offerta

Un progetto di questo livello può comprendere:

• infrastruttura multi-GPU;
• deployment di un modello frontier open-weight;
• serving ottimizzato;
• RAG e sistemi agentici;
• integrazione con applicazioni aziendali;
• autenticazione e autorizzazioni;
• audit e monitoring;
• alta disponibilità dove necessaria;
• procedure di aggiornamento dei modelli;
• supporto e manutenzione.

Ordine di grandezza: 250.000-500.000 € e oltre, a seconda dell’infrastruttura, della ridondanza e dei livelli di servizio richiesti.

Sembra molto rispetto alla workstation del primo esempio.

Ma è il confronto sbagliato.

La domanda non è quanto costa rispetto a una GPU consumer.

La domanda è: quanto vale il processo che questa infrastruttura deve supportare?

Se l’AI interviene su un processo che produce o protegge milioni di euro di valore, il dimensionamento segue il processo, non il prezzo della scheda video.

Non tutto deve essere locale

Naturalmente sovranità del dato non significa spegnere Internet e mettere il server in cantina.

La soluzione più razionale è spesso ibrida.

Un’azienda può utilizzare modelli cloud molto potenti per dati pubblici o non critici, servizi enterprise con adeguate garanzie per altri workload e infrastruttura privata per le informazioni che non vuole affidare a soggetti esterni.

Può anche utilizzare modelli diversi nello stesso sistema.

Il punto non è essere ideologicamente favorevoli al cloud o all’on-premise.

Il punto è decidere consapevolmente quale livello di dipendenza accettare per ogni dato e per ogni processo.

Quanto controllo serve alla tua AI?

Per questo non partiamo dal modello.

Partiamo dal problema, dai dati e dal valore del processo.

A volte la soluzione corretta è una macchina da 15.000 euro con un modello relativamente piccolo.

Altre volte significa progettare un’infrastruttura da centinaia di migliaia di euro capace di eseguire privatamente modelli di fascia frontier.

E spesso la risposta migliore sta da qualche parte nel mezzo.

La sovranità del dato non significa necessariamente possedere tutta l’infrastruttura. Significa poter scegliere dove elaborare le proprie informazioni, quali dipendenze accettare e quali invece eliminare.

Se stai valutando l’introduzione di AI su documenti, processi o dati che non vuoi semplicemente inviare a un servizio esterno, possiamo progettare l’architettura partendo da questi vincoli: dal modello locale su singola GPU fino a infrastrutture private per workload mission-critical.

Perché scegliere un LLM è facile.

Capire quale infrastruttura abbia realmente senso costruirgli intorno è il lavoro di ingegneria.