Les 38 contrôles
ne sont pas une liste à cocher.
C'est le contresens le plus fréquent en début de projet, et il coûte des mois de travail inutile. Les contrôles de l'Annexe A sont une référence dans laquelle on puise, pas un programme imposé.
Quatre étapes,
dans cet ordre.
L'ordre compte : commencer par l'Annexe A plutôt que par les risques produit un système de management qui ne correspond à rien.
- 1Identifier les risquesLa sélection ne part pas de l'Annexe A, mais de l'appréciation des risques menée au titre de la clause 6. Sans elle, il n'y a aucun critère pour retenir ou écarter quoi que ce soit.
- 2Rapprocher les contrôles des risquesChaque risque retenu appelle un traitement. L'Annexe A sert alors de point de comparaison, contrôle par contrôle, pour s'assurer que rien d'indispensable au traitement n'a été laissé de côté — pas de liste à appliquer intégralement.
- 3Compléter si nécessaireLes contrôles de l'Annexe A ne sont pas exhaustifs. Si un risque reste sans réponse, l'organisme doit identifier les contrôles supplémentaires nécessaires ; il peut les concevoir lui-même ou s'inspirer d'autres référentiels.
- 4Justifier inclusions et exclusionsC'est l'objet de la déclaration d'applicabilité, qui recense aussi ces contrôles propres. Un contrôle écarté n'est pas un manquement si la justification tient. Elle peut par exemple montrer que l'appréciation des risques ne le rend pas nécessaire et qu'aucune exigence externe applicable ne l'impose, ou que cette exigence prévoit une exception.
La déclaration
d'applicabilité.
C'est le document que l'auditeur ouvre en premier. Il recense tous les contrôles nécessaires, ceux de l'Annexe A comme ceux que l'organisme ajoute, et relie chacun à une décision : retenu, et pourquoi ; écarté, et pourquoi. Les risques identifiés et les contrôles qui y répondent doivent aussi y apparaître.
Une exclusion mal justifiée est un constat d'audit. Une exclusion bien justifiée ne l'est pas — même quand elle porte sur un domaine entier. Elle ne dispense pas pour autant des clauses qui traitent du même sujet : écarter A.5, par exemple, laisse entières les évaluations d'impact exigées par 6.1.4 et 8.4.
Où se trouve chaque contrôle
- A.2Politiques relatives à l'IA3
- A.3Organisation interne2
- A.4Ressources des systèmes d'IA5
- A.5Évaluation des impacts4
- A.6Cycle de vie du système d'IA9
- A.7Données pour les systèmes d'IA5
- A.8Information des parties intéressées4
- A.9Utilisation des systèmes d'IA3
- A.10Tiers et clients3
Les contrôles
qui méritent leur page.
La plupart des contrôles se comprennent dans leur domaine. Quelques-uns portent assez d'enjeux — réglementaires, contractuels, opérationnels — pour être traités à part.
A.6.2.8 — Enregistrer les journaux d'événements d'un système d'IA
Le contrôle A.6.2.8 d'ISO/IEC 42001 tient en un choix : à quelles étapes de la vie d'un système d'IA les journaux sont tenus, sans descendre sous la période d'utilisation. Leur contenu et leur durée de conservation, eux, restent à votre main. Pourquoi il reste excluable, et pourquoi l'AI Act rend l'exclusion intenable pour un système à haut risque.
A.10.3A.10.3 — Fournisseurs d'IA : garder la maîtrise de ce qu'on achète
Ce que le contrôle A.10.3 d'ISO/IEC 42001 attend quand vos systèmes d'IA reposent sur des tiers — API de modèle, cloud, assistant intégré, modèle à poids ouverts, logiciel métier, données, prestataire. Les questions à poser, ce qu'il faut obtenir par contrat, et les changements silencieux à surveiller.
Sélectionner est une chose.
Le prouver en est une autre.
Une fois les contrôles retenus, reste à constituer les preuves que l'auditeur acceptera. C'est l'objet des étapes « Mettre en œuvre » et « Prouver » du parcours.