Hoe een AI-incidentprocedure te maken

Uw AI-assistent vertelde een klant zojuist het verkeerde retourbeleid — en de klant heeft daar al op gehandeld. Of uw geautomatiseerde kredietbeoordelingsmodel heeft een volledig valide klant als hoog risico gemarkeerd, en niemand ontdekte dat gedurende drie dagen. Dit zijn geen hypothetische randgevallen meer; dit zijn het soort incidenten dat wekelijks in echte inboxen belandt. Dit artikel biedt u een concrete, stapsgewijze AI-incidentprocedure — met vastgelegde rollen, directe acties en een checklist — die uw organisatie nu meteen kan aanpassen en gebruiken.

Waarom de meeste organisaties onvoorbereid zijn op AI-incidenten

Bedrijven investeren fors in de inzet van AI-tools — chatbots, aanbevelingssystemen, documentsamenvatters, geautomatiseerde workflows — maar bepalen zelden wat er moet gebeuren wanneer die tools het laten afweten. Het gevolg is geïmproviseerd brandjes blussen: het supportteam geeft de schuld aan het technische team, het technische team geeft de schuld aan de modelleverancier, en niemand heeft een duidelijk mandaat om de klant te beschermen of het incident te documenteren.

Dit is een governance-kloof. En nu toezichthouders in de EU (via de AI Act), de VS en andere rechtsgebieden organisaties steeds vaker verplichten om aantoonbaar toezicht te houden op geautomatiseerde systemen, wordt die kloof een aansprakelijkheid — niet slechts een operationeel ongemak.

Een AI-incidentprocedure dicht die kloof. Het hoeft geen beleidsdocument van 50 pagina's te zijn. Het moet helder genoeg zijn zodat elke medewerker, ook op een slechte dag, het kan volgen.

Wat telt als een AI-incident?

Voordat u op een incident kunt reageren, moet uw team het eens zijn over hoe zo'n incident eruitziet. Een bruikbare werkdefinitie:

Een AI-incident is elke gebeurtenis waarbij een AI-systeem een uitkomst produceert — een beslissing, aanbeveling, stuk content of actie — die schade veroorzaakt of dreigt te veroorzaken aan een klant, medewerker, derde partij of de organisatie zelf.

Praktische voorbeelden die onder deze definitie vallen:

• Een klantenservice-chatbot noemt een verkeerde prijs, en een klant eist dat die prijs wordt gehonoreerd.
• Een AI-documentclassificator heeft een gevoelig contract verkeerd opgeslagen, waardoor het met de verkeerde partij is gedeeld.
• Een geautomatiseerde tool voor factuurverwerking heeft een dubbele betaling goedgekeurd omdat hij een leveranciersnaam verkeerd las.
• Een AI-gegenereerde samenvatting van een juridische clausule liet een cruciale uitzondering weg, waarop een manager vervolgens vertrouwde.
• Een aanbevelingsalgoritme heeft stelselmatig een beschermde demografische groep uitgesloten van het zien van een promotie.

Niet elke AI-fout is een incident. Een spelfout in een AI-opgestelde e-mail die een medewerker ontdekt vóór verzending is een kwaliteitskwestie, geen incident. De drempel is daadwerkelijke of aannemelijke schade — voor mensen, gegevens, compliance of vertrouwen.

De vier ernstniveaus die u moet definiëren

Niet alle incidenten zijn gelijk. Een gelaagd ernstmodel stelt uw team in staat het juiste reactieniveau in te zetten, zonder kleine problemen te escaleren of ernstige gevallen te onderschatten.

Niveau	Label	Omschrijving	Voorbeeld
1	Kritiek	Onmiddellijke schade of juridische blootstelling	AI-gegenereerd advies veroorzaakte financieel verlies bij een klant; mogelijke AVG-schending
2	Hoog	Significant bedrijfs- of reputatierisico	Verkeerde prijsstelling gecommuniceerd aan 200+ klanten via geautomatiseerde e-mail
3	Middel	Operationele verstoring, beperkte externe impact	AI-workflow stuurde 50 bestellingen naar verkeerd distributiecentrum
4	Laag	Kleine fout, intern onderschept, geen externe impact	AI-concept bevatte feitelijke fout, gecorrigeerd vóór verzending

Leg deze niveaus vast in uw proceduredocument. Teams moeten binnen de eerste 15 minuten na het ontdekken van een probleem een ernstniveau kunnen toewijzen.

Wie is waarvoor verantwoordelijk: de benodigde rollen

Een AI-incidentprocedure werkt alleen als specifieke mensen specifieke verantwoordelijkheden hebben. Dit hoeven geen fulltime functies te zijn — in kleinere organisaties kan één persoon meerdere rollen vervullen — maar de taken moeten bij naam worden benoemd.

AI Incident Coördinator (AIC) De persoon die de procedure activeert, taken toewijst en verantwoordelijk is voor de communicatie. In een klein bedrijf is dit vaak de IT-manager of operationeel verantwoordelijke. In een grotere organisatie kan dit een toegewijde AI-governance officer zijn.

Technisch Onderzoeker De persoon (of het team) die logs, modeluitkomsten en systeemgedrag doorzoekt om te begrijpen wat er werkelijk is gebeurd. Dit is doorgaans uw interne ontwikkelaar, data-engineer of de technisch contactpersoon bij uw AI-leverancier.

Business Owner De manager die verantwoordelijk is voor het proces of product waar de AI in opereert. Zij beoordelen de zakelijke impact en keuren herstelmaatregelen goed die de bedrijfsvoering raken.

Communicatieverantwoordelijke De persoon die klantgerichte of externe communicatie afhandelt. In gereguleerde sectoren (financiën, gezondheidszorg) coördineert deze persoon ook met juridische zaken en compliance.

Functionaris voor Gegevensbescherming (indien van toepassing) Vereist onder de AVG als het incident persoonsgegevens betreft. Moet bij niveau 1- en niveau 2-incidenten onmiddellijk worden ingelicht.

Stap voor stap: de AI-incidentprocedure

Stap 1 — Detecteren en melden (0–30 minuten)

Iedereen in de organisatie kan als eerste een AI-incident signaleren — een klantenservicemedewerker, een manager die output beoordeelt, een ontwikkelaar die afwijkende logs opmerkt. De procedure moet het gemakkelijk en vanzelfsprekend maken om dit te melden.

• Zorg voor één eenvoudig meldkanaal: een specifiek Slack-kanaal, een formulier of een e-mailadres. Verlaag de drempel.
• De eerste melder documenteert: wat hij of zij zag, wanneer, in welk systeem en wat de AI-uitkomst was (screenshot of kopieer-en-plak).
• De melding gaat direct naar de AI Incident Coördinator.

Wacht niet totdat u zeker weet dat het een echt incident is. Meld eerst, verifieer daarna.

Stap 2 — Triage en classificatie (30–60 minuten)

De AI Incident Coördinator beoordeelt de melding en:

1. Kent een ernstniveau toe (1–4) op basis van uw vastgelegde criteria.
2. Activeert de relevante rollen (Technisch Onderzoeker, Business Owner, Communicatieverantwoordelijke, FG indien nodig).
3. Opent een incidentlog — een gedeeld document of ticket waarin alle bevindingen en beslissingen worden vastgelegd.
4. Neemt de eerste cruciale beslissing: Moet het AI-systeem onmiddellijk worden gepauzeerd of beperkt?

Bij een niveau 1- of niveau 2-incident moet het standaardantwoord zijn: ja, beperk of pauzeer het systeem totdat u begrijpt wat er is gebeurd. Een AI-tool die actief schadelijke uitkomsten produceert, mag niet blijven draaien terwijl u onderzoek doet.

Stap 3 — Indammen (eerste 2–4 uur)

Indammen betekent de schade beperken — voorkomen dat het AI-systeem verdere schade veroorzaakt terwijl het onderzoek loopt.

• Als een chatbot verkeerde informatie heeft verstrekt: zet hem offline of schakel over op een modus waarbij wordt doorverbonden naar een medewerker.
• Als een geautomatiseerde workflow slechte transacties heeft goedgekeurd: blokkeer openstaande goedkeuringen en markeer ze voor handmatige controle.
• Als persoonsgegevens zijn blootgesteld: voer parallel uw bestaande procedure voor datalekken uit.
• Informeer getroffen klanten of interne teams waar nodig — feitelijk, zonder te speculeren over de oorzaak.

Indammen vereist geen volledige uitleg van wat er mis is gegaan. Het vereist een beslissing om de schade te stoppen.

Stap 4 — Onderzoeken (2–48 uur, afhankelijk van de ernst)

De Technisch Onderzoeker leidt deze fase. Het doel is vier vragen te beantwoorden:

1. Wat heeft het AI-systeem precies gedaan? (Reconstrueer de exacte uitkomst en de context die deze heeft veroorzaakt.)
2. Waarom heeft het dat gedaan? (Was het een promptprobleem, een probleem met trainingsdata, een integratiefout, een randgeval of een modelhallucinatie?)
3. Hoeveel personen of transacties zijn getroffen?
4. Is dit een eenmalige afwijking of een systemisch patroon?

Documenteer elke bevinding in het incidentlog. Vermijd conclusies trekken voordat het onderzoek is afgerond — voorbarige verklaringen blijken vaak onjuist te zijn en veroorzaken een tweede communicatieprobleem.

Stap 5 — Communiceren (afgestemd op de ernst)

De timing van de communicatie hangt af van de ernst en de wettelijke verplichtingen:

• Niveau 1: Externe communicatie (naar klanten, toezichthouders) binnen 24–72 uur, afhankelijk van uw rechtsgebied en sector.
• Niveau 2: Interne stakeholders binnen 4 uur; externe communicatie als klanten direct zijn getroffen.
• Niveau 3–4: Alleen interne communicatie, gedocumenteerd in het incidentlog.

Voor externe communicatie moet de boodschap bevatten: wat er is gebeurd, wat u heeft gedaan om het te stoppen, en wat getroffen partijen eventueel moeten doen. Speculeer in externe berichten niet over de oorzaak totdat het onderzoek is afgerond.

Onder de EU AI Act (voor hoog-risico AI-systemen) en de AVG (voor incidenten met persoonsgegevens) gelden specifieke meldverplichtingen. Weet welke van toepassing zijn op uw systemen voordat u ze nodig heeft.

Stap 6 — Herstellen (dagen tot weken)

Herstel betekent de onderliggende oorzaak aanpakken — niet alleen het symptoom verhelpen. Op basis van de onderzoeksbevindingen:

• Als het probleem zat in een prompt of instructieset: update, test en versiebeheer de nieuwe prompt.
• Als het probleem zat in het gedrag van het model: werk samen met uw leverancier aan een oplossing, of voeg een handmatige reviewlaag toe voor dat specifieke type uitkomst.
• Als het probleem zat in een integratiefout: herstel en regressietest de connector.
• Als het probleem zat in een procesgap (geen mens controleerde de uitkomst voordat die de klant bereikte): herontwerp de workflow om die controle toe te voegen.

Activeer het AI-systeem niet opnieuw totdat het herstel is getest. Documenteer wat er is gewijzigd en waarom.

Stap 7 — Evalueren en afsluiten (binnen 2 weken na afronding)

Elk incident — ook incidenten met lage ernst — moet eindigen met een gestructureerde evaluatie:

• Wat er is gebeurd en waarom (definitieve versie).
• Wat goed werkte in de respons en wat niet.
• Welke wijzigingen zijn aangebracht aan het systeem, het proces of de procedure.
• Welke monitoring of waarborgen zijn toegevoegd om dit type probleem de volgende keer eerder te signaleren.

Deze evaluatie wordt de basis van uw AI-incidentlog, die na verloop van tijd een van de waardevolste governance-documenten van uw organisatie wordt — een feitelijk overzicht van hoe uw AI-systemen zich hebben gedragen en hoe u heeft gereageerd.

Checklist AI-incidentprocedure

Gebruik deze checklist om te verifiëren dat uw procedure compleet is voordat u deze nodig heeft.

Voorbereiding (vóór elk incident)

• AI-incident ernstniveaus gedefinieerd en gedocumenteerd
• AI Incident Coördinator benoemd
• Technisch Onderzoeker benoemd
• Business Owner benoemd per AI-systeem
• Communicatieverantwoordelijke benoemd
• FG ingelicht (als persoonsgegevens betrokken zijn bij enig AI-systeem)
• Meldkanaal aangemaakt en gecommuniceerd aan alle medewerkers
• Sjabloon voor incidentlog klaar voor gebruik
• Lijst van gebruikte AI-systemen, met risicoklassificatie
• Wettelijke meldverplichtingen gedocumenteerd per systeem

Tijdens een incident

• Incident gemeld en voorzien van tijdstempel
• Ernstniveau toegewezen binnen 30 minuten
• Relevante rollen geactiveerd
• Incidentlog geopend
• Indammingsbeslissing genomen
• Onderzoeksvragen uitgezet
• Communicatie getimed en opgesteld
• Herstel bijgehouden in incidentlog

Na een incident

• Grondoorzaak gedocumenteerd
• Systeemwijzigingen getest vóór heractivering
• Evaluatieoverleg gehouden binnen 2 weken
• Geleerde lessen toegevoegd aan incidentlog
• Procedure bijgewerkt als er hiaten zijn gevonden

Veelgestelde vragen

Hebben we een aparte AI-incidentprocedure nodig, of kunnen we onze bestaande IT-incidentprocedure uitbreiden? U kunt uw IT-procedure uitbreiden, maar u zult AI-specifieke elementen moeten toevoegen: ernstniveaus die rekening houden met modelgedrag (niet alleen systeemuitval), onderzoeksvragen specifiek gericht op de kwaliteit van AI-uitkomsten, en communicatietaal die er niet van uitgaat dat het probleem een technische bug is (het kan ook een data- of ontwerpkwestie zijn). Een puur IT-incidentsjabloon dekt dit doorgaans niet.

Wat als het AI-systeem een tool van een derde partij is die wij niet zelf beheren, zoals een door een leverancier aangeboden chatbot? U blijft verantwoordelijk voor de manier waarop die tool uw klanten treft en voor uw complianceverplichtingen. Uw procedure moet bevatten: een contactroute naar het incidentresponsteam van de leverancier, duidelijkheid over welke gegevens zij beheren, en een beslissingsdrempel voor het opschorten van de tool terwijl de leverancier onderzoek doet. Uw contract met de leverancier moet ook hun verplichtingen op het gebied van incidentrespons specificeren — controleer dit nu, vóór een incident.

Hoe gaan we om met een AI-incident dat ook een datalek betreft? Voer beide procedures parallel uit. Wijs één coördinator aan die de verbinding tussen beide beheert, zodat de twee werkstromen elkaar niet tegenspreken in hun klantcommunicatie. De AVG-termijn van 72 uur voor melding van datalekken begint te lopen op het moment dat u er kennis van neemt — laat het AI-onderzoek de melding van het datalek niet vertragen.

Hoe vaak moeten we onze AI-incidentprocedure testen of evalueren? Evalueer deze minimaal jaarlijks en na elk niveau 1- of niveau 2-incident. Voer eenmaal per jaar een tafeloefening uit: presenteer een fictief AI-incidentscenario aan uw team en loop de procedure hardop door. U zult binnen ongeveer 20 minuten hiaten ontdekken die anders alleen aan het licht zouden komen tijdens een echte crisis.

Welke documentatie verwachten toezichthouders doorgaans? Onder de EU AI Act moet u voor hoog-risico AI-systemen logs bijhouden van de systeemwerking, ernstige incidenten documenteren en deze melden aan nationale autoriteiten. Ook voor systemen die niet onder de hoog-risicoclassificatie vallen, toont een gedocumenteerde procedure en incidentlog het soort menselijk toezicht aan waartoe de verordening oproept. Het incidentlog dat u in de loop van de tijd opbouwt, is uw bewijs van verantwoord bestuur.

Dit integreren in een breder AI-governance raamwerk

Een AI-incidentprocedure staat niet op zichzelf. Het is één onderdeel van een bredere governancestructuur die ook omvat: een inventaris van welke AI-systemen uw organisatie gebruikt en hoe deze zijn geclassificeerd, een beleid voor aanvaardbaar gebruik en menselijk toezicht, en een proces voor het beoordelen van nieuwe AI-tools vóór ingebruikname. Beschouw de incidentprocedure als de noodresponslaag — essentieel, maar alleen zinvol wanneer de preventieve lagen ook aanwezig zijn.

De organisaties die AI-incidenten goed afhandelen zijn niet de organisaties met de meest geavanceerde AI. Het zijn de organisaties die governance vanaf het begin als onderdeel van de implementatie hebben behandeld — niet als iets dat er pas na het eerste probleem aan wordt toegevoegd.

---

Bij Loggix werken we met organisaties die AI integreren in echte bedrijfsprocessen — binnen FileMaker-workflows, via API-connectoren naar externe tools, of via op maat gemaakte applicaties — en we zien uit de eerste hand waar governance-kloven risico's creëren. Als u AI-ondersteunde processen bouwt of uitbreidt en een praktisch gesprek wilt over hoe u toezicht, incidentafhandeling en menselijke controle vanaf het begin in de workflow kunt structureren, denken we daar graag met u over na.