L’utilisateur veut comprendre le risque dans le contexte de AI Safety & Risk et l’appliquer à un travail pratique de gouvernance ou de compliance IA.
Utilisez le terme risque pour les résultats négatifs potentiels avant ou pendant l’évaluation ; utilisez le terme dommage pour l’effet négatif qui s’est produit ou qui peut être décrit concrètement.
Le risque est la possibilité d’un résultat défavorable ; le dommage est l’effet défavorable lui-même. Dans la gouvernance de l’IA, le risque décrit ce qui peut arriver, la probabilité que cela se produise, la gravité possible et les contrôles nécessaires. Le dommage décrit une atteinte réelle ou concrètement décrite aux personnes, aux droits, à la sécurité, aux biens, aux organisations ou à la société. L’évaluation des risques est prospective et préventive ; l’analyse des dommages sert à comprendre l’impact, la responsabilité, les mesures correctrices et les enseignements tirés après ou autour d’un incident.
Le risque est le panneau d’avertissement ; le dommage est la blessure ou la perte que ce panneau annonce. Un modèle de recrutement peut présenter un risque de classement discriminatoire avant que quiconque soit affecté. Si des candidats sont effectivement rejetés injustement, l’organisation traite un dommage. Une bonne gouvernance cherche à réduire le risque avant qu’il ne devienne un dommage et à réagir correctement lorsqu’un dommage se produit.
Analogie
Le risque est la probabilité et la gravité d’une défaillance d’un pont ; le dommage est l’effondrement, la blessure, la perturbation ou le coût si cette défaillance survient.
La distinction est importante parce que les travaux juridiques, techniques et de gouvernance interviennent à des étapes différentes. Le langage du risque soutient les revues de conception, les contrôles d’achat, les analyses d’impact, les safety cases, le choix des contrôles et les approbations de déploiement. Le langage du dommage soutient les plaintes, la réponse aux incidents, les recours des utilisateurs, l’analyse de cause racine, le reporting, l’indemnisation et l’application des règles. Si les équipes confondent les deux, elles peuvent soit présenter des préoccupations hypothétiques comme des dommages prouvés, soit minimiser des dommages réels en les qualifiant seulement de risque théorique. Un vocabulaire clair améliore les pistes d’audit, le reporting au conseil d’administration, l’analyse réglementaire et la responsabilité des fournisseurs.
Urgence
Les équipes doivent séparer le langage du risque et celui du dommage dans les inventaires IA, registres de risques, journaux d’incidents et preuves de sécurité.
Un registre pratique des risques IA doit identifier le danger ou le mode de défaillance, les parties affectées, les dommages potentiels, la probabilité, la gravité, la détectabilité, les contrôles existants, le risque résiduel et le propriétaire responsable. Un registre des dommages doit identifier ce qui s’est produit, qui ou quoi a été affecté, les preuves, la gravité de l’impact, les causes racines, l’atténuation, la remédiation, les notifications et les enseignements tirés. L’évaluation des risques doit intervenir avant le déploiement et lors de changements importants. L’analyse des dommages doit intervenir lorsque des défaillances, plaintes, incidents, quasi-accidents ou signaux de monitoring montrent que des effets défavorables ont pu se produire.
L’erreur la plus fréquente consiste à formuler des risques vagues comme « biais de l’IA » sans identifier le dommage précis, le groupe affecté, le point de décision et le contrôle. Une autre erreur consiste à traiter le dommage comme une blessure uniquement physique. Dans les systèmes d’IA, le dommage peut inclure la discrimination, le refus d’accès, l’intrusion dans la vie privée, la perte économique, l’atteinte à la réputation, la détresse psychologique, la compromission de sécurité ou la perte d’autonomie. Les équipes échouent aussi lorsqu’elles maintiennent séparés les registres de risques et les journaux d’incidents, ce qui rend difficile de savoir si les risques prédits sont devenus des dommages réels.
Erreur 1 : Enregistrer un « risque d’hallucination » sans expliquer si le dommage possible est une erreur juridique, une désinformation médicale, une perte financière ou une tromperie de l’utilisateur.
Erreur 2 : Qualifier une fuite de données documentée de simple risque alors que des utilisateurs concernés ont déjà été exposés.
Cette page doit renvoyer vers risk, harm, ai-risk-assessment, safety-case et ai-safety. La comparaison la plus forte est risk-vs-harm parce qu’elle aide à produire une documentation de gouvernance IA plus nette. Elle doit aussi renvoyer vers safety-case-vs-ai-risk-assessment lorsque les équipes doivent comprendre la différence entre identifier des dommages possibles et construire un argument de sécurité appuyé par des preuves. Les questions associées incluent what-is-ai-safety, what-is-a-safety-case-for-ai et what-is-model-drift.