AI-incidentmanagement onder ISO 42001 en de EU AI Act: van detectie tot meldplicht

Een klantenservicechatbot die een toezegging doet die de organisatie geld kost. Een screeningsmodel dat een groep kandidaten systematisch lager scoort. Een leverancier die zijn model bijwerkt, waarna de foutmarge ongemerkt oploopt. Dit zijn AI-incidenten, en ze hebben één ding gemeen: in een klassiek incidentproces worden ze vaak niet eens herkend. Er valt geen systeem uit, er is geen datalek, en toch is er schade of een reëel risico daarop. ISO 42001 verwacht dat organisaties hierop voorbereid zijn, en de EU AI Act voegt daar wettelijke meldplichten met harde termijnen aan toe. In dit artikel leggen we uit wat een AI-incident is, wat norm en wet vragen, en hoe je een proces inricht dat in de praktijk werkt.

## Wat is een AI-incident?

Een AI-incident is breder dan een beveiligingsincident. In de praktijk onderscheiden we vijf categorieën. Ten eerste onjuiste of schadelijke output: verzonnen antwoorden, foute adviezen of besluiten met gevolgen voor klanten of de organisatie. Ten tweede bias en discriminatie: uitkomsten die bepaalde groepen systematisch benadelen, bijvoorbeeld bij werving of kredietbeoordeling. Ten derde privacy-incidenten: persoonsgegevens die in prompts belanden, output die persoonsgegevens van anderen prijsgeeft, of data die onbedoeld voor training wordt hergebruikt. Ten vierde security-incidenten die specifiek zijn voor AI: prompt injection, jailbreaks, data poisoning of gecompromitteerde API-sleutels van modelaanbieders. Ten vijfde degradatie: model drift of een gedragswijziging na een update van de leverancier, waardoor de kwaliteit van uitkomsten sluipend verslechtert.

Wat deze categorieën gemeen hebben: er is meestal geen technische storing. Monitoring die alleen kijkt naar beschikbaarheid en foutmeldingen ziet niets. Het signaal komt in de praktijk vaak van mensen: een medewerker die vreemde output opmerkt, een klant die klaagt, een journalist die belt. Dat heeft directe gevolgen voor hoe je detectie inricht.

## Wat ISO 42001 verwacht

ISO 42001 volgt de bekende managementsysteemlogica. De norm verwacht dat je AI-systemen monitort, afwijkingen vaststelt en corrigerende maatregelen neemt (clausule 10), en Annex A bevat beheersmaatregelen rond het reageren op incidenten en het informeren van belanghebbenden. Belangrijker dan de normtekst is wat een certificerende auditor wil zien: een definitie van wat jouw organisatie als AI-incident beschouwt, meldkanalen die medewerkers ook echt kennen, belegde rollen met mandaat, registratie van incidenten en afhandeling, en aantoonbaar leren. Dat laatste betekent: oorzaakanalyse, en waar nodig het bijstellen van de risicoanalyse, het beleid of de training.

Let daarbij op het verschil tussen opzet en werking. Een draaiboek dat nooit is gebruikt of geoefend, overtuigt een auditor niet. Een geregistreerd incident met een gedegen afhandeling en een aangepaste beheersmaatregel is juist sterk bewijs dat het managementsysteem functioneert.

## Welke meldplichten de EU AI Act toevoegt

Voor aanbieders van hoog-risico AI-systemen introduceert artikel 73 van de EU AI Act een meldplicht voor ernstige incidenten bij de markttoezichtautoriteit. Een ernstig incident is kort gezegd een incident dat leidt tot overlijden of ernstige schade aan de gezondheid, een ernstige en onomkeerbare verstoring van kritieke infrastructuur, een schending van verplichtingen ter bescherming van fundamentele rechten, of ernstige schade aan eigendom of milieu.

De termijnen zijn strak. Melden moet onmiddellijk nadat een oorzakelijk verband tussen het AI-systeem en het incident is vastgesteld (of redelijkerwijs aannemelijk is), en uiterlijk vijftien dagen na kennisname. Bij overlijden geldt uiterlijk tien dagen, en bij een wijdverbreide inbreuk of ernstige verstoring van kritieke infrastructuur uiterlijk twee dagen. Gebruiksverantwoordelijken die een ernstig incident constateren, moeten de aanbieder onverwijld informeren.

Houd daarnaast rekening met samenloop. Dezelfde gebeurtenis kan tegelijk een datalek zijn onder de AVG (melden binnen 72 uur bij de Autoriteit Persoonsgegevens) en een significant incident onder NIS2. De termijnen en loketten verschillen, dus je triage moet meldplichten parallel beoordelen in plaats van na elkaar.

## Een werkbaar AI-incidentproces in vijf stappen

### Stap 1: definieer en classificeer

Neem een definitie van AI-incidenten op met concrete voorbeelden per categorie, en koppel het proces aan je AI-register zodat bij elk systeem duidelijk is wat de impact van een incident kan zijn. Werk met ernstniveaus en markeer expliciet de categorie "mogelijk wettelijk meldbaar", zodat die beoordeling nooit afhangt van de inschatting van één medewerker.

### Stap 2: richt detectie en meldkanalen in

Combineer technische monitoring (outputkwaliteit, drift, misbruikpatronen, foutpercentages) met menselijke kanalen: een laagdrempelig intern meldpunt, structurele analyse van klantklachten en contractuele afspraken met leveranciers over het melden van hun incidenten en modelwijzigingen. Bij AI zijn de menselijke kanalen minstens zo belangrijk als de technische.

### Stap 3: bepaal de respons vooraf

Containment ziet er bij AI anders uit dan bij een gehackte server. Denk aan het tijdelijk uitschakelen van een systeem en terugvallen op menselijke afhandeling, het terugzetten van een eerdere modelversie, of het aanpassen van een prompt of configuratie. Leg vooraf vast wie mag besluiten een AI-systeem stil te leggen, ook als dat het primaire proces raakt. Tijdens een incident is daar geen tijd voor discussie.

### Stap 4: regel melding en communicatie

Werk de escalatielijnen uit: wie beoordeelt of een wettelijke meldplicht geldt, wie meldt bij welke autoriteit, en wie informeert klanten en betrokkenen. Zet contactpunten en conceptteksten klaar. De termijn van twee dagen uit de AI Act haal je niet als je tijdens het incident nog moet uitzoeken waar het loket zit.

### Stap 5: leer en corrigeer

Voer een oorzaakanalyse uit: lag het aan de data, het model, de configuratie of het gebruik? Werk de risicoanalyse, het beleid en waar nodig de training bij, test de aanpassing en registreer het geheel. Die registratie is tegelijk je bewijslast voor de certificeringsaudit.

## Sluit aan op je bestaande incidentproces

Bouw geen parallel proces naast je bestaande incidentmanagement uit ISO 27001 of ITIL. Breid het bestaande proces uit: AI-categorieën in de triage, de extra meldplichten in de escalatiematrix en AI-deskundigheid in het responsteam. Eén registratiesysteem voorkomt dat incidenten tussen wal en schip vallen omdat onduidelijk is of iets een security- of een AI-incident is.

## Veelgemaakte fouten

De fouten die wij in de praktijk het meest zien: alleen security-incidenten meetellen waardoor bias- en outputincidenten onzichtbaar blijven, geen meldkanaal voor medewerkers die vreemde output signaleren, wettelijke termijnen pas opzoeken tijdens het incident, leveranciersincidenten buiten beeld houden omdat een contractuele meldplicht ontbreekt, en niets registreren, waardoor bij de certificeringsaudit geen werking aantoonbaar is.

Een geregistreerd en goed afgehandeld incident is geen teken van falen. Het is juist het bewijs dat je AI-managementsysteem doet waarvoor het bedoeld is.