Interne audit van je AI-managementsysteem: zo vul je ISO 42001 clausule 9.2 in

Certificeringsinstellingen beginnen bij een ISO 42001-audit vaak bij hoofdstuk 9. Daar blijkt namelijk of een organisatie zichzelf serieus controleert. Clausule 9.2 verplicht tot interne audits op geplande momenten, en tot een auditprogramma dat die audits stuurt. Wie hier een lege plek heeft, komt niet door de certificeringsaudit. Dit artikel beschrijft hoe je zo'n programma inricht, wat een auditor inhoudelijk toetst en welke afwijkingen wij het vaakst tegenkomen.

Wat clausule 9.2 van je vraagt

De norm stelt twee eisen die in de praktijk vaak door elkaar lopen. De eerste (9.2.1) is dat je interne audits uitvoert die vaststellen of het AI-managementsysteem voldoet aan de eisen van ISO/IEC 42001 en aan je eigen eisen: je AI-beleid, je risicobehandelplan, je eigen procedures. De tweede (9.2.2) is dat je een auditprogramma hebt waarin frequentie, methoden, verantwoordelijkheden, planningseisen en rapportage zijn vastgelegd. Eén losse audit zonder programma voldoet niet. Een keurig programma zonder uitgevoerde audits evenmin.

In 9.2.1 staat nog een woord dat het meeste onderscheid maakt tussen een goede en een zwakke interne audit: effectief. Je moet aantonen dat het AIMS conform is ingericht, maar ook dat het daadwerkelijk functioneert. Dat verschil is niet academisch. Een organisatie kan een prima procedure hebben voor AI-risicobeoordeling en tegelijk drie modellen in productie hebben die nooit zijn beoordeeld. Alleen het eerste toetsen levert een schoon rapport op dat nergens over gaat.

Het auditprogramma: cyclus, frequentie en dekking

Een auditprogramma legt vast hoe je over een cyclus heen alle eisen dekt. In de praktijk werken organisaties met een cyclus van één tot drie jaar, waarbinnen alle HLS-clausules (4 tot en met 10) en alle van toepassing verklaarde Annex A-controls minstens één keer aan bod komen. Bij een cyclus langer dan een jaar moet je kunnen laten zien welk deel wanneer is gepland, anders ontstaan er blinde vlekken die de certificeringsinstelling er zo uithaalt.

De frequentie hoort risicogestuurd te zijn. AI-systemen met een hoog risicoprofiel, systemen die directe gevolgen hebben voor mensen, en processen waar vorig jaar afwijkingen op zijn geconstateerd, audit je vaker dan een intern hulpmiddel dat tekstsuggesties doet. Een programma dat elk proces met dezelfde frequentie behandelt, is meestal een teken dat de risicoafweging niet is gemaakt.

Verder moet het programma meebewegen. Nieuwe AI-systemen die live gaan, een reorganisatie van het governanceteam, een AI-incident, een wijziging in de regelgeving: het zijn allemaal redenen om de planning tussentijds bij te stellen. Een programma dat drie jaar ongewijzigd blijft terwijl de AI-portfolio verdubbelt, is een afwijking op zichzelf.

Onafhankelijkheid en competentie van de auditor

Twee eisen bepalen of de audit iets waard is. De auditor mag zijn eigen werk niet beoordelen, en de auditor moet begrijpen waar hij naar kijkt. Het eerste is een organisatorisch probleem: in kleinere bedrijven is de persoon die het AI-beleid heeft geschreven vaak ook degene die het het beste kent. Rotatie tussen afdelingen werkt tot op zekere hoogte, uitbesteden aan een externe partij lost het definitief op. Leg de afweging vast, en leg per audit een onafhankelijkheidsverklaring of belangenverklaring vast.

Competentie is bij ISO 42001 zwaarder dan bij ISO 9001 of ISO 27001. Een auditor die de norm kent maar niet weet wat drift is, wat een validatieset doet of hoe een model in productie wordt gemonitord, komt niet verder dan de documentkast. Wij zien in de praktijk dat een duo goed werkt: iemand met auditmethodologie en iemand met kennis van de modellen. Leg de competentie-eisen vast in een matrix en onderbouw ze met trainingsbewijs.

Wat de auditor inhoudelijk toetst

Een interne AIMS-audit volgt de norm, maar de aandacht ligt bij een aantal punten die typisch AI-specifiek zijn.

Bij hoofdstuk 4 gaat het om de rolbepaling. Ben je aanbieder, ontwikkelaar of gebruiker van een AI-systeem, en soms alle drie tegelijk voor verschillende systemen? Die vraag bepaalt de scope, en veel organisaties hebben hem nooit expliciet beantwoord.

Bij hoofdstuk 6 gaat het om de twee beoordelingen die naast elkaar bestaan: de AI-risicobeoordeling (6.1.2), die kijkt naar risico's voor de organisatie en haar doelstellingen, en de impactbeoordeling van het AI-systeem (6.1.4), die kijkt naar de gevolgen voor individuen en groepen. Ze worden vaak samengevoegd tot één document waarin de tweede invalshoek verdwijnt.

Bij hoofdstuk 8 en 9 gaat het om de operationele kant. Zijn de risicobeoordelingen daadwerkelijk uitgevoerd voor alle systemen in scope, en zijn ze actueel? Wordt er gemeten op meer dan alleen nauwkeurigheid en beschikbaarheid, dus ook op zaken als eerlijkheid, het aantal keer dat een mens een uitkomst terugdraait, en signalen van drift?

Bij de Annex A-controls gaat de aandacht meestal naar de levenscyclus van het AI-systeem, de herkomst en kwaliteit van data, de informatie die je aan gebruikers en betrokkenen verstrekt, en de afspraken met leveranciers van modellen en API's.

Vragen die een interne auditor stelt

Een paar voorbeelden uit onze eigen interne-auditmodule, die je kunt gebruiken om zelf te oefenen. Kun je de laatst uitgevoerde AI-risicobeoordeling laten zien, met de datum en de naam van degene die hem heeft vastgesteld? Welke AI-systemen vallen buiten de scope van het AIMS, en op grond waarvan is dat besloten? Hoe weet je dat een model dat vorig jaar is gevalideerd, vandaag nog steeds doet wat het moet doen?

En verder: wie mag besluiten dat een AI-systeem uit productie gaat, en is dat besluit ooit genomen? Welke opleiding hebben de mensen gehad die dagelijks met deze systemen werken, en waarop is de inhoud van die opleiding gebaseerd? Hoe is een concern of klacht over een AI-uitkomst het afgelopen jaar afgehandeld, en waar staat dat vastgelegd?

Bewijs verzamelen dat verder gaat dan documenten

Documentatie beoordelen is de makkelijke helft. De andere helft is vaststellen dat het beschreven proces ook is gevolgd. Dat betekent steekproeven: pak drie AI-systemen uit het register en volg ze door de hele keten. Is er een impactbeoordeling? Is die na de laatste grote wijziging geactualiseerd? Zit er monitoringdata achter? Zijn de afwijkende meetwaarden opgevolgd? Staat de leverancier in het contractregister met de juiste afspraken?

Bij ISO 42001 komt daar een technische component bij. Vraag om een export van monitoringdashboards, om logbestanden van menselijke interventies, om de testrapportage van de laatste modelupdate. Een auditor die alleen interviewt en documenten leest, kan geen uitspraak doen over effectiviteit.

Bevindingen classificeren en opvolgen

Bevindingen krijgen een classificatie: een grote afwijking als een norm-eis structureel niet is ingevuld, een kleine afwijking bij een incidentele tekortkoming, en daarnaast observaties en verbeterpunten. Leg de criteria voor die indeling vooraf vast, anders wordt de classificatie een onderhandeling.

De opvolging valt onder clausule 10.2. Daar gaat het niet alleen om het herstellen van de situatie, maar om oorzaakanalyse en het voorkomen van herhaling. Wij zien vaak dat de containment wel gebeurt (het ontbrekende document wordt alsnog opgesteld) en de oorzaakanalyse niet. Twaalf maanden later staat dezelfde bevinding weer in het rapport. Verifieer daarnaast of de maatregel heeft gewerkt: een corrigerende maatregel zonder effectiviteitstoets is niet afgerond.

De afwijkingen die wij het vaakst zien op 9.2 zelf

Audits die alleen documentatie beoordelen en niet toetsen of processen worden uitgevoerd. Een auditprogramma dat niet bestaat of niet is vastgelegd, waardoor audits ad hoc plaatsvinden. Annex A-controls die buiten de auditcyclus vallen omdat de aandacht volledig naar de HLS-hoofdstukken ging. Auditors zonder aantoonbare AI-kennis. Bevindingen die niet geclassificeerd zijn, waardoor niemand kan zien of het beter of slechter gaat. En audits die conformiteit toetsen maar nooit de vraag stellen of het AIMS zijn doel bereikt.

De link met de EU AI Act

Voor aanbieders van AI-systemen met een hoog risico is een kwaliteitsmanagementsysteem geen keuze. Artikel 17 van Verordening (EU) 2024/1689 verplicht daartoe, inclusief procedures voor ontwerp, verificatie, datagovernance, risicobeheer, monitoring na het in de handel brengen en incidentmelding. Een werkend AIMS met een serieus intern auditprogramma levert een groot deel van dat bewijs. Wil je eerst weten in welke risicocategorie je systemen vallen, gebruik dan de zelfassessment op /ai-act-check.

Bron: Verordening (EU) 2024/1689 (AI-verordening), artikel 17 (kwaliteitsmanagementsysteem), via EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Hoe wij het aanpakken

Secure Audit voert interne audits uit op ISO 42001, ISO 27001, NEN 7510, ISO 27701 en de andere managementsysteemnormen. In ons auditplatform zit per normelement het criterium, een set interviewvragen, een beschrijving van hoe een goed ingerichte situatie eruitziet, de veelvoorkomende afwijkingen en de documenten die je kunt verwachten. Dat maakt het mogelijk om het auditprogramma over meerdere normen heen te plannen en overlappende clausules één keer te toetsen. Neem contact op als je wilt bespreken hoe je auditcyclus voor het AIMS eruit kan zien.