Corrigerende maatregelen in het AIMS: zo richt je clausule 10.2 van ISO 42001 in

Elke organisatie met een AI-managementsysteem krijgt met afwijkingen te maken: een interne audit die constateert dat risicobeoordelingen niet worden geactualiseerd, een productiemodel dat bevooroordeelde output geeft, een klacht van een betrokkene. Clausule 10.2 van ISO/IEC 42001 schrijft voor wat er dan moet gebeuren. Het proces zelf is bekend terrein voor wie een ISO 27001- of 9001-systeem beheert. De AI-specifieke invulling is dat niet, en juist daar kijkt een auditor naar. Dit artikel beschrijft de stappen van 10.2, de oorzaakanalyse bij AI-afwijkingen en het bewijs dat je moet kunnen laten zien.

Correctie is geen corrigerende maatregel

De norm maakt een onderscheid dat in de praktijk vaak vervaagt. De correctie is de directe reactie: het probleem indammen en de gevolgen aanpakken. De corrigerende maatregel gaat over de oorzaak: waarom kon dit gebeuren, en wat verandert er zodat het niet terugkomt?

Een voorbeeld. De monitoring signaleert dat een kredietscoringsmodel na een hertraining aantoonbaar slechter presteert voor een specifieke groep aanvragers. De correctie: terugrollen naar de vorige modelversie en de geraakte aanvragen herbeoordelen. De corrigerende maatregel begint bij de vraag waarom de fairnesstest dit niet heeft tegengehouden. Misschien ontbrak de groep in de testdata, misschien was er wel een test maar geen drempel die de uitrol blokkeerde. Het antwoord bepaalt de maatregel: testdata aanvullen, een blokkerende gate inrichten in het uitrolproces, of beide. Wie alleen terugrolt en verder gaat, heeft het probleem verplaatst naar de volgende hertraining.

De stappen van clausule 10.2

In eigen woorden vraagt de norm bij elke afwijking het volgende. Reageer op de afwijking en beheers de gevolgen. Beoordeel of maatregelen nodig zijn om de oorzaak weg te nemen, zodat de afwijking niet opnieuw optreedt. Voer die maatregelen uit. Verifieer daarna of ze doeltreffend zijn geweest. En pas zo nodig het AIMS zelf aan, want soms is de afwijking een symptoom van een proces dat niet deugt. Over elke stap moet gedocumenteerde informatie worden bijgehouden: de aard van de afwijking, de genomen maatregelen en het resultaat.

Die laatste stap, het aanpassen van het managementsysteem, wordt het vaakst overgeslagen. Als drie afwijkingen in een jaar dezelfde onderliggende oorzaak hebben, bijvoorbeeld dat wijzigingen aan modellen buiten het wijzigingsbeheer om gaan, dan is het wijzigingsproces zelf aan herziening toe. Losse maatregelen per afwijking lossen dat niet op.

Waar afwijkingen vandaan komen

Afwijkingen komen uit meer bronnen dan de interne audit alleen. Denk aan monitoringsignalen (drift, teruglopende fairnessmetrieken), AI-incidenten, klachten van gebruikers of betrokkenen, bevindingen uit de managementreview en meldingen van medewerkers. Een werkend 10.2-proces heeft voor al die bronnen één route: de afwijking wordt geregistreerd, geclassificeerd (bijvoorbeeld minor of major), toegewezen aan een verantwoordelijke en voorzien van een termijn.

Het AI-incident verdient hier aparte aandacht. In onze auditpraktijk is dit een van de meest voorkomende bevindingen bij hoofdstuk 10: een incident met schadelijke of bevooroordeelde AI-output wordt afgehandeld als technisch probleem. Het model wordt bijgesteld, de melding gesloten. De koppeling naar het AIMS ontbreekt, dus niemand stelt de vraag welk governanceproces het incident mogelijk maakte. De les bereikt het managementsysteem nooit. De remedie is procedureel eenvoudig: neem in de incidentprocedure een vaste stap op die bij elk AI-incident beoordeelt of er ook een afwijking van het AIMS achter zit, en registreer die beoordeling.

Oorzaakanalyse bij AI-afwijkingen

Voor de oorzaakanalyse werken de vertrouwde technieken, zoals de 5x-waarom-methode of een visgraatdiagram. Het verschil zit in de categorieën oorzaken die je bij AI moet overwegen. Naast proces- en menskant zijn dat: de data (kwaliteit, representativiteit, herkomst), het model (gedrag na hertraining, drift) en de governance (ontbrekende gates, onduidelijke verantwoordelijkheden, verouderde risicobeoordelingen).

Een oorzaakanalyse die stopt bij "menselijke fout" of "het model deed het niet goed" is vrijwel altijd te ondiep. Doorvragen loont. Waarom kon één persoon zonder review een model uitrollen? Waarom viel de datakwaliteitscontrole niet op dat een bronveld was gewijzigd? Vaak ligt onder een technische afwijking een governance-oorzaak, en die is met een technische fix niet weggenomen.

Doeltreffendheid verifiëren

De stap die bij audits het vaakst als ontbrekend wordt genoteerd: de verificatie. Een maatregel doorvoeren is niet hetzelfde als vaststellen dat hij werkt. Plan bij elke corrigerende maatregel een controlemoment in en leg vast hoe je de werking meet. Bij het kredietscoringsvoorbeeld: draait de blokkerende fairnessgate inmiddels aantoonbaar mee in het uitrolproces, en is de eerstvolgende hertraining er daadwerkelijk langs gegaan? Een registratie met alleen de status "afgerond" zegt een auditor niets; een verificatie met datum, uitkomst en beoordelaar wel.

Welk bewijs een auditor verwacht

Bij een certificeringsaudit of interne audit van hoofdstuk 10 wordt om een beperkt aantal documenten gevraagd. Een procedure voor afwijkingen en corrigerende maatregelen die op het AIMS van toepassing is. Een register of log van afwijkingen, met classificatie, eigenaar en status. Oorzaakanalyses, in elk geval voor de zwaardere gevallen. Verificaties van doeltreffendheid met datum en uitkomst. En bij AI-incidenten: de koppeling tussen het incidentrapport en de bijbehorende afwijking in het register. De interviewvragen zijn navenant concreet: loop eens door de afhandeling van een recente afwijking heen, laat de oorzaakanalyse zien, toon aan dat de maatregel werkt.

Wie een ISO 27001-systeem heeft, kan het bestaande afwijkingenregister uitbreiden in plaats van een tweede register op te tuigen. Voorwaarde is dat AIMS-afwijkingen herkenbaar zijn en dat de oorzaakcategorieën voor AI erin passen.

Klein houden en laten draaien

Het risico van clausule 10.2 is overinrichting: een formulier met twintig velden dat niemand invult, waarna afwijkingen buiten het register om worden opgelost. Een register met tien velden dat gebruikt wordt, is meer waard dan een uitgebreid proces op papier. Begin klein, registreer ook de kleine afwijkingen en laat het proces een paar maanden draaien voordat de certificerende instelling komt. Een leeg register op de eerste certificeringsaudit is geen teken van perfectie; auditors lezen het als een teken dat het proces niet wordt gebruikt.

De interne-auditmodule van het Secure Audit platform bevat voor clausule 10.2 het criterium, de interviewvragen, een voorbeeld van een goede inrichting en de documenten die je paraat wilt hebben. Zo toets je vooraf of je verbeterproces auditbestendig is. Neem contact op voor een vrijblijvend gesprek.