La politique IA est le document le plus court d'un système ISO 42001 et celui que l'on écrit le plus souvent de travers, parce que la version facile est la politique de sécurité de l'information avec les noms changés. Cette version se lit de façon plausible et répond à la mauvaise norme : un système de management de l'IA demande à l'article 5.2 une politique adaptée à ce pour quoi l'entreprise utilise l'IA, qui donne le cadre des objectifs IA, s'engage sur les exigences applicables et sur l'amélioration du système, est documentée, communiquée et disponible et, à la différence de sa cousine de 27001, dit comment elle se place à côté des autres politiques de l'organisation. Trois mesures de l'annexe A portent les trois mêmes idées : A.2.2 demande la politique, A.2.3 son alignement avec les autres politiques, A.2.4 sa revue. Cet article lit l'article pour une entreprise de logiciels, expose les dix sections qu'une politique IA de deux pages porte, nomme les obligations du règlement sur l'IA que la politique doit mentionner et la seule qualification qu'elle ne doit pas faire, liste ce qu'un auditeur relève, et décrit la page gratuite qui rédige la politique à partir de onze réponses en six langues.

Ce que l'article demande, et en quoi il diffère de la politique de sécurité

Quatre des choses que l'article 5.2 demande portent sur le contenu et trois sur la gestion, et le contenu est là où la politique IA se sépare de la politique de sécurité. Adaptée à la finalité signifie que la politique nomme ce pour quoi l'entreprise utilise réellement l'IA, tri du support, revue de contrats ou assistance au code, et si elle construit les systèmes ou utilise ceux d'autrui, parce que les obligations diffèrent. Le cadre des objectifs signifie que la politique dit quels objectifs de l'article 6.2 elle fixe, et un objectif IA porte sur la destination, l'impact, la revue humaine, la provenance des données, les incidents et la maîtrise plutôt que sur la confidentialité et la disponibilité. L'engagement sur les exigences applicables est là où entre la réglementation, puisque le règlement sur l'IA impose au fournisseur et au déployeur des obligations qu'aucune politique de sécurité ne mentionne. Et l'alignement avec les autres politiques est une section à part entière : un système d'IA reste un système d'information sous la politique de sécurité, ses données restent des données sous la politique de protection des données, son fournisseur reste un fournisseur sous la politique des fournisseurs, et la politique IA doit dire ce qui se passe lorsqu'elles semblent se contredire. La gestion est la même qu'en 27001 : documentée au titre de l'article 7.5 avec un responsable, une version et une approbation, communiquée de sorte qu'un nouvel arrivant puisse dire ce qu'elle lui demande, et disponible pour un client ou un auditeur sur demande.

Les dix sections d'une politique IA courte

Finalité : ce pour quoi l'entreprise utilise l'IA aujourd'hui et qui en est responsable, en un paragraphe qui nomme les usages. Périmètre : quels systèmes, ceux construits, achetés, intégrés ou opérés, et quelles personnes. Position : la poignée de phrases qui font de la politique celle de l'entreprise, que l'IA est utilisée là où le travail s'améliore et où son comportement peut être expliqué, que chaque système a une destination déclarée et un propriétaire nommé, qu'un humain reste capable de revoir et de renverser un résultat qui affecte une personne, que l'impact est évalué avant de s'y fier et de nouveau au changement, que les données à caractère personnel ne sont utilisées que sur une base licite consignée, et que le contenu généré est signalé et vérifié. Les usages exclus : les décisions que l'entreprise ne déléguera pas à un système, écrites pour que la décision existe, si évidente qu'elle paraisse. Responsabilité : qui porte et approuve la politique, qui fait tourner le système au quotidien, et que chaque système a un propriétaire dans l'inventaire. Objectifs : trois à cinq lignes mesurables. Les exigences applicables : la section ci-dessous. La relation avec les autres politiques : à côté, pas à la place, avec un chemin pour les conflits. Communication et disponibilité : intégration, mesures de maîtrise, et disponibilité sur demande. Revue : le cycle et les trois déclencheurs, une capacité significativement nouvelle, une finalité modifiée, une position réglementaire qui a évolué.

Les obligations du règlement sur l'IA que la politique nomme, et la seule chose qu'elle ne doit pas dire

La section des exigences est courte et précise. L'obligation de maîtrise de l'IA de l'article 4 lie tout fournisseur et tout déployeur, de sorte que la politique engage l'entreprise à donner à chaque personne qui opère un système ou s'y fie les connaissances que son rôle exige, et renvoie au registre de maîtrise qui le montre. Lorsque l'entreprise construit des systèmes, elle s'engage sur les obligations du fournisseur telles qu'elles s'appliquent à la qualification de chaque système et sur les engagements qu'elle donne aux clients qui les déploient ; lorsqu'elle utilise les systèmes d'autrui, sur les obligations du déployeur et sur la notice d'utilisation du fournisseur auquel elle se fie. Lorsqu'elle génère du texte, des images ou du code, les obligations de transparence de l'article 50 s'appliquent à ce qu'elle construit ou utilise. Lorsqu'elle traite des données à caractère personnel, le droit de la protection des données s'applique, analyse d'impact comprise lorsque le traitement est susceptible d'engendrer un risque élevé. Et pour chaque système, la politique engage à une détermination consignée de son caractère à haut risque ou non au titre du règlement sur l'IA, faite sur les faits de ce système et conservée avec son entrée d'inventaire. Ce que la politique ne doit pas faire, c'est cette détermination elle-même : une phrase disant « nos systèmes ne sont pas à haut risque » est une conclusion juridique sur des faits que la politique ne détient pas, et un auditeur la lit exactement ainsi. La détermination du haut risque est une page à part, par système, et l'analyse d'impact sur les droits fondamentaux suit lorsque la réponse est oui.

Les erreurs qu'un auditeur relève

La politique de sécurité avec les noms changés, qui n'a ni position sur l'IA, ni usages exclus, ni inventaire. « IA responsable » comme adjectifs, sans objectif mesurable et sans rien dans la revue de direction qui le mesure. Une qualification dans la politique, haut risque ou non, affirmée pour tous les systèmes à la fois. Aucun chemin pour une personne affectée par un résultat vers un humain qui peut le renverser, dans une entreprise dont les systèmes affectent des personnes. Le silence sur l'IA générative dans une entreprise où tout le monde l'utilise. Aucune phrase sur la façon dont la politique se place à côté des politiques de sécurité, de protection des données et des fournisseurs, de sorte que le premier conflit est tranché par celui qui le remarque. Et les trois habituelles : pas d'approbation, pas de trace de communication, pas de revue depuis la première version. Chacune est un constat au premier audit, et chacune s'évite en écrivant les dix sections et en les datant.

Quoi en faire

Répondez aux onze questions de la page gratuite : ce pour quoi l'entreprise utilise l'IA, si elle construit des systèmes, utilise ceux d'autrui ou les deux, si les résultats influencent des décisions sur des personnes, si les systèmes traitent des données à caractère personnel, si elle utilise de l'IA générative, les usages qu'elle exclut, qui fait tourner le système, qui approuve la politique, le cycle de revue et les objectifs qu'elle mesurera. La page rédige les dix sections en mots simples, nomme les obligations du règlement sur l'IA que les réponses appellent et la détermination dont chaque système a encore besoin, et dit comment la politique se place à côté des autres. Modifiez-la jusqu'à ce qu'elle sonne comme l'entreprise, faites-la signer et dater par l'approbateur, publiez-la là où chaque arrivant la lit, et commencez l'inventaire et les évaluations d'impact qu'elle promet. StandardOS rédige la politique IA et les politiques d'évaluation d'impact, de gouvernance des données et des fournisseurs en dessous à partir des mêmes réponses, versionnées, et transforme l'inventaire, les évaluations et les preuves de maîtrise en lignes et en dates ; les mesures de l'annexe A disent, dans les mots de StandardOS, ce que chacune des trois mesures relatives à la politique demande.