Dai modelli stocastici alla garanzia deterministica: un quadro strategico per l'intelligenza artificiale safety-critical

Il panorama contemporaneo dell'intelligenza artificiale è attualmente diviso in due da un fraintendimento fondamentale della profondità tecnica. Da un lato di questa frattura si trova la rapida proliferazione di strati di interfaccia generativa—spesso caratterizzati come «wrapper» di Large Language Model (LLM)—che privilegiano il dispiegamento rapido e la fluidità conversazionale. Dal lato opposto si trova la disciplina rigorosa dell'ingegneria Deep AI, un campo definito dall'integrazione di verifica formale, resilienza della sensor fusion e architetture di safety deterministiche. Per i leader enterprise che navigano questa transizione, la distinzione non è più meramente accademica. Man mano che i sistemi autonomi si spostano dagli ambienti digitali a dispiegamenti fisici ad alto rischio, i limiti degli approcci probabilistici «basati su wrapper» sono stati esposti da una serie di fallimenti di alto profilo.

Gli incidenti che coinvolgono Uber Advanced Technologies Group (ATG), GM Cruise, Tesla e Waymo costituiscono dati empirici critici per questa analisi. Questi eventi rappresentano più di incidenti isolati; sono indicatori sistemici di fragilità architetturale. L'accordo transattivo da $8.5 million che ha coinvolto Uber ATG dopo il decesso di Tempe del 2018, la revoca del permesso operativo in California di GM Cruise nel 2023 e le indagini in corso della National Highway Traffic Safety Administration (NHTSA) sul sistema Full Self-Driving (FSD) di Tesla sono tutti sintomi di un «divario Percezione-Logica».¹ Questo rapporto analizza questi fallimenti per stabilire un nuovo paradigma per l'IA safety-critical—uno che posiziona Veriprajna non come facilitatore di interfacce stocastiche, ma come fornitore di autonomia profonda e verificabile.

La fragilità architetturale della percezione stocastica: lezioni da Uber ATG

La collisione del marzo 2018 a Tempe, in Arizona, che ha coinvolto un veicolo di test Uber ATG, resta il caso di studio fondativo sulla fragilità della classificazione. Mentre la narrazione dell'epoca si concentrava pesantemente sulla distrazione dell'operatore umano di safety, i riscontri del National Transportation Safety Board (NTSB) hanno rivelato un fallimento ben più profondo nella capacità del software di mantenere una rappresentazione stabile del mondo fisico.³

Oscillazione di classificazione e fallimento della permanenza dell'oggetto

Il sistema Uber ATG ha registrato per la prima volta il pedone, Elaine Herzberg, circa 5.6 secondi prima dell'impatto.⁵ A una velocità di 43 mph, il veicolo distava quasi 378 feet, offrendo una finestra ampia perché un sistema Automatic Emergency Braking (AEB) standard intervenisse.⁷ Tuttavia, la logica di percezione del sistema era caratterizzata da «oscillazione di classificazione». Nei secondi che hanno preceduto lo scontro, il software ha ripetutamente riclassificato il pedone—prima come «oggetto sconosciuto», poi come «veicolo» e infine come «bicicletta».⁶

Ogni riclassificazione non era meramente un cambio di etichetta; era un reset della traiettoria predetta dell'oggetto. Nei sistemi probabilistici privi di consistenza temporale, l'IA tratta ogni frame o cluster di frame come un evento quasi indipendente. Poiché il sistema non riusciva a fissare un'identità persistente per l'oggetto, non poteva calcolare una predizione di percorso affidabile finché non è stato troppo tardi. Il sistema ha determinato che era necessaria una frenata di emergenza solo 1.3 secondi prima dell'impatto—un punto in cui le leggi della fisica rendevano una collisione inevitabile.³

Debito tecnico e rimozione della ridondanza di safety

Un elemento critico del fallimento di Uber ATG è stata la disattivazione intenzionale dei sistemi di safety nativi del veicolo. Per prevenire un «comportamento erratico del veicolo» e offrire una guida più fluida al sistema autonomo, Uber aveva disabilitato le funzioni di collision avoidance e AEB installate di fabbrica sulla Volvo XC90.⁴ Il team di ingegneria ha scelto di affidarsi interamente a un sistema proprietario, in fase di sviluppo, che non era ancora verificato per un intervento ad alta confidenza.

Componente di fallimento	Meccanismo tecnico	Implicazione strategica
Pipeline di percezione	Oscillazione di classificazione (Sconosciuto -> Veicolo -> Bici)	La perdita della permanenza dell'oggetto disabilita la predizione di percorso.6
Soppressione della logica	Disattivazione manuale dell'AEB di fabbrica Volvo	Rimozione degli strati di safety hard-coded a favore di codice sperimentale.4
Interfaccia HMI	Eccessivo affidamento su un monitor umano distratto	Mancata considerazione della «compiacenza da automazione».3
Motore di predizione	Assunzione di traiettoria statica per attori dinamici	Incapacità di modellare gli attraversamenti pedonali non standard.5

Questo processo decisionale illustra una tendenza pericolosa nello sviluppo dell'IA: il sacrificio degli strati di safety deterministici in nome di prestazioni «fluide» in un modello stocastico. L'accordo transattivo da $8.5 million per lo scontro del 2018 riflette non solo una responsabilità legale, ma un fallimento nel gestire i «limiti funzionali» del sistema di guida automatizzata.⁴ L'ingegneria Deep AI, come sostenuta da Veriprajna, si oppone a questa gerarchia, sostenendo un'architettura «Safety-First» in cui lo strato di percezione è vincolato da vincoli formali che non possono essere sovrascritti da una policy sperimentale.

Diagnosi errata e fallimento della logica post-impatto: la crisi Cruise del 2023

Nell'ottobre 2023, un robotaxi GM Cruise a San Francisco ha urtato e trascinato un pedone per 20 feet, portando alla sospensione totale delle operazioni driverless dell'azienda in California.⁹ Questo incidente è andato oltre il problema della prevenzione iniziale della collisione, entrando nel territorio del «ragionamento post-impatto»—un dominio in cui i tipici wrapper LLM e le semplici API di percezione falliscono del tutto.

L'equivoco front-runover vs. impatto laterale

L'incidente Cruise è stato innescato da una terza parte: una Nissan guidata da un essere umano ha colpito un pedone, lanciandola sulla traiettoria del veicolo Cruise.⁹ L'auto Cruise ha colpito il pedone e si è inizialmente fermata. Tuttavia, poiché la logica di «rilevamento dell'impatto» del sistema era insufficientemente granulare, ha diagnosticato in modo errato la collisione. Nonostante il pedone fosse bloccato sotto il veicolo, i sensori del sistema non hanno riconosciuto un front-runover e hanno invece classificato l'evento come una collisione da impatto laterale.¹

Questa diagnosi errata ha innescato una manovra pre-programmata di «Minimal Risk Condition» (MRC). Il sistema era progettato per accostare a lato della strada dopo un impatto laterale per evitare di bloccare il traffico.¹¹ Poiché lo strato di percezione aveva «dimenticato» il pedone dopo l'impatto, il veicolo ha iniziato ad accostare, trascinando la vittima per 20 feet a circa 7 mph.⁹ Il trascinamento è cessato solo quando il veicolo ha rilevato uno «slip eccessivo delle ruote», che ha interpretato come un guasto meccanico piuttosto che come un'ostruzione umana.¹¹

La trasparenza come requisito tecnico

Il fallimento di Cruise è stato tanto organizzativo quanto tecnico. Le indagini hanno rivelato che la leadership senior era «fissata sul correggere la narrazione mediatica inaccurata» e non è stata trasparente con i regolatori riguardo al trascinamento.⁹ I dipendenti di Cruise hanno ammesso di «lasciare che il video parlasse da sé» durante le riunioni con il DMV, sapendo che i problemi di connettività internet spesso impedivano la riproduzione della porzione di «trascinamento» del video.⁹

Questo evidenzia una lezione critica per la consulenza Deep AI: la safety di un sistema autonomo è inseparabile dalla sua trasparenza. L'approccio di Veriprajna enfatizza lo sviluppo di «Explainable Safety Audit», in cui ogni decisione presa dall'IA, soprattutto post-impatto, è registrata in un formato deterministico a prova di manomissione che può essere auditato dai regolatori in tempo reale. La successiva multa penale da $500,000 per aver presentato rapporti falsi alla NHTSA sottolinea l'alto costo di trattare la safety dell'IA come un problema di marketing piuttosto che come un problema di ingegneria.¹

Il dilemma «Vision-Only» e i limiti del sensing probabilistico: Tesla FSD

Il sistema Full Self-Driving (FSD) di Tesla è diventato il centro di una massiccia indagine regolatoria, con la NHTSA che ha aperto oltre 40 inchieste su scontri tra il 2024 e il 2025.² Queste indagini, in particolare quelle identificate come PE24-031 e PE25-012, si concentrano sul fallimento del sistema nel «Capability Theater»—prestazioni ottimali in condizioni limpide che collassano di fronte agli «edge case» ambientali.¹³

Sensibilità ambientale e non conformità ai segnali

Le indagini della NHTSA hanno identificato pattern specifici in cui il sistema vision-only di Tesla non rispetta le leggi di base sulla sicurezza stradale:

1. Guasto ai semafori: In 18 reclami distinti, i veicoli con FSD abilitato non sono rimasti fermi ai semafori rossi oppure non hanno rilevato del tutto lo stato del segnale.¹²
2. Manovre contromano: Il sistema è stato osservato entrare in corsie di traffico opposte o eseguire svolte da corsie di solo transito, ignorando segnaletica e demarcazioni stradali chiare.²
3. Saturazione in bassa visibilità: Una collisione fatale significativa nel 2023 è avvenuta in uno stato di «abbagliamento solare su asfalto bagnato», in cui il sistema non è riuscito a rilevare un pedone.¹⁴

L'affidamento di Tesla a un'architettura «Vision-Only»—che esclude LiDAR e radar—crea una vulnerabilità fondamentale alla «saturazione dei sensori». In condizioni di nebbia, polvere o detriti in aria, il rapporto segnale-rumore ottico scende al di sotto della soglia richiesta per una navigazione sicura.¹³ Sebbene Tesla utilizzi «Occupancy Network» per predire la geometria 3D del mondo a partire da immagini 2D, i rapporti NHTSA suggeriscono che queste predizioni siano ancora troppo probabilistiche per essere usate come strato primario di safety.¹⁵

Formalizzare l'ambiente di guida

Per andare oltre il modello di fallimento Tesla, l'ingegneria Deep AI utilizza «Hazard-Driven Envelope». Invece di «feature» vaghe, il sistema deve definire Operational Design Domain (ODD) espliciti. Se la «percentuale di saturazione da abbagliamento» o l'«indice di backscatter da nebbia» supera una soglia verificata, il sistema deve avviare una transizione fail-safe.¹⁴

Modo di fallimento indagato	Frequenza/impatto	Causa tecnica
Non conformità al semaforo rosso	18+ reclami	Fallimento del rilevamento dello stato del segnale nello stack vision.12
Violazione della segnaletica di corsia	4+ report SGO	Incapacità di distinguere corsie di sola svolta vs. corsie di transito.12
Scontro in bassa visibilità	Decessi (2023-2024)	Saturazione dei sensori ottici (abbagliamento/nebbia/polvere).13
Ingresso in corsia opposta	2 report SGO	Fallimento nella ricostruzione 3D della geometria delle corsie.12

La filosofia di Veriprajna è che l'autonomia non può essere costruita su software «best-effort». I 2.9 million veicoli coinvolti dall'indagine NHTSA del 2025 rappresentano un rischio a livello di flotta che può essere mitigato solo attraverso l'implementazione di «Assurance Gate»—blocchi software che impediscono all'IA di prendere decisioni ad alto rischio quando il livello di confidenza del suo sistema di percezione scende al di sotto di un punto deterministico.²

Gridlock multi-agente e resilienza socio-tecnica: l'esperienza Waymo

Waymo è spesso considerato il benchmark per la safety, avendo registrato oltre 56 million miles con tassi di infortunio significativamente inferiori rispetto ai conducenti umani.¹⁷ Tuttavia, man mano che il sistema scala, ha incontrato una nuova classe di fallimento: l'«attrito socio-tecnico». Questo riguarda non solo come guida l'IA, ma come interagisce con l'ambiente sociale umano, complesso e spesso ostile.

Blocchi agli incroci e fallimenti di comunicazione

Durante un blackout del 2025 a Los Angeles, dozzine di robotaxi Waymo sono rimasti bloccati in una serie di incroci oscurati. Il «Waymo Driver», programmato per trattare i segnali spenti come stop a quattro vie, è stato sopraffatto dal picco concentrato di richieste di «Remote Assistance».¹⁸ Poiché i veicoli non erano in grado di comunicare efficacemente tra loro, sono entrati in uno stato di «gridlock multi-agente», in cui i robotaxi bloccavano altri robotaxi, creando una coda che il centro di comando centrale non poteva risolvere.¹⁸

Questo fallimento evidenzia la «trappola dell'indipendenza»—l'assunzione che un veicolo autonomo possa operare in sicurezza come agente solitario senza un sistema più ampio e coordinato.¹⁸ L'ingegneria Deep AI deve tenere conto della perdita della comunicazione wireless e della necessità di protocolli «V2V» (Vehicle-to-Vehicle) e «V2I» (Vehicle-to-Infrastructure) che consentano alla flotta di risolvere gli stalli in modo autonomo.²⁰

La necessità di una «Danger Escape Mode»

Forse la minaccia emergente più significativa per le operazioni autonome è l'aggressione pubblica. All'inizio del 2025, diversi veicoli Waymo sono stati attaccati da folle durante disordini civili a Los Angeles, con manifestanti che tagliavano pneumatici e davano fuoco ai veicoli.²¹ I veicoli, programmati per la «safety passiva», si sono semplicemente fermati quando circondati da persone.

Ciò ha portato alla proposta di sviluppo di una «Danger Escape Mode». Un tale sistema userebbe la suite di sensori a 360 gradi per rilevare «aggressione umana malevola» e spostare la direttiva del veicolo da «conformità passiva» a «fuga attiva».²¹ Sebbene il veicolo non debba mai essere programmato per causare danno, i fornitori di Deep AI sostengono che dovrebbe essere capace di commettere infrazioni stradali minori (come salire su un marciapiede o attraversare con il rosso) per proteggere i passeggeri e fuggire da una situazione volatile.²¹ Ciò richiede un ripensamento radicale dell'«Ethics Engine» dell'IA—un compito che va ben oltre le capacità di un wrapper LLM.

La soluzione tecnica: Bird's-Eye-View (BEV) e Occupancy Network

Per affrontare i fallimenti di tracking visti nei casi Uber e Cruise, l'industria si sta orientando verso la percezione Bird's-Eye-View (BEV). I sistemi standard per-camera elaborano immagini individuali, il che porta a perdita di dati durante lo «stitching». Al contrario, la percezione BEV trasforma i dati multi-view di camere e LiDAR in una griglia 3D unificata, vista dall'alto.²²

Occupancy Network vs. sensor fusion standard

La sensor fusion tradizionale tenta di «abbinare» pixel 2D a punti 3D, un processo computazionalmente costoso e soggetto a errori di proiezione. Veriprajna sostiene le «Occupancy Network»—un'architettura che predice la «probabilità di occupancy» di ogni voxel in un volume 3D.¹⁶

1. Permanenza dell'oggetto: Poiché le Occupancy Network tracciano il volume piuttosto che le sole «etichette», il sistema sa che uno spazio è occupato anche se non riesce a decidere se l'oggetto è un pedone o una bicicletta. Questo avrebbe prevenuto il flip di classificazione di Uber ATG.¹⁶
2. Fedeltà geometrica: Le Occupancy Network catturano strutture verticali e detriti stradali spesso ignorati dalle mappe BEV 2D. Questo avrebbe consentito al veicolo Cruise di «vedere» il pedone sotto il telaio durante la manovra post-impatto.¹⁶
3. Consistenza spazio-temporale: Usando architetture «BEVFormer», il sistema può usare la «temporal self-attention» per ricordare dove si trovava un oggetto anche durante occlusioni temporanee (ad es., un pedone che cammina dietro un camion parcheggiato).²⁴

$$X_{BEV} = f_{transformer}(I_1, I_2, ..., I_n, L_{cloud})$$

In questo modello, l'architettura Transformer non serve come strumento conversazionale, ma come motore di ragionamento spaziale che fonde dati eterogenei in una «Shared Canvas» singolare.²³ Questa è ingegneria Deep AI: l'uso di architetture di frontiera per risolvere problemi di fisica fondamentali nella navigazione.

Verifica formale: lo standard Veriprajna per l'IA ad alta assurance

Il differenziatore più significativo tra un «wrapper» e una «soluzione» è l'applicazione dei metodi formali. Il collaudo software tradizionale si affida a scenari «black-box»; se il sistema supera N test, si assume che sia sicuro. Nei sistemi safety-critical, tuttavia, richiediamo una prova matematica di correttezza.

Solver SMT e ragionamento a livello di rete

Strumenti come Marabou e α,β-CROWN consentono agli ingegneri di verificare le proprietà delle reti neurali profonde. Rappresentando la rete come un insieme di vincoli piecewise-linear, possiamo determinare se esiste qualsiasi input che potrebbe portare a un output non sicuro.²⁵

Una «Safety Property» potrebbe essere definita come segue:

Per tutti gli input x nell'intervallo di «Low Visibility», l'output y (comando di frenata) non deve mai essere inferiore a k.

$$\forall x \in X_{fog} \Rightarrow f(x) \geq Braking_{min}$$

Se un solver SMT come Marabou restituisce un «controesempio», ha identificato una perturbazione specifica, spesso impercettibile, che causerebbe il fallimento dell'IA. Questo consente a Veriprajna di «indurire» il modello durante la fase di training, un processo noto come «verification-aware training».²⁸

Pruning per la verificabilità

Una sfida maggiore nella verifica formale è la «maledizione della dimensionalità». Le reti grandi sono troppo complesse perché i solver attuali le analizzino in modo esaustivo. Veriprajna affronta questo tramite il «Neuron Pruning». Rimuovendo neuroni ridondanti e non-linearità che non contribuiscono all'accuratezza del modello, produciamo un «Pruned Model» che è matematicamente più facile da verificare senza sacrificare le prestazioni.²⁹

Tecnica di verifica	Metodologia	Beneficio
Bound Tightening	Analisi simbolica dei range di attivazione dei neuroni	Riduce lo spazio di ricerca per i solver SMT.25
Analisi di raggiungibilità	Calcolo dell'insieme di tutti gli output raggiungibili per un insieme di input	Garantisce che l'IA resterà all'interno di un «Safe Polytope».28
Approssimazione piecewise-linear	Sostituzione di attivazioni complesse con segmenti basati su ReLU	Abilita prove di verifica corrette e complete.27
Filtro formale di safety	Monitoraggio runtime dei comandi dell'IA rispetto a una baseline verificata	Fornisce un «Safe Recovery» se l'IA principale si comporta in modo irrazionale.31

L'orizzonte regolatorio: SOTIF e ISO/PAS 8800

Per le enterprise, la conformità agli standard internazionali emergenti non è più opzionale. Il panorama è passato dall'«autovalutazione volontaria» all'adesione obbligatoria a un framework di safety a livelli.⁵

ISO 26262 vs. ISO 21448 (SOTIF)

Mentre ISO 26262 gestisce la «Functional Safety» (ad es., un sensore che si guasta o un chip in cortocircuito), non può coprire i limiti inerenti dell'IA.³⁴ Questo vuoto è colmato da ISO 21448, lo standard per la «Safety of the Intended Functionality» (SOTIF). SOTIF è progettato specificamente per affrontare i pericoli che si verificano quando il sistema funziona esattamente come programmato ma incontra un ambiente «Unknown/Unsafe».³⁴

L'obiettivo di un engagement Veriprajna è massimizzare il quadrante «Known/Safe» del sistema di IA di un cliente. Questo comporta:

1. Analisi dei pericoli e dei rischi (HARA): Identificare rischi non da guasto come l'errata interpretazione dei sensori sotto pioggia intensa.³⁶
2. Identificazione delle condizioni di innesco: Mappare in modo sistematico gli stati ambientali che portano a errori di percezione.³⁶
3. V&V (Verification and Validation): Usare simulazioni ad alta fedeltà per «iniettare» edge case che sarebbero troppo pericolosi da testare su strade pubbliche.³⁶

ISO/PAS 8800: il futuro dell'integrazione dell'IA

A fine 2024, ISO/PAS 8800 è diventato lo standard primario per la «Functional Safety for AI in Road Vehicles».³⁷ Fornisce le prime linee guida globali per gestire il ciclo di vita dell'IA, dall'«acquisizione dei dati» al «monitoraggio post-dispiegamento».³³ Veriprajna assicura che le architetture dei nostri clienti non siano solo conformi, ma «a prova di futuro» rispetto al crescente rigore degli standard globali di governance dell'IA come l'EU AI Act e il NIST AI Risk Management Framework.³³

Il percorso strategico: il mandato Deep AI di Veriprajna

La transizione da una cultura «Wrapper» a una cultura «Deep AI» è un viaggio dalla speranza probabilistica alla garanzia deterministica. L'accordo transattivo da $8.5 million di Uber, la sospensione di Cruise e le 40+ indagini Tesla non sono ragioni per abbandonare l'IA; sono ragioni per ingegnerizzarla correttamente.

Il modello di consulenza di Veriprajna è costruito su tre pilastri che affrontano i modi di fallimento specifici identificati in questo rapporto:

1. Resilienza della percezione: Spostare i clienti dalla percezione 2D per-camera a Occupancy Network BEV basate su Transformer per assicurare permanenza dell'oggetto e stabilità del tracking.¹⁶
2. Decisioning verificato: Implementare la verifica formale basata su SMT per dimostrare che le architetture di controllo guidate dall'IA non violeranno mai le proprietà di safety fondamentali.²⁵
3. Indurimento socio-tecnico: Sviluppare «Escape Mode» sofisticate e framework di comunicazione V2X per gestire la realtà dei disordini civili e del gridlock multi-agente.¹⁸

Man mano che il costo globale di una singola violazione dei dati raggiunge $4.44 million e il costo di un decesso autonomo entra nelle decine di milioni in danni legali e operativi, il wrapper «economico» diventa l'errore più costoso che un'impresa possa commettere.¹⁴ Veriprajna fornisce le competenze di ingegneria profonda richieste per costruire IA che non si limita a funzionare in laboratorio—resiste nel mondo.

La scelta per l'impresa moderna è chiara: continuare ad avvolgere black box probabilistiche e gestire le conseguenze inevitabili, oppure collaborare con Veriprajna per architettare un futuro di autonomia verificabile e ad alta assurance. L'era dell'IA stocastica sta finendo; l'era dell'ingegneria Deep AI è iniziata.

Opere citate

1. Cruise Admits To Submitting A False Report To Influence A Federal Investigation And Agrees To Pay $500000 - Department of Justice, consultato il 9 febbraio 2026, https://www.justice.gov/usao-ndca/pr/cruise-admits-submitting-false-report-influence-federal-investigation-and-agrees-pay
2. NHTSA Opens Probe into 2.9M Teslas Over FSD Violations - Autobody News, consultato il 9 febbraio 2026, https://www.autobodynews.com/news/nhtsa-opens-probe-into-2-9m-teslas-over-fsd-violations
3. HWY18MH010.aspx - NTSB, consultato il 9 febbraio 2026, https://www.ntsb.gov/investigations/Pages/HWY18MH010.aspx
4. NTSB Shares Investigation Findings and Recommendations Regarding March 2018 Uber ATG Fatality | Eckert Seamans, consultato il 9 febbraio 2026, https://www.eckertseamans.com/legal-updates/ntsb-shares-investigation-findings-and-recommendations-regarding-march-2018-uber-atg-fatality
5. H-19-047 - Accident Data - NTSB, consultato il 9 febbraio 2026, https://data.ntsb.gov/carol-main-public/sr-details/H-19-047
6. NTSB releases preliminary report on fatal Uber self-driving car crash - Metro Magazine, consultato il 9 febbraio 2026, https://www.metro-magazine.com/news/ntsb-releases-preliminary-report-on-fatal-uber-self-driving-car-crash
7. Death of Elaine Herzberg - Wikipedia, consultato il 9 febbraio 2026, https://en.wikipedia.org/wiki/Death_of_Elaine_Herzberg
8. New Details Emerge Regarding Uber Self-Driving Vehicle Accident in Tempe, Arizona, consultato il 9 febbraio 2026, https://schwedlawfirm.com/blog/new-details-emerge-regarding-uber-self-driving-vehicle-accident/
9. A Root Cause Analysis of a Self-Driving Car Dragging a Pedestrian, consultato il 9 febbraio 2026, https://www.computer.org/csdl/magazine/co/2024/11/10720344/215PD0vqgTe
10. Notes on Cruise's pedestrian accident - Dan Luu, consultato il 9 febbraio 2026, https://danluu.com/cruise-report/
11. Lessons from the Cruise Robotaxi Pedestrian Dragging Mishap, consultato il 9 febbraio 2026, http://users.ece.cmu.edu/~koopman/pubs/Koopman2024_CruiseMishap_IEEEReliabilityMagazine.pdf
12. Office of Defects Investigation (ODI) Resume - nhtsa, consultato il 9 febbraio 2026, https://static.nhtsa.gov/odi/inv/2025/INOA-PE25012-19171.pdf
13. US regulators launch investigation into self-driving Teslas after series of crashes, consultato il 9 febbraio 2026, https://www.theguardian.com/technology/2025/oct/09/tesla-cars-self-driving-us-regulators-investigation
14. Tesla FSD Safety Issues: NHTSA Probes & AI Driving Future (Part 6) - PRIZ Guru, consultato il 9 febbraio 2026, https://www.priz.guru/tesla-fsd-safety-issues-nhtsa-probes-ai-driving-future-part-6/
15. AI & Robotics | Tesla, consultato il 9 febbraio 2026, https://www.tesla.com/AI
16. A Survey on Occupancy Perception for Autonomous Driving: The Information Fusion Perspective - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2405.05173v2
17. New Study: Waymo is reducing serious crashes and making streets safer for those most at risk, consultato il 9 febbraio 2026, https://waymo.com/blog/2025/05/waymo-making-streets-safer-for-vru
18. On Waymo's Traffic Jams - Stanford Center for Internet and Society, consultato il 9 febbraio 2026, https://cyberlaw.stanford.edu/blog/2025/12/on-waymos-traffic-jams/
19. Self-driving cars may create more traffic congestion than they solve, expert says - KJZZ, consultato il 9 febbraio 2026, https://www.kjzz.org/the-show/2026-01-07/self-driving-cars-may-create-more-traffic-congestion-than-they-solve-expert-says
20. A Systematic Literature Review on Vehicular Collaborative Perception – A Computer Vision Perspective - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2504.04631v2
21. When Robotaxis Get Attacked: Do Waymo Cars Need a 'Danger Escape Mode'?, consultato il 9 febbraio 2026, https://aragonresearch.com/robotaxis-attack-waymo-cars-danger-escape-mode/
22. MIC-BEV: Multi-Infrastructure Camera Bird's-Eye-View Transformer with Relation-Aware Fusion for 3D Object Detection - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2510.24688v1
23. [AV Vol.3] BEVFusion: Unifying Vision in Autonomous Driving Systems - Medium, consultato il 9 febbraio 2026, https://medium.com/demistify/av-vol-3-bevfusion-unifying-vision-in-autonomous-driving-systems-b2190f877c9b
24. A Transformer-based Temporal Feature Fusion Approach for Autonomous Driving BEV Perception | Request PDF - ResearchGate, consultato il 9 febbraio 2026, https://www.researchgate.net/publication/395804054_A_Transformer-based_Temporal_Feature_Fusion_Approach_for_Autonomous_Driving_BEV_Perception
25. The Marabou Framework for Verification and Analysis of Deep Neural Networks - Stanford Center for AI Safety, consultato il 9 febbraio 2026, https://aisafety.stanford.edu/marabou/MarabouCAV2019.pdf
26. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - arXiv, consultato il 9 febbraio 2026, https://arxiv.org/html/2401.14461v1
27. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - Stanford CS Theory, consultato il 9 febbraio 2026, https://theory.stanford.edu/~barrett/pubs/WIZ+24.pdf
28. Creating a Formally Verified Neural Network for Autonomous Navigation: An Experience Report - CSE CGI Server, consultato il 9 febbraio 2026, https://cgi.cse.unsw.edu.au/~eptcs/paper.cgi?FMAS2024.12.pdf
29. Verification of Neural Networks for Safety and Security-critical Domains - CEUR-WS.org, consultato il 9 febbraio 2026, https://ceur-ws.org/Vol-3345/paper10_RiCeRCa3.pdf
30. Formal Verification of Neural Networks for Safety-Critical Tasks in Deep Reinforcement Learning, consultato il 9 febbraio 2026, https://proceedings.mlr.press/v161/corsi21a/corsi21a.pdf
31. Formal Methods for Trustworthy AI-based Autonomous Systems - NII Shonan Meeting, consultato il 9 febbraio 2026, https://shonan.nii.ac.jp/docs/No.178.pdf
32. Formal Verification of Neural Networks-Based Control Architecture for Safety-Critical Autonomous Systems - Frontiers, consultato il 9 febbraio 2026, https://www.frontiersin.org/research-topics/74336/formal-verification-of-neural-networks-based-control-architecture-for-safety-critical-autonomous-systems
33. Implementing Responsible AI for Automotive Vehicle Safety - LHP Engineering Solutions, consultato il 9 febbraio 2026, https://www.lhpes.com/blog/implementing-responsible-ai-for-automotive-vehicle-safety
34. Functional Safety vs. SOTIF: What Is the Difference and Where Do They Overlap? - MES, consultato il 9 febbraio 2026, https://model-engineers.com/en/blog/functional-safety-vs-sotif-differences-overlaps/
35. The Necessity of a Holistic Safety Evaluation Framework for AI-Based Automation Features, consultato il 9 febbraio 2026, https://arxiv.org/html/2602.05157v1
36. What is SOTIF? (ISO 21448) - Visure Solutions, consultato il 9 febbraio 2026, https://visuresolutions.com/automotive/iso-21448/
37. Safety-Related Systems in Road Vehicles with Artificial Intelligence Are Addressed in ISO/PAS 8800:2024 | UL Solutions, consultato il 9 febbraio 2026, https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024
38. ISO 26262, SOTIF and simulation | Applied Intuition, consultato il 9 febbraio 2026, https://www.appliedintuition.com/blog/iso26262-sotif-simulation
39. Introducing ISO/PAS 8800 – Functional Safety for AI in Road Vehicles | SGS Georgia, consultato il 9 febbraio 2026, https://www.sgs.com/en-ge/news/2025/04/safeguards-04625-introducing-iso-pas-8800-functional-safety-for-ai-in-road-vehicles
40. NIST vs ISO - Compare AI Frameworks - ModelOp, consultato il 9 febbraio 2026, https://www.modelop.com/ai-governance/ai-regulations-standards/nist-vs-iso
41. AI Safety vs AI Security in LLM Applications: What Teams Must Know - Promptfoo, consultato il 9 febbraio 2026, https://www.promptfoo.dev/blog/ai-safety-vs-security/