Système automatisé ou d’IA impliqué dans une séquence accidentelle
Lorsqu’un système automatisé ou d’intelligence artificielle a recommandé ou exécuté une action avant un accident, l’expertise doit établir ce qu’il a fait, sur quelles données, ce que l’opérateur pouvait vérifier, et quelles traces en subsistent. Le sapiteur apporte une double lecture : celle de l’exploitation, et celle de l’assurance des systèmes d’IA en environnement à haut risque.
Quelle est la situation ?
Un site utilise un système d’aide à la décision : détection d’anomalies, maintenance prédictive, optimisation de la production, conseil de conduite. Avant l’accident, le système a émis une recommandation, ou n’en a pas émis, ou a exécuté une action automatique. L’opérateur l’a suivie, ou n’a pas pu la vérifier. Après l’accident, chacun cherche à comprendre le rôle du système.
Quelles questions l’expertise doit-elle éclairer ?
- Qu’a fait le système exactement ? Sur quelles données d’entrée ? Dans quelle version du modèle ?
- Les journaux de décisions et de données ont-ils été conservés ? Sont-ils exploitables ?
- Qu’affichait l’interface à l’opérateur ? Le système filtrait-il ou hiérarchisait-il l’information ?
- L’opérateur disposait-il d’un moyen indépendant de vérifier la recommandation, et du temps pour le faire ?
- Existait-il une validation humaine obligatoire, un mécanisme d’arrêt du système ? Avaient-ils été testés ?
- Le système assurait-il, de fait, une fonction de barrière ? Cette fonction figurait-elle dans l’étude de dangers ?
- Le modèle avait-il été modifié ou réentraîné, et ce changement était-il passé par la gestion des modifications ?
Pourquoi une expertise technique générale ne suffit-elle pas ?
Un expert en informatique peut analyser le code et les données. Un expert en procédés peut analyser la séquence physique. La question se situe entre les deux : une barrière de sécurité a-t-elle été, de fait, confiée à un modèle qui ne pouvait pas l’assurer ? Y répondre demande de connaître à la fois les barrières d’une installation à haut risque et les limites d’un système d’IA en exploitation.
Qu’apporte le sapiteur ?
- L’inventaire des pièces à demander, en s’appuyant sur le référentiel IOGP 817-1 : documentation du modèle, inventaire des systèmes, essais, dispositifs de supervision humaine, journaux.
- La reconstitution de ce que le système a fait et de ce que l’opérateur voyait.
- L’analyse de la fonction de barrière confiée de fait au système, avec la grille ABR.
- Le lien avec la gestion des modifications pour les mises à jour du modèle.
Il décrit qui disposait de quelle information et qui a exécuté quelle action. Il ne qualifie pas les responsabilités.
Voir aussi : systèmes automatisés et IA, défaillance d’une barrière de sécurité, le sapiteur, cadre juridique.
Questions fréquentes
Quelles traces un système d'IA laisse-t-il ?
Cela dépend de sa conception. Le référentiel IOGP 817-1 prévoit la conservation de journaux infalsifiables des décisions, des données d'entrée et des performances du système, pour l'audit et l'enquête. Leur existence, ou leur absence, est un fait que l'expertise peut constater.
Un modèle performant peut-il compromettre une barrière ?
Oui. Un modèle validé et bien employé peut ne pas percevoir la condition qu'une barrière a pour fonction de détecter. Si l'organisation assimile la performance du modèle à l'accomplissement de la barrière, celle-ci est compromise sans défaut apparent du modèle.
Le sapiteur dit-il qui, de l'exploitant ou du fournisseur, est responsable ?
Non. Il établit qui disposait de quelle information et qui a exécuté quelle action, à quel moment. L'appréciation des responsabilités appartient au juge (art. 238 CPC).
Rédigé par Carl Goodwin, sapiteur en risque industriel. Mise à jour : .
Définitions : Barrière de sécurité · Gestion des modifications (MOC)