Tout système de management ISO a une appréciation des risques, et une entreprise qui applique déjà l'ISO 27001 s'attend à ce que la norme IA demande la même chose avec un nouveau nom. Elle le demande, à l'article 6.1.2, puis elle demande quelque chose dont la norme de sécurité n'a aucune version : une analyse, par système d'IA, de ce que le système pourrait faire aux personnes qu'il touche et à la société, pas à l'entreprise. C'est l'article 6.1.4, l'analyse d'impact d'un système d'IA, et c'est l'article qui fait de l'ISO 42001 une norme différente plutôt que l'ISO 27001 avec le mot « IA » inséré. Cet article lit la clause et les mesures qui la portent, expose les trois niveaux de conséquences et ce à quoi ressemble une note à chacun, montre où l'analyse rencontre le règlement sur l'IA, liste les erreurs qu'un auditeur relève, et renvoie à la page gratuite qui rédige l'analyse pour un système dans l'ordre de l'article.
Ce que l'article demande, et pourquoi il n'a pas de pendant dans l'ISO 27001
L'article 6.1.4 demande à l'entreprise de définir un processus pour évaluer les conséquences potentielles de ses systèmes d'IA pour les individus, pour les groupes d'individus et pour la société, d'exécuter ce processus, de conserver les résultats comme information documentée et de les utiliser : les impacts alimentent l'appréciation des risques de 6.1.2, le traitement de 6.1.3 et le cycle de vie de l'article 8, où 8.4 réalise l'analyse en exploitation comme 6.1.4 l'a planifiée. Quatre mesures de l'annexe A portent le même sujet : l'une demande le processus et quand il doit tourner, une autre la conservation de chaque résultat, une autre l'évaluation du préjudice pour les individus et pour les groupes identifiables, et une autre le préjudice au-delà des personnes qui utilisent le système, pour la société. La raison pour laquelle il n'y a pas de pendant dans l'ISO 27001 est la direction du préjudice. Un risque de sécurité est un préjudice pour les informations de l'entreprise et, à travers elles, pour l'entreprise ; le registre demande quelle vraisemblance et quelle gravité pour nous. Un impact IA est un préjudice que le système de l'entreprise cause à quelqu'un d'autre, une personne refusée, mal classée, profilée ou mal informée, un groupe moins bien traité en moyenne, un public qui perd quelque chose dont il dépendait, et l'entreprise peut ne pas le ressentir du tout. La norme demande donc un second registre avec un autre sujet, et un auditeur qui trouve les impacts écrits comme des lignes du registre des risques de sécurité, avec l'entreprise pour seule partie exposée, écrit un constat sur 6.1.4 et sur les deux mesures relatives au préjudice en même temps.
Les trois niveaux, et ce à quoi ressemble une note à chacun
La norme nomme les trois niveaux ; l'entreprise décide comment les noter, et une vraisemblance et une gravité par niveau est la plus petite notation qui permette encore de lire un résultat. Les individus : ce que le système fait à une personne, un client, un candidat, un salarié, un patient, un lecteur, et à ses données, sa sécurité, ses droits, son argent et sa réputation. Un classificateur de tickets de support qui note un ticket en priorité basse par erreur fait attendre un client ; un modèle de crédit qui note un candidat de travers refuse un prêt ; la gravité diffère de plusieurs ordres de grandeur, et la note le dit. Les groupes : les effets qui n'apparaissent qu'à l'échelle d'une population, et c'est là que vit la plus grande part du préjudice que les systèmes d'IA causent réellement, une langue, une région, un âge, un handicap, un genre, un segment de clientèle moins bien traité en moyenne parce que les données d'entraînement ou les seuils le traitent moins bien. Les cas individuels ont l'air corrects un par un ; la note de groupe est la ligne qui amène l'entreprise à mesurer la précision par groupe plutôt qu'en bloc. La société : les conséquences au-delà des utilisateurs et de l'entreprise, l'environnement, le débat public, l'emploi dans un secteur, la confiance dans un service dont les gens dépendent, et pour la plupart des systèmes internes la note honnête est faible avec une phrase disant pourquoi, ce qui est un meilleur enregistrement qu'un niveau laissé vide. L'analyse pèse ensuite les bénéfices pour les mêmes personnes, parce qu'un résultat qui ne lit que le préjudice ne peut pas dire pourquoi le système tourne, fixe les mesures qui limitent le préjudice et le contrôle humain qui rattrape ce que les mesures manquent, et lit la plus haute des six notes contre eux : acceptable en l'état du système, acceptable avec les mesures, qui deviennent alors des actions avec un responsable et une date, ou non acceptable, auquel cas la finalité, la conception ou les mesures changent et l'analyse est réécrite.
Où l'analyse rencontre le règlement sur l'IA
Le règlement sur l'IA ne demande pas d'analyse d'impact ISO 42001 et l'ISO 42001 ne demande pas la conformité au règlement sur l'IA ; les deux se rencontrent dans l'enregistrement. Au titre de l'article 27, certains déployeurs de systèmes d'IA à haut risque, les organismes publics et les opérateurs privés de services publics parmi eux, ainsi que les déployeurs des systèmes de crédit et d'assurance que l'annexe liste, évaluent l'impact sur les droits fondamentaux avant la première utilisation, en nommant le processus, la période, les personnes concernées, les risques de préjudice, le contrôle humain et ce qui se passe si le préjudice se matérialise. Chacun de ces éléments est une section de l'analyse 6.1.4 déjà rédigée, si bien que l'enregistrement du système de management est l'entrée de l'enregistrement légal, et l'entreprise qui a le premier rédige le second en un après-midi. Au titre de l'article 50, un système qui interagit avec des personnes ou génère du contenu porte une obligation de transparence, et la ligne des mesures de l'analyse est l'endroit où l'entreprise enregistre comment les personnes concernées sont informées. Et qu'un système soit à haut risque ou non est une lecture des listes du règlement que l'entreprise fait et enregistre, avec sa date, de sorte que l'analyse porte la lecture à côté des impacts sans prétendre être un conseil juridique. La page gratuite enregistre quatre lectures, pas encore lue, haut risque, obligation de transparence, ni l'un ni l'autre, et écrit la conséquence de chacune dans le résultat ; la page de l'article 27 décide si l'analyse sur les droits fondamentaux est due, et la page haut risque lit un système contre les listes.
Les erreurs qu'un auditeur relève
L'analyse écrite comme une ligne du registre des risques, avec l'entreprise pour seule partie exposée, ce qui manque le sujet de l'article. Des conséquences écrites pour les individus seulement, si bien que le niveau des groupes, où vit la mesure propre de la norme, manque. Chaque niveau noté sans une phrase disant en quoi consiste le préjudice, si bien que la note ne peut pas être vérifiée. Les bénéfices omis, si bien que le résultat est une liste de préjudices sans balance. Les mesures écrites comme des intentions plutôt que des actions avec un responsable et une date, si bien que l'audit suivant les trouve inchangées. Une analyse faite une fois, au lancement, et jamais plus, bien que le modèle, les données et les utilisateurs aient changé. Pas d'inventaire des systèmes d'IA, si bien que personne ne peut dire quels systèmes ont une analyse et lesquels n'en ont pas, et l'auditeur tire celui qui n'en a pas. Un contrôle humain nommé dans l'analyse et absent en pratique, l'agent qui relit chaque brouillon en charge normale et aucun en période de pointe. Et la lecture au regard du règlement sur l'IA décidée dans l'analyse comme s'il s'agissait d'une qualification juridique, ou absente comme si le règlement ne s'appliquait pas ; l'enregistrement veut la lecture de l'entreprise, datée, avec le raisonnement, et rien de plus. Chacune de ces erreurs s'évite en rédigeant l'analyse dans l'ordre de l'article et en laissant un niveau vide plutôt qu'en le sautant, parce qu'un niveau vide se voit et qu'un niveau sauté ne se voit pas.
Que faire de tout cela
Saisissez le système sur la page gratuite : l'entreprise, le système, le rôle de l'entreprise, où en est le système, le responsable et les dates ; la finalité prévue et le mauvais usage raisonnablement prévisible ; les personnes qu'il touche ; pour chacun des trois niveaux une vraisemblance, une gravité et la nature du préjudice ; les bénéfices, les mesures et le contrôle humain ; le résultat et la lecture au regard du règlement sur l'IA. La page rédige l'analyse dans l'ordre de l'article, avec les faits et les notes dans le lien et le texte libre gardé sur la page, et laisse un niveau vide comme un blanc à remplir. Copiez-la, faites-la lire par le responsable et par quelqu'un qui n'a pas construit le système, classez-la comme l'information documentée du système, et mettez la date de revue au calendrier. StandardOS tient une analyse par système d'IA dans l'inventaire, avec les groupes concernés, la finalité, le mauvais usage prévisible et les conséquences comme champs, les mesures comme actions, la date de revue au calendrier et la lecture au regard du règlement sur l'IA à côté, de sorte que les mesures de l'annexe A sur l'analyse d'impact sont prouvées par l'enregistrement lui-même ; la politique IA promet les analyses, et la liste des mesures est l'endroit où siègent les quatre mesures derrière celle-ci.