Che differenza c’è tra AI privata e AI sovrana?

“Privato” risponde a una domanda di riservatezza. Dice che i tuoi prompt, i tuoi documenti e i tuoi output non sono visibili ad altri tenant, non vengono usati per addestrare un modello condiviso e sono trattati sulla base di un accordo che lo stabilisce. È una proprietà reale e, per molti casi d’uso, basta.

“Sovrano” risponde a una domanda di controllo, e ha tre componenti che vengono spesso confuse. Giurisdizione: quale ordinamento può imporre l’accesso ai dati, che non sempre coincide con il paese in cui si trovano i server. Controllo operativo: chi può cambiare il modello, i filtri o le condizioni, e con quale preavviso. Sostituibilità: se un componente può essere sostituito senza ricostruire il sistema, ed è questo che rende le prime due esigibili nei fatti e non solo sul contratto.

La distinzione ha un peso commerciale. Un fornitore può essere del tutto sincero sulla privacy e lasciarti comunque senza risposta quando il modello dietro il suo endpoint viene deprecato, riaddestrato o riprezzato — e in un ambiente regolato un cambiamento nel comportamento del modello è un cambiamento nel comportamento del tuo sistema, che devi essere in grado di rilevare e spiegare.

È la tassonomia usata in tutto questo sito. Esiste perché “sovrano”, da solo, è diventato una parola di marketing, e una specifica deve essere più precisa di una parola.

AI completamente locale

Indicizzazione, retrieval, identità, audit e generazione girano tutti su infrastruttura controllata dall’organizzazione. Nulla di una risposta esce dal perimetro. Il costo è l’hardware e la scelta del modello: hai i modelli che riesci a ospitare, con il throughput che le tue GPU consentono.

AI ibrida sovrana

Dati, retrieval, riconciliazione, identità e audit restano in locale; solo il passo finale di generazione chiama un endpoint di inferenza esterno, secondo policy, con il contesto recuperato passato all’endpoint e il registro della chiamata conservato in locale. Il componente è sostituibile: cambiare fornitore cambia un’integrazione, non l’architettura. È il modello in produzione presso Federfarma Lombarda.

Inferenza privata in UE

Inferenza su infrastruttura privata o residente in UE, con condizioni di residenza, conservazione e accesso definite esplicitamente. Adatta quando il vincolo decisivo è la giurisdizione e le condizioni di trattamento, più che la custodia fisica dell’hardware.

Dirlo in questo modo ha due conseguenze. La prima: la descrizione onesta di un sistema ibrido non è “completamente on-premise” e nemmeno “i dati non escono mai dal perimetro” — il contesto recuperato esce, e sostenere il contrario è il genere di affermazione che crolla durante un audit. La seconda: l’ingegneria interessante sta nel confine — cosa viene inviato, cosa viene rimosso prima dell’invio e cosa viene registrato dello scambio.

Decidono cinque criteri, più o meno in quest’ordine:

• —Classe dei dati. Le categorie particolari di dati personali ai sensi del GDPR, o dati la cui divulgazione è già di per sé l’incidente, spingono verso l’AI completamente locale — o verso un’architettura in cui quella classe di dati non arriva mai al passo di generazione.
• —Threat model. Da chi ti stai davvero difendendo: un altro tenant, un attaccante opportunista, il personale stesso del fornitore o un procedimento giudiziario straniero? L’ultimo è una questione di giurisdizione, e nessuna cifratura dei dati a riposo gli dà risposta.
• —Esposizione normativa. Cosa dovrai dimostrare, a chi e quanto tempo dopo i fatti. È questo a determinare la superficie di audit, che di solito è un vincolo più forte della topologia di inferenza.
• —Capacità richiesta. Se il compito richiede davvero un modello di frontiera, un deployment completamente locale è la decisione di accettare meno capacità. A volte è la scelta giusta; deve essere una decisione, non una scoperta.
• —Costo totale e realtà operativa. GPU, energia, ridondanza e le persone per gestirle. Un’architettura che nessuno sa far funzionare alle 3 di notte non è sovrana: è indisponibile.

“Cloud sovrano.” Chiedi quale delle tre componenti viene rivendicata. La sola localizzazione del datacenter è la più debole, ed è quella che si intende più spesso.

“I tuoi dati non escono mai.” Chiedi cosa si intende per dati. Prompt, contesto recuperato, telemetria, payload di errore e snapshot per il supporto sono tutti usciti da sistemi descritti esattamente così.

“Conforme al GDPR by design.” La conformità è una proprietà di un trattamento nel suo contesto organizzativo, non un attributo di prodotto che un fornitore possa conferire. Quello che un’architettura può fare è portare i controlli — minimizzazione in fase di ingestion, limiti di conservazione, separazione degli accessi, un registro di audit — e lasciare che il titolare dimostri il resto. Questa distinzione è tutto il lavoro della consulenza su governance e compliance.