Ce que l'Europe peut apprendre des dossiers de sécurité

Un dossier de sécurité est un argument vivant qui relie dangers et hypothèses aux preuves, au risque résiduel et à une décision. Il offre aux équipes IA une...

Ce que l'Europe peut apprendre des dossiers de sécurité

Un dossier qui doit répondre avant que le train ne parte

La réglementation ferroviaire européenne commence par une question sans éclat : qu’est-ce qui a changé. Un changement peut être technique, opérationnel ou organisationnel. Il peut concerner un équipement, une procédure, une organisation du personnel ou une interface entre organisations. La méthode commune de sécurité pour l’évaluation et l’appréciation des risques demande au proposant d’évaluer l’importance de ce changement, d’appliquer un processus de gestion des risques lorsque cela est requis, et de recourir à un organisme d’évaluation indépendant pour vérifier que le processus et ses résultats ont été correctement appliqués. La règle ne s’intéresse pas à savoir si le changement a été annoncé avec assurance. Elle s’intéresse à savoir si l’argument justifiant la poursuite de l’exploitation peut être examiné.

Cette habitude mérite d’être transposée à l’IA. Un système ne devient pas sûr parce que son modèle est ingénieux, que son interface est apaisante ou que son fournisseur a produit un beau rapport d’essai. Il devient défendable pour un usage défini lorsqu’une organisation peut expliquer ce qu’elle affirme, quels dangers se cachent derrière cette affirmation, quelles hypothèses rendent cette affirmation possible, quelles preuves étayent chaque maillon, qui a accepté le risque résiduel, et ce qui rouvrirait la décision. Le résultat est communément appelé dossier de sécurité : un argument structuré étayé par des preuves, délimité par des conditions et maintenu à jour au fil des changements.

Un dossier de sécurité n’est pas un récit sur un accident imaginaire. C’est une manière de refuser de faire porter à l’accident tout le poids des preuves. Il pose les questions difficiles tant que la conception, l’acquisition et les pratiques d’exploitation peuvent encore évoluer. Cela le rend utile pour les chemins de fer, l’aviation, les dispositifs médicaux, le contrôle industriel et les infrastructures critiques. Cela le rend également utile pour l’IA, où un composant peut être statistiquement impressionnant et opérationnellement inadapté à la fois. Un modèle peut réussir un test tandis que le système qui l’entoure n’a aucune réponse sûre face à l’incertitude, aucun opérateur responsable et aucune voie pour corriger une mauvaise décision.

Cette distinction compte en Europe parce que le règlement sur l’intelligence artificielle demande déjà aux systèmes à haut risque de fonctionner avec un processus continu et documenté de gestion des risques. L’article 9 décrit l’identification, l’estimation, l’évaluation et le traitement itératifs des risques tout au long du cycle de vie du système, y compris les utilisations abusives raisonnablement prévisibles et les informations issues de la surveillance après mise sur le marché. L’article 11 exige une documentation technique avant la mise sur le marché d’un système et précise qu’elle doit être tenue à jour. Ces dispositions n’utilisent pas l’expression dossier de sécurité comme étiquette universelle. Elles décrivent néanmoins les habitudes qui rendent un dossier de sécurité crédible.

Un dossier de sécurité rend le chemin allant d’une affirmation de sécurité à une décision de mise en service suffisamment visible pour être contesté.

Le dossier de sécurité n’est pas un rapport d’essai

Un rapport de test répond à une question sur un test. Il consigne ce qui a été testé, dans quelles conditions, avec quel résultat et, si le travail est bien fait, avec quelles limites. Cela a de la valeur. Un dossier de sécurité pose une autre question : existe-t-il un argument suffisamment étayé pour démontrer que ce système est acceptable pour cette finalité, dans ce contexte, avec ces personnes, ces contrôles et ces risques résiduels. Un résultat de test peut être un élément de cet argument. Il ne peut pas silencieusement devenir l'argument tout entier simplement parce que le tableau comporte des cases vertes.

Supposons qu'un classifieur ait été testé sur un jeu de données étiqueté. Le rapport peut nous indiquer ses performances sur ce jeu de données, peut-être par classe, par seuil ou par point de fonctionnement. Il ne nous dit pas en soi si les données reçues en production ont la même signification, si la population concernée est représentée, si un examinateur peut reconnaître un résultat faible, si un recours est possible, si un fournisseur peut modifier le modèle sans préavis, ou si l'organisation peut arrêter et inverser une action en aval. Ces questions relèvent du système et de son usage, et non pas seulement du composant.

L'erreur inverse est également courante. Un volumineux dossier d'assurance peut contenir des centaines de pages et ne pas réussir à présenter un argument. Un catalogue de tests, de politiques et de comptes rendus de réunions n'est pas un dossier de sécurité si aucune affirmation ne les relie. Une preuve a besoin d'un rôle. Un test peut étayer une affirmation sur la robustesse. Une description de poste peut étayer une affirmation sur l'autorité. Un exercice de restauration peut étayer une affirmation sur la récupération. Une piste d'audit peut étayer une affirmation sur la traçabilité. Sans la relation entre l'affirmation et la preuve, le dossier est une archive d'activités, et non une explication de la sécurité.

C'est pourquoi un dossier de sécurité peut être plus court qu'un rapport de test à un endroit et plus volumineux à un autre. Il se construit autour des dangers et des décisions. Un outil de rédaction à faible enjeu peut nécessiter un argument modeste couvrant le périmètre, le traitement des données, la relecture et la correction. Un système lié à des décisions cliniques, de transport, financières ou de service public nécessite davantage de preuves, car davantage de personnes dépendent du résultat et parce que la voie de recours peut être difficile. La taille suit la conséquence et l'incertitude, et non la longueur à la mode de la fiche modèle.

L'argument doit également distinguer les preuves relatives au composant des preuves opérationnelles. Les preuves relatives au composant concernent le modèle, l'algorithme ou le capteur, isolément ou dans une intégration contrôlée. Les preuves opérationnelles concernent le flux de travail réel : accès, fraîcheur des données, relecture humaine, files d'attente, autorisations des outils, gestion des incidents et contrôle des changements. Un modèle peut être stable alors qu'une file d'attente s'effondre. Un flux de travail peut être bien conçu alors qu'un fournisseur modifie le schéma des données d'entrée. Les dossiers de sécurité obligent à mettre ces deux perspectives sur la même page, ce qui est légèrement inconfortable et donc sain.

Commencez par une affirmation qui a des contours

Chaque dossier de sécurité commence par une affirmation de haut niveau. L'affirmation doit être suffisamment étroite pour être testée et suffisamment utile pour guider une décision. La phrase « cette IA est sûre » n'est pas une affirmation avec des contours. Sûre pour qui, pour faire quoi, dans quelles conditions et avec quels contrôles. Une meilleure affirmation pourrait dire qu'une fonction d'aide à la décision spécifiée est acceptable pour un groupe nommé d'opérateurs formés, à condition que le système ne soit utilisé que pour des recommandations, que les preuves et l'incertitude soient présentées, qu'un humain ayant autorité examine le résultat et que des voies définies d'arrêt et de correction soient disponibles.

Cette phrase est moins commercialisable et beaucoup plus précieuse. Elle identifie la finalité, l'acteur, la limite et les conditions. Elle révèle également ce qui rendrait l'affirmation fausse. Si la même fonction est connectée directement à une décision automatique, l'affirmation ne la couvre plus. Si les utilisateurs prévus ne sont pas formés ou ne peuvent pas contester un résultat, l'affirmation s'affaiblit. Si une source de données change et ne peut pas être tracée, les preuves de l'affirmation peuvent expirer. Une bonne affirmation de haut niveau porte en elle sa propre liste de façons d'être rouverte.

Les affirmations peuvent être décomposées. Le système reste dans le cadre de son usage prévu. Les entrées respectent les conditions de qualité et de permission énoncées. La sortie du modèle est interprétée d'une manière qui ne crée pas de biais d'automatisation dangereux. Les actions à fort enjeu font l'objet d'un examen proportionné à leur risque. Les opérateurs peuvent écarter ou inverser une sortie. L'organisation peut détecter une dérive significative. Un changement n'est pas publié sans vérifier les hypothèses concernées. Chaque sous-affirmation nécessite des contrôles et des preuves. L'arbre n'est pas une illustration pour une diapositive ; c'est le chemin par lequel un examinateur peut localiser un maillon faible.

Une affirmation doit aussi préciser ce qu'elle ne cherche pas à prouver. Le dossier peut étayer une utilisation sûre pour une tâche donnée sans prouver une intelligence générale, une équité universelle ou une pertinence pour toutes les populations. Il peut étayer une publication dans le cadre d'un déploiement défini sans prouver qu'une configuration non documentée se comportera de la même manière. Les non-affirmations ne sont pas des ornements de modestie. Elles empêchent un résultat étroit de circuler dans une organisation comme une promesse beaucoup plus large.

Il existe une intuition européenne utile derrière cette précision. Le règlement 402/2013 demande à un proposant ferroviaire de décider si un changement est significatif, de sélectionner un principe d'acceptation du risque et, le cas échéant, de recourir à une évaluation indépendante. Le proposant n'est pas tenu de prouver que tout état futur concevable du système ferroviaire est sûr. Il est tenu de rendre le changement actuel et ses interfaces suffisamment intelligibles pour une décision proportionnée. Les équipes d'IA peuvent emprunter la même discipline. Nommer le changement, nommer le contexte d'exploitation et rendre la limite visible.

Les dangers sont des conditions, pas des gros titres

Un danger est une condition qui peut conduire à un préjudice. La distinction est plus utile qu'il n'y paraît. Une décision erronée concernant une prestation est un résultat. Un danger pourrait être un dossier incomplet combiné à un système qui présente une recommandation non étayée comme prête à être approuvée. Une alerte de maintenance retardée est un résultat. Un danger pourrait être un flux de capteurs obsolète que le flux de travail traite comme actuel. Une violation de la vie privée est un résultat. Un danger pourrait être une permission de récupération trop large associée à un outil qui copie le matériel source dans un enregistrement durable.

Rédiger les dangers de cette manière déplace l'attention en amont. Cela rend possibles les contrôles de conception et d'exploitation. Si le danger est une recommandation non étayée présentée avec une autorité indue, un contrôle pourrait exiger des preuves de source, faire apparaître l'incertitude, restreindre l'action et offrir une voie de révision. Si le danger est une entrée obsolète, un contrôle pourrait vérifier la fraîcheur, marquer l'état des données, bloquer l'action ou orienter vers une personne. Si le danger est un accès excessif, un contrôle pourrait contraindre la récupération, séparer les identités, expurger la sortie et consigner la décision d'accès. Le contrôle doit traiter la condition, pas simplement promettre d'être prudent autour du résultat.

L'analyse des dangers doit inclure les mauvais usages prévisibles, pas seulement l'usage prévu dans un document d'achat. L'AI Act rend cela explicite pour les systèmes à haut risque. L'article 9 demande une évaluation des risques lorsque le système est utilisé conformément à son usage prévu et dans des conditions de mauvais usage raisonnablement prévisibles. Le mauvais usage ne signifie pas chaque demande absurde. Il signifie les usages qu'une équipe compétente pourrait anticiper à partir de l'interface, des incitations, des instructions et du flux de travail environnant. Si le chemin le plus rapide dans le système est d'accepter une recommandation sans lire ses preuves, ce chemin appartient à l'analyse, même si la politique exige un examen.

Les dangers vivent aussi aux interfaces. Un modèle peut produire une recommandation bornée, mais une intégration peut la convertir en instruction non bornée. Un fournisseur peut proposer un point de terminaison versionné, mais un déploiement peut mettre en cache des réponses au-delà de la période de validité. Une autorité publique peut conserver la responsabilité de la décision, mais un contrat peut faire du fournisseur la seule partie habilitée à inspecter la trace. La frontière du système pour un dossier de sécurité doit suivre le chemin causal jusqu'à la conséquence. Tracer la frontière autour du seul modèle est un moyen efficace de manquer le travail qui rend le modèle pertinent.

Tous les dangers ne méritent pas le même traitement. Certains peuvent être réduits par la conception. D'autres nécessitent des contrôles procéduraux ou une relecture humaine. Certains peuvent être surveillés et acceptés sous conditions. D'autres indiquent que l'usage proposé n'est pas approprié. Un dossier de sécurité doit montrer le raisonnement, pas le cacher derrière un score de risque universel. La méthode ferroviaire européenne permet différents principes d'acceptation du risque, notamment les codes de pratique, la comparaison avec des parties similaires d'un système et l'estimation explicite du risque. La leçon n'est pas qu'une méthode l'emporte partout. La leçon est que la méthode et son adéquation au changement doivent être consignées.

Les hypothèses portent la charge

Tout argument de sécurité repose sur des hypothèses. L'opérateur est formé. La source est à jour. Le seuil a la signification que l'équipe pense qu'il a. La personne qui reçoit l'alerte peut agir à temps. Le service externe sera disponible ou une solution de repli existe. La sortie restera une recommandation plutôt que de devenir une décision de fait. L'organisation remarquera si une mise à jour du modèle change le comportement. De nombreux échecs de sécurité ne sont pas causés par une hypothèse déraisonnable. Ils sont causés par une hypothèse invisible.

Une hypothèse appartient au dossier avec un responsable et un moyen de la vérifier. Si l'argument repose sur des relecteurs formés, le dossier doit indiquer la compétence requise, comment elle est établie et ce qui se passe lorsque le personnel change. Si l'argument repose sur une source restant dans une fenêtre de fraîcheur, le système doit enregistrer la fraîcheur et faire dépendre l'action de celle-ci lorsque nécessaire. Si l'argument repose sur une intégration préservant un champ, le contrat d'interface et un test doivent rendre la dépendance visible. Une hypothèse qui ne peut pas être vérifiée est un risque portant un nom plus doux.

Les hypothèses peuvent concerner le monde extérieur autant que le logiciel. Un hôpital peut dépendre d'un parcours clinique. Un exploitant ferroviaire peut dépendre d'une interface de signalisation. Un organisme public peut dépendre d'un processus légal et d'un décideur humain conservant son autorité. Un fabricant peut dépendre de la maintenance effectuée dans un intervalle défini. Le dossier de sécurité ne contrôle pas chaque condition externe. Il doit dire quelles conditions il suppose, quelle partie les possède et comment un changement est reconnu.

Lorsque les hypothèses changent, le dossier ne doit pas s'étirer silencieusement. Une équipe peut commencer avec un usage de recommandation uniquement, puis ajouter un transfert automatique parce que la recommandation a été souvent acceptée. Le modèle n'a pas changé, mais l'autorité et le danger ont changé. Un fournisseur de données peut ajouter une nouvelle catégorie qui semble inoffensive jusqu'à ce qu'elle modifie le sens d'une règle en aval. Un déploiement peut passer de spécialistes formés à une équipe de support générale. Ce sont des changements de dossier même si le numéro de version du modèle reste le même.

Les hypothèses sont particulièrement importantes pour les systèmes probabilistes parce qu'une moyenne stable peut dissimuler un bord instable. Le dossier doit identifier où le système est censé être incertain, quelles preuves signalent cette incertitude et quel contrôle humain ou technique prend le relais. Le but n'est pas de prétendre que l'incertitude peut être éliminée. C'est d'empêcher une attente tacite de certitude de devenir la politique opérationnelle.

Une preuve n'est pas un passeport valable dans tous les contextes. Ses hypothèses définissent jusqu'où elle peut voyager.

La preuve exige une chaîne de traçabilité

Dans un dossier de sécurité, une preuve est bien plus qu'un résultat recopié dans un tableau. Elle a une identité, un périmètre, une date, une méthode, une personne ou une équipe responsable, et un lien avec l'affirmation qu'elle étaye. Un test nécessite une entrée et une configuration définies. Une revue nécessite une question et une décision. Un exercice nécessite une réponse attendue et une observation. Un journal nécessite suffisamment de contexte pour être interprété sans recourir à la mémoire. Un enregistrement source nécessite une trace de provenance. Les détails varient selon le domaine, mais le principe reste stable : la preuve doit pouvoir être examinée après la réunion au cours de laquelle elle a semblé convaincante.

L'AI Act confère à ce principe un poids juridique pour les systèmes à haut risque. L'article 11 exige que la documentation technique soit disponible avant la mise sur le marché du système et tenue à jour. L'article 12 exige l'enregistrement automatique des événements pertinents pendant toute la durée de vie du système, avec des capacités de journalisation proportionnées à la finalité prévue et utiles pour identifier les risques, soutenir la surveillance après mise sur le marché et surveiller le fonctionnement. L'article 13 demande des informations permettant aux déployeurs de comprendre les capacités, les limites, les risques prévisibles, la supervision humaine et les exigences en matière de données d'entrée. Un dossier de sécurité relie ces enregistrements au lieu de les laisser dans des tiroirs de conformité séparés.

La preuve doit préserver ses conditions. Un résultat de performance sans sa population de test peut être mal interprété. Un résultat de robustesse sans les perturbations utilisées peut être surestimé. Une revue de facteurs humains sans le flux de travail et la pression temporelle dans lesquels elle a été réalisée peut devenir un compliment général. Un journal d'incident sans la version, l'état des données et les autorisations en vigueur peut produire une cause racine attrayante mais erronée. Plus la décision est lourde de conséquences, moins il est acceptable de détacher un résultat des circonstances qui l'ont rendu vrai.

La preuve peut être qualitative ou quantitative. Un jugement d'expert documenté peut constituer une preuve valide lorsque la question est appropriée, l'expertise est identifiée et le raisonnement est consigné. Un score numérique peut être une preuve faible lorsque le dénominateur, le seuil ou les conditions du test ne sont pas clairs. Il n'existe pas de hiérarchie morale dans laquelle un nombre surpasserait automatiquement une observation attentive. Le dossier doit expliquer l'adéquation à l'usage et l'incertitude, et non faire preuve de révérence pour les décimales.

La traçabilité rend aussi le désaccord productif. Un évaluateur doit pouvoir dire quelle affirmation n'est pas étayée, quelle hypothèse est trop optimiste ou quel contrôle n'a pas été exercé. Le dossier devient alors un objet partagé de contestation plutôt qu'un ensemble d'approbations cérémonielles. C'est l'une des raisons pour lesquelles les industries critiques pour la sécurité investissent dans l'évaluation indépendante et les rapports d'assurance structurés. Le but n'est pas de rendre le désaccord confortable. C'est de le rendre localisable.

Le risque résiduel est une décision, pas un reliquat

Le risque ne disparaît pas parce que des contrôles ont été ajoutés. Le risque qui subsiste après les contrôles est le risque résiduel. Il doit être décrit et accepté par une autorité capable de comprendre les preuves, d'imposer des conditions et d'arrêter l'utilisation lorsque ces conditions ne sont plus remplies. Qualifier un risque d'acceptable ne revient pas à dire qu'il est faible. Cela signifie que l'organisation a pris une décision raisonnée sur l'exposition restante dans un contexte défini et n'a pas dissimulé le fondement de cette décision.

L'article 9 du règlement sur l'IA utilise directement ce langage pour les systèmes à haut risque. Le risque résiduel pertinent associé à chaque danger, ainsi que le risque résiduel global, doivent être jugés acceptables. Le règlement demande également l'élimination ou la réduction des risques lorsque cela est techniquement faisable, ainsi que des mesures d'atténuation et de contrôle lorsque les risques ne peuvent pas être éliminés. C'est un ordre utile. D'abord modifier la conception lorsque c'est possible. Ensuite ajouter des contrôles. Puis consigner ce qui reste. Une étiquette d'avertissement n'est pas une excuse pour conserver un danger évitable dans l'architecture.

Le risque résiduel devrait inclure la réversibilité. Les critères de risque du règlement sur l'IA examinent si un résultat peut être corrigé ou inversé, et notent que les effets néfastes sur la santé, la sécurité ou les droits fondamentaux ne devraient pas être traités comme facilement corrigibles du seul fait qu'un bouton d'annulation technique existe. C'est une distinction discrète mais importante. Un brouillon peut être corrigé. Une prestation perdue, un service refusé ou une accusation publique peuvent être beaucoup plus difficiles à réparer. Le dossier devrait prévoir des contrôles plus stricts lorsque la personne concernée ne peut pas raisonnablement se retirer ou annuler le résultat.

L'acceptation doit être assortie de conditions. Un système peut être accepté pour un pilote limité, une équipe formée, une source de données nommée et une voie de réexamen. Il ne peut pas être accepté pour une population différente, un flux de travail sans supervision ou une intégration qui supprime des preuves. Les conditions doivent être rédigées de manière à ce qu'un opérateur puisse déterminer si elles sont toujours remplies. Si une condition se limite à dire que les utilisateurs feront preuve de jugement, le dossier n'a pas expliqué comment le système soutient ce jugement ni ce qui se passe lorsque la charge de travail rend le jugement difficile.

Une décision sur le risque résiduel nécessite aussi une date d'expiration ou un déclencheur de réexamen. Une date fixe au calendrier peut aider, mais les événements sont généralement plus informatifs : un changement de modèle, une nouvelle source, un incident important, un signal de dérive, un changement d'utilisateurs, une nouvelle obligation légale ou un échec d'un exercice de contrôle. La décision n'est pas un charme posé sur la version. C'est une autorisation assortie d'un calendrier de maintenance.

La supervision humaine doit avoir de l'autorité

La supervision humaine est souvent évoquée comme si une personne se tenant quelque part près de la sortie rendait le système sûr. Le règlement sur l'IA est plus exigeant. L'article 14 dispose que les systèmes à haut risque doivent être conçus pour que des personnes physiques puissent les superviser efficacement pendant leur utilisation. La supervision doit être proportionnée au risque, à l'autonomie et au contexte. Les personnes qui y sont affectées devraient comprendre les capacités et les limites, détecter les anomalies, reconnaître le biais d'automatisation, interpréter les résultats, décider de ne pas utiliser le système ou de le remplacer, et intervenir ou arrêter le système selon une procédure sûre.

Ce sont des exigences de conception autant que des exigences d’effectif. Un évaluateur ne peut pas interpréter un résultat si les preuves sont cachées. Un évaluateur ne peut pas contester une recommandation si l’interface ne présente l’acceptation que comme la seule voie pratique. Un évaluateur ne peut pas arrêter un système si l’action d’arrêt exige une permission que personne n’a accordée. Un évaluateur ne peut pas exercer une surveillance utile s’il n’est mesuré qu’au débit. Un dossier de sécurité devrait donc traiter le rôle humain comme un moyen de contrôle avec des entrées, une autorité, une charge de travail, une formation et un comportement observable.

L’autorité est le détail que les descriptions polies omettent. Qui peut suspendre le flux de travail. Qui peut annuler une action. Qui peut déclarer qu’une hypothèse ne tient plus. Qui peut contacter le fournisseur. Qui détient le dossier. Qui décide si le risque résiduel est toujours acceptable. Si personne n’a l’autorité, la description de l’humain dans la boucle est du théâtre. La personne peut voir le résultat, mais voir n’est pas gouverner.

Une bonne surveillance est aussi sélective. L’objectif n’est pas d’envoyer chaque brouillon trivial à un comité. Il est de placer le jugement humain là où les conséquences, l’incertitude ou la contestabilité l’exigent. Certains cas peuvent être traités par des vérifications structurées. Certains nécessitent un spécialiste formé. Certains exigent deux confirmations indépendantes en vertu du droit applicable. Certains devraient être refusés. Le dossier devrait expliquer la sélection et démontrer que la voie choisie est disponible dans les opérations réelles, et non seulement dans un manuel de procédures.

Il y a une forme modeste de respect dans cette façon de concevoir. Elle accepte que les gens se fatiguent, que les files d’attente s’allongent, que les interfaces façonnent l’attention et qu’un avertissement qui apparaît cent fois puisse cesser d’être un avertissement. L’ingénierie de la sécurité a appris cela par l’expérience dans les transports et l’industrie. Les équipes d’IA n’ont pas besoin de répéter chaque leçon en menant une expérience évitable sur le public.

Le changement ne cesse d’entrer dans le dossier

Un dossier de sécurité est vivant parce que le système est vivant. La version du modèle peut changer, mais aussi l’invite, l’index de récupération, la taxonomie, la politique, le matériel, l’effectif, l’interface, la source de données ou le fournisseur. Une petite modification peut invalider une hypothèse ou déplacer un contrôle. Le risque qui en résulte peut être plus élevé, plus faible ou simplement différent. La bonne réponse n’est pas de figer le système pour toujours. Elle est de rendre le changement visible, de classer son importance et de décider quelles parties de l’argumentation doivent être réexaminées.

La pratique ferroviaire offre un modèle clair. Le règlement 402/2013 applique sa méthode commune lorsque des changements techniques, opérationnels ou organisationnels affectent le système ferroviaire. Le proposant considère l’importance du changement et, lorsque nécessaire, utilise des principes d’acceptation du risque et une évaluation indépendante. Le règlement avertit également que la totalité des changements depuis le dernier processus de risque peut avoir de l’importance. Plusieurs petits changements peuvent s’additionner pour en devenir un important. La gouvernance de l’IA a besoin de la même méfiance envers les incréments d’apparence inoffensive.

Pour l’IA, un registre des changements devrait identifier ce qui a bougé et ce qui n’a pas bougé. Les poids du modèle ont-ils changé. La collecte de preuves a-t-elle changé. Les permissions des outils ont-elles changé. La population d’utilisateurs a-t-elle changé. Le seuil a-t-il bougé. Le flux de travail est-il devenu automatique à un point qui était auparavant consultatif. Le chemin de repli est-il resté disponible. L’évaluation a-t-elle capturé le nouvel état. Le registre devrait relier chaque réponse à la revendication, au danger, au contrôle ou à l’hypothèse concerné, et préciser les tests ou les examens nécessaires avant la mise en service.

Le contrôle des changements devrait inclure un mode de mise en service sûr. Une exécution en parallèle, un déploiement progressif, une population limitée, une condition de retour arrière explicite ou une confirmation humaine peuvent empêcher le nouveau comportement de devenir un fait institutionnel avant que quiconque ne l’ait inspecté. Ces mécanismes ne sont pas la preuve que le système est faible. Ils sont la preuve que l’organisation comprend que le nouveau comportement a besoin d’un lieu pour apprendre.

La surveillance après mise sur le marché prolonge le dossier après la sortie du produit. L’article 9 renvoie aux données recueillies au titre de l’article 72, et l’article 72 exige un système de surveillance documenté pour les systèmes à haut risque tout au long de leur durée de vie. La surveillance doit rechercher les signaux qui comptent pour la revendication : des schémas d’erreur modifiés, des refus inhabituels, une utilisation inattendue, les résultats des recours, des preuves manquantes, des événements de sécurité et des défaillances des contrôles humains. Un tableau de bord qui ne rend compte que de la disponibilité est une manière agréable de passer à côté d’un problème de sécurité.

L’évaluation indépendante est une contrainte utile

Les personnes qui ont conçu un système connaissent son élégance, ses raccourcis et les pressions dans lesquelles il a été livré. Ce savoir est nécessaire. Il ne suffit pas pour accepter le risque. Une évaluation indépendante crée un espace pour que quelqu’un puisse contester l’argumentation sans porter les mêmes incitations liées au lancement. L’indépendance n’exige pas d’hostilité ni un logo externe sur chaque page. Elle exige des compétences, un périmètre, un accès aux preuves et l’autorité d’enregistrer un désaccord que le propriétaire ne peut pas simplement supprimer.

La méthode ferroviaire européenne rend cette séparation concrète. L’ERA décrit un organisme d’évaluation chargé de vérifier la bonne application du processus d’évaluation des risques et de ses résultats, avec des exigences de compétence, d’accréditation ou de reconnaissance. Le règlement autorise une entité externe ou interne indépendante et compétente, à condition qu’elle réponde aux critères. La conception est proportionnée plutôt que théâtrale. Elle reconnaît que l’assurance peut être interne lorsque l’indépendance est réelle, et qu’un badge ne peut pas sauver un évaluateur qui ne peut pas voir les preuves pertinentes.

Pour l’IA, l’indépendance peut être organisée en couches. Un responsable de domaine vérifie que l’utilisation est légitime et que l’analyse des dangers reflète le travail effectué. Un évaluateur technique vérifie l’intégration et les modes de défaillance. Un évaluateur de sécurité teste les chemins d’accès et de manipulation. Un évaluateur opérationnel vérifie la charge de travail, l’escalade et la reprise. Une fonction de gouvernance ou de conformité vérifie les enregistrements et les obligations. Pour les utilisations à conséquences élevées, une évaluation externe ou une voie passant par un organisme notifié peut s’appliquer dans le cadre juridique pertinent. Le dossier de sécurité doit nommer le rôle que joue chaque évaluateur et les questions qu’il est autorisé à poser.

L’indépendance est aussi une protection contre l’opacité des fournisseurs. Un rapport de fournisseur peut étayer une revendication, mais le déployeur doit savoir ce qui a été testé, dans quelle configuration et quelles limitations subsistent. Si un résultat critique ne peut pas être rejoué, inspecté ou transféré à la fin du contrat, la dépendance doit figurer dans le dossier. Les achats doivent demander l’accès aux preuves, l’identité des versions, la notification des incidents, la notification des changements, l’exportation, le retour en arrière et une sortie pratique. Le mot pratique fait ici un travail considérable. Un droit qui ne peut pas être exercé sous pression de temps n’est pas vraiment un contrôle.

Une bonne évaluation produit plus qu’un tampon d’approbation. Elle enregistre les conditions, les constats ouverts, les lacunes de preuves, le risque résiduel et le suivi requis. Parfois, la bonne décision est de libérer avec des restrictions. Parfois, c’est de retarder. Parfois, c’est de rejeter l’utilisation proposée. Une culture de la sécurité n’est pas une culture où chaque dossier passe. C’est une culture où la décision suit l’argumentation.

Ce que l’AI Act ajoute à l’argumentation

L’AI Act ne transforme pas chaque déploiement d’IA en chemin de fer. Il établit néanmoins un vocabulaire européen pour la gestion des risques, la documentation technique, la journalisation, la transparence, la supervision humaine, la précision, la robustesse et la cybersécurité pour les systèmes à haut risque. Un dossier de sécurité peut aider une organisation à intégrer ces obligations dans une explication opérationnelle, au lieu de traiter chaque article comme une tâche de conformité distincte.

L'article 8 lie la conformité à la finalité prévue et à l'état de l'art généralement reconnu, et permet d'intégrer les essais, rapports, informations et documentation nécessaires aux procédures d'harmonisation existantes de l'Union lorsqu'un produit est déjà couvert par celles-ci. Cela importe pour l'ingénierie de la sécurité. Il reconnaît qu'un système peut déjà disposer d'un processus d'assurance mature et que dupliquer des fichiers est moins utile que de les relier. L'étude de cas devrait montrer où se situe la preuve relative à l'IA dans l'argumentation plus large du produit ou du service.

L'article 11 et l'annexe IV donnent au dossier technique une forme générale. Il comprend la finalité prévue, les versions, les interfaces, le matériel, les méthodes de développement, l'architecture, la provenance et les caractéristiques des données, la surveillance humaine, les modifications prédéterminées, les procédures de validation et d'essai, les mesures, les journaux d'essai et les mesures de cybersécurité. Cela ne revient pas à un dossier de sécurité, mais cela fournit bon nombre des éléments dont un dossier de sécurité a besoin. Une équipe peut faire correspondre chaque élément à une affirmation et mettre en évidence ce qui n'a toujours ni propriétaire ni preuve.

L'exigence de journalisation de l'article 12 est particulièrement concrète. Si un système à haut risque doit techniquement permettre l'enregistrement automatique des événements sur toute sa durée de vie, la décision de mise sur le marché devrait s'interroger sur ce que le système peut réellement reconstituer. Quelle entrée, quel modèle, quelle configuration, quelle preuve, quel appel d'outil, quelle intervention humaine et quelle action en aval peuvent être reliés. Quels journaux relèvent du contrôle du fournisseur et lesquels relèvent de celui du déployeur. Comment sont-ils protégés et conservés. Une personne concernée ou une autorité peut-elle comprendre le cheminement pertinent sans recevoir un flux de données personnelles sans rapport.

L'article 15 ajoute une vision du cycle de vie de l'exactitude, de la robustesse et de la cybersécurité, y compris la résilience aux erreurs, aux défauts et aux incohérences et, le cas échéant, des plans de secours ou de repli. Un dossier de sécurité donne à ces termes un cadre où ils prennent sens. L'affirmation n'est pas qu'un score est élevé. L'affirmation est que le système fonctionne de manière cohérente pour sa finalité prévue, que les conditions de défaillance connues sont bornées et que le flux de travail dispose d'une réponse sûre lorsqu'elles se produisent. La preuve doit énoncer les conditions dans lesquelles la conclusion tient.

Les obligations du règlement s'appliquent selon le système, le fournisseur, le déployeur et l'usage. Un dossier de sécurité ne devrait pas prétendre qu'un modèle général règle la classification ou le conseil juridique. Il devrait consigner la décision d'applicabilité, son raisonnement et les points qui la modifieraient. C'est un autre avantage des hypothèses explicites. Lorsqu'un fait change, l'organisation sait quelle partie de l'argumentation nécessite une attention plutôt que de redécouvrir toute la carte juridique dans la panique.

L'aviation considère l'apprentissage comme partie de l'assurance

Le document de réflexion sur l'intelligence artificielle de l'Agence européenne de la sécurité aérienne, numéro 2, est utile car il ne décrit pas la sécurité de l'IA comme une propriété unique du modèle. Le document affine les orientations pour les applications de niveau 1 qui améliorent les capacités humaines et approfondit les travaux sur l'assurance de l'apprentissage, l'explicabilité de l'IA et l'évaluation fondée sur l'éthique. Il aborde également les systèmes de niveau 2, où l'IA peut prendre automatiquement des décisions sous surveillance humaine, et met en lumière le travail en équipe humain-IA et la conception d'une interaction sûre.

L'idée importante n'est pas que chaque organisation devrait copier la terminologie aéronautique. C'est que l'assurance doit suivre la relation entre le système et le travail humain. Un modèle qui aide un opérateur formé ne pose pas le même problème de sécurité qu'un modèle qui décide pendant qu'une personne se contente de superviser. La capacité de l'opérateur à comprendre, intervenir et récupérer fait partie du système. Il en va de même pour les limites autour de l'apprentissage, des mises à jour et des preuves. Le document de l'AESA donne aux équipes d'IA un exemple européen d'une industrie qui tente de rendre ces relations explicites avant le déploiement.

L'assurance de l'apprentissage est une expression utile, car l'apprentissage automatique peut modifier le récit habituel des preuves. Une version logicielle classique peut être testée par rapport à une implémentation définie. Un système adaptatif peut modifier son comportement lorsque les données, l'état ou l'environnement changent. Le dossier de sécurité doit donc préciser ce qui est autorisé à apprendre, ce qui est figé, comment le changement est détecté, quelles preuves sont actualisées et quand le système réintègre un processus d'acceptation. Si l'apprentissage est hors du périmètre du dossier, celui-ci ne concerne que le système d'hier.

Le travail en équipe humain-IA modifie également le sens de la supervision. L'humain n'est pas un frein d'urgence fixé à une machine conçue sans conducteur. L'équipe est un dispositif sociotechnique avec des rôles, des attentes, des signaux, une autorité et une formation. Une interaction sûre peut exiger que la machine explique une limite, demande une confirmation, refuse une action ou rende l'incertitude visible. Elle peut exiger que l'humain conteste la machine et que l'organisation récompense cette contestation. Les preuves doivent examiner l'interaction plutôt que de l'inférer à partir d'une phrase de politique générale.

Là encore, aucun vol ou accident inventé n'est nécessaire pour illustrer le propos. Un document de réflexion d'une agence publique suffit à montrer que la réflexion européenne sur la sécurité évolue vers l'apprentissage, l'interaction humaine et l'assurance comme un seul problème de conception. Les équipes IA peuvent lire ce document comme une invitation à se demander ce que leur propre système apprend, ce que l'opérateur peut voir et quelles preuves survivent à un changement.

Un portail de mise en production composite, présenté comme tel

Composite illustratif, et non un événement rapporté : imaginons un service public qui envisage un outil d'IA aidant le personnel à organiser le matériel des dossiers entrants avant qu'une personne ne prenne la décision. L'outil n'est pas autorisé à décider de l'éligibilité, à envoyer un avis ou à clore un dossier. La revendication de sécurité proposée est étroite : un personnel formé peut utiliser l'outil pour préparer une file de révision lorsque le dossier source est complet, que le panneau de preuves est visible, que la recommandation est clairement marquée comme telle et que le membre du personnel peut la remplacer, la suspendre ou la supprimer.

La première branche du dossier nomme les dangers. Un dossier incomplet pourrait recevoir une priorité apparemment cohérente. Un document de politique périmé pourrait influencer la recommandation. Une file pourrait exercer une pression sur un réviseur pour qu'il accepte l'ordre sans vérification. Une erreur de permission pourrait exposer le matériel d'une personne dans un autre dossier. Une mise à jour du fournisseur pourrait modifier le sens d'une catégorie. Il ne s'agit pas d'affirmer qu'un tel événement s'est produit. Ce sont des conditions que l'équipe peut raisonnablement prévoir à partir de la conception proposée.

La branche suivante nomme les contrôles. L'exhaustivité et la fraîcheur des entrées sont vérifiées avant qu'une recommandation ne soit affichée. Les preuves utilisées pour la suggestion sont visibles à côté du dossier. L'action reste un brouillon jusqu'à ce qu'une personne formée l'accepte ou la modifie. Une source manquante achemine l'élément vers un autre parcours. Les permissions sont testées à la frontière de récupération, et non seulement à l'interface utilisateur. Le flux de travail dispose d'un contrôle de suspension et d'un parcours manuel. Un changement de version s'exécute en mode limité et peut être annulé. Le dossier consigne la raison d'être de chaque contrôle et le danger auquel il répond.

Les preuves doivent ensuite exercer les contrôles. Un test de données fournit des dossiers incomplets et périmés et enregistre le résultat. Une revue d'utilisabilité vérifie si le personnel peut trouver les preuves et comprendre la recommandation sous une charge de travail réaliste. Un test d'accès vérifie qu'un dossier ne peut pas récupérer de matériel hors de son périmètre. Une répétition de mise en production vérifie que les parcours de suspension et d'annulation fonctionnent. Une revue de changement confirme que la nouvelle catégorie et la politique n'invalident pas la logique de la file. Ce sont des tests hypothétiques dans ce composite, et non des rapports de tests effectués par un service nommé.

La décision est conditionnelle. L’outil peut être utilisé pour la préparation de la file d’attente dans le cadre défini. Il ne peut pas être utilisé pour prendre ou communiquer la décision de fond. La condition selon laquelle le personnel doit avoir l’autorité de passer outre est assignée à un rôle. La condition selon laquelle la fraîcheur de la source est enregistrée est surveillée. Un changement apporté au modèle, à la politique, au contrat de données, à la population d’utilisateurs ou à l’action en aval rouvre le dossier. Si l’organisation ne peut pas prouver ces conditions, la porte de mise en production reste fermée. Cette histoire est utile précisément parce que personne n’a besoin de prétendre qu’une ville, une équipe ou un mardi particulier a existé.

Un petit exemple tiré de notre Trust Centre

Chez Dweve, notre Trust Centre public établit une distinction similaire dans son dossier d’évaluation. La page des évaluations présente une méthode qui identifie le modèle, la suite exacte, la configuration, l’état capturé, les preuves et la décision du réviseur. Elle sépare l’identité de l’évaluation de l’état changeant du modèle, distingue la couverture préparée d’un résultat réel, et décrit la relecture comme un contrat qui dépend de l’artefact capturé, du graphe d’exécution, du routage, de l’ordre, de l’état, des contraintes, des outils et des preuves. La page indique également qu’aucun premier résultat de diffusion externe n’existait au 1er août 2026, car cette diffusion n’avait pas encore eu lieu.

Ce n’est qu’un petit exemple, pas une preuve qu’un dossier de sécurité a été complété pour chaque utilisation de nos systèmes. Sa valeur réside dans la limite. Une méthode n’est pas un résultat. Une catégorie n’est pas un score. Une diffusion planifiée n’est pas une exécution historique. Un état capturé rejouable n’est pas la même chose qu’un monde vivant dont les preuves et l’état adaptatif ont changé. Ces distinctions sont exactement ce dont un dossier de sécurité a besoin lorsqu’il précise où les preuves s’appliquent et où elles s’arrêtent.

Pour une entreprise technologique européenne, publier de telles limites peut sembler laisser un espace marketing utile vide. C’est plus utile que de remplir cet espace avec un chiffre que personne ne peut défendre. La même discipline s’applique à une autorité publique, à un fournisseur, à un groupe de recherche ou à une équipe de plateforme interne. Dites quelles preuves existent, lesquelles sont préparées, lesquelles sont protégées, lesquelles n’ont pas été collectées et quel événement futur créerait un nouveau résultat. Le lecteur peut alors décider ce que les preuves soutiennent.

Notre exemple montre aussi pourquoi un Trust Centre doit être lu comme un index de preuves plutôt que comme une promesse. La page publique pointe vers l’identité, la méthode, la capture, la révision et les limites de diffusion. Elle ne supprime pas la nécessité d’inspecter un déploiement, un objectif ou une population affectée particuliers. Un dossier de sécurité ajouterait ce contexte local, les dangers du flux de travail réel et l’autorité de la personne qui prend la décision. La transparence publique est une surface de départ, pas un certificat universel.

Ce qu’un dossier de sécurité peut prouver

Un bon dossier de sécurité peut soutenir une conclusion limitée. Il peut montrer qu’un système a été conçu pour un objectif nommé, que les dangers prévisibles ont été identifiés, que les contrôles répondent à ces dangers, que les preuves ont été collectées dans des conditions définies, que les risques résiduels ont été évalués, qu’une autorité compétente a accepté ou rejeté l’utilisation, et que l’organisation dispose d’un moyen de détecter les changements et de revoir la décision. Il peut rendre un argument suffisamment inspectable pour être contesté et maintenu.

Il peut aussi montrer ce qui est incertain. Un dossier peut démontrer des preuves solides pour une population et des preuves limitées pour une autre. Il peut montrer que le système est robuste face à une classe définie d’entrées malformées, mais pas face à une classe inconnue. Il peut montrer qu’un humain peut intervenir lorsque le personnel et les autorisations sont conformes aux spécifications. Il peut montrer qu’une solution de repli existe mais n’a pas encore été exercée à pleine échelle opérationnelle. Un dossier honnête ne cache pas ces asymétries. Il en fait des conditions d’utilisation.

Un dossier de sécurité peut également étayer les décisions d'achat et de gouvernance. Un acheteur peut comparer les preuves qu'un fournisseur propose avec celles dont le processus a besoin. Un régulateur peut voir quelles affirmations sont étayées et quels enregistrements manquent. Un conseil d'administration peut comprendre où se situe le risque résiduel et qui en est responsable. Un opérateur peut savoir quel signal doit déclencher une pause. Les personnes concernées peuvent disposer d'un moyen plus clair de contester un résultat. Le dossier devient une carte des responsabilités, et non pas seulement un artefact d'ingénierie.

Il peut soutenir le changement sans prétendre que le changement est gratuit. En reliant les affirmations, les dangers, les hypothèses, les mesures de contrôle et les preuves, l'organisation peut identifier la plus petite réévaluation pertinente lorsqu'un composant change. C'est plus efficace que de répéter aveuglément chaque test et plus sûr que de supposer qu'aucune réévaluation n'est nécessaire. La proportionnalité ne fonctionne que lorsque la structure est visible. Sinon, une équipe exécute un rituel ou prend des raccourcis.

Ce qu'un dossier de sécurité ne peut pas prouver

Un dossier de sécurité ne peut pas prouver qu'aucun préjudice ne surviendra jamais. Les systèmes réels rencontrent des conditions qui n'ont pas été anticipées, et les personnes réagissent aux incitations et à la pression d'une manière qu'aucun diagramme ne peut entièrement prédire. Le but n'est pas la certitude. C'est une base disciplinée pour fonctionner, apprendre et s'arrêter lorsque cette base n'est plus valable.

Il ne peut pas prouver qu'un modèle est généralement intelligent, généralement équitable ou sûr dans tous les domaines. Une preuve a une portée. Un test sur un ensemble de données ne détermine pas la performance pour un autre. Un examen réussi dans un processus n'établit pas la même autorité dans un autre. Un itinéraire d'arrêt bien conçu ne prouve pas que chaque opérateur l'utilisera sans formation, temps ou soutien organisationnel. Le dossier doit résister à la tentation de transformer une preuve locale en adjectif global.

Il ne peut pas transférer la responsabilité à un fournisseur, un auditeur ou une marque de certification. Les preuves peuvent être produites par quelqu'un d'autre, mais le déployeur a toujours une utilisation, un processus et des personnes qui dépendent du résultat. Les contrats peuvent répartir les obligations et fournir un accès. Ils ne peuvent pas rendre une organisation inconsciente du système qu'elle exploite. Un certificat ne peut pas non plus excuser un changement qui sort le système du champ d'application évalué.

Il ne peut pas rendre une utilisation interdite ou inappropriée acceptable en ajoutant de la paperasse. Si le danger ne peut pas être maîtrisé à un niveau acceptable, la réponse peut être de changer l'objectif ou de ne pas déployer. Les dossiers de sécurité sont souvent décrits comme une assurance, mais le résultat le plus précieux peut être un non bien étayé. Un dossier complet peut encore soutenir une mauvaise décision si l'argument est faible. Le but du dossier est d'améliorer la décision, et non pas seulement de la rendre plus lisible une fois qu'elle a été prise.

Enfin, il ne peut pas remplacer la loi, le jugement professionnel ou la responsabilité démocratique. C'est un instrument d'ingénierie et de gouvernance. Il devrait aider les gens à comprendre la décision et ses conditions, et non pas prétendre trancher des questions qui relèvent des tribunaux, des régulateurs, des cliniciens, des responsables publics ou des personnes concernées.

Questions pour une réunion de lancement européenne

Une équipe n'a pas besoin d'attendre une norme parfaite ou un classeur de 400 pages pour commencer. Elle peut poser une série de questions simples. Qu'affirmons-nous exactement que ce système peut faire. Qui est concerné lorsqu'il se trompe. Quels dangers sont des conditions du système et du processus plutôt que de vagues mauvais résultats. Quelles hypothèses doivent rester vraies. Quelles preuves soutiennent chaque affirmation, et sous quelle configuration et pour quelle population. Ce qui reste incertain. Qui accepte ce risque résiduel. Qui peut arrêter le système. Quel événement rouvrirait le débat.

La réunion devrait faire de la place à une question moins confortable : qu'est-ce qui nous ferait refuser la mise en production ? Si la seule réponse est un score plus bas, l'équipe n'a probablement pas décrit ses dangers. Un refus peut être déclenché par des preuves manquantes, une hypothèse non assumée, un exercice de reprise échoué, un évaluateur inaccessible, une intégration non bornée ou un changement qui ne peut pas être rejoué. Nommer les conditions de refus transforme la sécurité en un contrôle opérationnel plutôt qu'en une humeur.

Demandez comment le dossier voyage avec le système. Un opérateur peut-il trouver l'objectif visé, les limites et le chemin d'arrêt ? Un enquêteur d'incident peut-il identifier le modèle, les preuves, les permissions et les décisions humaines qui ont compté ? Un acheteur peut-il exporter les enregistrements si le fournisseur change ? Un régulateur peut-il obtenir les informations nécessaires pour évaluer la conformité ? Une nouvelle équipe peut-elle comprendre pourquoi un contrôle existe sans interviewer la personne qui est partie ? Un dossier de sécurité qui ne vit que dans un dossier privé est une mémoire fragile, pas un argument vivant.

Demandez comment le dossier évolue. Quel est le déclencheur de révision pour une mise à jour du modèle, un changement de source, un changement de politique, un nouveau groupe d'utilisateurs, un nouvel outil, une nouvelle juridiction ou une nouvelle action en aval ? Quelles évaluations sont répétées, et quelles hypothèses sont vérifiées ? Que se passe-t-il lorsque la surveillance détecte un signal faible mais pas encore un incident grave ? Existe-t-il une voie sûre et assumée pour faire une pause et enquêter ? Une organisation bien gérée devrait pouvoir répondre sans inventer une crise pour donner l'impression que le processus est réel.

Et demandez si les preuves peuvent être lues par les personnes dont la décision est censée être soutenue. Un dossier technique que personne ne peut interpréter n'est pas transparent. Une politique que personne ne peut appliquer n'est pas un contrôle. Un tableau de bord plein de cellules vertes qui masque le dénominateur n'est pas une réassurance. La pratique européenne de la sécurité est à son meilleur lorsqu'elle rend le raisonnement accessible à la personne responsable, et pas seulement à celle qui a assemblé le document.

L'avantage discret d'un argument honnête

Les dossiers de sécurité semblent bureaucratiques de loin parce qu'ils contiennent des enregistrements, des rôles, des conditions et des points de révision. De près, ils sont un moyen de garder l'ingénierie honnête lorsque les systèmes deviennent persuasifs. Ils empêchent un test de se faire passer pour une décision, une hypothèse de se faire passer pour un fait, une évaluation planifiée de se faire passer pour un résultat et une présence humaine de se faire passer pour une autorité.

L'Europe possède déjà des morceaux de cette discipline dans ses institutions. Les chemins de fer traitent le changement technique, opérationnel et organisationnel comme une question de risque et utilisent des méthodes communes et une évaluation indépendante. Les directives de l'aviation abordent l'assurance de l'apprentissage, l'explicabilité et le travail en équipe humain-IA. La loi sur l'IA associe la gestion du risque du cycle de vie à la documentation, aux journaux, à la transparence, à la supervision humaine et à la performance du cycle de vie. Ce ne sont pas des cadres identiques, et ils ne devraient pas être aplatis en une seule liste de contrôle. Ils partagent néanmoins un respect pour les conditions, les preuves et la responsabilité.

La leçon pratique est assez simple pour être apportée à une réunion du lundi. Commencez par une affirmation qui a des limites. Nommez les dangers qui pourraient la rendre fausse. Enregistrez les hypothèses qui la soutiennent. Placez les contrôles là où le travail se fait réellement. Attachez des preuves avec une identité et une portée. Jugez le risque résiduel plutôt que de le cacher. Donnez à une personne une autorité réelle pour intervenir. Rouvrez l'argument lorsque le système ou le contexte change. Laissez un évaluateur indépendant être gênant. Publiez les limites avec le même soin que les succès.

Cette approche ne rendra pas chaque système d'IA sûr, et elle ne transformera pas l'incertitude en certitude. Elle rendra plus difficile le maintien d'une confiance dangereuse. Elle donnera aux opérateurs une voie pour faire une pause, aux évaluateurs quelque chose de concret à contester et aux personnes concernées une meilleure explication de l'endroit où se situe la responsabilité. Elle rendra également plus faciles à améliorer les bons systèmes, car l'organisation pourra voir quelle partie de l'argument a changé.

Un dossier de sécurité n'est donc pas un paragraphe final après l'ingénierie. C'est le fil qui relie l'objectif, la conception, les personnes, les preuves et le changement. L'Europe peut s'inspirer des dossiers de sécurité, car ils offrent une version civique de la discipline d'ingénierie : aucun slogan n'est accepté sans itinéraire, aucun itinéraire n'est accepté sans preuve, et aucune preuve n'est autorisée à aller plus loin que ses hypothèses.

Sources