Des modèles stochastiques à l'assurance déterministe : un cadre stratégique pour l'intelligence artificielle critique pour la sécurité

Le paysage contemporain de l'intelligence artificielle est actuellement scindé par une mécompréhension fondamentale de la profondeur technique. D'un côté de cette fracture se trouve la prolifération rapide des couches d'interface générative — souvent caractérisées comme des « wrappers » de grands modèles de langage (LLM) — qui privilégient le déploiement rapide et la fluidité conversationnelle. De l'autre côté se trouve la discipline rigoureuse de l'ingénierie d'IA profonde, un domaine défini par l'intégration de la vérification formelle, de la résilience de la fusion de capteurs et d'architectures de sécurité déterministes. Pour les dirigeants d'entreprise qui naviguent dans cette transition, la distinction n'est plus simplement académique. À mesure que les systèmes autonomes passent des environnements numériques aux déploiements physiques à fort enjeu, les limites des approches probabilistes « basées sur des wrappers » ont été exposées par une série de défaillances très médiatisées.

Les incidents impliquant Uber Advanced Technologies Group (ATG), GM Cruise, Tesla et Waymo constituent des données empiriques critiques pour cette analyse. Ces événements représentent davantage que des accidents isolés ; ce sont des indicateurs systémiques de fragilité architecturale. Le règlement de $8.5 million impliquant Uber ATG après le décès de Tempe en 2018, la révocation du permis d'exploitation californien de GM Cruise en 2023, et les enquêtes en cours de la National Highway Traffic Safety Administration (NHTSA) sur le système Full Self-Driving (FSD) de Tesla sont autant de symptômes d'un « écart perception-logique ».¹ Ce rapport analyse ces défaillances afin d'établir un nouveau paradigme pour l'IA critique pour la sécurité — un paradigme qui positionne Veriprajna non pas comme un facilitateur d'interfaces stochastiques, mais comme un fournisseur d'autonomie profonde et vérifiable.

La fragilité architecturale de la perception stochastique : leçons d'Uber ATG

La collision de mars 2018 à Tempe, en Arizona, impliquant un véhicule d'essai Uber ATG, demeure l'étude de cas fondatrice de la fragilité de classification. Alors que le récit de l'époque s'est fortement concentré sur la distraction de l'opérateur de sécurité humain, les conclusions du National Transportation Safety Board (NTSB) ont révélé une défaillance bien plus profonde dans la capacité du logiciel à maintenir une représentation stable du monde physique.³

Oscillation de classification et défaillance de la permanence de l'objet

Le système Uber ATG a d'abord enregistré la piétonne, Elaine Herzberg, approximativement 5.6 secondes avant l'impact.⁵ À une vitesse de 43 mph, le véhicule se trouvait à près de 378 feet, offrant une fenêtre amplement suffisante pour qu'un système de freinage d'urgence automatique (AEB) standard intervienne.⁷ Cependant, la logique de perception du système était caractérisée par une « oscillation de classification ». Dans les secondes précédant l'accident, le logiciel a reclassé à plusieurs reprises la piétonne — d'abord comme un « objet inconnu », puis comme un « véhicule », et enfin comme un « vélo ».⁶

Chaque reclassification n'était pas simplement un changement d'étiquette ; c'était une réinitialisation de la trajectoire prédite de l'objet. Dans les systèmes probabilistes dépourvus de consistance temporelle, l'IA traite chaque image ou groupe d'images comme un événement quasi indépendant. Parce que le système ne pouvait pas se fixer sur une identité persistante de l'objet, il n'a pas pu calculer une prédiction de trajectoire fiable avant qu'il ne soit trop tard. Le système a déterminé que le freinage d'urgence était nécessaire seulement 1.3 secondes avant l'impact — un point auquel les lois de la physique rendaient une collision inévitable.³

Dette technique et suppression de la redondance de sécurité

Un élément critique de la défaillance d'Uber ATG a été la désactivation intentionnelle des systèmes de sécurité natifs du véhicule. Pour prévenir un « comportement erratique du véhicule » et offrir une conduite plus fluide au système autonome, Uber avait désactivé les fonctions d'évitement de collision et d'AEB installées en usine sur le Volvo XC90.⁴ L'équipe d'ingénierie a choisi de s'appuyer entièrement sur un système propriétaire, encore en développement, qui n'était pas encore vérifié pour une intervention à haut niveau de confiance.

Composant de défaillance	Mécanisme technique	Implication stratégique
Pipeline de perception	Oscillation de classification (Unknown -> Vehicle -> Bike)	La perte de permanence de l'objet désactive la prédiction de trajectoire.6
Suppression de la logique	Désactivation manuelle de l'AEB d'usine Volvo	Suppression des couches de sécurité codées en dur au profit d'un code expérimental.4
Interface HMI	Surdépendance à un moniteur humain distrait	Échec à prendre en compte la « complaisance d'automatisation ».3
Moteur de prédiction	Hypothèse de trajectoire statique pour des acteurs dynamiques	Incapacité à modéliser les traversées piétonnes non standard.5

Ce processus décisionnel illustre une tendance dangereuse dans le développement de l'IA : le sacrifice des couches de sécurité déterministes au nom d'une performance « fluide » dans un modèle stochastique. Le règlement de $8.5 million pour l'accident de 2018 reflète non seulement une responsabilité juridique, mais un échec à gérer les « limitations fonctionnelles » du système de conduite automatisé.⁴ L'ingénierie d'IA profonde, telle que défendue par Veriprajna, s'oppose à cette hiérarchie, plaidant pour une architecture « Safety-First » où la couche de perception est liée par des contraintes formelles qui ne peuvent pas être outrepassées par une politique expérimentale.

Erreur de diagnostic et défaillance de la logique post-impact : la crise Cruise de 2023

En octobre 2023, un robotaxi GM Cruise à San Francisco a percuté et traîné une piétonne sur 20 feet, entraînant une suspension totale des opérations sans conducteur de l'entreprise en Californie.⁹ Cet incident a dépassé le problème de l'évitement initial de collision pour entrer dans le domaine du « raisonnement post-impact » — un domaine où les wrappers LLM typiques et les API de perception simples échouent entièrement.

Le sophisme du passage par-dessus frontal vs. l'impact latéral

L'incident Cruise a été déclenché par un tiers : un Nissan conduit par un humain a percuté une piétonne, la projetant sur la trajectoire du véhicule Cruise.⁹ La voiture Cruise a percuté la piétonne et s'est d'abord arrêtée. Cependant, parce que la logique de « détection d'impact » du système n'était pas suffisamment granulaire, elle a mal diagnostiqué la collision. Bien que la piétonne fût coincée sous le véhicule, les capteurs du système n'ont pas reconnu un passage par-dessus frontal et ont plutôt classé l'événement comme une collision par impact latéral.¹

Ce mauvais diagnostic a déclenché une manœuvre préprogrammée de « condition de risque minimal » (MRC). Le système était conçu pour se ranger sur le côté de la route après un impact latéral afin d'éviter de bloquer la circulation.¹¹ Parce que la couche de perception avait « oublié » la piétonne après l'impact, le véhicule a commencé à se ranger, traînant la victime sur 20 feet à approximativement 7 mph.⁹ Le traînage n'a cessé que lorsque le véhicule a détecté un « patinage excessif des roues », qu'il a interprété comme une panne mécanique plutôt que comme une obstruction humaine.¹¹

La transparence comme exigence technique

La défaillance de Cruise était autant organisationnelle que technique. Les enquêtes ont révélé que la direction senior était « fixée sur la correction du récit médiatique inexact » et n'a pas fait preuve de transparence vis-à-vis des régulateurs concernant le traînage.⁹ Des employés de Cruise ont admis avoir « laissé la vidéo parler d'elle-même » lors de réunions avec le DMV, sachant que des problèmes de connectivité Internet empêchaient souvent la portion « traînage » de la vidéo d'être lue.⁹

Cela met en lumière une leçon critique pour le conseil en IA profonde : la sécurité d'un système autonome est indissociable de sa transparence. L'approche de Veriprajna met l'accent sur le développement d'« audits de sécurité explicables », où chaque décision prise par l'IA, surtout post-impact, est consignée dans un format déterministe infalsifiable, auditable par les régulateurs en temps réel. L'amende pénale de $500,000 ultérieure pour avoir soumis de faux rapports à la NHTSA souligne le coût élevé de traiter la sécurité de l'IA comme un problème de marketing plutôt que d'ingénierie.¹

Le dilemme « Vision-Only » et les limites de la détection probabiliste : Tesla FSD

Le système Full Self-Driving (FSD) de Tesla est devenu le centre d'une enquête réglementaire massive, la NHTSA ouvrant plus de 40 enquêtes sur des accidents entre 2024 et 2025.² Ces enquêtes, en particulier celles identifiées comme PE24-031 et PE25-012, portent sur la défaillance du système dans le « théâtre des capacités » — une performance optimale dans des conditions claires qui s'effondre face aux « cas limites » environnementaux.¹³

Sensibilité environnementale et non-conformité aux signaux

Les enquêtes de la NHTSA ont identifié des schémas spécifiques où le système vision-uniquement de Tesla ne se conforme pas aux lois élémentaires de sécurité routière :

1. Défaillance aux feux de circulation : Dans 18 plaintes distinctes, des véhicules équipés de FSD ne sont pas restés à l'arrêt aux feux rouges ou n'ont pas détecté l'état du signal du tout.¹²
2. Manœuvres à contresens : Le système a été observé pénétrant dans des voies de circulation opposées ou exécutant des virages depuis des voies de circulation tout droit uniquement, ignorant les marquages routiers et la signalisation clairs.²
3. Saturation en basse visibilité : Une collision mortelle significative en 2023 s'est produite dans un état d'« éblouissement solaire sur asphalte mouillé », où le système n'a pas détecté un piéton.¹⁴

La dépendance de Tesla à une architecture « Vision-Only » — écartant le LiDAR et le radar — crée une vulnérabilité fondamentale à la « saturation des capteurs ». Dans des conditions de brouillard, de poussière ou de débris aériens, le rapport signal/bruit optique tombe sous le seuil requis pour une navigation sûre.¹³ Bien que Tesla utilise des « réseaux d'occupation » pour prédire la géométrie 3D du monde à partir d'images 2D, les rapports de la NHTSA suggèrent que ces prédictions restent trop probabilistes pour servir de couche de sécurité primaire.¹⁵

Formaliser l'environnement de conduite

Pour dépasser le modèle de défaillance Tesla, l'ingénierie d'IA profonde utilise des « enveloppes guidées par les dangers ». Au lieu de « fonctionnalités » vagues, le système doit définir des domaines de conception opérationnelle (ODD) explicites. Si le « pourcentage de saturation par éblouissement » ou l'« indice de rétrodiffusion du brouillard » dépasse un seuil vérifié, le système doit initier une transition fail-safe.¹⁴

Mode de défaillance investigué	Fréquence/Impact	Cause technique
Non-conformité au feu rouge	18+ plaintes	Défaillance de détection de l'état du signal dans la pile vision.12
Violation du marquage de voie	4+ rapports SGO	Incapacité à distinguer les voies de virage exclusif vs. les voies de circulation tout droit.12
Accident en basse visibilité	Décès (2023-2024)	Saturation des capteurs optiques (éblouissement/brouillard/poussière).13
Entrée en voie opposée	2 rapports SGO	Défaillance de la reconstruction 3D de la géométrie des voies.12

La philosophie de Veriprajna est que l'autonomie ne peut pas être construite sur un logiciel de « meilleur effort ». Les 2.9 million de véhicules concernés par l'enquête NHTSA de 2025 représentent un risque à l'échelle de la flotte qui ne peut être atténué que par la mise en œuvre de « portes d'assurance » — des verrous logiciels qui empêchent l'IA de prendre des décisions à haut risque lorsque le niveau de confiance de son système de perception tombe sous un point déterministe.²

Enlisement multi-agents et résilience socio-technique : l'expérience Waymo

Waymo est souvent considérée comme la référence en matière de sécurité, ayant parcouru plus de 56 million miles avec des taux de blessures significativement inférieurs à ceux des conducteurs humains.¹⁷ Cependant, à mesure que le système s'étend, il a rencontré une nouvelle classe de défaillance : la « friction socio-technique ». Celle-ci concerne non seulement la façon dont l'IA conduit, mais aussi la façon dont elle interagit avec l'environnement social humain, complexe et souvent hostile.

Blocages d'intersections et défaillances de communication

Lors d'une panne de courant en 2025 à Los Angeles, des dizaines de robotaxis Waymo sont restés bloqués à une série d'intersections plongées dans l'obscurité. Le « Waymo Driver », programmé pour traiter les signaux éteints comme des stops à quatre voies, a été submergé par le pic concentré de demandes d'« assistance à distance ».¹⁸ Parce que les véhicules n'étaient pas en mesure de communiquer efficacement entre eux, ils sont entrés dans un état d'« enlisement multi-agents », où des robotaxis bloquaient d'autres robotaxis, créant un encombrement que le centre de commandement central n'a pas pu résoudre.¹⁸

Cette défaillance met en lumière le « piège de l'indépendance » — l'hypothèse qu'un véhicule autonome peut opérer en sécurité comme un agent solitaire sans un système plus large et coordonné.¹⁸ L'ingénierie d'IA profonde doit prendre en compte la perte de communication sans fil et la nécessité de protocoles « V2V » (Vehicle-to-Vehicle) et « V2I » (Vehicle-to-Infrastructure) qui permettent à la flotte de résoudre les impasses de manière autonome.²⁰

La nécessité d'un « Danger Escape Mode »

La menace émergente peut-être la plus significative pour les opérations autonomes est l'agression publique. Début 2025, plusieurs véhicules Waymo ont été attaqués par des foules lors de troubles civils à Los Angeles, des manifestants crevant les pneus et incendiant des véhicules.²¹ Les véhicules, programmés pour une « sécurité passive », se sont simplement arrêtés lorsqu'ils ont été encerclés par des personnes.

Cela a conduit à la proposition de développement d'un « Danger Escape Mode ». Un tel système utiliserait la suite de capteurs à 360 degrés pour détecter une « agression humaine malveillante » et faire passer la directive du véhicule de la « conformité passive » à « l'échappement actif ».²¹ Bien que le véhicule ne doive jamais être programmé pour causer un préjudice, les fournisseurs d'IA profonde soutiennent qu'il devrait être capable de commettre des infractions mineures au code de la route (comme rouler sur un trottoir ou passer un feu rouge) pour protéger ses passagers et échapper à une situation volatile.²¹ Cela exige une refonte radicale du « moteur éthique » de l'IA — une tâche qui va bien au-delà des capacités d'un wrapper LLM.

La solution technique : vue à vol d'oiseau (BEV) et réseaux d'occupation

Pour traiter les défaillances de suivi observées dans les cas Uber et Cruise, l'industrie s'oriente vers la perception en vue à vol d'oiseau (BEV). Les systèmes standard par caméra traitent des images individuelles, ce qui entraîne une perte de données lors de l'« assemblage ». En revanche, la perception BEV transforme les données multi-vues de caméras et de LiDAR en une grille 3D unifiée, vue de dessus.²²

Réseaux d'occupation vs. fusion de capteurs standard

La fusion de capteurs traditionnelle tente d'« apparier » des pixels 2D à des points 3D, un processus coûteux en calcul et sujet aux erreurs de projection. Veriprajna plaide pour les « réseaux d'occupation » — une architecture qui prédit la « probabilité d'occupation » de chaque voxel dans un volume 3D.¹⁶

1. Permanence de l'objet : Parce que les réseaux d'occupation suivent le volume plutôt que de simples « étiquettes », le système sait qu'un espace est occupé même s'il ne peut pas décider si l'objet est un piéton ou un vélo. Cela aurait empêché le basculement de classification d'Uber ATG.¹⁶
2. Fidélité géométrique : Les réseaux d'occupation capturent les structures verticales et les débris routiers souvent ignorés par les cartes BEV 2D. Cela aurait permis au véhicule Cruise de « voir » la piétonne sous son châssis pendant la manœuvre post-impact.¹⁶
3. Consistance spatio-temporelle : Grâce aux architectures « BEVFormer », le système peut utiliser l'« auto-attention temporelle » pour se souvenir de l'emplacement d'un objet même pendant des occlusions temporaires (p. ex., un piéton marchant derrière un camion stationné).²⁴

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

Dans ce modèle, l'architecture Transformer ne sert pas d'outil conversationnel, mais de moteur de raisonnement spatial qui fusionne des données hétérogènes en un « canevas partagé » unique.²³ C'est cela, l'ingénierie d'IA profonde : l'usage d'architectures de frontière pour résoudre des problèmes de physique fondamentaux en navigation.

Vérification formelle : le standard Veriprajna pour une IA à haute assurance

Le différenciateur le plus significatif entre un « wrapper » et une « solution » est l'application des méthodes formelles. Les tests logiciels traditionnels s'appuient sur des scénarios « boîte noire » ; si le système réussit N tests, on suppose qu'il est sûr. Dans les systèmes critiques pour la sécurité, cependant, nous exigeons une preuve mathématique de correction.

Solveurs SMT et raisonnement au niveau du réseau

Des outils comme Marabou et α,β-CROWN permettent aux ingénieurs de vérifier les propriétés des réseaux de neurones profonds. En représentant le réseau comme un ensemble de contraintes linéaires par morceaux, nous pouvons déterminer s'il existe n'importe quelle entrée qui pourrait conduire à une sortie non sûre.²⁵

Une « propriété de sécurité » pourrait être définie comme suit :

Pour toutes les entrées x dans la plage de « basse visibilité », la sortie y (commande de freinage) ne doit jamais être inférieure à k.

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

Si un solveur SMT comme Marabou renvoie un « contre-exemple », il a identifié une perturbation spécifique, souvent imperceptible, qui ferait échouer l'IA. Cela permet à Veriprajna de « durcir » le modèle pendant la phase d'entraînement, un processus connu sous le nom d'« entraînement conscient de la vérification ».²⁸

Élagage pour la vérifiabilité

Un défi majeur de la vérification formelle est la « malédiction de la dimensionnalité ». Les grands réseaux sont trop complexes pour que les solveurs actuels les analysent de manière exhaustive. Veriprajna y répond par l'« élagage de neurones ». En retirant les neurones redondants et les non-linéarités qui ne contribuent pas à la précision du modèle, nous produisons un « modèle élagué » mathématiquement plus facile à vérifier sans sacrifier la performance.²⁹

Technique de vérification	Méthodologie	Bénéfice
Resserrement des bornes	Analyse symbolique des plages d'activation des neurones	Réduit l'espace de recherche pour les solveurs SMT.25
Analyse d'accessibilité	Calcul de l'ensemble de toutes les sorties accessibles pour un ensemble d'entrées	Garantit que l'IA restera dans un « polytope sûr ».28
Approximation linéaire par morceaux	Remplacement des activations complexes par des segments basés sur ReLU	Permet des preuves de vérification saines et complètes.27
Filtre de sécurité formel	Surveillance à l'exécution des commandes de l'IA contre une baseline vérifiée	Fournit une « récupération sûre » si l'IA principale se comporte de manière irrationnelle.31

L'horizon réglementaire : SOTIF et ISO/PAS 8800

Pour les entreprises, la conformité aux normes internationales émergentes n'est plus optionnelle. Le paysage est passé de l'« auto-évaluation volontaire » à l'adhésion obligatoire à un cadre de sécurité à plusieurs niveaux.⁵

ISO 26262 vs. ISO 21448 (SOTIF)

Alors que l'ISO 26262 traite de la « sécurité fonctionnelle » (p. ex., un capteur qui tombe en panne ou une puce en court-circuit), elle ne peut pas prendre en compte les limitations inhérentes de l'IA.³⁴ Cette lacune est comblée par l'ISO 21448, la norme pour la « Safety of the Intended Functionality » (SOTIF). SOTIF est spécifiquement conçue pour traiter les dangers qui surviennent lorsque le système fonctionne exactement comme programmé mais rencontre un environnement « inconnu/non sûr ».³⁴

L'objectif d'un engagement Veriprajna est de maximiser le quadrant « connu/sûr » du système d'IA d'un client. Cela implique :

1. Analyse des dangers et des risques (HARA) : Identifier les risques hors défaillance tels que la mauvaise interprétation des capteurs sous forte pluie.³⁶
2. Identification des conditions déclenchantes : Cartographier systématiquement les états environnementaux qui conduisent à des erreurs de perception.³⁶
3. V&V (vérification et validation) : Utiliser des simulations haute fidélité pour « injecter » des cas limites trop dangereux à tester sur voies publiques.³⁶

ISO/PAS 8800 : l'avenir de l'intégration de l'IA

Fin 2024, l'ISO/PAS 8800 est devenue la norme principale pour la « sécurité fonctionnelle de l'IA dans les véhicules routiers ».³⁷ Elle fournit les premières lignes directrices mondiales pour la gestion du cycle de vie de l'IA, de l'« acquisition de données » à la « surveillance post-déploiement ».³³ Veriprajna s'assure que les architectures de nos clients ne sont pas seulement conformes, mais « pérennisées » face à la rigueur croissante des normes mondiales de gouvernance de l'IA comme l'EU AI Act et le NIST AI Risk Management Framework.³³

La voie stratégique : le mandat d'IA profonde de Veriprajna

La transition d'une culture du « Wrapper » vers une culture de l'« IA profonde » est un voyage de l'espoir probabiliste vers l'assurance déterministe. Le règlement de $8.5 million d'Uber, la suspension de Cruise et les 40+ enquêtes Tesla ne sont pas des raisons d'abandonner l'IA ; ce sont des raisons d'en assurer une ingénierie correcte.

Le modèle de conseil de Veriprajna repose sur trois piliers qui traitent les modes de défaillance spécifiques identifiés dans ce rapport :

1. Résilience de la perception : Faire passer les clients de la perception 2D par caméra aux réseaux d'occupation BEV basés sur Transformer afin d'assurer la permanence de l'objet et la stabilité du suivi.¹⁶
2. Décision vérifiée : Mettre en œuvre une vérification formelle basée sur SMT pour prouver que les architectures de contrôle pilotées par l'IA ne violeront jamais les propriétés de sécurité fondamentales.²⁵
3. Durcissement socio-technique : Développer des « modes d'échappement » sophistiqués et des cadres de communication V2X pour gérer la réalité des troubles civils et de l'enlisement multi-agents.¹⁸

Alors que le coût mondial d'une seule fuite de données atteint $4.44 million et que le coût d'un décès autonome entre dans les dizaines de millions en dommages juridiques et opérationnels, le wrapper « bon marché » devient l'erreur la plus coûteuse qu'une entreprise puisse commettre.¹⁴ Veriprajna fournit l'expertise d'ingénierie profonde requise pour construire une IA qui ne fonctionne pas seulement en laboratoire — elle perdure dans le monde.

Le choix pour l'entreprise moderne est clair : continuer à envelopper des boîtes noires probabilistes et gérer les retombées inévitables, ou s'associer à Veriprajna pour architecturer un avenir d'autonomie vérifiable à haute assurance. L'ère de l'IA stochastique s'achève ; l'ère de l'ingénierie d'IA profonde a commencé.

Ouvrages cités

1. Cruise Admits To Submitting A False Report To Influence A Federal Investigation And Agrees To Pay $500000 - Department of Justice, consulté le 9 février 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, consulté le 9 février 2026, https://www.autobodynews.com/news/nhtsa-opens-probe-into-2-9m-teslas-over-fsd-violations
3. HWY18MH010.aspx - NTSB, consulté le 9 février 2026, https://www.ntsb.gov/investigations/Pages/HWY18MH010.aspx
4. NTSB Shares Investigation Findings and Recommendations Regarding March 2018 Uber ATG Fatality | Eckert Seamans, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://www.metro-magazine.com/news/ntsb-releases-preliminary-report-on-fatal-uber-self-driving-car-crash
7. Death of Elaine Herzberg - Wikipedia, consulté le 9 février 2026, https://en.wikipedia.org/wiki/Death_of_Elaine_Herzberg
8. New Details Emerge Regarding Uber Self-Driving Vehicle Accident in Tempe, Arizona, consulté le 9 février 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, consulté le 9 février 2026, https://www.computer.org/csdl/magazine/co/2024/11/10720344/215PD0vqgTe
10. Notes on Cruise's pedestrian accident - Dan Luu, consulté le 9 février 2026, https://danluu.com/cruise-report/
11. Lessons from the Cruise Robotaxi Pedestrian Dragging Mishap, consulté le 9 février 2026, http://users.ece.cmu.edu/~koopman/pubs/Koopman2024_CruiseMishap_IEEEReliabilityMagazine.pdf
12. Office of Defects Investigation (ODI) Resume - nhtsa, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://www.priz.guru/tesla-fsd-safety-issues-nhtsa-probes-ai-driving-future-part-6/
15. AI & Robotics | Tesla, consulté le 9 février 2026, https://www.tesla.com/AI
16. A Survey on Occupancy Perception for Autonomous Driving: The Information Fusion Perspective - arXiv, consulté le 9 février 2026, https://arxiv.org/html/2405.05173v2
17. New Study: Waymo is reducing serious crashes and making streets safer for those most at risk, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://arxiv.org/html/2504.04631v2
21. When Robotaxis Get Attacked: Do Waymo Cars Need a 'Danger Escape Mode'?, consulté le 9 février 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, consulté le 9 février 2026, https://arxiv.org/html/2510.24688v1
23. [AV Vol.3] BEVFusion: Unifying Vision in Autonomous Driving Systems - Medium, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://aisafety.stanford.edu/marabou/MarabouCAV2019.pdf
26. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - arXiv, consulté le 9 février 2026, https://arxiv.org/html/2401.14461v1
27. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - Stanford CS Theory, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://ceur-ws.org/Vol-3345/paper10_RiCeRCa3.pdf
30. Formal Verification of Neural Networks for Safety-Critical Tasks in Deep Reinforcement Learning, consulté le 9 février 2026, https://proceedings.mlr.press/v161/corsi21a/corsi21a.pdf
31. Formal Methods for Trustworthy AI-based Autonomous Systems - NII Shonan Meeting, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://arxiv.org/html/2602.05157v1
36. What is SOTIF? (ISO 21448) - Visure Solutions, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://www.appliedintuition.com/blog/iso26262-sotif-simulation
39. Introducing ISO/PAS 8800 – Functional Safety for AI in Road Vehicles | SGS Georgia, consulté le 9 février 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, consulté le 9 février 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, consulté le 9 février 2026, https://www.promptfoo.dev/blog/ai-safety-vs-security/