I tuoi dipendenti stanno già rivelando i tuoi segreti a ChatGPT — e vietarlo ha solo peggiorato le cose

Ero seduto di fronte a un CISO di una grande società di servizi finanziari quando disse qualcosa che mi rimase impresso per settimane. Si appoggiò allo schienale, si massaggiò le tempie e disse: "Abbiamo bloccato ChatGPT su ogni dispositivo che gestiamo. Abbiamo aggiornato la policy di utilizzo accettabile. Abbiamo inviato tre email a tutta l'azienda. E lo scorso martedì ho scoperto che l'intero team M&A ha incollato i termini delle trattative in Claude sui propri telefoni personali durante la pausa pranzo."

Non era arrabbiato. Era esausto. Aveva fatto tutto ciò che il manuale della cybersecurity gli diceva di fare, e non aveva funzionato.

Quella conversazione ha cristallizzato qualcosa che avevo visto in ogni progetto enterprise che il mio team in Veriprajna aveva assunto: vietare l'AI generativa non impedisce alle persone di usarla — le spinge solo a nasconderla. E l'uso nascosto è infinitamente più pericoloso dell'uso visibile. I dati raccontano la stessa storia. Il quarantasei percento dei dipendenti afferma che continuerebbe a usare gli strumenti di AI anche se la propria azienda li vietasse esplicitamente. Il trentotto percento ammette di aver già condiviso dati di lavoro sensibili con piattaforme di AI pubbliche senza dirlo a nessuno. Il volume di dati che confluisce nelle app di AI generativa è aumentato di trenta volte anno su anno. Questo non è un problema di policy. È un problema architetturale.

La notte in cui Samsung ha cambiato tutto

Nel maggio 2023, tre ingegneri della divisione semiconduttori di Samsung fecero una cosa del tutto razionale. Stavano eseguendo il debug di codice proprietario per la fabbricazione di chip — un lavoro complesso e ad alto rischio in cui una seconda opinione poteva far risparmiare giorni di fatica. Così incollarono il loro codice in ChatGPT.

Uno caricò il codice sorgente di database per la misurazione dei semiconduttori. Un altro condivise la logica di programma per l'identificazione dei difetti di resa — il tipo di dato che incide direttamente sul prezzo delle azioni di Samsung. Un terzo caricò la registrazione di una riunione interna per generarne il verbale.

Nessuno di loro stava cercando di danneggiare l'azienda. Stavano cercando di fare bene il proprio lavoro. Trattavano ChatGPT come tratteresti una calcolatrice: inserisci qualcosa, ottieni qualcosa, vai avanti. Ciò che non colsero appieno era che i termini di servizio di OpenAI dell'epoca consentivano di conservare gli input — potenzialmente usati per l'addestramento del modello, sicuramente archiviati su server al di fuori del controllo di Samsung.

Ricordo di aver letto la copertura mediatica e di aver sentito un nodo allo stomaco. Non perché la fuga di dati fosse sorprendente — avevo messo in guardia i clienti proprio su questo scenario — ma perché la risposta di Samsung fu così prevedibile. Emisero un divieto a livello aziendale. Minacciarono il licenziamento per le violazioni. Blindarono la rete.

E sapevo, con assoluta certezza, che non avrebbe funzionato.

Perché vietare l'AI si ritorce sempre contro?

Ecco cosa la maggior parte dei team di sicurezza sbaglia: modellano la minaccia come se i dipendenti fossero avversari. Costruisci un muro più alto e il problema sparisce. Ma le persone che fanno trapelare dati verso ChatGPT non sono avversari. Sono i vostri migliori talenti.

Pensate a chi usa davvero gli strumenti di AI al lavoro. Non è la persona che scivola pigra attraverso la giornata. È l'ingegnere sotto pressione per rilasciare entro venerdì. L'analista che deve riassumere quaranta pagine di due diligence entro mattina. Lo sviluppatore che sa che l'AI può individuare in pochi secondi un bug che a lui richiederebbe un'ora per trovare manualmente.

Quando vietate lo strumento, state dicendo alle vostre persone più produttive: "Siate più lenti. Siate meno efficaci. Guardate i vostri concorrenti superarvi, e accettatelo." Ovviamente non si adeguano. Passano semplicemente ai loro telefoni personali. Usano hotspot 4G per aggirare la rete aziendale. Trovano una delle oltre 317 distinte app di AI generativa che Netskope ha rilevato negli ambienti enterprise — perché anche se bloccate OpenAI, Google e Anthropic, ci sono centinaia di alternative più piccole e meno sicure in attesa.

Quando la sicurezza è percepita come un ostacolo anziché come un abilitatore, i vostri dipendenti più coscienziosi diventano i principali violatori delle policy.

Ho iniziato a chiamare questo il "Paste Gap" nelle conversazioni con il mio team. I dati lasciano il laptop aziendale sicuro, viaggiano verso un dispositivo personale e vengono incollati in un servizio cloud pubblico. Nessun firewall li intercetta. Nessun CASB li registra. Sono invisibili. E sta accadendo proprio ora, in ogni organizzazione che ha provato a risolvere questo problema con un promemoria di policy.

I numeri sono impressionanti: un aumento del 485% di codice sorgente proprietario incollato negli strumenti di AI. Il settantadue percento dell'uso enterprise dell'AI avviene tramite account personali, completamente al di fuori della visibilità dell'IT. Questo non è un rivolo. È un'inondazione, e gli argini sono fatti di carta.

Cosa ho sbagliato sui livelli "enterprise" dell'AI

Sarò onesto — quando OpenAI lanciò ChatGPT Enterprise, pensai che potesse bastare. Zero conservazione dei dati. Nessun addestramento sui dati aziendali. Conformità SOC 2. Spuntava tutte le caselle.

Poi abbiamo iniziato a fare una due diligence più approfondita per i nostri clienti, e le crepe sono emerse.

Persino gli accordi enterprise includono in genere una breve finestra di conservazione dei dati — spesso trenta giorni — per il monitoraggio degli abusi. Sono trenta giorni in cui i vostri prompt più sensibili risiedono sui server di qualcun altro. E "qualcun altro" è un'azienda con sede negli Stati Uniti, il che ci porta a un problema che tiene svegli di notte i CISO europei.

Lo US CLOUD Act — il Clarifying Lawful Overseas Use of Data Act — consente alle forze dell'ordine statunitensi di obbligare le aziende tecnologiche americane a consegnare i dati archiviati sui loro server, indipendentemente da dove quei server siano fisicamente collocati. Se una banca tedesca usa Azure OpenAI con un data center a Francoforte, i dati potrebbero essere "a riposo" nell'UE, ma l'entità giuridica controllante è comunque soggetta ai mandati statunitensi. Durante l'inferenza — quando il modello elabora effettivamente i vostri dati — questi potrebbero comunque transitare attraverso infrastrutture controllate dagli Stati Uniti.

Ho visto una stanza piena di responsabili della compliance impallidire mentre li accompagnavo attraverso tutto questo. Avevano firmato l'accordo enterprise pensando di aver risolto il problema della sovranità. Non l'avevano nemmeno scalfito.

Ho scritto di questo problema architetturale — e dell'intero modello di minaccia — nel nostro whitepaper interattivo sulla Shadow AI e sugli LLM privati enterprise. È nato esattamente da queste conversazioni.

La trappola del wrapper

Nello stesso periodo, la mia casella di posta ha iniziato a riempirsi di proposte da parte di società di consulenza sull'AI. "Costruiremo per voi una soluzione AI personalizzata!" La maggior parte di esse erano wrapper — una bella interfaccia montata sopra l'API di OpenAI, magari con un system prompt che diceva "Sei un assistente legale disponibile."

Ho assistito a una demo in cui il fornitore mostrava con orgoglio una "piattaforma AI proprietaria" per l'analisi dei contratti. Ho fatto una sola domanda: "Dove vanno i dati quando un utente carica un contratto?" Silenzio. Poi: "Beh, vanno all'API di OpenAI, ma abbiamo un BAA in essere."

Quella non è una soluzione. È un intermediario che aggiunge latenza alla vostra fuga di dati.

Un wrapper non risolve il problema della sovranità dei dati. Si limita ad abbellire l'interfaccia della fuoriuscita di dati.

I wrapper deludono le aziende in tre modi specifici. Primo, sono banalmente replicabili — se la vostra "soluzione AI" è un prompt più una chiave API, il vostro stagista può ricostruirla in un pomeriggio. Secondo, mancano di un'integrazione profonda con i vostri dati reali, faticando con le sfumature della terminologia specifica dell'azienda, delle codebase legacy o dei controlli di accesso. Terzo — e questo è il colpo fatale — inviano comunque i vostri dati attraverso l'internet pubblico a un fornitore terzo. Il rischio per la sicurezza non è cambiato. Avete solo aggiunto un logo.

Cosa significa davvero "possedere l'intelligenza"?

C'è stato un momento specifico in cui il nostro approccio in Veriprajna si è cristallizzato. Stavamo lavorando con un cliente in un settore regolamentato — non posso dire quale, ma pensate a "il tipo di dati la cui fuga finisce nel telegiornale della sera." Il loro team legale aveva appena bocciato un promettente progetto pilota di AI perché si basava su un'API pubblica. Il team di ingegneria era furioso. La business unit minacciava di agire per conto proprio e costruire la propria soluzione con account personali.

Ero in chiamata con il mio lead architect, e lui disse una cosa semplice: "Perché stiamo discutendo su quale API usare? Dovremmo semplicemente eseguire il modello noi stessi."

È stato allora che ci siamo impegnati pienamente in ciò che ora chiamo Deep AI — implementare modelli linguistici di grandi dimensioni open-source direttamente all'interno dell'infrastruttura del cliente. Non incapsulare il modello di qualcun altro. Non affittare l'intelligenza a token. Possederla davvero.

Ecco come appare questo nella pratica. Prendete un modello open-weights ad alte prestazioni — Llama 3 di Meta, per esempio, dove la versione da 70B di parametri rivaleggia con GPT-4 su molti benchmark — e lo implementate su istanze GPU all'interno del Virtual Private Cloud del cliente. I pesi del modello risiedono su hardware controllato dal cliente. Il motore di inferenza gira dietro il firewall aziendale. Quando uno sviluppatore invia al modello un prompt con codice proprietario, quel codice viaggia dal suo laptop a un server interno, viene elaborato in memoria e ritorna. Non tocca mai l'internet pubblico. Non atterra mai su un server di terze parti.

Abbiniamo questo a ciò che chiamiamo Private RAG — Retrieval-Augmented Generation costruito su database vettoriali implementati all'interno dello stesso ambiente sicuro. I documenti dell'azienda vengono ingeriti, incorporati e archiviati localmente. E, cosa fondamentale, il sistema rispetta i controlli di accesso esistenti. Se non avete il permesso di vedere un documento in SharePoint, l'AI non lo recupererà nemmeno per rispondere alla vostra domanda. Quel problema di "autorizzazione piatta" — in cui un chatbot fa emergere accidentalmente dati riservati a chiunque li chieda — semplicemente non esiste in questa architettura.

Come si rende un modello grezzo di livello enterprise?

Una delle lezioni più dure che abbiamo imparato all'inizio: implementare un modello è forse il trenta percento del lavoro. Renderlo sicuro perché migliaia di dipendenti lo usino ogni giorno — quello è l'altro settanta.

I modelli linguistici grezzi sono imprevedibili. Discuteranno volentieri argomenti che non dovrebbero, genereranno contenuti che violano le policy aziendali o risponderanno a ingegnose prompt injection progettate per aggirare i protocolli di sicurezza. Servono guardrail — essenzialmente un firewall per i prompt.

Implementiamo NVIDIA NeMo Guardrails come un livello programmabile attorno al modello. Prima che un prompt raggiunga il modello, viene scansionato. Se qualcuno digita un codice fiscale o un numero di carta di credito, il guardrail lo intercetta. Se qualcuno chiede a un bot HR le password di un database, il sistema riconosce l'incongruenza di intento e rifiuta. Se qualcuno tenta un attacco di tipo jailbreak — quei trucchi del tipo "ignora tutte le istruzioni precedenti" — il livello di difesa lo intercetta.

Ricordo un penetration test che eseguimmo su una delle nostre prime implementazioni. Il nostro red team passò due giorni a cercare di estrarre dati di addestramento o aggirare le restrizioni sugli argomenti. Furono creativi — prompt di role-play annidati, istruzioni codificate, il tutto. I guardrail hanno retto. Il mio architetto mi inviò uno screenshot del log dei tentativi bloccati alle 2 di notte con un solo messaggio: "Il muro tiene." Quella fu una buona notte.

Per l'analisi tecnica completa di questa architettura — lo stack di inferenza, la configurazione del database vettoriale, l'implementazione dei guardrail — consulta il nostro approfondimento tecnico sulla sicurezza dell'AI enterprise.

"Ma le GPU sono costose e le API sono economiche"

Questa è l'obiezione che sento più spesso dai CFO, ed è sbagliata in un modo che vale la pena approfondire.

Sì, i prezzi delle API sembrano economici in superficie — frazioni di centesimo per token. Ma le applicazioni RAG enterprise sono voracemente affamate di token. Per rispondere a una singola domanda, il sistema potrebbe recuperare dieci pagine di contesto come token di input. Moltiplicate questo per mille dipendenti che pongono dieci domande al giorno, e vi ritrovate con da 1.000 a 3.000 $ al giorno. Sono potenzialmente un milione di dollari all'anno, e scala linearmente. Se l'adozione raddoppia, la fattura raddoppia.

I modelli self-hosted funzionano diversamente. Pagate per l'hardware — noleggio o acquisto di GPU — e l'elettricità. Un singolo nodo ben configurato può gestire migliaia di richieste al secondo. Finché non saturate quel nodo, il costo marginale del token successivo è di fatto zero. Per un'azienda di medie dimensioni che elabora un miliardo di token al mese, abbiamo visto il self-hosting risultare dal 50 al 70 percento più economico rispetto ai costi API equivalenti, con la privacy come bonus gratuito.

E ci sono costi nascosti nelle API che non compaiono mai sulla fattura. Rate limit che causano interruzioni durante i rilasci a livello aziendale. Deprecazioni di modelli che vi costringono a ri-testare ogni prompt e workflow quando il fornitore ritira una versione. Con un modello self-hosted, nulla cambia a meno che non decidiate voi di aggiornarlo. Ottenete stabilità. Ottenete prevedibilità. Potete smettere di preoccuparvi di cosa deciderà il prossimo trimestre il comitato prezzi di OpenAI.

Su scala enterprise, il self-hosting non è l'opzione costosa. È quella che non vi manda in bancarotta quando l'adozione ha successo.

Perché non lo stanno già facendo tutti?

La gente me lo chiede, e la risposta onesta è: è difficile. Non concettualmente — la logica è lineare — ma dal punto di vista operativo. Servono persone che comprendano l'orchestrazione delle GPU con Kubernetes, che sappiano configurare vLLM per un throughput ottimale, che sappiano costruire pipeline di retrieval consapevoli del RBAC, che sappiano implementare guardrail abbastanza rigidi da prevenire gli abusi ma abbastanza flessibili da non frustrare gli utenti.

La maggior parte delle aziende non ha quel team. Nemmeno la maggior parte delle società di consulenza sull'AI ce l'ha — sanno chiamare un'API, non come implementare uno stack di inferenza. È questo il divario che colmiamo in Veriprajna. Non vendiamo l'accesso a un modello. Costruiamo la capacità di eseguire modelli in modo indipendente. Quando ce ne andiamo, il cliente possiede tutto — i pesi del modello messo a punto, gli indici vettoriali, l'infrastruttura di orchestrazione. È suo. È tutto qui il punto.

L'altra cosa che rallenta l'adozione è l'inerzia. Il CISO che ha bloccato ChatGPT ha la sensazione di aver fatto qualcosa. Ammettere che il divieto non ha funzionato significa ammettere che l'ultimo anno di applicazione delle policy è stato teatro. È una conversazione difficile da avere con un consiglio di amministrazione. Ma l'alternativa — fingere che il problema non esista mentre i dipendenti incollano codice sorgente in account AI personali — è peggiore. Non è questione di se accadrà la prossima fuga di dati su scala Samsung. È questione di quando, e se capiterà a voi.

Il segnale nascosto nella Shadow AI

Ecco cosa penso che la maggior parte delle persone non colga riguardo all'epidemia di Shadow AI: non è solo un problema di sicurezza. È un segnale. Un segnale forte e inequivocabile che la vostra forza lavoro è disperatamente in cerca di strumenti migliori ed è disposta a rischiare il posto di lavoro pur di averli.

Il quarantasei percento dei dipendenti afferma che sfiderebbe un divieto esplicito. Non è sfida fine a se stessa. Sono persone che vi dicono, attraverso le loro azioni, che l'AI è diventata essenziale per il modo in cui lavorano. La domanda non è se la vostra organizzazione userà l'AI generativa. Quella decisione è già stata presa — dai vostri dipendenti, senza il vostro permesso, sui loro dispositivi personali, durante la pausa pranzo.

L'unica domanda che resta è se fornirete un modo sicuro per fare ciò che stanno già facendo in modo non sicuro.

La Shadow AI è la vostra forza lavoro che vota con i propri tasti. Hanno scelto l'AI. Ora scegliete voi: visibile e sicura, o invisibile e con perdite di dati.

Abbiamo superato l'era in cui "no" era una strategia AI accettabile. I modelli open-source sono abbastanza buoni. L'infrastruttura di implementazione è abbastanza matura. L'economia funziona. L'unica cosa che si frappone tra la maggior parte delle aziende e una capacità di AI sovrana è la volontà di smettere di fingere che il proibizionismo funzioni.

Non dovete vietare l'AI. Dovete possederla.