L'auto a guida autonoma l'ha vista 5,6 secondi prima dell'impatto — e non è riuscita comunque a decidere che cosa fosse

Ero seduto in una sala riunioni alla fine del 2023, mentre guardavo un video che avrebbe cambiato per sempre il mio modo di pensare alla sicurezza dell'IA. Le immagini provenivano da un robotaxi Cruise a San Francisco. Un pedone era stato investito da un'auto guidata da una persona, scaraventato sulla traiettoria del veicolo autonomo e rimasto incastrato sotto il veicolo. Il robotaxi si è fermato — brevemente — e poi ha iniziato ad accostare sul lato della strada, trascinando la donna per 20 piedi sull'asfalto.

Nella stanza era calato il silenzio. Qualcuno del mio team ha detto: "L'auto ha pensato di aver subito una collisione laterale." E quella frase — l'auto ha pensato — è diventata il seme di tutto ciò che da allora stiamo costruendo in Veriprajna.

Perché l'auto non ha "pensato" nulla. Ha eseguito una subroutine di classificazione, ha ottenuto la risposta sbagliata e ha messo in atto una manovra preprogrammata che ha trasformato un incidente sopravvivibile in qualcosa di molto peggio. Non c'è stato alcun ragionamento. Nessuna consapevolezza. Nessuna architettura di sicurezza in grado di intercettare una diagnosi errata catastrofica prima che diventasse una catastrofe.

Questo è il divario che continuo a cercare di spiegare a investitori, clienti e colleghi ingegneri: la distanza tra un'IA che si esibisce bene nelle demo e un'IA che si comporta in modo sicuro quando il mondo smette di collaborare. Ho iniziato a chiamarlo il Divario Percezione-Logica — lo spazio tra ciò che un sistema autonomo vede e ciò che effettivamente comprende. E in questo momento quel divario sta uccidendo delle persone.

Cosa è successo quando l'IA ha avuto quasi sei secondi e ha comunque fallito?

L'incidente di Uber ATG a Tempe, in Arizona, nel marzo 2018 è il caso a cui torno più spesso, perché è l'illustrazione più pura di come un sistema probabilistico possa avere tutti i dati di cui ha bisogno e commettere comunque un errore fatale.

I sensori del veicolo hanno registrato per la prima volta Elaine Herzberg — un pedone che spingeva una bicicletta attraversando una strada buia — circa 5,6 secondi prima dell'impatto. A 43 mph, si tratta di circa 378 piedi di distanza. Più che sufficienti perché qualsiasi sistema frenante competente fermasse l'auto.

Ma l'IA non riusciva a decidere che cosa stesse guardando. Nel corso di quei 5,6 secondi, il sistema di percezione ha riclassificato ripetutamente Herzberg: prima come "oggetto sconosciuto", poi come "veicolo", poi come "bicicletta". Ogni riclassificazione non era solo un cambio di etichetta: era un azzeramento completo della traiettoria prevista dell'oggetto. In sostanza, il sistema sviluppava un'amnesia ogni volta che cambiava idea.

Ricordo di aver letto il rapporto dell'NTSB per la prima volta e di essermi sentito fisicamente male. Non per l'esito — per quanto devastante — ma per il meccanismo. L'IA ha stabilito che la frenata di emergenza era necessaria solo 1,3 secondi prima dell'impatto. La fisica ha reso inevitabile il resto.

Un'IA che riesce a vedere un ostacolo per quasi sei secondi e non riesce ancora a decidere che cosa sia non ha un problema di sensori. Ha un problema di architettura.

A peggiorare le cose — a farmi arrabbiare, sinceramente — è stato scoprire che Uber aveva deliberatamente disattivato il sistema anticollisione installato di fabbrica sulla Volvo XC90. L'auto era dotata di frenata automatica di emergenza fornita dal costruttore. Uber l'ha spenta per evitare quello che definiva un "comportamento erratico del veicolo". Volevano una guida più fluida per il loro software sperimentale, così hanno rimosso l'unico livello di sicurezza deterministico che avrebbe potuto salvare una vita.

Quella decisione perseguita questo settore. È il peccato originale di trattare la sicurezza dell'IA come un problema di taratura anziché come una disciplina ingegneristica.

Perché lo stesso guasto continua a ripetersi su auto diverse?

Dopo l'incidente Uber, mi aspettavo che il settore imparasse. Nello specifico, mi aspettavo che le aziende costruissero architetture in cui un guasto della percezione non potesse propagarsi a cascata in un guasto decisionale. In cui esistessero confini di sicurezza rigidi che nessun software sperimentale potesse scavalcare.

Invece è arrivata Cruise.

L'incidente dell'ottobre 2023 a San Francisco è stato diverso da quello di Uber nei dettagli, ma identico nell'architettura. Una Nissan guidata da una persona ha investito un pedone, scaraventandola sulla traiettoria di un robotaxi Cruise. Il veicolo Cruise l'ha colpita e si è fermato. Fino a quel momento il sistema stava funzionando — in modo imperfetto, ma entro i parametri.

Poi è entrata in azione la logica post-impatto. Il rilevamento dell'impatto del sistema non era abbastanza granulare da distinguere tra un investimento frontale e una collisione laterale. Ha classificato l'evento come un impatto laterale. E la risposta preprogrammata a un impatto laterale era: accostare sul lato della strada per non bloccare il traffico.

L'auto ha accostato. Con un essere umano incastrato sotto di sé. L'ha trascinata per 20 piedi a circa 7 mph prima di rilevare uno "slittamento eccessivo delle ruote" — che ha interpretato come un guasto meccanico, non come una persona.

Ho passato una settimana dopo quell'incidente a discutere con il mio team su quale avrebbe dovuto essere l'architettura di risposta corretta. Uno dei nostri ingegneri — un tipo brillante, molto orientato ai metodi formali — continuava a insistere che il problema fosse risolvibile con una migliore fusione dei sensori. "Se il sistema avesse avuto il rilevamento di occupazione sotto il telaio," ha detto, "lo avrebbe saputo."

Aveva ragione. Ma stava anche mancando il punto. Il guasto più profondo era che il sistema non aveva alcun concetto di incertezza sulla propria diagnosi. Ha classificato l'impatto e poi ha agito su quella classificazione con piena fiducia. Non esisteva uno stato intermedio del tipo "non sono sicuro di cosa sia appena successo, quindi non dovrei fare nulla finché non lo saprò". L'architettura non ammetteva il dubbio.

È questo che intendo quando parlo del Divario Percezione-Logica. Non si tratta solo di vedere meglio. Si tratta di sapere quando non si sa.

Anche l'insabbiamento era architettura

Ciò che è accaduto dopo l'incidente del trascinamento di Cruise è stato quasi altrettanto rivelatore dell'incidente stesso. Le indagini hanno rilevato che i vertici aziendali erano "fissati sul correggere la narrazione mediatica inesatta" anziché essere trasparenti con le autorità di regolamentazione. I dipendenti hanno ammesso di aver mostrato ai regolatori un video dell'incidente sapendo che i problemi di connettività a Internet spesso impedivano la riproduzione della parte relativa al trascinamento.

Cruise ha infine pagato una sanzione penale di 500.000 dollari per aver presentato segnalazioni false alla NHTSA. Il suo permesso operativo in California è stato revocato.

Sollevo la questione non per infierire su Cruise, ma perché rivela qualcosa di strutturale sul modo in cui il settore tratta la sicurezza. Quando il tuo sistema di IA è una scatola nera — quando nemmeno i tuoi ingegneri riescono a spiegare fino in fondo perché ha preso una determinata decisione in un determinato momento — la tentazione di controllare la narrazione invece di correggere l'architettura diventa irresistibile.

La trasparenza non è una strategia di PR per i veicoli autonomi. È un requisito tecnico. Se non puoi sottoporre ad audit ogni decisione presa dalla tua IA durante una crisi, non hai un sistema di sicurezza: hai una responsabilità legale.

In Veriprajna abbiamo reso gli audit di sicurezza spiegabili una parte centrale del nostro lavoro architetturale. Ogni decisione presa dall'IA, specialmente dopo un impatto, viene registrata in un formato deterministico e a prova di manomissione che le autorità di regolamentazione possono sottoporre ad audit in tempo reale. Non perché siamo più virtuosi di Cruise, ma perché abbiamo visto cosa succede quando l'alternativa è "lasciamo che il video parli da sé".

Ho scritto del framework tecnico completo alla base di questo approccio nel nostro whitepaper interattivo, inclusi gli specifici modi di guasto che abbiamo catalogato a partire da Uber, Cruise, Tesla e Waymo.

Cosa significa davvero per la sicurezza la scommessa "solo visione" di Tesla?

L'approccio di Tesla alla guida autonoma è filosoficamente diverso da quello di Uber o di Cruise, e anche i guasti sono diversi. Ma fanno rima.

Il sistema Full Self-Driving di Tesla si affida interamente alle telecamere: niente LiDAR, niente radar. Elon Musk ha definito il LiDAR una "stampella". La scommessa è che reti neurali sufficientemente avanzate possano ricostruire una comprensione 3D completa del mondo a partire dalle sole immagini 2D, come fa la visione umana.

È un'idea elegante. La trovo persino intellettualmente convincente. Ma la NHTSA ha aperto oltre 40 indagini su incidenti legati a FSD tra il 2024 e il 2025, che riguardano 2,9 milioni di veicoli, e lo schema è schiacciante.

Diciotto denunce distinte riguardano veicoli che passano con il rosso o che non rilevano lo stato dei semafori. Diverse segnalazioni descrivono auto che imboccano corsie di marcia opposte. Una collisione mortale del 2023 è avvenuta in presenza di riverbero solare su asfalto bagnato — condizioni in cui il rapporto segnale-rumore ottico scende al di sotto di ciò che qualsiasi sistema di telecamere può interpretare in modo affidabile.

Io lo chiamo Teatro delle Capacità: il sistema si comporta magnificamente in condizioni ottimali, creando un'illusione di competenza che crolla ai margini. Giornata di sole, strada libera, incrocio standard? Impeccabile. Sole basso, asfalto bagnato, un pedone che attraversa in modo inconsueto? Il sistema non degrada in modo graduale. Fallisce di colpo.

Il problema non è che il vision-only non possa funzionare in teoria. È che Tesla lo sta implementando su larga scala senza quelle che io chiamerei Barriere di Garanzia — confini rigidi che impediscono all'IA di prendere decisioni ad alto rischio quando la sua confidenza scende sotto una soglia verificata. Se la saturazione da riverbero supera una certa percentuale, il sistema dovrebbe rifiutarsi di guidare, non tirare a indovinare con più forza.

Come si dimostra che un'IA non ucciderà qualcuno?

È la domanda che mi tiene sveglio la notte. Non metaforicamente: letteralmente. C'è stato un periodo, l'anno scorso, in cui portavo avanti esperimenti di verifica formale fino alle 2 del mattino, cercando di trovare il confine tra "testato a sufficienza" e "dimostrato sicuro".

Il testing tradizionale del software è black-box: si fa passare il sistema attraverso N scenari e, se li supera tutti, lo si rilascia. Ma i veicoli autonomi non incontrano N scenari. Incontrano l'intero mondo fisico, con tutto il suo caos, i suoi casi limite e gli esseri umani che fanno cose inspiegabili. Nessuna quantità di test su scenari può coprire quello spazio.

La verifica formale adotta un approccio diverso. Invece di chiedere "il sistema ha superato questi test?", chiede: "esiste un qualsiasi input in grado di produrre un output non sicuro?" Strumenti come Marabou e α,β-CROWN possono rappresentare una rete neurale come un insieme di vincoli matematici e poi cercare — in modo esaustivo — le violazioni.

Una proprietà di sicurezza potrebbe avere questo aspetto: per ogni possibile input all'interno di un intervallo di "scarsa visibilità", il comando di frenata non deve mai scendere sotto una soglia minima. Se il solver trova un controesempio — un input specifico che viola la proprietà — hai identificato una vulnerabilità prima che uccida qualcuno.

Una notte stavamo eseguendo la verifica su un modello di percezione e il solver ha restituito un controesempio che nessuno di noi aveva previsto. Una combinazione molto specifica di angolo di illuminazione e distanza dell'oggetto che faceva scendere quasi a zero la confidenza nella frenata. Non era uno scenario che a qualcuno di noi sarebbe venuto in mente di testare. Il solver l'ha trovato perché non stava tirando a indovinare: stava dimostrando.

Quel momento ha cristallizzato qualcosa per me. Il testing chiede "questo funziona?". La verifica chiede "questo può fallire?". Sono domande fondamentalmente diverse, e l'IA safety-critical esige la seconda.

Il testing ti dice cosa fa la tua IA. La verifica ti dice cosa non potrà mai fare. Per i sistemi safety-critical conta solo la seconda domanda.

Il problema è che le reti neurali attuali sono enormi — milioni di parametri — e la verifica esaustiva di reti di grandi dimensioni è computazionalmente intrattabile. Affrontiamo la questione tramite il pruning dei neuroni: la rimozione sistematica dei neuroni ridondanti che non contribuiscono all'accuratezza ma rendono la rete troppo complessa da verificare. Il risultato è un modello più snello che è al tempo stesso performante e matematicamente dimostrabile.

Per l'analisi tecnica completa della nostra pipeline di verifica — inclusa la metodologia del solver SMT e l'approccio di pruning — vedi il nostro paper di ricerca dettagliato.

Quando il problema non è l'IA — è il mondo

Waymo ha registrato oltre 56 milioni di miglia e ha tassi di lesioni significativamente inferiori a quelli dei conducenti umani. Secondo la maggior parte delle metriche, è il leader del settore. Eppure Waymo ha rivelato una modalità di guasto a cui nessuno nel settore dei veicoli autonomi era preparato: il mondo stesso che si rifiuta di collaborare.

Durante un blackout del 2025 a Los Angeles, decine di robotaxi Waymo sono rimasti bloccati a incroci al buio. I veicoli erano programmati per trattare i semafori spenti come incroci con stop su tutti e quattro i lati — la risposta corretta secondo la legge. Ma quando decine di veicoli autonomi arrivano tutti allo stesso incrocio spento, ciascuno in attesa educata del proprio turno e ciascuno che richiede simultaneamente l'assistenza umana da remoto, si ottiene quella che ho iniziato a chiamare la Trappola dell'Indipendenza: ogni veicolo si comporta correttamente in isolamento, mentre collettivamente creano un ingorgo che nessun veicolo singolo può risolvere.

Il centro di assistenza remota è stato sommerso. I robotaxi bloccavano altri robotaxi. Il sistema che funzionava perfettamente con un'auto a un incrocio è crollato quando è stato scalato a una flotta durante un'emergenza a livello cittadino.

E poi c'è il problema di cui nessuno vuole parlare pubblicamente. Durante i disordini civili a Los Angeles all'inizio del 2025, la folla ha attaccato i veicoli Waymo — squarciando gli pneumatici, rompendo i finestrini, dando fuoco alle auto. I veicoli, programmati per la "sicurezza passiva", si sono semplicemente fermati quando sono stati circondati dalle persone. Che è esattamente la risposta sbagliata quando le persone che ti circondano stanno cercando di distruggere il veicolo con i passeggeri a bordo.

Questo ha portato a discussioni serie su quella che alcuni ricercatori chiamano una "Modalità di Fuga dal Pericolo" — la capacità di un veicolo autonomo di commettere infrazioni stradali minori (salire su un marciapiede, passare con il rosso) per proteggere i propri passeggeri dalla violenza. Richiede di ripensare radicalmente la gerarchia etica dell'IA, ed è un problema che nessuna quantità di sensori migliori o di processori più veloci può risolvere.

Ho sollevato la questione in una riunione con un potenziale cliente, e qualcuno ha detto: "Non potete semplicemente usare GPT per gestire casi limite come quello?" Credo che la mia espressione abbia detto più delle mie parole. Questo è un problema di architettura decisionale che richiede un ragionamento etico formale, non un chatbot.

Perché non possiamo semplicemente arrivare alla sicurezza a forza di test?

Me lo chiedono di continuo. "Se Waymo ha 56 milioni di miglia di dati, non sono abbastanza test?"

No. E la ragione è matematica, non filosofica.

Lo spazio dei possibili scenari di guida è di fatto infinito. Puoi percorrere 56 milioni di miglia e non incontrare mai quella specifica combinazione di riverbero solare, asfalto bagnato e pedone vestito in modo insolito che manda in crisi il tuo sistema di percezione. I casi limite non sono versioni rare di scenari comuni: sono scenari che esistono negli spazi vuoti tra tutto ciò che hai già visto.

Ecco perché il panorama normativo si sta spostando da "mostrateci i risultati dei vostri test" a "mostrateci le vostre prove di sicurezza". La ISO 21448, nota come SOTIF — Safety of the Intended Functionality — è stata concepita specificamente per affrontare i pericoli che si verificano quando l'IA funziona esattamente come programmata ma incontra un ambiente che non è in grado di gestire. Non riguarda il guasto dell'hardware. Riguarda i limiti intrinseci dell'IA che incontrano il mondo reale.

E la ISO/PAS 8800, diventata alla fine del 2024 lo standard principale per l'IA nei veicoli stradali, va oltre: richiede di gestire l'intero ciclo di vita dell'IA, dall'acquisizione dei dati fino al monitoraggio successivo al rilascio. L'era del "pubblichiamolo e vediamo cosa succede" sta finendo, almeno per le aziende che vogliono operare legalmente nell'UE, negli Stati Uniti e nei principali mercati asiatici.

In Veriprajna strutturiamo il nostro lavoro attorno all'obiettivo di portare i clienti in quello che SOTIF chiama il quadrante "Noto/Sicuro": identificando sistematicamente le condizioni scatenanti, mappando gli stati ambientali che causano errori di percezione e usando simulazioni ad alta fedeltà per iniettare casi limite che sarebbero troppo pericolosi da testare su strade reali.

La vera differenza tra un wrapper e una soluzione

Ho passato gli ultimi anni a osservare l'industria dell'IA dividersi in due schieramenti, e la spaccatura si sta allargando.

Da una parte c'è l'economia dei wrapper — aziende che costruiscono interfacce conversazionali sopra i grandi modelli linguistici, ottimizzando per velocità di rilascio ed esperienza utente. Parte di questo lavoro è genuinamente utile. La maggior parte è irrilevante per le applicazioni safety-critical.

Dall'altra parte c'è quella che chiamo ingegneria profonda dell'IA: l'integrazione di verifica formale, resilienza nella fusione dei sensori e architetture di sicurezza deterministiche. È più lenta. È più difficile. È meno impressionante nelle demo. Ed è l'unico approccio che può sopravvivere al contatto con il mondo fisico.

Il fulcro tecnico di questo cambiamento è la percezione Bird's-Eye-View con le Occupancy Network. Invece di elaborare i singoli flussi delle telecamere e cercare di ricucirli insieme — un processo che perde dati a ogni giunzione — la percezione BEV trasforma i dati multi-vista di telecamere e LiDAR in una griglia 3D unificata vista dall'alto. E invece di chiedere "che cos'è questo oggetto?", le occupancy network chiedono "questo spazio è occupato?".

Quella distinzione conta enormemente. Se il sistema Uber ATG avesse tracciato lo spazio occupato invece di cercare di classificare gli oggetti, non avrebbe avuto alcuna importanza che il sistema pensasse che Herzberg fosse un pedone, una bicicletta o un oggetto sconosciuto. Lo spazio era occupato. Lo spazio era sulla traiettoria del veicolo. Frenare.

Analogamente, se il veicolo Cruise avesse avuto attivo il rilevamento dell'occupazione sotto il proprio telaio, avrebbe saputo che c'era qualcosa sotto l'auto a prescindere da come avesse classificato l'impatto. Lo spazio occupato avrebbe avuto la precedenza sulla manovra di accostamento.

La domanda non è "che cos'è questo oggetto?" — è "questo spazio è occupato?". Quella singola riformulazione avrebbe potuto evitare i due disastri più famigerati dei veicoli autonomi dell'ultimo decennio.

Usiamo architetture Transformer — la stessa tecnologia fondamentale alla base di GPT — ma non per la conversazione. Le usiamo come motori di ragionamento spaziale che fondono dati eterogenei dei sensori in quello che chiamiamo Canvas Condiviso. L'auto-attenzione temporale permette al sistema di ricordare dove si trovava un oggetto anche durante occlusioni temporanee: un pedone che cammina dietro un camion parcheggiato non scompare dalla consapevolezza del modello solo perché le telecamere non riescono a vederla per due secondi.

La lezione da 8,5 milioni di dollari

Il risarcimento di Uber ATG è stato di 8,5 milioni di dollari. La sanzione penale di Cruise è stata di 500.000 dollari — una cifra che non inizia nemmeno a tenere conto della sospensione operativa, del danno reputazionale o della sofferenza umana. L'indagine della NHTSA su Tesla riguarda 2,9 milioni di veicoli. Il costo medio globale di una singola violazione dei dati è oggi di 4,44 milioni di dollari.

Quando sommo questi numeri, la conclusione è scomoda per la folla del "muoviti in fretta e rompi le cose": il wrapper di IA economico è l'errore più costoso che un'azienda possa commettere. Non perché non funzioni — funziona benissimo in ambienti controllati. Ma nel momento in cui incontra il mondo non controllato — la strada buia, la confusione post-impatto, il riverbero del sole sull'asfalto bagnato, la folla inferocita — l'assenza di un'architettura di sicurezza deterministica trasforma un limite del software in una catastrofe umana.

A volte le persone obiettano al nostro approccio dicendo che la verifica formale è troppo lenta, troppo costosa, troppo accademica per le tempistiche di rilascio nel mondo reale. Capisco l'obiezione. La verifica è computazionalmente costosa. Il pruning delle reti per renderle verificabili richiede tempo. Costruire architetture di sicurezza con barriere di garanzia rigide è più lavoro che avvolgere un'API.

Ma chiederei a quelle persone di guardare il video del trascinamento di Cruise. Di leggere il rapporto dell'NTSB sulla morte di Elaine Herzberg. Di osservare le 18 denunce per il passaggio con il rosso nell'indagine su Tesla FSD. E poi di dirmi che "troppo lento" è una critica valida a un approccio progettato proprio per prevenire quegli esiti.

L'era della costruzione di sistemi autonomi sulla speranza probabilistica sta finendo. Non perché siano i regolatori a imporlo — anche se lo stanno facendo — ma perché lo esige la fisica del mondo reale. Un sistema di IA che percorre mille incroci perfettamente e poi passa con il rosso al milleunesimo non è sicuro al 99,9%. È non sicuro, punto. La sicurezza non è una percentuale. È una proprietà: o vale in tutte le condizioni verificate, o non vale affatto.

È questo il cambiamento attorno a cui sto costruendo Veriprajna. Non wrapper migliori. Non demo più veloci. Garanzia deterministica per sistemi in cui il fallimento non è un bug report: è un conteggio di vittime.