Qu’est-ce qu’un audit d’IA ?
Un audit d'IA est un examen systématique, indépendant et documenté de la manière dont une organisation gouverne, développe, déploie et utilise les systèmes d'IA. Dans le contexte de ISO 42001, il s'agit du mécanisme par lequel vous vérifiez que votre système de gestion de l'IA (AIMS) est conforme à la norme, à vos propres exigences documentées, et qu'il est effectivement mis en œuvre et maintenu.
Les audits d'IA diffèrent des audits de sécurité de l'information traditionnels sur trois points essentiels. Premièrement, ils couvrent des éléments spécifiques à l'IA qui ne figurent pas dans un programme ISO 27001, tels que les analyses d'impact des systèmes d'IA, les fiches de modèles, les enregistrements de provenance des données d'entraînement et les rapports de validation du cycle de vie. Deuxièmement, ils évaluent les considérations éthiques et sociétales, notamment l'équité, la transparence et la responsabilité, et non seulement la confidentialité, l'intégrité et la disponibilité. Troisièmement, ils suivent le cycle de vie des systèmes d'IA, de la définition des objectifs à la mise hors service, au lieu d'auditer des contrôles statiques de manière isolée.
Un audit d'IA peut être interne (audit de première partie), réalisé auprès des fournisseurs (audit de deuxième partie) ou de certification ou de surveillance (audit de troisième partie, effectué par un organisme accrédité). Cette page se concentre sur l'audit interne, car c'est là que la plupart des équipes travaillent au quotidien et qu'une liste de contrôle structurée apporte le plus de valeur ajoutée. Pour un contexte plus large sur le cycle d'audit, consultez notre guide sur… Audit ISO 42001 processus.
Pourquoi utiliser une liste de contrôle d'audit IA ?
Auditer un système de gestion de l'IA sans liste de contrôle, c'est s'exposer à passer à côté de certaines informations, à oublier des preuves et à transformer les revues de direction en disputes sur le périmètre d'audit. Une liste de contrôle pratique vous apporte quatre éléments essentiels :
- Portée cohérente. Chaque audit couvre les mêmes domaines dans le même ordre, ce qui permet une comparaison pertinente d'une année sur l'autre et assure aux auditeurs de surveillance la maturité du programme.
- Preuves recevables. Pour chaque domaine de contrôle, vous savez à l'avance quelles preuves demander, ce qui signifie que les entités auditées peuvent se préparer et que vous pouvez consacrer votre temps à l'évaluation plutôt qu'à la recherche de preuves.
- Procédures de test reproductibles. Une inspection des lieux, un contrôle des preuves et un test par échantillonnage produisent des résultats reproductibles par un autre auditeur. C'est ce qu'un auditeur externe s'attend à voir.
- Critères de réussite ou d'échec clairs. Sans critères, les conclusions deviennent des opinions. Une liste de contrôle transforme chaque élément en une question fermée (oui/non) étayée par des preuves.
La liste de contrôle de ce guide est limitée aux exigences d'audit interne énoncées à la clause 9.2 et détaille les neuf points. Contrôles de l'Annexe A Ce document couvre les zones A.2 à A.10. Il est conçu pour être imprimé, rempli et joint au rapport d'audit afin de prouver que l'audit a été planifié et exécuté conformément à un périmètre défini.
Comment la norme ISO 42001 définit-elle les exigences en matière d'audit interne ?
L'article 9.2 de la norme ISO 42001 exige des organismes qu'ils réalisent des audits internes à intervalles planifiés afin de vérifier si leur système de management de la sécurité (SMS) est conforme à leurs propres exigences et à celles de la norme, et s'il est mis en œuvre et maintenu efficacement. Cette formulation est essentielle. Les auditeurs ne se contentent pas de vérifier l'existence de politiques ; ils s'assurent du bon fonctionnement du système de management dans la pratique.
Cette clause vous oblige également à :
- Planifier, établir, mettre en œuvre et maintenir un programme d'audit, y compris la fréquence, les méthodes, les responsabilités, les exigences de planification et les rapports.
- Définir les critères et le périmètre de chaque audit
- Sélectionner les auditeurs et réaliser les audits afin de garantir l'objectivité et l'impartialité.
- Communiquer les résultats des audits à la direction concernée
- Conserver les informations documentées comme preuve du programme d'audit et de ses résultats
Les lignes directrices normatives pour la mise en œuvre dans Annexe B – Orientations Cela apporte des précisions supplémentaires. En combinant la clause 9.2 avec les domaines de contrôle de l'annexe A, on obtient la structure de la liste de contrôle ci-dessous.
Tout ce dont vous avez besoin pour ISO 42001
Contenu structuré, risques cartographiés et flux de travail intégrés pour vous aider à gouverner l'IA de manière responsable et en toute confiance.
Liste de contrôle d'audit d'IA : Les 9 domaines à couvrir
L'annexe A de la norme ISO 42001 est organisée en neuf domaines de contrôle. Le tableau ci-dessous récapitule les éléments de la liste de contrôle, les preuves types et les procédures de test pour chacun d'eux. Utilisez-le comme base de votre audit interne. Pour chaque ligne, le critère de réussite est que les preuves soient disponibles, à jour, approuvées et cohérentes avec le contrôle visé.
| Zone de l'annexe A | Éléments de la liste de contrôle | Preuves typiques | Procédure de test |
|---|---|---|---|
| A.2 Politiques relatives à l'IA | Une politique en matière d'IA existe et est approuvée ; elle est alignée sur les politiques organisationnelles ; elle est révisée à intervalles définis ; elle est communiquée au personnel ; elle couvre les objectifs d'une IA responsable | Politique d'IA approuvée, journal d'examen, registre des communications, registre d'accusés de réception ou d'attestations | Examen en détail avec le responsable de la police d'assurance, vérification de l'historique des approbations et des révisions, exemples d'attestations provenant de différents rôles. |
| A.3 Organisation interne | Les rôles et responsabilités liés à l'IA sont documentés et attribués ; les lignes hiérarchiques pour les questions d'IA sont définies ; le forum de gouvernance se réunit et un compte rendu est rédigé. | Organigramme, matrice RACI pour les décisions en matière d'IA, mandat pour forum sur la gouvernance de l'IA, procès-verbaux de réunion, registre des signalements de problèmes | Entretien avec le responsable de la gouvernance de l'IA, exemples de comptes rendus de réunions des 12 derniers mois, suivi complet d'un problème signalé |
| A.4 Ressources pour les systèmes d'IA | Les ressources nécessaires aux systèmes d'IA sont identifiées et documentées (données, outils, puissance de calcul, expertise humaine) ; leur adéquation est évaluée ; la documentation est tenue à jour. | Registre des ressources, fiches de compétences, inventaire des outils et des équipements informatiques, résultats de l'évaluation de l'adéquation des ressources | Prenons l'exemple d'un système d'IA : examinons sa documentation relative aux ressources, vérifions l'existence de dossiers de compétences pour les rôles clés et confirmons les preuves d'évaluation. |
| A.5 Évaluation des impacts des systèmes d'IA | Processus d’évaluation d’impact défini ; appliqué à chaque système d’IA concerné ; couvrant les individus, les groupes et la société ; documenté et examiné | Registre des évaluations d'impact des systèmes d'IA, évaluations réalisées, dossiers d'examen et d'approbation, preuves de mesures prises concernant les impacts importants | Examinez deux systèmes d'IA, analysez leurs évaluations d'impact, vérifiez que leur périmètre couvre l'impact sociétal et suivez les actions entreprises jusqu'à leur clôture. |
| A.6 Cycle de vie d'un système d'IA | Objectifs, conception, développement, vérification, validation, déploiement, exploitation, surveillance et contrôles de mise hors service en place ; preuves recueillies à chaque étape | Documentation du cycle de vie, dossiers de conception, plans de test, rapports de validation, approbations de déploiement, journaux de surveillance, dossiers de mise hors service | Choisissez un système d'IA et parcourez son cycle de vie complet, en examinant les preuves à chaque étape ; assurez-vous que la validation était indépendante du développement. |
| A.7 Données pour les systèmes d'IA | Les contrôles d'acquisition, de qualité, de préparation et de provenance des données ont été définis et appliqués ; les sources de données ont été documentées ; la qualité a été mesurée ; la provenance a été conservée. | Inventaire des sources de données, critères de qualité, registres de préparation des données, documentation de provenance, documents relatifs à la base légale, le cas échéant. | Prélever un échantillon d'un jeu de données d'entraînement pour un système concerné, examiner la provenance, vérifier que les contrôles de qualité ont été effectués et documentés. |
| A.8 Informations destinées aux parties intéressées | Documentation système fournie aux utilisateurs ; mécanismes de signalement externes définis ; plans de communication en cas d’incident mis en place | Documentation destinée aux utilisateurs, notes de version, rapports externes, modèles et journaux de communication des incidents | Examiner la documentation utilisateur d'un système déployé, analyser les communications relatives aux incidents et vérifier que les obligations de déclaration externe sont respectées. |
| A.9 Utilisation des systèmes d'IA | Processus d'utilisation responsable définis ; utilisation prévue documentée ; objectifs d'utilisation examinés ; utilisation hors champ d'application empêchée ou détectée | registre des cas d'utilisation, déclarations d'utilisation prévue, politique d'utilisation acceptable, enregistrements de surveillance, résultats d'examen | Prenons deux exemples d'utilisation, comparons l'utilisation réelle à l'utilisation prévue, examinons le suivi et analysons les preuves. |
| A.10 Relations avec les tiers et les clients | Les fournisseurs de systèmes et de composants d'IA ont été évalués ; les responsabilités entre les parties ont été réparties ; les obligations du client ont été documentées. | Inscription des fournisseurs avec vérification préalable spécifique à l'IA, contrats, matrice de répartition des responsabilités, documentation relative aux obligations envers le client | Sélectionnez deux fournisseurs d'IA, examinez les documents de vérification préalable et les contrats, et assurez-vous que les responsabilités sont clairement définies par écrit. |
A.2 Politiques liées à l'IA
Commencez par la direction. Assurez-vous qu'une politique en matière d'IA existe, qu'elle est approuvée au niveau approprié, qu'elle est révisée selon un cycle défini et qu'elle est communiquée et prise en compte par le personnel occupant les fonctions concernées. Cette politique doit définir les orientations pour IA responsable et doit être cohérente avec les autres politiques de l'organisation, notamment en matière de sécurité de l'information et de protection des données. Les constats font souvent état de retards dans les évaluations, d'accusés de réception incomplets ou d'une absence de mention dans la politique concernant un point essentiel tel que… IA tierce outils.
A.3 Organisation interne
Auditez la structure de gouvernance. Qui est responsable des décisions relatives à l'IA ? Où les problèmes liés à l'IA sont-ils signalés et comment sont-ils traités ? Existe-t-il un forum de gouvernance doté d'un mandat clair et d'un quorum ? Analysez des exemples de comptes rendus de réunion pour en évaluer le contenu, et pas seulement la présence. On constate fréquemment qu'une matrice RACI bien fournie ne se reflète pas dans le processus décisionnel réel, ce qui est facilement vérifiable en retraçant le processus décisionnel de bout en bout.
A.4 Ressources pour les systèmes d'IA
Vérifiez que les ressources nécessaires au développement, à l'exploitation et à la gouvernance des systèmes d'IA sont identifiées, documentées et suffisantes. Ces ressources comprennent les données, les outils, l'infrastructure informatique et l'expertise humaine. Les compétences constituent souvent le point faible. Privilégiez les critères de compétences spécifiques à chaque rôle et les preuves que les personnes occupant ces rôles les maîtrisent, plutôt que les formations génériques.
A.5 Évaluation des impacts des systèmes d'IA
L’analyse d’impact des systèmes d’IA est l’une des caractéristiques essentielles de la norme ISO 42001 et une source régulière de conclusions. Cette analyse doit couvrir les impacts sur les individus, les groupes et la société, et doit être réalisée avant le déploiement et révisée lors de tout changement. Consultez notre guide détaillé sur Évaluations d'impact de l'IA Pour des exemples concrets, prenons deux systèmes d'IA concernés et suivons l'intégralité du processus d'évaluation d'impact, de l'approbation à la clôture du dossier.
A.6 Cycle de vie d'un système d'IA
Il s'agit du domaine de contrôle le plus vaste, qui justifie une analyse approfondie du cycle de vie. Choisissez un système d'IA en production et suivez son évolution depuis la définition des objectifs jusqu'à sa mise hors service, en passant par la conception, le développement, la vérification, la validation, le déploiement, l'exploitation et la surveillance. Le test crucial consiste à vérifier si la validation était indépendante du développement et si la surveillance a détecté des dérives, des incidents ou une utilisation hors périmètre. cycle de vie d'un système d'IA Le guide présente la liste complète des commandes.
A.7 Données pour les systèmes d'IA
Les données sont le facteur déterminant du succès ou de l'échec des systèmes d'IA. Il est essentiel d'auditer l'acquisition, la qualité, la préparation et la provenance des données. Il convient d'échantillonner un jeu de données d'entraînement et de vérifier que ses sources, licences, contrôles qualité et base légale (en cas de données personnelles) sont documentés. Il faut s'attendre à rencontrer des problèmes de provenance pour les systèmes plus anciens et à ce que la mesure de la qualité des données soit informelle plutôt que documentée.
A.8 Informations destinées aux parties intéressées
Assurez-vous que les utilisateurs, les clients, les organismes de réglementation et les autres parties intéressées reçoivent les informations nécessaires. Cela inclut la documentation système lors du déploiement, les communications relatives aux incidents et le respect des obligations de déclaration externe. Analysez un incident récent ou une modification importante et examinez les communications qui ont suivi.
A.9 Utilisation des systèmes d'IA
L'usage prévu de chaque système d'IA doit être documenté et son utilisation réelle doit être contrôlée. Les organisations qui développent exclusivement des IA et celles qui déploient exclusivement des IA tierces ont toutes deux besoin de ce contrôle. Il convient d'illustrer deux cas d'utilisation par des exemples, de comparer l'usage réel à l'usage prévu et d'examiner le système de surveillance qui détecte les écarts.
A.10 Relations avec les tiers et les clients
Vérifiez comment les fournisseurs d'IA sont évalués, comment les responsabilités sont réparties entre vous et eux, et comment les obligations envers le client sont documentées. Concernant plus particulièrement les fournisseurs de modèles de base et les fournisseurs d'API d'IA, assurez-vous que la diligence raisonnable a permis de recueillir la provenance des modèles, les données d'évaluation et les engagements de notification des incidents. Les constats concernent souvent des contrats antérieurs au programme d'IA et qui n'ont pas été mis à jour pour refléter les responsabilités attribuées.
Quelles preuves devez-vous recueillir lors d'un audit d'IA ?
Ce sont les preuves qui transforment une opinion en conclusion. Pour chaque élément de la liste de contrôle, veuillez recueillir au moins un des éléments suivants et le joindre aux documents de travail de l'audit :
- La preuve documentaire. Politiques, procédures, registres, dossiers d'évaluation, procès-verbaux de réunions, dossiers d'approbation et dossiers de formation.
- Preuves générées par le système. Journaux d'accès, résultats de surveillance, tableaux de bord de performance des modèles, alertes de détection de dérive et tickets d'incident.
- Notes d'entretien. Réunions de suivi avec les responsables des contrôles, les membres du forum de gouvernance, les data scientists et les chefs de produit, avec enregistrement de la date, des participants et des points clés.
- Preuves d'observation. Captures d'écran, enregistrements d'écran ou extraits annotés montrant le contrôle en fonctionnement, comme par exemple un flux d'approbation rejetant une modification non approuvée.
- Exemples de résultats de tests. Lorsque vous avez testé un échantillon (par exemple, dix évaluations d'impact de systèmes d'IA sur quinze), enregistrez la taille de l'échantillon, la méthode de sélection et le résultat (réussite ou échec) pour chaque élément.
Reliez chaque élément de preuve au contrôle qu'il soutient et à la conclusion d'audit (ou à l'absence de conclusion) qu'il engendre. Cette traçabilité est essentielle pour un auditeur externe et constitue l'une des erreurs les plus fréquentes lors des audits sur support papier. Pour une description complète des exigences de la norme en matière de documentation écrite, consultez notre guide. documentation requise selon la norme ISO 42001.
Commencer votre essai gratuit
Envie d'explorer ?
Inscrivez-vous pour votre essai gratuit dès aujourd'hui et découvrez toutes les fonctionnalités de conformité qu'ISMS.online a à offrir.
Comment documentez-vous les constatations et les mesures correctives ?
Une constatation est un énoncé de fait documenté, étayé par des preuves et évalué au regard d'un critère. Une bonne constatation comporte quatre éléments : la condition (ce qui a été observé), le critère (ce qui était requis, par exemple la clause ou le contrôle), la cause (pourquoi cela s'est produit) et la conséquence (ce que cela signifie pour les objectifs). Les constatations sont ensuite classées, généralement comme suit :
- Non-conformité majeure. Une défaillance totale d'un contrôle requis, ou de multiples non-conformités mineures connexes révélant un problème systémique, peuvent bloquer la certification si elles sont constatées par un auditeur externe.
- Non-conformité mineure. Un simple dysfonctionnement dans un système de contrôle par ailleurs fonctionnel. Il doit être corrigé, mais il bloque rarement la certification à lui seul.
- Observation ou opportunité d'amélioration. Il ne s'agit pas d'un manquement aux exigences, mais d'un point qu'il convient d'aborder avant qu'il ne soit constaté.
Toute non-conformité doit déclencher une action corrective conformément à la clause 10. Cela implique de corriger la non-conformité, d'en déterminer la cause, de vérifier l'existence de problèmes similaires ailleurs, de mettre en œuvre l'action, d'en vérifier l'efficacité et de conserver les informations documentées. Les enregistrements des actions correctives doivent être liés à la conclusion d'audit et faire le point sur toute mise à jour des risques, des contrôles, des politiques ou des procédures. Déclaration d'applicabilité.
Un modèle de constat utile comporte des colonnes pour : l’identifiant du constat, la référence d’audit, le contrôle ou la clause de l’annexe A, la condition, le critère, la cause, la conséquence, la classification, le responsable, la date d’échéance, l’action corrective, la vérification de l’efficacité et la date de clôture. Intégrez-le à vos documents de travail ou, mieux encore, à une plateforme qui assure le suivi.
Comment ISMS.online simplifie les audits d'IA
ISMS.en ligne vous fournit la liste de contrôle d'audit, la bibliothèque de preuves, le suivi des constatations et le flux de travail des actions correctives en un seul endroit, pré-cartographiés selon la norme ISO 42001.
- Programme d'audit préétabli. Plans d'audit interne alignés sur la clause 9.2 avec calendriers d'audit, définition de la portée et affectation des auditeurs intégrés.
- Modèles de listes de contrôle par zone de l'annexe A. Chaque élément de la liste de contrôle est déjà associé au contrôle correspondant, ce qui permet aux auditeurs de consacrer du temps à l'évaluation plutôt qu'à la rédaction de modèles.
- Preuves liées au niveau de contrôle. Les éléments de preuve recueillis au regard des contrôles de l'annexe A sont visibles directement dans la liste de contrôle d'audit, ce qui évite la recherche fastidieuse.
- Constatations et mesures correctives dans un seul flux de travail. Les non-conformités relevées lors de l'audit créent automatiquement des actions correctives avec des responsables, des dates d'échéance, des étapes de vérification et un suivi de clôture conformément à la clause 10.
- Éléments d'entrée pour la revue de direction générés automatiquement. Les résultats d'audit, les non-conformités et les actions sont directement intégrés au dossier de revue de direction de la clause 9.3.
- Réutilisation multi-normes. Les éléments de preuve recueillis lors des audits internes ISO 27001 sont réutilisables par rapport aux contrôles ISO 42001 pertinents, car ils résident tous sur la même plateforme.
Le résultat est qu'un audit qui aurait nécessité deux semaines de traitement de feuilles de calcul et de relance par courriel se déroule désormais comme un flux de travail géré au sein d'un seul outil, avec la piste de preuves prête pour votre auditeur externe.
Pourquoi choisir ISMS.online pour la gestion des audits IA ?
ISMS.en ligne Elle a été conçue dès le départ pour la norme ISO 42001, et couvre l'intégralité du cycle d'audit interne. Voici ce que vous obtenez en exécutant des audits IA sur la plateforme :
- Une liste de contrôle d'audit IA prête à l'emploi. Préconfiguré selon la clause 9.2 et chaque domaine de contrôle de l'annexe A, votre premier audit ne commence donc pas avec un modèle vierge.
- Bibliothèque de preuves intégrée. Les politiques, les risques, les évaluations d'impact et les éléments de preuve de contrôle sont liés aux contrôles qu'ils soutiennent, de sorte que les auditeurs ouvrent un élément et voient la preuve.
- Constatations et actions réunies en un seul endroit. Les non-conformités relevées lors de l'audit donnent lieu à des actions correctives avec des responsables, des échéances et des vérifications d'efficacité, conformément à la clause 10.
- Prêt pour la revue de direction. Les résultats d'audit, les non-conformités et les actions correctives alimentent directement le dossier de revue de direction de la clause 9.3, supprimant ainsi l'exercice de collecte de données de fin d'année.
- Partagé avec la norme ISO 27001. Un programme d'audit unique couvrant les normes ISO 42001 et ISO 27001, utilisant un seul ensemble de preuves, un seul registre des risques et un seul générateur de déclaration d'applicabilité.
- Méthode de résultats assurés. Une approche éprouvée de mise en œuvre et d'audit qui a aidé des centaines d'organisations à obtenir leur certification dès la première fois, avec un soutien humain en direct tout au long du processus.
Que vous réalisiez votre premier audit interne, que vous vous prépariez à un audit de certification de niveau 2 ou que vous gériez la surveillance annuelle, ISMS.en ligne maintient le programme structuré et les preuves défendables. Pour une vérification de préparation plus large, effectuez un analyse des écarts tout d'abord, ou parcourez notre guide complet Liste de contrôle de conformité à la norme ISO 42001.
Prêts à voir la plateforme en action ? Demander demo pour voir comment ISMS.en ligne peut alimenter votre programme d'audit IA.
FAQ
Qu'est-ce qu'une liste de contrôle d'audit d'IA ?
Une liste de contrôle d'audit de l'IA est une liste structurée d'éléments que l'auditeur interne examine pour évaluer la conformité du système de management de l'IA d'une organisation à la norme ISO 42001 et son efficacité. Une liste de contrôle pertinente couvre les exigences d'audit de la clause 9.2 et les neuf domaines de contrôle de l'annexe A (A.2 à A.10), en définissant les preuves attendues et les procédures de test pour chaque élément afin de garantir la cohérence et la validité des conclusions.
À quelle fréquence dois-je effectuer un audit interne en IA ?
La clause 9.2 de la norme ISO 42001 exige des audits internes à intervalles planifiés, sans toutefois préciser de fréquence. En pratique, la plupart des organisations réalisent un audit complet de leur système de gestion de l'IA (SGIA) chaque année, complété par des audits ciblés sur les systèmes d'IA ou les domaines de contrôle présentant un risque plus élevé, au moins tous les six mois. La fréquence des audits doit être adaptée aux risques ; ainsi, un système d'IA générative à fort impact en production justifie un examen plus fréquent qu'un outil de productivité interne.
Qui peut réaliser un audit interne ISO 42001 ?
Les auditeurs internes doivent être objectifs et impartiaux, ce qui signifie qu'ils ne peuvent pas auditer les travaux dont ils sont responsables. De nombreuses organisations font appel à une combinaison de personnel interne formé, extérieur à la fonction d'audit interne, d'une équipe d'assurance centrale ou d'un tiers indépendant agissant en tant qu'auditeur de première partie. L'essentiel est que l'auditeur soit compétent pour évaluer les contrôles spécifiques à l'audit interne et qu'il soit exempt de conflits d'intérêts concernant les domaines audités.
Quelle est la différence entre un audit d'IA et une évaluation d'impact de l'IA ?
Une évaluation d'impact d'un système d'IA (Annexe A.5) évalue les impacts potentiels d'un système d'IA sur les individus, les groupes et la société avant son déploiement et lors de son évolution. Un audit d'IA (Article 9.2) vérifie si le système de gestion qui encadre l'IA, y compris le processus d'évaluation d'impact lui-même, est conforme aux exigences et fonctionne correctement. Un audit s'appuie généralement sur un échantillon d'évaluations d'impact à titre de preuves, mais il couvre également les politiques, les contrôles du cycle de vie, la gouvernance des données, les fournisseurs et tous les autres aspects du système de gestion de l'IA.
L’audit interne doit-il couvrir systématiquement tous les systèmes d’IA ?
Non. Le programme d'audit doit garantir que, sur un cycle défini (généralement d'un à trois ans), chaque composante du système de gestion de l'information et chaque système d'IA concerné soit audité. Toutefois, certains audits peuvent être limités à un sous-ensemble. Pour la plupart des organisations, l'audit annuel sélectionne les systèmes d'IA en fonction du risque et de l'importance relative, de sorte que les systèmes à fort impact sont audités plus fréquemment, tandis que ceux présentant un risque moindre sont audités par rotation. Le programme d'audit constitue la preuve écrite de ce plan.
Comment les conclusions des audits d'IA sont-elles liées aux mesures correctives ?
Toute non-conformité relevée lors d'un audit doit déclencher une action corrective conformément à l'article 10. Cela implique de corriger le problème, d'en déterminer la cause profonde, de vérifier si le même problème existe ailleurs, de mettre en œuvre l'action, d'en vérifier l'efficacité et de conserver les informations documentées. ISMS.en ligneLes constatations relevées lors de l'audit créent automatiquement des actions correctives avec des responsables et des échéances, et la vérification de leur efficacité est suivie jusqu'à la clôture afin qu'aucun problème ne soit négligé.
Un même audit peut-il couvrir les normes ISO 42001 et ISO 27001 ?
Oui. Les deux normes suivent la structure de haut niveau de l'annexe SL et partagent des clauses relatives au leadership, à la planification, au support, à l'exploitation, à l'évaluation et à l'amélioration. L'annexe D de l'ISO 42001 établit une correspondance explicite avec l'ISO 27001. Un programme d'audit combiné est plus efficace, évite la collecte de preuves en double et est pris en charge par des plateformes multi-normes telles que… ISMS.en ligne qui utilisent un registre des risques unique, une bibliothèque de preuves et un flux de travail d'audit communs aux deux normes.
