Il giorno in cui la nostra AI privata ha mostrato a un dipendente uno stipendio che non avrebbe mai dovuto vedere

La circolare che non funziona

In questo preciso momento, da qualche parte nella tua azienda, qualcuno ha incollato il contratto di un cliente in un chatbot per riassumerlo. Non ha chiesto il permesso. Non è in malafede. Aveva una scadenza e uno strumento che funzionava, e quello strumento ha finito per inviare quel contratto a un server di proprietà di un'azienda in un altro continente.

Lo so perché ogni CISO con cui ho lavorato ha la stessa dashboard, e racconta la stessa storia. Uno di loro ha aperto Netskope durante una riunione e mi ha mostrato 317 distinte app di AI generativa in uso attivo nella sua organizzazione. Ne aveva autorizzate una manciata. Le altre erano i suoi dipendenti che risolvevano i propri problemi, un incollaggio alla volta.

Quel divario — tra l'AI che hai approvato e l'AI che le tue persone stanno effettivamente usando — è il problema che ho passato l'ultimo tratto della mia carriera a risolvere costruendo Veriprajna. Ci occupiamo di deployment di LLM privati: mettiamo un large language model capace all'interno della tua stessa infrastruttura, sotto i tuoi controlli, così che il lavoro che i tuoi dipendenti stanno già facendo con l'AI smetta di fuoriuscire dai lati dell'edificio. L'AI sovrana non è un discorso filosofico sull'indipendenza tecnologica nazionale. È la risposta pratica a una domanda a cui ogni responsabile della sicurezza sta già fallendo nel rispondere: dove stanno andando i nostri dati, e possiamo dimostrarlo?

L'istinto, quando vedi quella dashboard per la prima volta, è di mandare una circolare. Vietare gli strumenti. Ho provato quel ragionamento all'inizio, e voglio dirti esattamente perché crolla — perché quel fallimento è l'intera ragione per cui questa azienda esiste.

Vietare l'AI non la rimuove dalla tua azienda. Ti toglie soltanto la visibilità su di essa.

I numeri sostengono la tesi meglio di quanto possa fare io. Il report Cost of a Data Breach 2025 di IBM ha rilevato che un'organizzazione su cinque ha già subìto una violazione legata alla shadow AI — strumenti non autorizzati usati all'insaputa dell'IT. Quelle violazioni sono costate in media $670,000 in più rispetto agli incidenti tradizionali, e ci sono voluti 247 giorni per individuarle contro i 241 per tutto il resto. Un'indagine separata l'ha detto senza giri di parole: il 43% dei dipendenti ammette di condividere informazioni di lavoro sensibili con strumenti di AI che il proprio datore di lavoro non ha mai approvato. Un divieto non cambia quel comportamento. Garantisce soltanto che sarai l'ultimo a saperlo quando le cose andranno male.

Perché un chatbot privato non risolve la shadow AI?

Quindi, se non puoi vietarla, costruisci l'alternativa sicura. Metti in piedi un chatbot interno, lo colleghi a un buon modello, dici a tutti di usare quello invece. È qui che ho commesso il mio errore più costoso, e vale la pena soffermarcisi perché quasi tutti lo commettono.

Il primo deployment interno a cui sono stato vicino sembrava ottimo nella demo. Interfaccia pulita, risposte veloci, un modello che conosceva i documenti dell'azienda. Ne eravamo orgogliosi. Poi, durante il pilota, qualcuno con un ruolo junior gli ha posto una domanda su un piano retributivo — e ha risposto. In modo completo. Accurato. Con dettagli estratti da un documento che quella persona non aveva alcun motivo di leggere.

Non era stato violato nulla. Il sistema di retrieval ha fatto esattamente ciò per cui l'avevamo costruito: trovare i documenti più rilevanti e passarli al modello. Semplicemente non gli avevamo mai insegnato che rilevanza e permesso sono cose diverse. Il chatbot era un bibliotecario fedele a cui era stata data la chiave universale di ogni stanza chiusa a chiave dell'edificio.

Quel pomeriggio ha ridefinito l'intero problema per me. Il modello non è mai stato la parte difficile. La parte difficile è il permesso.

Ecco la cosa che nessuno ti dice nelle demo dei fornitori: la maggior parte delle imprese si porta dietro anni di logica di accesso accumulata e sepolta in Active Directory — gruppi di sicurezza annidati, permessi ereditati, liste di distribuzione, unità organizzative stratificate una sull'altra da persone che se ne sono andate anni fa. Quando costruisci un sistema di retrieval, la mossa ingenua è etichettare ogni frammento di testo con un elenco piatto di chi può vederlo. Questo crolla nel momento in cui incontri l'annidamento dei gruppi del mondo reale. Un documento eredita l'accesso da un gruppo, che eredita da un altro gruppo, a cui un collaboratore esterno è stato aggiunto per un singolo progetto anni fa.

Farlo bene è il vero lavoro. Abbiamo costruito un livello di sincronizzazione che si colloca tra l'identity provider — Active Directory, Okta, Azure AD — e il database vettoriale dove risiedono i documenti. Risolve l'appartenenza ai gruppi in modo ricorsivo, appiattisce quelle catene di ereditarietà e aggiorna i metadati di accesso a cadenza serrata. Per la maggior parte dei deployment sincronizziamo ogni 60-90 secondi. Ma il caso che ti tiene sveglio la notte è la cessazione del rapporto: qualcuno viene accompagnato all'uscita alle 9 del mattino, e non puoi permetterti che il sistema risponda ancora con i suoi accessi alle 9:05. Perciò le revoche non aspettano la sincronizzazione successiva — un webhook di Okta o Azure AD attiva una cancellazione immediata nell'istante in cui l'account viene disabilitato.

Rilevanza e permesso non sono la stessa cosa, e un sistema di retrieval che li confonde consegnerà la risposta giusta esattamente alla persona sbagliata. Nessuna piattaforma RAG di rilievo lo risolve pronto all'uso — sono andato a cercare.

Non è sicurezza da marketing — è ciò che ho trovato cercando. TrueFoundry, Databricks, i prodotti di ricerca cloud-native hanno tutti risposte parziali: controlli dei permessi in sola lettura, sincronizzazioni periodiche. Nessuno di loro eredita il quadro completo delle policy di gruppo e delle regole basate su attributi — accesso a tempo limitato, "solo da un dispositivo gestito", livelli di classificazione — su cui un'impresa regolamentata effettivamente si regge. Perciò costruiamo quel motore di policy come lavoro su misura, perché non ci sono scorciatoie. Se vuoi l'architettura completa di come questa applicazione dei permessi funziona da un capo all'altro, è illustrata sulla nostra pagina AI sovrana e deployment di LLM privati.

Un data center a Francoforte rende la tua AI europea?

C'è una seconda trappola, ed è più subdola perché sembra conformità. Molte imprese ricorrono a un'opzione gestita — Azure OpenAI, AWS Bedrock — e si sentono al sicuro. I dati restano nel loro tenant cloud. Ci sono endpoint VPC, rete privata, una pila di certificazioni. Per parecchie aziende quella è davvero la risposta giusta, e lo dirò in faccia a un cliente quando lo è.

Ma sotto quello tecnico c'è un fatto giuridico che vedo le persone ignorare di continuo. Ospitare la tua AI in un data center a Francoforte non la rende europea. Microsoft e Amazon sono aziende con sede negli Stati Uniti, e questo le rende soggette al CLOUD Act statunitense, che consente alle forze dell'ordine americane di obbligare un'azienda statunitense a consegnare dati che conserva ovunque nel mondo. L'articolo 48 del GDPR afferma che un ordine di un tribunale straniero è valido qui solo con un accordo internazionale. Quelle due leggi puntano in direzioni opposte, e i tuoi dati stanno nel mezzo.

Questo ha smesso di essere teorico nel marzo 2026. L'Autorità per la protezione dei dati dell'Austria ha multato una fintech di Vienna di EUR 450,000 per aver effettuato credit scoring tramite un'API di AI con sede negli Stati Uniti — dichiarandolo un trasferimento di dati illecito ai sensi del GDPR. L'azienda aveva presunto, come fa quasi chiunque, che l'hosting in regione europea fosse sufficiente. Non lo era. Tengo quella sentenza tra i preferiti perché è l'illustrazione più netta che abbia trovato di un rischio che la maggior parte dei consigli di amministrazione non sa di correre.

Il caso speculare è una catena ospedaliera statunitense: lì il CLOUD Act conta a malapena, ma i requisiti sui business associate dell'HIPAA e — nel momento in cui tocchi contratti federali — il NIST AI Risk Management Framework e FedRAMP High diventano la linea che stai tracciando al suo posto. La questione della giurisdizione mantiene la stessa forma; cambia solo la norma appesa al muro.

Per un'azienda finanziaria statunitense senza clienti europei, niente di tutto questo conta e Azure OpenAI è spesso esattamente la scelta giusta. Per una banca europea che tratta i dati dei propri clienti, il calcolo si ribalta — e l'unica configurazione che elimina del tutto l'esposizione al CLOUD Act è un deployment self-hosted su modelli open-weight in esecuzione su un'infrastruttura il cui operatore non è soggetto alla giurisdizione statunitense. È questa la funzione reale dei provider di cloud sovrano europei — OVHcloud, Scaleway, la nuova capacità Blackwell che sta entrando in funzione in Europa. Non patriottismo. Giurisdizione.

E la scadenza è reale. Gli obblighi di trasparenza dell'articolo 50 dell'EU AI Act diventano applicabili il 2 agosto 2026. Somma le sanzioni dell'AI Act a quelle del GDPR e il tetto combinato raggiunge EUR 55 milioni, o l'11% del fatturato annuo globale. Non è una multa che assorbi. È un numero che pone fine alle carriere.

"Basta usare l'API" — la conversazione che affronto ogni mese

L'obiezione che sento più spesso è finanziaria, ed è legittima: il self-hosting sembra costoso. Perché comprare GPU e assumere un team quando un'API è a un addebito su carta di credito di distanza?

Perché la matematica si ribalta, e il punto in cui si ribalta è più specifico di quanto la gente si aspetti. Per un modello self-hosted da 70 miliardi di parametri, l'inferenza costa intorno ai $0.013 per mille token. Lo stesso lavoro tramite un'API ospitata come GPT-4o mini costa da $0.15 a $0.60 per mille. Non è una differenza da arrotondamento. Ma conta solo al di sopra di un certo volume, perché le GPU self-hosted costano denaro sia che tu le stia usando sia che siano inattive.

Il punto di pareggio si colloca intorno ai due milioni di token al giorno. Al di sotto di quella linea, vincono le API — non stai pagando per hardware inattivo, e dirò a un cliente di restare sulle API senza esitare. Al di sopra, il self-hosting fa risparmiare dal 60 all'85% sull'inferenza. Una fintech che conosco ha tagliato la sua bolletta mensile per l'AI da $47,000 a $8,000 passando a un self-hosting ibrido.

Ma — e questa è la parte che i cartellini dei prezzi delle GPU nascondono — l'hardware è raramente la voce di costo più grande. Ai prezzi odierni una H100 si affitta da $2.50 a $3.50 l'ora, e una singola scheda che esegue un modello open-weight come Llama 3.3 70B serve dai 30 ai 50 utenti simultanei con latenza inferiore ai due secondi. La parte costosa sono le persone. Servono ingegneri MLOps — due come minimo per l'affidabilità in produzione — da $200,000 a $350,000 ciascuno, più monitoraggio, pipeline di valutazione, una strategia di rollback. Per un team alle prime armi con la gestione dei modelli, il costo totale di proprietà si attesta intorno a 3.2x il costo grezzo dell'API nel primo anno. Per un team maturo con strumenti già in essere, scende a circa 1.8x.

Quella fintech che ha tagliato la bolletta in modo così drastico? Ha funzionato perché avevano già un team Kubernetes e 18 mesi di cicatrici operative. La stessa mossa avrebbe mandato in bancarotta un team che impara sul campo.

La GPU è la parte più economica del self-hosting. I due ingegneri che la tengono in funzione sono la voce di costo che decide se la matematica funziona davvero — e chiunque risponda a "dovremmo fare self-hosting?" più in fretta di "dipende dal tuo volume e dal tuo team" ti sta vendendo qualcosa.

La buona notizia sotto tutto questo è che i modelli open-weight sono diventati abbastanza buoni da rendere la domanda degna di essere posta. Llama 3.3 70B raggiunge l'86% sul benchmark MMLU e gira circa 25 volte più a buon mercato in self-hosting rispetto all'API equivalente. DeepSeek-V3 ottiene l'88.5% — superando di poco un modello proprietario di frontiera su quella misura. Per la grande maggioranza dei compiti aziendali, il modello che puoi eseguire dentro le tue mura non è più il compromesso che era due anni fa.

Cosa succede quando l'AI smette di limitarsi a parlare

Uno sviluppo trasforma tutto questo da prudente in urgente. L'AI nella tua azienda sta per smettere di essere un chatbot e iniziare a essere un agente — software che non si limita a rispondere alle domande ma compie azioni, con accesso permanente ai tuoi sistemi.

Gartner prevede che il 40% delle applicazioni aziendali integrerà agenti AI entro la fine del 2026, rispetto a meno del 5% un anno prima. Ma solo circa il 5% delle imprese ha effettivamente portato gli agenti dal pilota alla produzione, e il quadro della sicurezza è genuinamente allarmante: il 92% dei responsabili della sicurezza afferma di non avere piena visibilità sulle identità AI che già operano nel proprio ambiente. Un agente che può leggere il tuo CRM, aprire ticket e spostare denaro è un rischio molto diverso da un chatbot che può riassumere un PDF.

Tutto ciò che ho descritto — l'applicazione dei permessi, il controllo della giurisdizione, i guardrail in runtime che intercettano il prompt injection — smette di essere un optional nel momento in cui la tua AI può agire. Un chatbot che recupera il documento sbagliato è un imbarazzo. Un agente con accesso permanente e nessun confine di permessi è un incidente in attesa di una data.

Questo è il ripensamento che vorrei lasciarti. Anche qui il livello dei guardrail conta — e vale la pena sapere che opzioni pronte all'uso come NeMo Guardrails di NVIDIA aggiungono una latenza reale, dai 100 ai 300 millisecondi per chiamata, motivo per cui ottimizziamo la logica delle policy sul pattern di conformità specifico invece di applicare un filtro generico. Ma il punto più profondo è architetturale. Non puoi mettere un agente su un'infrastruttura che non controlli e definirla governata.

La parte su cui le persone obiettano sempre

Le persone mi chiedono se devono davvero scegliere — se possono mantenere alcune API cloud e continuare a definirsi sovrane. Sì: la maggior parte dei deployment che consiglierei sono ibridi, i carichi di lavoro sensibili su infrastruttura privata e quelli a basso rischio su API gestite, con un chiaro confine di policy che decide quale sia quale. La sovranità non è mai stata un voto tutto-o-niente; è tracciare la linea nel punto giusto ed essere in grado di dimostrare dove si trova.

L'altra domanda è la tempistica — non è presto? La multa austriaca è già arrivata. La scadenza dell'articolo 50 è sul calendario. I tuoi dipendenti stanno incollando dati in centinaia di strumenti che non hai approvato mentre leggi questo. Il costo di muoversi presto è un progetto. Il costo di muoversi tardi si misura rispetto a un tetto dell'undici percento del fatturato.

Ho fondato Veriprajna perché ho visto un piccolo chatbot fedele consegnare a un dipendente junior uno stipendio che non avrebbe mai dovuto mostrargli, e ho capito che l'intero settore vendeva modelli quando il vero problema era il controllo. Il modello è la parte facile. Lo è sempre stato.

Le tue persone non stanno aspettando il permesso di usare l'AI. L'unica domanda aperta è se l'AI che stanno usando risponde a te.

Se vuoi vedere come progettiamo quel controllo per uno specifico profilo di rischio — dove dovrebbe collocarsi la linea tra privato e gestito, come viene costruito il livello dei permessi, quale sia il costo totale reale per il tuo team — è ciò che illustriamo, onestamente e in modo neutrale rispetto ai fornitori, sulla pagina AI sovrana di Veriprajna. Porta la tua dashboard. So già più o meno cosa dice.