Il bug da 89 milioni di dollari: che cosa hanno sbagliato Apple e Goldman Sachs sull'AI nella finanza

Ero seduto nel mio studio di casa, un martedì sera dello scorso ottobre, quando il comunicato stampa della CFPB è comparso nel mio feed. Apple e Goldman Sachs, condannate a pagare oltre 89 milioni di dollari per carenze sistemiche nella gestione delle contestazioni sull'Apple Card. Ho letto il consent order due volte. Poi l'ho letto una terza volta, perché non riuscivo a credere a quello che avevo davanti.

Il guasto di fondo non era una qualche esotica ingegneria finanziaria andata storta. Non era un algoritmo impazzito che prendeva decisioni di credito discriminatorie. Era un pulsante. Un modulo secondario nell'app Apple Wallet che, quando i consumatori lo lasciavano incompleto, faceva svanire nel nulla digitale le loro contestazioni di fatturazione. Decine di migliaia di persone hanno segnalato addebiti non autorizzati, e il sistema semplicemente... se li è mangiati. Nessuna indagine. Nessun riscontro. Nessuna risoluzione. I consumatori sono rimasti con il conto in mano.

Costruisco sistemi di AI per mestiere. La mia azienda, Veriprajna, si concentra su quella che chiamiamo deep AI — architetture neurosimboliche che uniscono la flessibilità dei large language model al rigore matematico della verifica formale. Quando ho letto quel consent order, non mi sono sentito giustificato. Mi sono sentito male. Perché tutto ciò che è andato storto con l'Apple Card era evitabile. Non con test migliori. Non con più ingegneri. Con un modo radicalmente diverso di concepire la costruzione di sistemi di AI per i settori regolamentati.

Che cosa è successo davvero alla vostra contestazione Apple Card?

Lasciate che vi accompagni attraverso il fallimento, perché i dettagli contano più della cifra del titolo.

Apple e Goldman Sachs hanno firmato il loro accordo di partnership nel 2017. Apple avrebbe posseduto l'esperienza del consumatore — l'elegante interfaccia Wallet, il sistema di messaggistica, tutto il front end. Goldman Sachs sarebbe stata la banca dietro le quinte: emissione del credito, elaborazione delle transazioni e indagine sulle contestazioni quando qualcosa andava storto.

Nel giugno 2020 Apple ha rilasciato un aggiornamento del workflow "Report an Issue". Prima dell'aggiornamento, bastava toccare una transazione sospetta, premere "Report an Issue" e si veniva indirizzati a una chat basata su Messaggi con Goldman Sachs. Semplice. Dopo l'aggiornamento, Apple ha aggiunto un modulo secondario — un passaggio in più che i consumatori avrebbero dovuto completare dopo il messaggio iniziale.

Ed è qui che si è rotto tutto: quando le persone inviavano la contestazione tramite Messaggi ma non completavano il modulo secondario, il sistema trattava la contestazione come incompleta. Non trasmetteva mai il reclamo a Goldman Sachs. Dal punto di vista normativo, molti di questi messaggi si qualificavano come validi Billing Error Notice ai sensi del Truth in Lending Act. Giuridicamente, avrebbero dovuto attivare un'indagine entro tempi precisi. Invece sono spariti.

Decine di migliaia di contestazioni dei consumatori giuridicamente valide sono state inghiottite da una macchina a stati che nessuno aveva verificato formalmente.

Ricordo di aver letto quel dettaglio e di aver pensato a ogni conversazione avuta con dirigenti dei servizi finanziari che mi dicono che i loro sistemi sono "collaudati sul campo". Collaudati contro cosa? Contro lo scenario specifico in cui una modifica all'interfaccia introduce uno stato morto in un workflow distribuito? Non è il genere di cosa che si intercetta con unit test e sprint di QA.

La clausola da 25 milioni di dollari che ha rovinato tutto

C'è un dettaglio sepolto nel consent order a cui continuo a tornare. Il contratto di Apple con Goldman Sachs prevedeva una clausola da 25 milioni di dollari di penale forfettaria per ogni ritardo di 90 giorni causato da Goldman nel lancio dell'Apple Card.

Venticinque milioni di dollari. A trimestre. Per essere in ritardo.

Sono stato in stanze dove la pressione commerciale distorce le decisioni ingegneristiche. Ho visto team rilasciare cose che sapevano non essere pronte perché il costo del ritardo sembrava più concreto del costo del fallimento. Ma non ho mai visto una struttura di incentivi esplicitata così apertamente. Goldman Sachs veniva di fatto multata in anticipo per essere prudente.

L'Apple Card è entrata in funzione il 20 agosto 2019. I team interni di Goldman avevano segnalato dubbi sulla prontezza del sistema. Le code di messaggi tra l'app Wallet e il back-end di Goldman erano poco testate. I protocolli di sincronizzazione erano fragili. Ma il conto era semplice: rilasciare adesso e sistemare dopo, oppure pagare 25 milioni di dollari e sistemare prima.

Hanno rilasciato. E per oltre un anno il sistema ha funzionato con un buco che dall'esterno nessuno poteva vedere.

Ci penso quando mi chiedono perché Veriprajna insista sulla verifica formale prima del deployment. "Non è lento?", chiedono. "Non si può semplicemente monitorare in produzione e intercettare i problemi?" Certo. Si può anche guidare senza freni e pensare di schivare gli ostacoli con lo sterzo. Funziona finché non funziona più. E quando non funziona nei servizi finanziari, le persone in carne e ossa ci rimettono.

Perché nessuno se n'è accorto?

È la domanda che mi perseguita. Due delle aziende tecnologicamente più sofisticate del pianeta — Apple, con la sua leggendaria cultura ingegneristica, e Goldman Sachs, con la sua potenza di fuoco quantitativa — e nessuna delle due si è accorta che migliaia di contestazioni finivano in un buco nero?

La risposta, credo, è architetturale. Il sistema era progettato come un relè: Apple gestisce il front end, Goldman gestisce il back end e i messaggi viaggiano tra i due. Ma nessuno era proprietario dello spazio tra i due sistemi. Nessuno aveva un modello formale di ciò che sarebbe dovuto accadere quando una contestazione entrava nello stato A ("messaggio inviato") ma non raggiungeva mai lo stato B ("modulo completato"). In una macchina a stati ben progettata, quella è una transizione che si prevede esplicitamente. Nel sistema dell'Apple Card era una lacuna che nessuno aveva specificato, e quindi nessuno monitorava.

Circa un anno fa ho fatto tardi una notte — io e il mio team stavamo costruendo un workflow di compliance per un cliente, e una delle nostre ingegnere, Priya, ha segnalato qualcosa di simile. Stava modellando le transizioni di stato di un processo di revisione documentale e ha trovato un percorso in cui un invio poteva restare bloccato indefinitamente in uno stato di "arricchimento in sospeso" se un'API di terze parti andava in timeout. Non era un bug nel codice. Il codice faceva esattamente ciò che gli era stato detto di fare. Era un bug nel design — uno stato che la specifica non aveva previsto.

L'abbiamo intercettato perché usiamo strumenti di verifica formale — nello specifico, modelliamo i workflow come macchine a stati e li facciamo passare attraverso SMT solver che verificano esaustivamente ogni percorso possibile. Il solver ha trovato lo stato morto di Priya in pochi secondi. Nel sistema dell'Apple Card, quello stato morto è rimasto in produzione per mesi.

Il fallimento dell'Apple Card non era un bug nel codice. Il codice faceva esattamente ciò che gli era stato detto di fare. Era un bug nel design — uno stato che nessuno aveva specificato, e quindi nessuno monitorava.

Perché non si può semplicemente usare GPT per questo?

Mi fanno questa domanda di continuo. Un investitore me l'ha detta quasi alla lettera durante un incontro di pitch: "Perché non potete semplicemente fare il fine-tuning di GPT-4 sulle normative TILA e lasciargli gestire le contestazioni?"

Ho preso fiato. Poi gli ho chiesto: "Se GPT-4 dice a un consumatore che la sua contestazione è stata risolta, ma in realtà non è mai stata trasmessa alla banca, chi ne risponde?"

Non aveva una risposta. Non ce l'ha nessun altro, perché la domanda mette a nudo il problema di fondo di quello che chiamo l'approccio "mega-prompt" all'AI nei settori regolamentati. Si prende un large language model, gli si infilano le normative rilevanti nella context window e si spera che gestisca tutto correttamente. Nessun livello di governance. Nessuna verifica formale. Nessuna garanzia matematica che gli output del sistema siano coerenti con la legge.

Nel caso Apple Card, il fallimento era un errore logico in una macchina a stati distribuita. Un wrapper basato su LLM non avrebbe risolto nulla — anzi, avrebbe potuto peggiorare le cose. Immaginate un LLM che dice con sicurezza a un consumatore "La sua contestazione è stata inviata ed è in corso di indagine" quando, in realtà, la contestazione non ha mai lasciato i server di Apple. Non è un'ipotesi teorica. È l'aspetto che ha l'allucinazione in un contesto finanziario, ed è terrificante.

I siti divulgativi di finanza più popolari e i contenuti più condivisi sull'AI nel settore bancario mancano quasi universalmente questa distinzione. Parlano di AI che "automatizza" la compliance come se la parte difficile fosse leggere le normative. La parte difficile non è leggerle. La parte difficile è dimostrare che il vostro sistema le rispetta in ogni scenario possibile, compresi gli scenari a cui non avete ancora pensato.

Per uno sguardo più approfondito su come il fallimento Apple-Goldman si mappa su specifiche violazioni normative e lacune architetturali, ho scritto un'analisi interattiva che ripercorre il consent order in dettaglio.

Che cosa significa davvero "dimostrabilmente corretto"

Quando dico che Veriprajna costruisce sistemi di compliance "dimostrabilmente corretti", non intendo "testati molto bene". Intendo dimostrati matematicamente. C'è una differenza, ed è enorme.

Il testing verifica scenari specifici. Si scrive un test che dice "se un utente invia una contestazione e completa il modulo, verifica che arrivi a Goldman Sachs". Il test passa. Ottimo. Ma non avete testato lo scenario in cui l'utente invia una contestazione e non completa il modulo. O quello in cui lo completa ma la rete perde il pacchetto. O quello in cui due contestazioni arrivano simultaneamente e una sovrascrive l'altra.

La verifica formale non verifica scenari. Verifica proprietà. Si definisce una proprietà — "ogni contestazione inviata deve prima o poi raggiungere uno stato di indagine" — e un solver matematico dimostra esaustivamente che la proprietà vale in ogni possibile esecuzione del sistema. Ogni percorso. Ogni caso limite. Ogni race condition. Se esiste anche un solo controesempio, il solver lo trova e vi mostra esattamente come il sistema può fallire.

Usiamo strumenti come Imandra, che ci permette di costruire quello che è in sostanza un gemello digitale della logica di compliance. Il gemello gira in parallelo al sistema di produzione e, se il codice di produzione tenta un'azione che devia dal modello verificato — per esempio scartare una contestazione a causa di un passaggio incompleto nell'interfaccia — il sistema lo intercetta in tempo reale.

È il tipo di approccio che avrebbe intercettato il bug dell'Apple Card prima che venisse colpito un solo consumatore. In fase di progettazione, un SMT solver avrebbe immediatamente rilevato che la variabile "CompletedFormB" non era un campo obbligatorio ai sensi del TILA. La logica di trasmissione lo richiedeva, ma la legge no. Quel disallineamento è un difetto dimostrabile, e sarebbe stato segnalato prima del deployment.

L'architettura che costruiamo davvero

Voglio essere specifico su come si presenta nella pratica un sistema di compliance "deep AI", perché le affermazioni vaghe sulla "compliance basata sull'AI" sono parte del problema.

Veriprajna usa un'architettura multi-agente. Invece di un'unica AI monolitica che cerca di fare tutto, mettiamo in campo agenti specializzati con ruoli e confini definiti. Pensatelo meno come assumere un genio e più come mettere insieme una squadra in cui ognuno ha un compito specifico e un supervisore che ne controlla il lavoro.

Un Intake Agent gestisce la parte disordinata e umana — l'analisi delle contestazioni in linguaggio naturale. Quando qualcuno scrive "Non ho mai comprato questo caffè a Seattle; quel giorno ero a Londra", l'agente estrae le entità chiave: la transazione, l'esercente, la data, la natura del reclamo. È qui che gli LLM danno davvero il meglio.

Ma poi — ed è qui che ci discostiamo da ogni approccio basato su wrapper che ho visto — le informazioni estratte passano a un Policy Engine simbolico che non fa previsioni e non tira a indovinare. Valuta la contestazione rispetto a codifiche in logica del primo ordine della normativa federale. Questo messaggio contiene informazioni sufficienti per costituire un valido Billing Error Notice ai sensi del TILA? Il motore non stima. Dimostra.

Un Workflow Agent impone la sequenza delle operazioni. Un Verification Agent esegue controlli matematici in tempo reale. Un Audit Agent registra ogni interazione in quella che chiamiamo una "glass box" — trasparenza completa per i regolatori.

E, cosa cruciale, un Sentinel Agent sorveglia esattamente il tipo di stato morto che ha ucciso il sistema dell'Apple Card. Se una contestazione resta in "inviata ma non trasmessa" oltre una soglia definita, il Sentinel non aspetta che se ne accorga un essere umano. Determina autonomamente se le informazioni esistenti sono sufficienti per procedere, le impacchetta e le trasmette attraverso un canale verificato.

In un sistema costruito per la compliance assoluta, è la legge — non l'interfaccia — a determinare se una contestazione è valida. Se un consumatore vi ha segnalato un addebito non autorizzato, l'assenza di un modulo completato è un problema vostro, non suo.

Perché la tempistica è un requisito di legge, non una metrica di performance

C'è un'altra dimensione della questione che la maggior parte delle discussioni tecniche ignora del tutto. Nella compliance finanziaria, il tempo è legge. La Regulation Z non dice soltanto che dovete indagare sulle contestazioni. Dice che dovete darne riscontro entro periodi precisi e risolverle entro 60 giorni. Goldman Sachs è stata multata in parte perché non ha inviato gli avvisi di riscontro entro queste finestre temporali.

Il mio team ha passato mesi a sviluppare quella che chiamiamo analisi di Symbolic Latency — un modo per dimostrare matematicamente che un sistema distribuito porterà a termine il proprio lavoro entro una scadenza normativa nelle condizioni peggiori. Non in condizioni medie. Non al "95esimo percentile". Nel caso peggiore.

Il monitoraggio tradizionale vi dice se il vostro sistema è stato lento. La Symbolic Latency vi dice se il vostro sistema può essere lento. Se una modifica al codice dell'interfaccia porta il tempo di elaborazione nel caso peggiore oltre la finestra normativa dei 60 giorni, il deployment viene automaticamente rifiutato. Non lo scoprite a cose fatte. Lo scoprite prima di rilasciare.

Ricordo la discussione che abbiamo avuto internamente su se questo livello di rigore fosse necessario. Uno dei miei ingegneri — un tipo brillante che aveva passato anni in un grande cloud provider — si è opposto con forza. "Stai aggiungendo settimane al ciclo di deployment per uno scenario che potrebbe non verificarsi mai", ha detto. Gli ho indicato il consent order dell'Apple Card. "È successo", ho detto. "Ad Apple. A Goldman Sachs. A decine di migliaia di consumatori che non avevano fatto nulla di male."

Dopo di che non ha più discusso.

Per l'analisi tecnica completa del nostro approccio alla verifica formale, inclusa la metodologia Performal per i limiti di latenza, consultate il nostro paper di ricerca.

"Ma ci vorrebbe troppo tempo per costruirlo"

Le persone obiettano sempre su questo punto, e capisco perché. L'Apple Card è stata lanciata in pochi mesi. Un'architettura di compliance formalmente verificata richiede dai 18 ai 36 mesi per una piena ottimizzazione in un ambiente pieno di sistemi legacy. Sembra un'eternità in un mondo in cui i concorrenti rilasciano ogni settimana.

Ma lasciate che vi riformuli il conto. Apple e Goldman Sachs hanno passato anni a costruire e lanciare l'Apple Card. Poi hanno passato anni a gestirne le conseguenze — indagini interne, esami dei regolatori, costi legali, danno reputazionale e, alla fine, 89,8 milioni di dollari tra sanzioni e rimborsi ai consumatori. L'approccio "veloce" non è stato veloce. È stata velocità caricata all'inizio e catastrofe caricata alla fine.

Il nostro approccio di deployment per fasi tiene conto della realtà. Non si possono strappare via i sistemi core di una banca. I mainframe COBOL che girano dagli anni '80 non spariranno da un giorno all'altro. Perciò integriamo a livelli: verifichiamo l'architettura esistente, costruiamo un gateway API intelligente, facciamo girare il sistema di AI in shadow mode per validare gli output del sistema legacy e spostiamo gradualmente l'autorità decisionale man mano che le dimostrazioni formali si accumulano.

La prima fase — assessment e modellazione formale — richiede dalle 14 alle 20 settimane. Alla fine avete un modello matematico della vostra logica di compliance in grado di intercettare il tipo di bug da stato morto che ha afflitto l'Apple Card. Non sono 36 mesi. Sono meno di cinque mesi per arrivare a un sistema radicalmente più sicuro.

Il momento che ha cambiato il mio modo di vedere la cosa

C'è un momento preciso a cui continuo a tornare. Era circa otto mesi fa e stavamo facendo un proof-of-concept per un cliente dei servizi finanziari. Avevamo modellato il loro workflow di risoluzione delle contestazioni come una macchina a stati distribuita e stavamo eseguendo la suite di verifica formale.

Il solver ha trovato undici stati morti.

Undici percorsi attraverso il sistema in cui il reclamo di un consumatore poteva restare bloccato senza risoluzione e senza alcun alert. Il team di ingegneria del cliente gestiva quel sistema da tre anni. Avevano elaborato milioni di transazioni. Avevano dashboard di monitoraggio, sistemi di alerting, audit trimestrali. E niente di tutto questo aveva intercettato quegli undici buchi.

La stanza è piombata nel silenzio quando ho mostrato loro i risultati. La loro responsabile della compliance — una donna che aveva passato vent'anni nella regolamentazione bancaria — ha guardato lo schermo e ha detto: "Quanti consumatori sono finiti in quegli stati?"

Non lo sapevamo. Non lo sapevano nemmeno loro. È questo il punto degli stati morti nei sistemi distribuiti: se nessuno li cerca, sono invisibili. I consumatori colpiti potrebbero aver chiamato il servizio clienti, essere stati rimbalzati da un ufficio all'altro e alla fine aver rinunciato. Oppure potrebbero ancora stare pagando addebiti che non hanno mai fatto.

È così che appare dall'interno il fallimento dell'Apple Card. Non un'esplosione drammatica. Un accumulo lento e silenzioso di danni che nessuno riesce a vedere finché un regolatore non costringe ad aprire la scatola nera.

Come saranno i prossimi cinque anni

L'azione della CFPB contro Apple e Goldman Sachs non è un evento isolato. È l'inizio di una resa dei conti normativa su come le aziende tecnologiche gestiscono l'infrastruttura finanziaria. Man mano che il banking diventa sempre più embedded — nei telefoni, nelle app, in piattaforme che non erano state originariamente progettate come servizi finanziari — il divario tra "funziona quasi sempre" e "si dimostra che funziona sempre" diventa una responsabilità misurata in centinaia di milioni di dollari.

Penso all'obiezione che sento più spesso: "La verifica formale non è eccessiva per la maggior parte dei sistemi finanziari?" E la mia risposta è diventata più semplice con il tempo. L'Apple Card è uno dei prodotti finanziari al consumo più visibili al mondo, costruito da due aziende con risorse ingegneristiche sostanzialmente illimitate. Se loro non sono riuscite a individuare uno stato morto in un workflow di contestazioni con testing e monitoraggio tradizionali, cosa vi fa pensare che il vostro sistema sia diverso?

Il settore si sta muovendo verso quella che chiamo Compliance Assoluta — non la compliance come esercizio di spunta di caselle, ma la compliance come proprietà architetturale. Un sistema in cui l'aderenza alla legge non è qualcosa che si verifica a posteriori, ma qualcosa che si dimostra prima del deployment. Dove il divario tra l'interfaccia e la normativa non è colmato dalla vigilanza umana ma dalla certezza matematica.

L'era del "rilascia in fretta e sistema dopo" è incompatibile con i requisiti di "muovere denaro e proteggere le persone" della finanza globale. L'Apple Card lo ha dimostrato. La domanda è se il settore imparerà la lezione prima o dopo la prossima multa da 89 milioni di dollari.

Stiamo costruendo quel futuro in Veriprajna. Non perché sia facile — la verifica formale dei sistemi finanziari distribuiti è davvero difficile, e chiunque vi dica il contrario vi sta vendendo qualcosa. Ma perché l'alternativa è quello che abbiamo visto nell'ottobre 2024: due delle aziende più potenti al mondo, un pulsante rotto e decine di migliaia di persone lasciate con il conto in mano per addebiti che non avevano mai fatto.

Non è un problema tecnologico. È un problema di etica ingegneristica. E la soluzione non è un monitoraggio migliore o patch più rapide. È costruire sistemi corretti per costruzione — sistemi in cui la matematica garantisce che la contestazione di nessun consumatore svanirà mai nel vuoto.

La multa da 89 milioni di dollari è già stata pagata. Il costo reale è la fiducia che è stata infranta. Ricostruirla richiede più delle promesse. Richiede prove.