AI-incident

Wat is een AI-incident?

Een AI-incident is elk voorval waarbij een AI-systeem, of de manier waarop mensen het gebruiken, schade veroorzaakt of daar rakelings langs gaat. De opvolgmail die naar vierhonderd klanten vertrok in plaats van naar veertig. De prijs die een model een komma te laag online zette. Het document dat een assistent bovenhaalde voor een collega die het niet mocht zien.

De term dekt twee ladingen, en wie ze door elkaar haalt, gaat in beide richtingen de mist in. De operationele betekenis is die hierboven: er is iets misgelopen, en je hebt een manier nodig om het te merken, stil te leggen, recht te zetten en eruit te leren. De juridische betekenis is veel smaller. De AI Act definieert een ernstig incident en koppelt daar een meldplicht aan, en zo goed als niets uit een gewone werkweek valt daaronder. De expertengroep van de OESO voegde in mei 2024 een bruikbaar derde woord toe: bij een incident is de schade er echt geweest, bij een gevaar had ze er plausibel kunnen zijn. Bijna-ongevallen horen in hetzelfde logboek, want dat zijn de goedkoopste lessen die je krijgt.

Wat de AI Act een ernstig incident noemt

Artikel 3, punt 49 omschrijft een ernstig incident als een incident of gebrekkige werking van een AI-systeem dat direct of indirect leidt tot een van vier dingen: het overlijden van een persoon of ernstige schade aan iemands gezondheid, een ernstige en onomkeerbare verstoring van het beheer of de werking van kritieke infrastructuur, de schending van verplichtingen uit het Unierecht die grondrechten beschermen, of ernstige schade aan eigendom of het milieu. Lees dat lijstje één keer en de schaal is duidelijk. Een chatbot die een klant de verkeerde leverdatum geeft, staat er niet bij.

Artikel 73 legt vast wie meldt en hoe snel. Aanbieders van AI-systemen met een hoog risico melden aan de markttoezichtautoriteit van de lidstaat waar het incident zich voordeed, meteen nadat het oorzakelijk verband vaststaat en in elk geval binnen 15 dagen nadat ze ervan op de hoogte zijn. Twee uitzonderingen verkorten dat: twee dagen bij een wijdverspreide inbreuk of een ernstige en onomkeerbare verstoring van kritieke infrastructuur, en 10 dagen als er iemand overleden is, geteld vanaf het moment dat je een oorzakelijk verband vermoedt en niet vanaf het bewijs ervan. Een eerste onvolledig rapport gevolgd door een volledig rapport mag uitdrukkelijk.

De meeste Belgische bedrijven zijn geen aanbieder maar gebruiksverantwoordelijke, en dan geldt artikel 26, lid 5. Denk je dat het systeem gebruiken volgens de handleiding een risico oplevert, dan breng je de aanbieder zonder onnodige vertraging op de hoogte en schors je het gebruik. Stel je een ernstig incident vast, dan verwittig je eerst de aanbieder, dan de invoerder of distributeur, en dan de bevoegde markttoezichtautoriteit. De aanbieder bouwt en rapporteert; jij kijkt toe en trekt aan de bel. Over de timing: verordening (EU) 2026/1744, de Digital Omnibus on AI, is op 27 juli 2026 in werking getreden en schoof de verplichtingen voor hoog risico op naar 2 december 2027 voor losstaande systemen en 2 augustus 2028 voor AI die ingebouwd zit in producten die al onder de Europese productveiligheidsregels vallen.

Wat telt als incident in een gewoon bedrijf

Niets daarvan zegt je wat je op een dinsdag moet noteren. Dit is de set die het logboek van een KMO effectief vult.

• Een massamail op een foute lijst. Een query geeft meer rijen terug dan iemand verwachtte en de mail vertrekt keurig naar de verkeerde mensen.

• Een fout cijfer online. Een gegenereerde prijs, voorraad of leveringstermijn belandt in de webshop voor iemand ze gelezen heeft.

• Een lek via een assistent. Iemand stelt een vraag en krijgt een antwoord uit een bestand dat hij niet had mogen openen.

• Een agent die gehandeld heeft. Een boeking gemaakt, een record verwijderd, een leverancier gemaild, zonder dat een mens het goedkeurde.

• Een gehallucineerd antwoord bij een klant. Een verzonnen garantietermijn, een regel die niet bestaat, een product dat je niet verkoopt.

Een werkbare regel: noteer het als een klant of een collega het gezien heeft, als er geld of een record bewogen is, als persoonsgegevens ergens beland zijn waar ze niet horen, of als je iets hebt moeten uitzetten. Alles waarvoor je de noodstop voor AI-agents indrukt, verdient ook een lijn in het logboek.

De vijf stappen als het misgaat

1. Merk het op. Iemand moet het zien en weten waar hij het kan zeggen. De site reliability engineering-praktijk van Google raadt aan om vroeg een incident uit te roepen in plaats van te wachten tot je zeker bent, met drie aanleidingen: er moet een tweede team bij, klanten zien het, of een uur geconcentreerd zoeken heeft het niet opgelost.

2. Leg het stil. Zet het systeem uit voor je het begrijpt. Agent af, trigger uit, pagina offline. Een uur stilstand kost minder dan nog een uur waarin dezelfde output buitengaat.

3. Zoek uit wie geraakt is. Welke records, welke klanten, welke periode. Deze stap beslist of je een vervelend voorval hebt of een meldplicht, en hier verdient je audit trail zichzelf terug. Logt niets wat het model te zien kreeg en wat het gedaan heeft, dan zit je te gissen.

4. Zet recht en zeg het. Data herstellen, correctie versturen, de klant bellen die de verkeerde offerte kreeg. Een korte eerlijke mail dezelfde dag is beter dan een gepolijste volgende week.

5. Schrijf het op. Zolang het vers is, in het register, telkens in dezelfde vorm.

Zitten er persoonsgegevens in, dan loopt er een tweede klok

Artikel 33 van de GDPR geeft de verwerkingsverantwoordelijke 72 uur vanaf het moment dat hij kennis krijgt van een gegevenslek om het te melden bij de toezichthouder, tenzij het lek waarschijnlijk geen risico inhoudt voor de rechten en vrijheden van de betrokkenen. In België gaat die melding via het portaal van de Gegevensbeschermingsautoriteit, en de GBA zegt er letterlijk bij dat meldingen per mail niet behandeld worden. Artikel 34 voegt eraan toe dat je bij een hoog risico ook de betrokkenen zelf moet verwittigen, en artikel 33, lid 5 verplicht je om elk lek te documenteren, ook de lekken die je bewust niet gemeld hebt en waarom.

Een klein incident dat goed afliep

Een installatiebedrijf met veertig mensen draait een interne assistent over zijn SharePoint. Op een dinsdagochtend vraagt een projectingenieur naar loonschalen voor een offerte en krijgt een tabel met de individuele lonen van de vier werfleiders terug, uit een HR-map.

Hij zegt het binnen het uur tegen de officemanager. Zij zet de SharePoint-connector uit, tien minuten werk, en de assistent blijft antwoorden uit zijn andere bronnen. Waarom het gebeurd is weet nog niemand, en dat hoeft ook niet meteen. Daarna gaan de logs erop na voor elke vraag die de HR-site raakte: drie in zes weken, allemaal van dezelfde ingenieur, allemaal over het onderwerp van vanochtend. Er is niets buiten het bedrijf geraakt, en de vier werfleiders van wie het loon te zien was, horen het dezelfde dag.

De postmortem vindt de oorzaak, en die zit niet in het model. De zoekindex was opgebouwd met een beheerdersaccount, waardoor de assistent sites kon lezen die zijn gebruikers niet konden lezen. Drie dingen veranderen: de index draait onder een account met de rechten van een gewone werknemer, de HR-site wordt expliciet uitgesloten, en een maandelijks overzicht toont welke sites geïndexeerd zijn en met wiens rechten. Voor de GDPR-vraag documenteert het bedrijf het lek en beredeneert het waarom er niet gemeld wordt: intern gebleven, vier betrokkenen, binnen het uur ingedamd, geen kopieën gemaakt. Had dezelfde index een publieke chatbot gevoed, dan was het antwoord omgekeerd geweest en waren de 72 uur die ochtend om negen uur beginnen lopen.

Het register en de postmortem

Het register is een tabel, en een spreadsheet is een prima start. Eén rij per incident: wanneer je het merkte, welk systeem, wat er gebeurd is in één zin, wie of wat geraakt werd, wat je meteen gedaan hebt, wie de opvolging trekt, en waar de postmortem staat. Meer niet, want een formulier dat niemand invult is slechter dan geen formulier. Het werkt enkel als het vasthangt aan een lijst van wat je effectief draait, dus een agentregister of AI-inventaris geeft elke lijn een systeemnaam die iets betekent, en beantwoordt de vraag die altijd als tweede komt: waar draait dat ding nog meer.

Google omschrijft een postmortem in zijn SRE-boek als een geschreven verslag van een incident, de impact ervan, wat er ondernomen is om het op te lossen, de onderliggende oorzaken en de vervolgacties die herhaling tegenhouden. Wat het doet werken, is dat er niemand met de vinger gewezen wordt: je gaat ervan uit dat iedereen verstandig gehandeld heeft met de informatie die hij had, en je zoekt uit waarom die informatie fout of onvolledig was. Zoals hetzelfde boek het zegt: mensen kan je niet herstellen, systemen en processen wel.

Wat een postmortem waard is, zie je aan de acties die eruit komen. Een recht dat versmald wordt, een limiet die ingesteld wordt, een goedkeuringsstap die erbij komt, een voorbeeld dat in de testset belandt: dat zijn oplossingen. "We gaan voortaan beter opletten met die HR-map" is een goed voornemen met zes weken houdbaarheid. Moet iemand de opvolging onthouden, dan komt hetzelfde incident onder een andere naam terug.

Een AI-incident tegenover een gewoon IT-incident

De stappen lijken op elkaar, dus worden ze vaak als hetzelfde behandeld. Waar ze uit elkaar gaan, is bij de vraag wat opgelost betekent.

Onder een gewoon IT-incident zit een defect. De schijf liep vol, een certificaat verliep, een query joinde op de verkeerde kolom. Je vindt de lijn, je past ze aan, dezelfde input geeft voortaan telkens het juiste resultaat, en je bewijst het met een test die voor de wijziging faalt en erna slaagt.

Onder een AI-incident zit vaak geen lijn die je kan aanpassen. Het model gaf een fout antwoord op een input die het vorige week prima aankon en volgende week misschien opnieuw aankan. Er is niets stuk. Het gedrag is een verdeling en geen regel, dus "dit gebeurt niet meer" is een belofte die je niet eerlijk kan maken. Wat je wel kan veranderen, is de omgeving waarin het model werkt: waar het bij kan, welke context het krijgt, welke versie het draait, en wie bevestigt voor een actie het huis verlaat. De oplossing beweegt naar buiten toe, weg van het model, en je regressietest wordt een set echte voorbeelden, ook dat ene van vandaag, die je opnieuw draait bij elke promptwijziging en elke modelupgrade.

Een AI-incident afsluiten betekent dus dat je benoemt welk soort output fout liep en wat dat soort voortaan tegenhoudt, niet dat je naar een gepatchte regel wijst. Ook indammen weegt zwaarder, want je kan er niet op rekenen dat de oplossing snel klaar is. Voor alles wat je klanten mailt of in je boekhouding schrijft, blijft de betrouwbare controle de menselijke bevestiging vlak voor de actie, plus een manier om het systeem stil te leggen terwijl je nadenkt.