A dicembre 2025, circa 500 startup nel campo dell’intelligenza artificiale hanno scoperto una cosa scomoda. I dati riservati che avevano consegnato al loro fornitore di compliance, tra cui nomi legali, fornitori di infrastrutture, contatti per la sicurezza e tempistiche di audit, erano accessibili pubblicamente attraverso un foglio Google non protetto.
Il fornitore si chiamava Delve. Era stato assunto esattamente per validare che i dati di quelle aziende fossero al sicuro.
L’ironia scrive da sola la storia. C’è però un livello più profondo che vale la pena esplorare, perché questa vicenda non riguarda solo Delve e non riguarda solo quelle 500 aziende.
Un foglio Google e i dati di 500 aziende.
Stando a quanto ricostruito in una dettagliata inchiesta pubblicata su DeepDelver, il leak è avvenuto attraverso un documento Google Sheets configurato con visibilità pubblica. Al suo interno si trovava un elenco strutturato di clienti Delve con link diretti ai loro report di audit riservati.
I dati esposti includevano nomi legali delle società, fornitori di infrastruttura cloud come AWS, GCP e Azure, descrizioni dei sistemi, indirizzi email dei referenti per la sicurezza e le tempistiche complete dei cicli di audit. Si trattava di un mix di aziende certificate SOC 2 Tipo 1, SOC 2 Tipo 2 e ISO 27001, molte delle quali operano in settori ad alto rischio: AI sanitaria, fintech, legal tech. Settori in cui la riservatezza dei dati non è una preferenza, ma un obbligo regolatorio.
Quando i clienti ne sono venuti a conoscenza, Delve ha risposto negando che i dati fossero stati realmente esposti. L’inchiesta ha dimostrato il contrario.
Il paradosso: il garante della sicurezza come punto di vulnerabilità
C’è una struttura narrativa precisa in questa storia, e vale la pena nominarla.
Quelle 500 startup avevano fatto la cosa giusta. Si erano sottoposte a un processo di audit formale e avevano investito tempo e risorse considerevoli, nel caso di Delve tra i 6.000 e i 15.000 dollari a contratto, per dimostrare a clienti enterprise, investitori e partner che la loro postura di sicurezza era solida e verificata.
Avevano esternalizzato il rischio. O almeno credevano di averlo fatto.
Quello che in realtà avevano fatto era introdurre un nuovo punto di vulnerabilità: il fornitore stesso. Quel fornitore gestiva il proprio processo interno di raccolta dati su un foglio di calcolo accessibile con un link pubblico.Non è una storia di attacco sofisticato. Non c’è stato un breach, un ransomware, una APT. C’è stato un campo di condivisione configurato nel modo sbagliato. Il rischio che quelle aziende cercavano di eliminare era già dentro casa del controllore.
Il problema sistemico: la compliance come evento annuale
È facile leggere il caso Delve come un’anomalia: un fornitore negligente, una startup cresciuta troppo in fretta, un errore umano isolato. Quella lettura, però, manca il punto.
Il modello su cui Delve operava, e su cui opera ancora gran parte del mercato della compliance, è strutturalmente fragile perché tratta la conformità come un evento discreto, non come un processo continuo.
Si ottiene la certificazione. Si pubblica la trust page. Si risponde ai questionari dei vendor. Per i successivi undici mesi il tema scompare dall’agenda, fino alla finestra di rinnovo successiva.
In questo modello, il fornitore di compliance diventa il custode di tutto: dei dati, delle evidenze, dei report, delle credenziali. Diventa un single point of failure travestito da garanzia di sicurezza. Quando quel punto cede, per negligenza, per errore umano o per un campo di condivisione configurato male, l’esposizione non riguarda solo il fornitore. Riguarda ogni azienda che gli aveva affidato i propri dati più sensibili.
La compliance non è una casella da spuntare una volta l’anno. È un presidio operativo continuo. Nel momento in cui la tratti come un adempimento da esternalizzare, stai costruendo la tua postura di sicurezza sul processo interno di qualcun altro, un processo che non puoi vedere, non puoi auditare e non puoi controllare.
I dati che non avresti mai voluto rendere pubblici
Vale la pena soffermarsi su cosa significava concretamente essere tra le 500 aziende nel foglio di calcolo di Delve.
- Il nome legale della società, non il brand name ma l’entità giuridica registrata, è un dato che in mani sbagliate abilita attacchi di social engineering mirati, frodi documentali e impersonation nei confronti di fornitori e partner.
- Il fornitore di infrastruttura, che si tratti di AWS, GCP, Azure, Render o Railway, identifica la superficie di attacco cloud dell’azienda. È esattamente il tipo di informazione che un attore malevolo usa per calibrare un attacco prima di sferrarlo.
- L’email del referente per la sicurezza è il contatto privilegiato per qualsiasi operazione di phishing mirato nei confronti del team tecnico.
- Le tempistiche di audit rivelano i cicli operativi interni, i periodi di osservazione e le finestre in cui i controlli sono attivi o in revisione.
Nessuno di questi dati era segreto per Delve: erano stati consegnati volontariamente come parte del processo di onboarding. Il problema è che erano stati consegnati con l’aspettativa implicita che venissero trattati con lo stesso livello di cura che Delve stava certificando nei propri clienti. Quell’aspettativa era ragionevole. Si è rivelata sbagliata.
Cosa avrebbe reso questo fallimento strutturalmente impossibile
La domanda che ogni responsabile compliance e ogni C-suite dovrebbe portare fuori da questa storia non è come si sceglie un fornitore più affidabile. È più profonda: il nostro stack di compliance ha gli stessi single points of failure?
Un foglio di calcolo con link pubblici è un esempio estremo. La logica sottostante, fatta di processi manuali, dati centralizzati in strumenti generici e dipendenza dalla diligenza individuale invece che da controlli strutturali, è però molto più diffusa di quanto si voglia ammettere.
La risposta non è sostituire un fornitore con un altro. È cambiare il modello.
Una compliance AI affidabile non è quella che produce il report più velocemente o costa meno. È quella costruita su un’infrastruttura che rende certi tipi di errore strutturalmente impossibili, non solo improbabili. Un’infrastruttura in cui i dati riservati non transitano su strumenti generici, ogni accesso è tracciato e controllato e la sicurezza del fornitore è essa stessa certificata e auditata da terzi indipendenti.Noi di Aptus.AI abbiamo costruito la nostra piattaforma su questi principi. La nostra infrastruttura è certificata ISO/IEC 27001:2022. I dati dei nostri clienti non vengono mai utilizzati per addestrare i nostri modelli. Ogni funzione, dal monitoraggio normativo in tempo reale all’analisi dei rischi, è progettata per restituire al professionista il controllo, non per accentrarlo in un processo opaco che non può vedere.
La lezione che nessun audit certifica
Le 500 aziende nel foglio di calcolo di Delve avevano fatto la cosa giusta. Avevano cercato una validazione esterna della propria postura di sicurezza, avevano investito in un processo formale e avevano preso sul serio un obbligo che molte aziende della loro dimensione ignorano.
Il sistema in cui si erano fidate le ha deluse.
Questa non è una critica a quelle aziende. È una critica al modello. Un modello in cui la conformità viene trattata come un prodotto da acquistare invece che come una capacità da costruire. In cui il fornitore diventa il custode di tutto, incluso del rischio che era stato assunto per eliminare. In cui nessuno si chiede chi controlla i controllori, fino a quando la risposta non arriva da sola sotto forma di un link pubblico su Google.
La compliance non si esternalizza. Si presidia.
Domande frequenti
Il caso Delve riguarda solo le aziende americane?
No. Tra le aziende esposte nel leak ci sono società che operano su dati di cittadini europei e sono quindi soggette al GDPR. L’esposizione di dati come email di referenti per la sicurezza e descrizioni dei sistemi può configurare obblighi di notifica alle autorità di controllo e responsabilità dirette ai sensi dell’articolo 83 del GDPR.
Come faccio a sapere se il mio fornitore di compliance gestisce i miei dati in modo sicuro?
Chiedi esplicitamente: “è certificato ISO/IEC 27001?”, “I tuoi dati sono ospitati in Europa?”, “Vengono usati per addestrare modelli AI?”, “Hai accesso a un registro degli accessi ai tuoi dati?” Se anche una sola di queste domande riceve una risposta vaga o viene elusa, è un segnale da non ignorare.
Cos’è un single point of failure nella compliance?
È qualsiasi elemento del processo, un fornitore, uno strumento o una persona, la cui compromissione o indisponibilità espone l’intera postura di sicurezza dell’organizzazione. Il foglio di calcolo di Delve era un single point of failure: un unico documento conteneva i dati riservati di centinaia di aziende ed era accessibile con un semplice link.
Come si costruisce una compliance strutturalmente resiliente?
Distribuendo i controlli invece di centralizzarli, scegliendo fornitori la cui infrastruttura è certificata e auditata indipendentemente e trattando il monitoraggio normativo come un processo operativo continuo invece che come un adempimento periodico. Le istituzioni finanziarie più avanzate seguono già questo approccio da anni: è un modello replicabile.
