CAPA maakt van elk AI-incident een vast governanceritme: signaleren, oorzaken analyseren, verbeteren, effect meten en aantoonbaar leren borgen.
Een AI-incident is pas afgerond als niet alleen de fout is hersteld. De organisatie moet ook weten waarom het misging, herhaling voorkomen en aantonen dat de gekozen maatregel werkt. CAPA maakt daarvan een vast ritme van signaleren, analyseren, verbeteren en bewijzen.
Een AI-model geeft opeens meer verkeerde uitkomsten. Een chatbot deelt informatie die niet had mogen worden gebruikt. Een klant begrijpt niet dat AI een rol speelde. Of een bepaalde groep mensen wordt vaker afgewezen dan andere groepen.
De eerste reactie is vaak praktisch: herstel de fout zo snel mogelijk. Het model wordt opnieuw getraind. De tekst op de website wordt aangepast. Een verkeerde beslissing wordt teruggedraaid. De betrokken klant ontvangt uitleg. Daarna wordt het incident gesloten.
Dat snelle herstel is nodig. Maar het is niet genoeg. Want wat was de werkelijke oorzaak? Kan dezelfde fout ook in andere systemen zitten? Is de werkwijze aangepast? En waaruit blijkt dat de maatregel echt werkt?
De bestuurlijke vraag moet daarom niet zijn: “Is het incident opgelost?” De betere vraag is:
“Hebben wij aantoonbaar geleerd en is de kans op herhaling kleiner geworden?”
Daar begint CAPA.
Bij een AI-incident denken organisaties vaak eerst aan een technische storing. Maar een incident kan op veel meer manieren ontstaan. Het kan gaan om:
Incidenten moeten daarom zichtbaar en herleidbaar worden gemaakt. Zonder een vast format blijft een incident gemakkelijk hangen in een e-mail, telefoongesprek of losse notitie. Dan ontbreekt overzicht. De organisatie ziet geen patronen en kan niet aantonen wat zij heeft geleerd.
Dat risico is bij AI extra groot. Een AI-systeem is na de ingebruikname niet automatisch stabiel. Data verandert. Gebruikers gaan anders met het systeem om. Klanten stellen nieuwe vragen. De omgeving verandert. Daardoor kunnen prestaties, fairness en uitlegbaarheid langzaam achteruitgaan.
Dit wordt ook wel drift genoemd. Het gedrag van het model verschuift, terwijl het systeem technisch gezien nog steeds actief is.
Daarom eindigt AI-governance niet bij de ingebruikname van een systeem. Juist daarna begint het toezicht op de werking in de praktijk. Dit heet post-market monitoring: het actief volgen van het AI-systeem nadat het in gebruik is genomen.
Bij een incident lopen vier soorten acties vaak door elkaar. Dat maakt het moeilijk om te beoordelen of het probleem werkelijk is opgelost.
De eerste stap is het beperken van de schade. Een organisatie kan bijvoorbeeld:
Deze actie beschermt klanten, burgers, medewerkers en de organisatie tegen verdere schade.
De correctieve actie herstelt het probleem dat nu zichtbaar is.
Een model met slechte prestaties wordt bijvoorbeeld opnieuw getraind. Een fout in de code wordt aangepast. Een onduidelijke melding wordt herschreven. Deze stap brengt het systeem terug naar een aanvaardbare situatie.
De preventieve actie voorkomt dat hetzelfde probleem opnieuw ontstaat. Denk aan:
De preventieve actie verandert dus niet alleen het systeem. Zij kan ook het proces, de rolverdeling, de documentatie of het gedrag veranderen.
Tot slot moet de organisatie vaststellen of de maatregel werkelijk effect heeft.
Is het aantal klachten gedaald? Is de afwijking tussen groepen kleiner geworden? Blijft de modelprestatie stabiel? Worden menselijke controles nu op tijd uitgevoerd? Pas daarna kan een CAPA worden gesloten.
De root cause beschrijft de echte oorzaak. De correctieve actie lost het huidige probleem op. De preventieve actie voorkomt herhaling. Bewijs van uitvoering en een aparte effectmeting ronden de leercyclus af.
Een geïmplementeerde maatregel is nog geen bewezen verbetering.
CAPA staat voor Corrective and Preventive Actions. In eenvoudige taal:
CAPA voegt daar nog iets belangrijks aan toe: een onderzoek naar de echte oorzaak en een controle op het uiteindelijke effect. Het is dus meer dan een actielijst.
De volledige keten ziet er als volgt uit:
Kort samengevat: eerst wordt het probleem hersteld, daarna wordt voorkomen dat het terugkomt. De root cause is daarbij niet het zichtbare probleem, maar de onderliggende reden waarom het kon ontstaan.
Een zwakke oorzaakanalyse blijft dicht bij het zichtbare probleem.
“Het model gaf een verkeerde uitkomst.” “De medewerker gebruikte de verkeerde versie.” “De uitleg was niet duidelijk.”
Dat zijn beschrijvingen van wat er gebeurde. Het zijn nog geen oorzaken. Een goede root cause-analyse kijkt ten minste vanuit vier kanten.
Deze vier kanten moeten in samenhang worden bekeken.
Een dataprobleem kan bijvoorbeeld ontstaan doordat het proces voor datakwaliteit niet goed is ingericht. Een menselijke fout kan voortkomen uit een onduidelijke instructie. En een technisch probleem kan te laat worden ontdekt doordat niemand eigenaar was van de monitoring.
Maak daarom expliciet onderscheid tussen proces-, data-, mens- en techniekoorzaken. Daarmee voorkomt de organisatie dat alleen het symptoom wordt opgelost.
Neem een AI-model dat kredietaanvragen beoordeelt. De monitoring laat zien dat jonge ondernemers vaker een hoge risicoscore krijgen dan vergelijkbare andere klanten.
Een mogelijke correctieve actie is het model opnieuw trainen met een actuele en beter verdeelde dataset. Daarmee wordt het huidige probleem aangepakt.
Een mogelijke preventieve actie is om voor iedere volgende modelversie een aparte fairness-test voor jonge ondernemers verplicht te maken. Deze test wordt opgenomen in de voorwaarden waaraan een nieuwe release moet voldoen.
De eerste actie herstelt het bestaande model. De tweede actie verandert het ontwikkelproces.
Dat verschil is essentieel. Zonder de preventieve actie kan bij een volgende modelversie precies hetzelfde probleem terugkomen. Deze combinatie leidt in de praktijk tot stabielere prestaties en minder escalaties naar de klachtenafdeling en het toezicht.
Hetzelfde geldt bij onduidelijke AI-uitleg. De correctieve actie is dan het aanpassen van de huidige tekst. De preventieve actie kan zijn dat iedere nieuwe AI-tekst vóór publicatie verplicht wordt beoordeeld op begrijpelijkheid, B1-taal en een duidelijke route naar menselijk contact.
De correctieve actie repareert het product. De preventieve actie versterkt het systeem eromheen.
CAPA’s worden in de praktijk soms gesloten zodra de actiehouder meldt dat de maatregel is uitgevoerd: de training is gegeven, het model is opnieuw getraind, de werkinstructie is aangepast, de nieuwe controle staat in het proces.
Dat zijn nuttige bewijzen van uitvoering. Maar ze zeggen nog niet of het probleem is verminderd. Daarvoor zijn twee soorten bewijs nodig.
Hiermee laat de organisatie zien dat de afgesproken actie echt is uitgevoerd. Voorbeelden zijn:
Hiermee laat de organisatie zien dat de maatregel het gewenste resultaat heeft. Voorbeelden zijn:
De sluitingsbeslissing hoort daarom niet alleen te bestaan uit de vraag “Is de actie uitgevoerd?” Daar moet een tweede vraag bij:
“Laat de praktijk zien dat het risico daadwerkelijk kleiner is geworden?”
Effectmeting hoort dus bij de formele CAPA-sluiting. Een verbetercyclus zonder gemeten effect levert vooral schijncontrole op.
CAPA werkt niet wanneer het een aparte lijst van de complianceafdeling wordt.
Dan ontstaat een tweede werkelijkheid. Het AI-team ontwikkelt nieuwe functies en releases. Daarnaast bestaat een CAPA-register dat af en toe wordt besproken. Openstaande acties krijgen daardoor gemakkelijk minder aandacht dan nieuwe functionaliteit.
Neem incidenten en CAPA’s daarom op in het normale ontwikkel- en bestuursritme.
Bij de planning wordt bepaald welke CAPA’s in de volgende sprint of werkperiode worden uitgevoerd. Een belangrijk fairnessprobleem krijgt bijvoorbeeld voorrang boven een nieuwe functie.
De Definition of Ready, kortweg DoR, beschrijft wanneer werk klaar is om te beginnen. Bij een nieuwe release wordt gecontroleerd of bekende incidenten en openstaande CAPA’s zijn meegenomen in het ontwerp en de testcriteria.
De Definition of Done, kortweg DoD, beschrijft wanneer werk werkelijk klaar is. Een wijziging is niet gereed wanneer een bijbehorende CAPA nog openstaat zonder duidelijk plan. Ook moeten de afgesproken tests en bewijsstukken beschikbaar zijn.
Tijdens de review laat het team niet alleen zien wat technisch is gebouwd. Het toont ook:
Tijdens de terugblik bespreekt het team wat het van incidenten heeft geleerd. De vraag is niet alleen wat fout ging, maar vooral: “Wat hadden wij eerder kunnen zien?”
In de kwartaalreview worden patronen zichtbaar gemaakt. Ontstaan veel incidenten rond hetzelfde systeem? Zit het probleem vaak in data? Komen klachten steeds uit hetzelfde kanaal? Zijn meerdere leveranciers betrokken bij vergelijkbare afwijkingen?
Zo wordt verbeteren geen los project, maar onderdeel van het vaste werkritme.
Een CAPA-proces werkt alleen als duidelijk is wie waarvoor verantwoordelijk is.
De eerste lijn bestaat uit onder meer de Product Owner, Data Science, IT Operations en de verantwoordelijke businessmanager. Zij:
De eerste lijn moet dus niet alleen melden wat er misging. Zij moet de verbetering uitvoeren en kunnen uitleggen waarom de gekozen maatregel voldoende is.
Compliance, Risk, Privacy en Ethics vormen meestal de tweede lijn. Zij:
De tweede lijn mag ondersteunen en bewegen, maar moet voorkomen dat zij zelf eigenaar wordt van het operationele probleem.
Interne audit beoordeelt niet ieder technisch detail. Zij kijkt naar de werking van het hele CAPA-proces. Belangrijke vragen zijn:
Dezelfde rolverdeling geldt voor post-market monitoring. De eerste lijn monitort en signaleert. De tweede lijn bewaakt onder meer CAPA-effectiviteit en naleving. De derde lijn beoordeelt onafhankelijk de werking van het monitoringstelsel. Een centrale AI-governancerol bewaakt de samenhang en rapportage.
Eén incident vertelt iets over één gebeurtenis. Tien vergelijkbare incidenten vertellen iets over de kwaliteit van het governancestelsel.
Daarom moet het bestuur niet alleen kijken naar het aantal incidenten. Een grote organisatie met een veilige meldcultuur kan relatief veel incidenten registreren. Dat hoeft niet direct slecht te zijn. Een organisatie met bijna geen gemelde incidenten kan juist blinde vlekken hebben.
De betere managementinformatie gaat over patronen:
Een klein dashboard is vaak voldoende. Denk aan indicatoren voor tijdige beoordeling, herhaalde incidenten, modellen met drift en tijdig uitgevoerde post-market reviews. Overschrijding van een afgesproken grens is in beginsel aanleiding voor een nieuwe CAPA.
Ook de ouderdom van openstaande CAPA’s is belangrijk. Als veel acties langer dan negentig dagen openstaan, kan dat betekenen dat eigenaarschap, prioriteit of capaciteit tekortschiet. Het percentage oude openstaande CAPA’s is daarmee bruikbare bestuurlijke stuurinformatie.
Deze grenzen zijn geen vaste norm voor iedere organisatie. Het passende niveau hangt af van de risico’s, schaal en volwassenheid. Het principe is wel steeds hetzelfde:
meet niet alleen hoeveel er misgaat, maar vooral hoe goed de organisatie leert.
Een verzekeraar gebruikt een AI-model om mogelijke fraude te signaleren.
Na verloop van tijd stijgt het aantal false positives. Dat zijn meldingen van mogelijke fraude die na onderzoek geen fraude blijken te zijn. Klanten ervaren extra vragen en vertraging. Medewerkers krijgen meer onnodig onderzoekswerk.
Een volwassen CAPA-proces ziet er dan als volgt uit:
Deze aanpak leidt tot stabielere prestaties, minder onterechte signalen en lagere werkdruk. Ook ontstaat een duidelijk bewijsdossier richting toezicht en bestuur.
Het sterke punt is niet alleen dat het model is hersteld. Het ontwikkel- en monitoringsproces is eveneens aangepast. Daardoor wordt de organisatie beter in het vroeg herkennen van hetzelfde risico.
Een organisatie hoeft niet te wachten op een groot AI-governanceprogramma. Een praktisch CAPA-ritme kan in drie stappen worden opgebouwd.
Stel één incident- en CAPA-format vast. Leg minimaal vast:
Koppel ieder incident aan het AI-register. Zo blijft zichtbaar bij welk systeem, proces en risico het incident hoort.
Neem openstaande CAPA’s op in de planning. Pas DoR en DoD aan. Zorg dat bekende incidenten vóór een nieuwe release worden meegenomen en dat werk niet als gereed wordt gemeld zonder bewijs.
Laat teams in reviews niet alleen functionaliteit tonen, maar ook incidenten, acties en effecten.
Maak een compact dashboard met trends, ouderdom en herhaling. Bespreek ieder kwartaal:
Laat interne audit daarna risicogericht toetsen of gesloten CAPA’s ook werkelijk aantoonbaar effectief zijn.
Een bestuur hoeft niet ieder technisch incident te begrijpen. Het moet wel kunnen beoordelen of de organisatie aantoonbaar leert. Daarvoor zijn vijf vragen voldoende:
Wanneer het antwoord op een van deze vragen onduidelijk is, is het incident waarschijnlijk technisch gesloten, maar bestuurlijk nog niet afgerond.
AI-systemen zullen fouten blijven maken. Data zal veranderen. Modellen kunnen verschuiven. Medewerkers kunnen waarschuwingen missen. Klanten kunnen uitleg anders begrijpen dan verwacht.
Sterke AI-governance belooft daarom niet dat er nooit meer iets misgaat. Zij zorgt ervoor dat afwijkingen vroeg worden ontdekt, schade wordt beperkt en de organisatie aantoonbaar beter wordt.
CAPA maakt die beweging zichtbaar: signaleren → registreren → analyseren → herstellen → voorkomen → meten → borgen.
Deze aanpak verandert losse incidenten in patronen waarop kan worden gestuurd. Het versterkt de meldveiligheid, verkleint de kans op herhaling en geeft bestuur en toezicht inzicht in wat er is gebeurd én wat ermee is gedaan.
Een incident mag snel worden hersteld.
Een CAPA mag pas worden gesloten als het leren is bewezen.
Van bestuurlijke AI-vraag tot DORA, SIRA, BCM of hersteltraject: plan een vrijblijvend gesprek met een specialist.