Gains :
- Capacité à expliquer les cadres de sécurité fonctionnelle ISO 26262 et ISO 21448 (SOTIF) et leurs effets sur les systèmes contenant de l'intelligence artificielle
- Capacité à gérer la confidentialité des données, les données des conducteurs, la cybersécurité (ISO/SAE 21434) et les risques éthiques dans le contexte automobile
- Capacité à assumer la responsabilité humaine des décisions critiques pour la sécurité en comprenant que les résultats de l'IA ne remplacent pas l'approbation d'un ingénieur compétent.
Vous êtes dans l'unité la plus critique de ce module. Jusqu’à présent, nous avons considéré l’IA comme un accélérateur de la conception à la fabrication, des tests à la chaîne d’approvisionnement. Mais la question décisive dans le secteur automobile est la suivante : ce système va-t-il nuire à quelqu’un et qui en est responsable ? Cette unité couvre en langage simple les cadres d'utilisation responsable de l'IA dans un secteur où la sécurité est critique : sécurité fonctionnelle, SOTIF, cybersécurité, confidentialité et éthique. Le principe de base reste constant : les résultats de l’IA ne remplacent jamais l’approbation d’un ingénieur compétent ; Les décisions et responsabilités critiques en matière de sécurité appartiennent à l’humain.
ISO 26262 : sécurité fonctionnelle
ISO 26262 est la norme de sécurité fonctionnelle pour les systèmes électriques/électroniques des véhicules routiers. Sécurité fonctionnelle ; Il s'agit de s'assurer que lorsqu'un système tombe en panne (un capteur tombe en panne, un logiciel tombe en panne), cela n'entraîne pas une situation dangereuse.
Au cœur de cette norme se trouve l’ASIL (Automotive Safety Integrity Level). Un danger est évalué selon trois dimensions :
- Gravité : à quel point cela serait-il grave si cela se produisait ? (blessure légère ou décès)
- Exposition : à quelle fréquence cela se produit-il ?
- Contrôlabilité : dans quelle mesure le conducteur peut-il contrôler la situation ?
Ces trois éléments combinés donnent un niveau allant de ASIL A (le plus bas) à ASIL D (le plus élevé, par exemple freinage, direction). À mesure que le niveau augmente, les exigences en matière de développement, de test et de documentation deviennent plus strictes.
PRINCIPAL
système d'échantillonnage
Intensité du besoin
A.
Dysfonctionnement de l'éclairage intérieur
faible
B.
feu arrière
moyen
C.
Certaines fonctions ADAS
haut
D.
Frein, direction, airbag
le plus élevé
Astuce : Connaître le niveau PRINCIPAL d’une fonction vous indique l’attention requise par l’utilisation de l’IA dans cette fonction. AUCUNE décision basée sur les résultats de l’IA dans une fonction ne peut être acceptée sans vérification de sécurité indépendante.
ISO 21448 (SOTIF) : sécurité de la fonction prévue
La sécurité fonctionnelle classique (ISO 26262) se concentre sur la question « que se passe-t-il en cas de panne du système ? Mais il existe un nouveau problème dans les systèmes de détection d’intelligence artificielle : même si le système ne présente jamais de dysfonctionnement, il peut être inadéquat. La caméra fonctionne bien mais ne reconnaît pas une plaque enneigée ; Le radar est solide, mais il ignore un véhicule à l'arrêt comme un signal fantôme. Il n’y a pas de panne matérielle/logicielle ici ; Le problème se situe à la limite de la portée prévue de la fonction.
ISO 21448 - SOTIF (Safety Of The Intended Functionality) répond exactement à cette lacune : gérer les risques découlant de scénarios non reconnus, de limites de détection et de situations imprévues, même si le système fonctionne comme prévu. Dans l’ADAS/conduite autonome basée sur l’IA, SOTIF est aussi critique que la norme ISO 26262.
Cadre
Concentrez-vous
exemple
OIN 26262
Risque dû à l'échec
Le capteur se brise, le signal disparaît
ISO 21448 (SOTIF)
Risque d'insuffisance/non-reconnaissance
Une caméra robuste ne reconnaît pas les dalles enneigées
ISO/SAE 21434
cybersécurité
Attaque système, manipulation de données
Attention : les modèles d'IA sont statistiques ; Ils ne peuvent pas garantir qu'ils « verront correctement chaque situation ». La SOTIF vise à affiner les scénarios dangereux inconnus dans ces systèmes intrinsèquement limités et à réduire le risque restant à un niveau acceptable. « Le modèle est précis à 99,9 % » n’est pas une preuve de sécurité.
ISO/SAE 21434 : cybersécurité
Les véhicules connectés et définis par logiciel sont vulnérables aux cyberattaques. Un attaquant distant peut modifier la commande de freinage, voler la télémétrie ou tromper le modèle de détection (attaque contradictoire : faire en sorte que le modèle le reconnaisse mal en plaçant un petit autocollant sur une plaque). ISO/SAE 21434 est le cadre d'ingénierie pour la cybersécurité des véhicules. Dans le contexte de l’intelligence artificielle, deux risques se démarquent : tromper le modèle (adversarial) et empoisonner les données d’entraînement (data poisoning). Les systèmes d’IA critiques pour la sécurité doivent être testés contre ces attaques.
Confidentialité et données personnelles
Le véhicule moderne est un « centre de données sur roues » : localisation, comportement de conduite, audio et même caméra d’habitacle. La plupart de ces données sont des données personnelles et sont couvertes par le KVKK (Turquie) et le RGPD (Europe). Le VIN (numéro de châssis) permet d'identifier un véhicule et indirectement son propriétaire. Principes de base :
- Minimisation des données : collectez uniquement ce qui est nécessaire.
- Limitation de la finalité : Ne pas utiliser les données à des fins autres que celles pour lesquelles elles ont été collectées.
- Anonymisation/pseudonymisation : supprimez ou encodez les informations d'identification personnelle.
- Consentement explicite et transparence : le conducteur doit savoir ce qui est collecté.
- Stockage et transfert sécurisés.
Attention : L'envoi d'un VIN brut, d'un historique de localisation ou d'un comportement de conduite à un outil d'IA de cloud public peut constituer à la fois une violation de la vie privée et un risque contractuel. Lorsque vous travaillez avec ces données, anonymisez-les et utilisez un environnement institutionnel protégé par les données.
Éthique et responsabilité de l’ingénieur
L’intelligence artificielle comporte certains risques éthiques :
- Biais : si les données d'entraînement prédominent dans certaines conditions (par exemple, jour, peau claire, certaines routes régionales), le modèle peut être peu performant dans des conditions sous-représentées (nuit, conditions différentes). Il s'agit d'une vulnérabilité.
- Excès de confiance (biais d’automatisation) : les gens font aveuglément confiance à l’automatisation et passent outre leur propre jugement. Si l’ingénieur de test arrête de regarder les données brutes simplement parce que l’IA dit « réussite », il s’agit d’une tendance dangereuse.
- Perte de responsabilité : « Le modèle a décidé » ne constitue pas un moyen de défense. Il devrait toujours y avoir une personne qui signe la décision.
Mini-études de cas
Cas 1 – Limite SOTIF. Un système de freinage d'urgence automatique a réussi tous les tests en laboratoire, sans aucun dysfonctionnement. Dans un champ, sous un soleil bas, un camion blanc prend sa remorque pour le ciel et freine tardivement. Il ne s'agit pas d'un dysfonctionnement, mais d'une vulnérabilité SOTIF : le système est intact mais le scénario est hors limite de détection. L'équipe ajoute ce scénario à la bibliothèque de tests et renforce la fusion radar. Conclusion : « Aucune panne » n'est pas une preuve de sécurité ; L'insuffisance est également un risque.
Cas 2 – Données biaisées. Un modèle de détection des piétons a été formé principalement avec des données diurnes ; Le rappel nocturne est nettement inférieur. L'équipe équilibre et recycle les données de nuit et de faible luminosité et rapporte les scénarios de nuit séparément. Conclusion : des données déséquilibrées créent une vulnérabilité mortelle dans certaines circonstances.
Cas 3 – Prévention des atteintes à la vie privée. Un analyste est sur le point de coller les données de la flotte dans un outil d'IA public lorsqu'il remarque que les données contiennent des emplacements bruts VIN et GPS. Il fonctionne dans un environnement d'entreprise en anonymisant les données (vehicle_01..arac_50 au lieu du VIN, code région au lieu de l'emplacement). Résultat : un moment d’attention a empêché une grave violation du KVKK.
modèles d'invite
Modèle 1 – Évaluation préalable/évaluation préliminaire des risques (projet) :
Rôle : Vous êtes consultant en sécurité fonctionnelle. Tâche : Prépare un projet pour faciliter l'analyse des dangers et des risques pour une fonction. Contexte : Fonction : freinage d'urgence automatique ; urbain et interurbain.Contrainte : affectation exacte de l'ASIL ; Donnez une liste de questions et de points d’attention sur les dimensions de gravité/exposition/contrôlabilité ; indiquez que l'affectation finale incombe à l'ingénieur de sécurité autorisé. Sortie : Taille | question d'évaluation | tableau des notes d'attention.
Modèle 2 - Analyse de scénario SOTIF :
Rôle : Vous êtes un expert SOTIF. Tâche : Répertorier les scénarios dans lesquels une fonction de détection pourrait être « système intact mais inadéquat ». Contexte : Caméra + radar ; soleil bas, neige, sortie de tunnel, objets inhabituels. Sortie : Scénario | pourquoi insuffisance | recommandation de réduction.
Modèle 3 – Contrôle de confidentialité :
Rôle : Vous êtes consultant en protection des données (KVKK/GDPR). Tâche : Effectuer un audit de confidentialité avant de partager un ensemble de données. Contexte : Télémétrie de la flotte ; Les colonnes contiennent le VIN, le GPS, le score de conduite. Contrainte : Quels champs sont des données personnelles, comment les anonymiser, que ne dois-je pas partager du tout ; sort.Output : Champ | risque | tableau des transactions recommandé.
Modèle 4 – Vérification des biais :
Rôle : Vous êtes un auditeur de sécurité et d'équité ML. Tâche : Dites-moi comment rechercher un risque de biais dans un modèle de détection. Contexte : Détection des piétons ; données d'entraînement pondérées jour/ville. Sortie : Condition à vérifier | mesure | signe de risque.
Invite faible/Invite forte
Invite faible :
Ce système de freinage autonome est-il sécuritaire, confirmez.
Essayer d’obtenir une habilitation de sécurité en matière d’IA est dangereux ; L'approbation appartient à l'ingénieur agréé.
Invite puissante :
Rôle : Vous êtes consultant en sécurité fonctionnelle et SOTIF. Tâche : Énumérez les questions que je dois poser et les preuves que je dois recueillir lors de l'évaluation de la sécurité de ma fonction de freinage automatique. Contexte : détection basée sur l'IA ; caméra+radar ; ASIL peut être élevé. Contrainte : « Approuver » le système ; Fournir des listes distinctes de questions et de preuves en termes de ISO 26262 (défaut) et SOTIF (déficience) ; Insistez sur le fait que l'approbation finale appartient à l'ingénieur de sécurité agréé. Résultat : Framework | questions | tableau des preuves requises.
Erreurs courantes
- Confondre « aucun dysfonctionnement » avec « sûr ». Une carence en SOTIF peut tuer sans dysfonctionnement.
- Obtenir une habilitation de sécurité IA. L'approbation et la responsabilité incombent à l'ingénieur agréé.
- Confondre la précision du modèle avec une preuve de sécurité. Une précision de 99,9 % n’indique pas que le risque restant a été géré.
- Ne protège pas les données personnelles. Le VIN/l'emplacement/le comportement de conduite relèvent du champ d'application du KVKK/GDPR.
- Ignorer les préjugés et l’excès de confiance. Des données déséquilibrées et une confiance aveugle dans l’automatisation sont des vulnérabilités.
En résumé
- L'ISO 26262 gère le risque dû à la défaillance (avec ASIL), tandis que l'ISO 21448/SOTIF gère le risque de défaillance sans défaillance ; Les deux sont essentiels à la détection de l’IA.
- Cybersécurité ISO/SAE 21434 ; les attaques contradictoires et d’empoisonnement des données sont des menaces spécifiques à l’IA.
- La minimisation des données, la limitation de la finalité et l'anonymisation sont obligatoires dans le cadre du KVKK/GDPR ; Le VIN/localisation est une donnée personnelle.
- Les préjugés, l’excès de confiance et la perte de responsabilité sont les principaux risques éthiques.
- La sortie de l’IA ne remplace pas l’approbation d’un ingénieur qualifié ; La décision et la signature critiques pour la sécurité appartiennent toujours à la personne.
Tâche de candidature
Sélectionnez une fonction liée à la sécurité (par exemple maintien de la voie). (1) Discutez des raisons pour lesquelles le niveau ASIL de cette fonction peut être élevé/faible selon les dimensions gravité/exposition/contrôlabilité. (2) Générez 5 scénarios « système solide mais inadéquat » avec le modèle 2. (3) Auditez la confidentialité d'un ensemble de données pertinent avec le modèle 3. (4) Expliquez pourquoi dire « le modèle confirmé » n'est pas une défense.
liste de contrôle
- [ ] J'ai évalué les dimensions RÉELLES de la fonction (j'ai laissé la mission exacte à l'autorité).
- [ ] J'ai fait la distinction entre ISO 26262 (dysfonctionnement) et SOTIF (insuffisance).
- [ ] J'ai pris en compte le risque de cybersécurité (conversation/empoisonnement).
- [ ] J'ai anonymisé et minimisé les données personnelles.
- [ ] J'ai vérifié les risques de parti pris et d'excès de confiance.
- [ ] J'ai confirmé que l'habilitation de sécurité est celle de l'ingénieur qualifié.