Meer in de kennisbank over AI-compliance
AI incident response plan: template en procedure
Een AI-incident kan drie meldregimes tegelijk raken: Artikel 73 AI Act (15 dagen, en 2 dagen bij overlijden of ernstige gezondheidsschade), de AVG (72 uur bij de Autoriteit Persoonsgegevens) en NIS2 (24 uur voor de eerste waarschuwing bij het CSIRT). Die termijnen beginnen te lopen zodra je van het incident weet, niet als het onderzoek klaar is, en melden gebeurt parallel aan de operationele response. Hieronder staat het plan waarmee je die termijnen haalt: severity-classificatie, zeven responsfasen, een meldprotocol per regime en een rolverdeling per fase.
Prometheus21 helpt MKB-organisaties om AI-incidenten beheersbaar te maken met concrete procedures en templates. Onderdeel van onze AI-compliance-aanpak.
Geschreven door Prometheus21, AI-strategiepartner voor het MKB
Meldtermijn voor ernstige incidenten bij de markttoezichtautoriteit onder Artikel 73 AI Act
Meldtermijn voor een datalek bij de Autoriteit Persoonsgegevens onder AVG Artikel 33
Severity-niveaus in de classificatiematrix: kritiek, hoog, midden, laag
AI-incidenten komen voor: de vraag is of je voorbereid bent.
Een AI-incident is elke situatie waarin een AI-systeem niet functioneert zoals bedoeld en daardoor schade veroorzaakt of kan veroorzaken. Dat kan een verkeerde medische triage zijn door een algoritme, een chatbot die vertrouwelijke klantgegevens prijsgeeft, een scoringsmodel dat systematisch bepaalde groepen benadeelt, of een volledig systeem dat uitvalt midden in een kritiek bedrijfsproces.
Het verschil tussen een beheersbaar incident en een crisis ligt in voorbereiding. Organisaties met een uitgewerkt incident response plan reageren gemiddeld sneller, beperken schade effectiever en voldoen aan hun wettelijke meldverplichtingen. Organisaties zonder plan verliezen tijd aan het uitzoeken van verantwoordelijkheden, missen meldtermijnen en nemen ad-hoc beslissingen die de schade vergroten.
Drie wettelijke regimes zijn tegelijk relevant bij AI-incidenten. De AI Act (met name Artikel 73 voor ernstige incidenten bij high-risk systemen), de AVG (Artikel 33 en 34 voor datalekken met persoonsgegevens), en NIS2 (voor cybersecurity-incidenten bij essentiële en belangrijke entiteiten). Elk regime heeft eigen definities, meldtermijnen, ontvangers en inhoudseisen. Een enkel incident kan onder alle drie vallen en drie parallelle meldprocedures triggeren.
Voor MKB-organisaties is een gestructureerd plan extra belangrijk. Waar grote ondernemingen gespecialiseerde incident-response-teams hebben, moet een MKB dezelfde wettelijke verplichtingen nakomen met minder mensen en minder ervaring met dit type situaties. Een concreet plan met duidelijke rollen, stappen en templates maakt dat verschil werkbaar.
Deze gids bevat alles wat je nodig hebt: het wettelijk kader, een classificatiematrix met vier severity-niveaus, een responsprocedure in zeven fasen, meldvereisten per regime, een complete template-structuur, een RACI-matrix en een checklist met meer dan 30 actiepunten. Koppeling met onze AI Act compliance-roadmap en risicomanagement-gids.
Ernstig incident (AI Act): Artikel 3 lid 49 definieert dit als een incident dat leidt tot overlijden, ernstige gezondheidsschade, ernstige verstoring van kritieke infrastructuur, schending van grondrechten, of ernstige schade aan eigendom of milieu.
Datalek (AVG): Artikel 4 lid 12 definieert dit als een inbreuk op de beveiliging die leidt tot ongeoorloofde toegang tot, vernietiging, wijziging of vrijgave van persoonsgegevens.
Drie parallelle regimes
AI Act Artikel 73, AVG Artikel 33/34, NIS2 Artikel 23. Elk met eigen termijnen, definities en ontvangers. Eén incident, drie meldprocedures.
Tijd is de kritieke factor
72 uur voor AVG-melding, 24 uur voor NIS2, 15 dagen voor AI Act. Zonder voorbereiding mis je termijnen.
Plan verlaagt boete-risico
Artikel 99 lid 7 AI Act: aantoonbare maatregelen en medewerking zijn verzachtende factoren bij boete-bepaling.
Elk regime een eigen meldverplichting
De AI Act, AVG en NIS2 stellen elk eigen eisen aan het melden van incidenten. Een AI-incident kan onder alle drie tegelijk vallen.
AI Act: Artikel 73 ernstige incidenten
Artikel 73 verplicht aanbieders van high-risk AI-systemen om ernstige incidenten te melden bij de markttoezichtautoriteit van de lidstaat waar het incident heeft plaatsgevonden. De meldtermijn is 15 dagen na kennisname van het incident. Bij overlijden of ernstige gezondheidsschade geldt een versnelde eerste melding: onmiddellijk, maar uiterlijk binnen 2 dagen, gevolgd door een volledige melding binnen 15 dagen.
De melding bevat: identificatie van het AI-systeem, beschrijving van het incident, betrokken partijen, genomen maatregelen, en inschatting van de oorzaak. De aanbieder moet na melding meewerken aan het onderzoek van de toezichthouder. Deployers zijn niet direct meldplichtig onder Artikel 73. Wel verplicht Artikel 26 lid 5 hen om de aanbieder te informeren. In Nederland is de Autoriteit Persoonsgegevens coördinerend toezichthouder.
AVG: Artikel 33 en 34 datalekken
Wanneer een AI-incident leidt tot een inbreuk op persoonsgegevens, is de verwerkingsverantwoordelijke verplicht dit binnen 72 uur te melden bij de Autoriteit Persoonsgegevens (Artikel 33). Als het datalek waarschijnlijk een hoog risico inhoudt voor de rechten en vrijheden van betrokkenen, moeten ook de betrokkenen zelf worden geïnformeerd (Artikel 34). De verwerker moet de verwerkingsverantwoordelijke onverwijld informeren na ontdekking.
AI-systemen die persoonsgegevens verwerken zijn extra gevoelig: een fout in het model kan leiden tot ongeautoriseerde openbaarmaking van trainingsdata, verkeerde koppeling van persoonsinformatie, of onbedoelde profilering. Elk van deze situaties kan een meldplichtig datalek zijn.
NIS2: Artikel 23 cybersecurity-incidenten
Organisaties die als essentiële of belangrijke entiteit onder NIS2 vallen, moeten significante cybersecurity-incidenten melden bij het nationale CSIRT. De termijnen zijn strenger: vroegtijdige waarschuwing binnen 24 uur, incidentmelding binnen 72 uur, eindverslag binnen een maand. Een AI-systeem dat wordt gecompromitteerd door een cyberaanval valt hier direct onder.
De overlap met AI-incidenten is groot: adversarial attacks op AI-modellen, data-poisoning, model-extractie en ongeautoriseerde toegang tot AI-systemen zijn tegelijk cybersecurity-incidenten en AI-incidenten. Zie ook onze gids over AI Act en NIS2.
Praktijkvoorbeeld: Een MKB-zorgorganisatie gebruikt een AI-systeem voor patiëntrisico-scoring (high-risk onder Annex III). Het systeem genereert door een fout verkeerde scores voor 500 patiënten, waarbij medische gegevens onbedoeld zichtbaar worden voor onbevoegd personeel. Dit is: (1) een ernstig incident onder Artikel 73 AI Act (gezondheidsrisico door verkeerde scores), (2) een datalek onder AVG Artikel 33 (ongeoorloofde toegang tot medische gegevens), en mogelijk (3) een NIS2-incident als de zorgorganisatie onder NIS2 valt. Drie meldingen, drie instanties, drie termijnen, allemaal tegelijk.
De severity-niveaus
De classificatie bepaalt welk responseteam wordt geactiveerd, welke meldtermijnen gelden en welke escalatieprocedure je volgt. Gebruik deze matrix als basis en pas criteria aan op je organisatie.
| Niveau | Wat het vraagt | Wie in actie komt |
|---|---|---|
| Niveau 4 · Kritiek | Onmiddellijke actie | Het volledige crisisteam; de directie wordt direct geïnformeerd |
| Niveau 3 · Hoog | Snelle response binnen 4 uur | Een incident commander, het technisch team en een juridisch adviseur |
| Niveau 2 · Midden | Response binnen 24 uur | Het operationeel team; het incident wordt geregistreerd en gevolgd tot oplossing |
| Niveau 1 · Laag | Registratie en monitoring | Vastleggen in het incidentlog en oppakken in de normale werkcyclus |
Niveau 4: Onmiddellijke actie vereist
Volledige activering van het crisisteam, directie wordt direct geïnformeerd. Alle beschikbare resources worden ingezet.
- Direct gevaar voor leven of gezondheid van personen
- Grootschalig datalek met bijzondere persoonsgegevens (medisch, biometrisch, strafrechtelijk)
- Volledige uitval van AI-systeem in kritiek bedrijfsproces zonder fallback
- Systematische discriminatie door AI met directe gevolgen voor betrokkenen
- Aanwijzing van een verboden AI-praktijk (Artikel 5) in eigen organisatie
Niveau 3: Snelle response binnen 4 uur
Incident commander wordt aangewezen. Technisch team en juridisch adviseur worden geactiveerd.
- Significante schade aan betrokkenen door verkeerde AI-output
- Datalek met gewone persoonsgegevens van meer dan 1.000 betrokkenen
- Langdurige uitval van een high-risk AI-systeem (meer dan 4 uur)
- Aangetoonde bias in AI-systeem die groepen structureel benadeelt
- Ongeautoriseerde toegang tot AI-model of trainingsdata
Niveau 2: Response binnen 24 uur
Operationeel team pakt het op. Incident wordt geregistreerd en gevolgd tot oplossing.
- Beperkte schade door verkeerde AI-output, snel gecorrigeerd
- Datalek met beperkt aantal betrokkenen (minder dan 100)
- Tijdelijke uitval van AI-systeem met werkende fallback
- Prestatie-afwijking van AI-model die beslissingen beinvloedt
- Onbedoeld gebruik van AI-systeem buiten beoogde toepassing
Niveau 1: Registratie en monitoring
Vastleggen in incidentlog, oppakken in normale werkcyclus. Monitoren op herhaling.
- Intern gedetecteerde fout die nog niet tot output heeft geleid
- Prestatie-afwijking zonder impact op beslissingen
- Mislukte poging tot ongeautoriseerde toegang (afgevangen)
- Kleine configuratiefout zonder gevolgen voor gebruikers
- Model-drift gedetecteerd binnen acceptabele marges
Fasen van detectie tot evaluatie
Elke fase heeft een duidelijk doel, verantwoordelijke en tijdslijn. De procedure is ontworpen zodat meldtermijnen worden gehaald zonder dat de operationele response vertraagt.
- 1
Fase 1 · Doorlopend
Detectie
Het incident wordt gesignaleerd. Dit kan via meerdere kanalen: automatische monitoring (alerts op prestatie-afwijking, foutmeldingen, anomalie-detectie), gebruikersmeldingen (klachten, foutrapportages), interne observatie (medewerker constateert vreemd gedrag), of externe bronnen (toezichthouder, media, onderzoekers).
Elk signaal wordt vastgelegd in het incidentregistratiesysteem met: tijdstip, bron, eerste beschrijving, betrokken AI-systeem. Geen signaal wordt genegeerd; liever tien valse meldingen geregistreerd dan één echt incident gemist. De persoon die het incident detecteert, meldt het direct bij de aangewezen eerstelijns-contact (in veel MKB's is dit de IT-verantwoordelijke of de operationeel manager).
- 2
Fase 2 · Binnen 30 minuten na detectie
Triage
Eerste beoordeling van het incident. Bepaal het severity-niveau op basis van de classificatiematrix. Stel vast welke AI-systemen zijn geraakt, of er persoonsgegevens betrokken zijn, of er sprake kan zijn van een ernstig incident onder Artikel 73, en of er een cybersecurity-component is.
Op basis van het severity-niveau activeer je het juiste responseteam. Bij kritiek: directie + volledig crisisteam. Bij hoog: incident commander + technisch + juridisch. Bij midden: operationeel team. Bij laag: registratie in log, oppakken in planning. De triage-beslissing wordt gedocumenteerd inclusief onderbouwing. Bij twijfel over het niveau: altijd naar boven classificeren.
- 3
Fase 3 · Direct na triage
Indamming
Beperk de impact zo snel mogelijk. De prioriteit is: voorkom dat het incident groter wordt. Concrete acties afhankelijk van het type incident:
Bij verkeerde AI-output: schakel het systeem over op handmatige verwerking of fallback-proces. Bij een datalek: isoleer het getroffen systeem, blokkeer verdere toegang, beveilig de data. Bij een cyberaanval: isoleer het netwerksegment, blokkeer de aanvalsvector. Bij systematische bias: stop het gebruik van de output voor beslissingen tot het probleem is onderzocht. Documenteer elke indammingsactie met tijdstip en uitvoerder. De indamming mag niet wachten op volledig onderzoek; eerst stoppen, dan onderzoeken.
- 4
Fase 4 · Start binnen 2 uur (kritiek/hoog) of 24 uur (midden)
Onderzoek
Bepaal de grondoorzaak en de volledige omvang van het incident. Beantwoord: wat is er precies misgegaan? Wanneer begon het? Welke data is geraakt? Hoeveel personen zijn betroffen? Is er sprake van een datalek in de zin van de AVG? Valt dit onder de definitie van een ernstig incident onder Artikel 73?
Verzamel bewijsmateriaal: logs, timestamps, versie-informatie van het model, inputdata die tot het probleem leidde, outputdata die is gegenereerd. Betrek de leverancier of aanbieder van het AI-systeem als dat nodig is. Als je deployer bent, informeer de aanbieder conform Artikel 26 lid 5. Leg alle bevindingen vast in het incidentdossier. Dit dossier is later de basis voor de meldingen aan toezichthouders.
- 5
Fase 5 · Na vaststelling grondoorzaak
Herstel
Implementeer de oplossing en herstel de normale operatie. Dit kan zijn: update van het AI-model, aanpassing van configuratie, patch van een beveiligingskwetsbaarheid, correctie van foutieve output, herstel van data-integriteit.
Test de oplossing voordat je het systeem weer volledig in productie neemt. Controleer dat de grondoorzaak is weggenomen en niet alleen het symptoom. Indien mogelijk: gefaseerde herinvoering met extra monitoring in de eerste periode. Documenteer: welke wijzigingen zijn doorgevoerd, wie heeft ze getest, wat is het testresultaat, wanneer is het systeem hersteld. Informeer gebruikers over het herstel en eventuele acties die zij moeten nemen (bijvoorbeeld: controleer beslissingen die in de incidentperiode zijn genomen op basis van AI-output).
- 6
Fase 6 · Parallel aan fasen 3-5, binnen wettelijke termijnen
Melding
Meld het incident bij de juiste instanties binnen de wettelijke termijnen. Dit loopt parallel aan de operationele response; wacht niet tot het onderzoek compleet is. De meldtermijnen starten bij kennisname, dus al voordat het onderzoek is afgerond.
AI Act Artikel 73: melding bij markttoezichtautoriteit binnen 15 dagen (2 dagen bij overlijden/gezondheidsschade). AVG Artikel 33: melding bij AP binnen 72 uur, en indien nodig betrokkenen informeren (Artikel 34). NIS2 Artikel 23: vroegtijdige waarschuwing bij CSIRT binnen 24 uur, incidentmelding binnen 72 uur, eindverslag binnen een maand. Als deployer: informeer de aanbieder van het AI-systeem. Intern: informeer directie, betrokken afdelingen, en eventueel klanten. Gebruik vooraf opgestelde meld-templates om snelheid te garanderen.
- 7
Fase 7 · Binnen 10 werkdagen na sluiting incident
Post-incident evaluatie
Voer een gestructureerde evaluatie uit met alle betrokkenen. Doel: leren en verbeteren, zonder schuld toe te wijzen. Beantwoord: wat ging goed in de response? Wat ging niet goed? Welke fasen duurden langer dan gepland? Waren de rollen duidelijk? Zijn de meldtermijnen gehaald? Was de classificatie juist?
Leg de bevindingen vast in een post-incident review-rapport. Formuleer concrete verbeteracties met eigenaar en deadline. Pas het incident response plan aan op basis van de geleerde lessen. Deel relevante inzichten met de organisatie (geanonimiseerd indien nodig). Update de classificatiematrix als de criteria niet passend bleken. Deze evaluatie is geen optionele stap; het is de investering die voorkomt dat hetzelfde incident zich herhaalt.
Wie meldt wat, aan wie, wanneer
Overzicht van de drie parallelle meldverplichtingen met termijnen, ontvangers en inhoudseisen per regime.
| Regime | Wanneer meldplichtig | Aan wie | Termijn | Door wie |
|---|---|---|---|---|
| AI Act | Ernstig incident bij high-risk AI-systeem (Artikel 73 + Artikel 3 lid 49) | Markttoezichtautoriteit van lidstaat waar incident plaatsvond (NL: Autoriteit Persoonsgegevens) | 15 dagen na kennisname; 2 dagen bij overlijden of ernstige gezondheidsschade | Aanbieder; deployer informeert aanbieder (Art. 26 lid 5) |
| AVG | Inbreuk op persoonsgegevens (datalek) ongeacht AI-betrokkenheid | Autoriteit Persoonsgegevens + betrokkenen bij hoog risico (Art. 34) | 72 uur na kennisname bij AP; onverwijld bij betrokkenen | Verwerkingsverantwoordelijke; verwerker meldt aan verantwoordelijke |
| NIS2 | Significant cybersecurity-incident bij essentiële of belangrijke entiteit | Nationaal CSIRT (NL: NCSC of sectoraal CSIRT) + bevoegde autoriteit | 24 uur vroegtijdige waarschuwing, 72 uur incidentmelding, 1 maand eindverslag | De entiteit zelf |
Inhoud AI Act-melding
Identificatie van het AI-systeem (naam, versie, CE-markering), beschrijving van het incident (wat gebeurde, wanneer, waar), betrokken partijen (aanbieder, deployer, betrokkenen), genomen corrigerende maatregelen, inschatting van de oorzaak. Bij een eerste melding (binnen 2 dagen) volstaat een voorlopige beschrijving; de volledige melding volgt binnen 15 dagen.
Inhoud AVG-datalekmelding
Aard van de inbreuk (welke categorieën persoonsgegevens, hoeveel betrokkenen), waarschijnlijke gevolgen, genomen of voorgestelde maatregelen, contactgegevens van de FG of ander contactpunt. De AP verwacht deze informatie in het standaard meldformulier op de AP-website. Als niet alle informatie beschikbaar is binnen 72 uur: meld wat je weet en lever de rest zo snel mogelijk na.
Inhoud NIS2-melding
Vroegtijdige waarschuwing: is er vermoeden van kwaadwillige handeling, kan het incident grensoverschrijdend effect hebben. Incidentmelding: eerste beoordeling van ernst en impact, indicators of compromise. Eindverslag: gedetailleerde beschrijving van incident inclusief grondoorzaak, genomen maatregelen, grensoverschrijdende impact.
Interne communicatie
Naast externe meldingen is interne communicatie belangrijk. Directie wordt geïnformeerd bij severity kritiek en hoog. Betrokken afdelingen worden geïnformeerd over impact op hun processen. Medewerkers die met het getroffen AI-systeem werken krijgen instructies over fallback-procedures. Bij klantraking: klantenservice wordt voorbereid op vragen. Bewaar alle communicatie in het incidentdossier.
Structuur van het incident response plan
Een compleet AI incident response plan bevat deze onderdelen. Gebruik dit als template en vul aan met organisatie-specifieke details.
Doelstelling en scope
Beschrijf het doel van het plan, welke AI-systemen het dekt, en de relatie met bestaand incident-management en bedrijfscontinuiteitsplan. Definieer wat binnen en buiten scope valt. Verwijs naar de wettelijke kaders (AI Act, AVG, NIS2) die van toepassing zijn.
Definities en afkortingen
Definieer de kernbegrippen: AI-incident, ernstig incident (Art. 3 lid 49), datalek (AVG Art. 4 lid 12), severity-niveaus, incident commander, responseteam. Voorkom verwarring door duidelijke afbakening van termen die in verschillende wetten anders worden gebruikt.
AI-systeemregister
Overzicht van alle AI-systemen in de organisatie met: naam, type, leverancier, classificatie onder AI Act, betrokken persoonsgegevens, criticiteit voor bedrijfsprocessen, verantwoordelijke eigenaar. Dit register koppelt aan het AI-register.
Classificatiematrix
De vier severity-niveaus met criteria, voorbeelden en bijbehorende escalatieprocedures. Inclusief beslisboom: als X dan severity Y. Houd de matrix eenvoudig genoeg om in stressvolle situaties snel te gebruiken. Jaarlijks reviewen op basis van ervaringen.
Rollen en verantwoordelijkheden
RACI-matrix per fase van de responsprocedure. Benoem: incident commander, technisch responseteam, juridisch adviseur, privacy officer/FG, communicatie-verantwoordelijke, directie. Per rol: wie vervult deze, wie is backup, contactgegevens (ook buiten kantooruren).
Responsprocedure
De zeven fasen uitgewerkt met per fase: doel, verantwoordelijke, acties, tijdslijn, deliverables. Dit is het hart van het plan. Houd het concreet: specifieke stappen die iemand onder druk kan volgen.
Meldprotocol per regime
Per wettelijk regime: trigger (wanneer melden), ontvanger (aan wie), termijn, inhoud, formulier/kanaal, verantwoordelijke. Inclusief vooraf ingevulde meldtemplates met standaardinformatie over de organisatie. Bewaar login-gegevens voor meldportalen op een veilige, toegankelijke plek.
Communicatieplan
Interne communicatie: wie informeert wie bij welk severity-niveau, via welk kanaal, met welke inhoud. Externe communicatie: wie communiceert met klanten, pers, toezichthouders. Voorbereide communicatie-templates per scenario. Regel: één woordvoerder, afstemming voor publicatie.
Fallback-procedures
Per AI-systeem: wat gebeurt er als het systeem moet worden uitgeschakeld. Handmatig alternatief, geschatte verwerkingscapaciteit zonder AI, maximale duur voordat handmatig onhoudbaar wordt. Koppel aan je business impact analyse en recovery time objectives.
Post-incident review template
Standaardformat voor de evaluatie: tijdlijn van het incident, wat ging goed, wat ging niet goed, grondoorzaak-analyse, verbeteracties met eigenaar en deadline, aanpassingen aan het incident response plan. Bewaar alle reviews als kennisbank voor toekomstige incidenten.
Test- en oefenschema
Frequentie van tabletop-oefeningen (minimaal jaarlijks), scenario's voor oefening, evaluatiecriteria, wie neemt deel. Plan ook ad-hoc tests na significante wijzigingen aan AI-systemen of na een werkelijk incident. Documenteer oefen-resultaten en verbeterpunten.
Bijlagen en contactlijsten
Contactgegevens toezichthouders (AP, sectorale autoriteiten, CSIRT), leveranciers van AI-systemen, externe juridisch adviseur, externe cybersecurity-partner. Contactgegevens van alle interne rolhouders inclusief privénummers voor buiten kantooruren. Versiehistorie van het plan.
RACI-matrix per fase
R = Responsible (voert uit), A = Accountable (eindverantwoordelijk), C = Consulted (wordt geraadpleegd), I = Informed (wordt geïnformeerd). Pas de rollen aan op je organisatiestructuur.
| Fase | Incident Commander | Technisch Team | Juridisch / FG | Communicatie | Directie |
|---|---|---|---|---|---|
| Detectie | I | R | I | — | — |
| Triage | A | R | C | I | I (kritiek/hoog) |
| Indamming | A | R | C | I | I |
| Onderzoek | A | R | R | I | I |
| Herstel | A | R | C | I | I |
| Melding (AI Act) | A | C | R | C | I |
| Melding (AVG) | I | C | R | C | A |
| Melding (NIS2) | A | R | C | C | I |
| Evaluatie | R | R | R | C | A |
MKB-tip: In kleinere organisaties vervult één persoon vaak meerdere rollen. De directeur is tegelijk incident commander en accountable voor meldingen. De IT-verantwoordelijke is technisch team én eerste detectielijn. Dat is prima, zolang de rollen expliciet zijn benoemd en de persoon weet welke pet hij of zij op elk moment draagt. Benoem voor elke rol ook een backup; als de primaire persoon niet bereikbaar is, moet het plan toch functioneren. Koppeling met de deployer-verplichtingen gids.
Leren van elk incident
De post-incident review is de investering die voorkomt dat hetzelfde incident zich herhaalt. Voer deze uit binnen 10 werkdagen na sluiting van het incident.
Tijdlijn reconstructie
Stel een volledige tijdlijn op van het incident: eerste signaal, detectie, triage-beslissing, indammingsacties, onderzoeksstappen, meldmomenten, herstelacties, sluiting. Per moment: wie deed wat, hoelang duurde het, was het conform het plan. Dit geeft objectief inzicht in de werkelijke doorlooptijden.
Grondoorzaak-analyse
Gebruik een gestructureerde methode (5-why's, visgraatdiagram of vergelijkbaar) om voorbij het symptoom te komen. De vraag is wat er misging in het AI-systeem en waarom de bestaande controles het niet hebben voorkomen en waarom de detectie zo lang duurde. Onderscheid technische, procesmatige en organisatorische oorzaken.
Verbeteracties formuleren
Vertaal bevindingen naar concrete acties. Per actie: beschrijving, eigenaar, deadline, verwachte impact. Prioriteer op basis van risicovermindering. Onderscheid quick wins (direct uitvoerbaar) en structurele verbeteringen (projectmatig). Monitor de voortgang van verbeteracties in het volgende teamoverleg.
Plan-update en kennisdeling
Pas het incident response plan aan op basis van de review. Als de classificatiematrix niet passend bleek: update de criteria. Als een fase te lang duurde: onderzoek de bottleneck. Deel relevante inzichten met de organisatie. De geleerde les deel je breed, de details hoeven dat niet. Bewaar het review-rapport als onderdeel van het incidentdossier.
AI incident response checklist
Gebruik deze checklist om te toetsen of je incident response plan compleet is en je organisatie operationeel voorbereid is.
Voorbereiding en governance
AI incident response plan is opgesteld, goedgekeurd door directie en gedistribueerd aan alle betrokkenen.
Alle AI-systemen zijn geïnventariseerd in het AI-register met classificatie, criticiteit en verantwoordelijke eigenaar.
Classificatiematrix met vier severity-niveaus is opgesteld met criteria en voorbeelden per niveau.
RACI-matrix is ingevuld met namen, niet alleen functietitels. Backup-personen zijn benoemd per rol.
Contactlijst is actueel: interne rollen, toezichthouders (AP, CSIRT), leveranciers, externe adviseurs, inclusief nummers buiten kantooruren.
Relatie met bestaand bedrijfscontinuiteitsplan en incident-management is vastgelegd; geen dubbele of conflicterende procedures.
Detectie en monitoring
Monitoring is ingericht op AI-systemen: prestatie-afwijking, foutmeldingen, anomalie-detectie, output-kwaliteit.
Meldkanaal voor gebruikers en medewerkers is ingericht en gecommuniceerd (hoe meld je een vermoeden van AI-incident).
Drempelwaarden voor alerts zijn per AI-systeem gedefinieerd, in balans tussen te gevoelig (alert-moeheid) en te ruim (gemiste incidenten).
Log-retentie is geregeld: AI-systeemlogs worden minimaal de wettelijk vereiste periode bewaard.
Responscapaciteit
Incident commander is benoemd en getraind. Backup is beschikbaar en getraind.
Technisch responseteam weet welke AI-systemen onder hun verantwoordelijkheid vallen en hoe deze te isoleren/uitschakelen.
Juridisch adviseur of FG is beschikbaar binnen 2 uur na activering, ook buiten kantooruren.
Fallback-procedures zijn uitgewerkt per AI-systeem: handmatig alternatief, capaciteit, maximale duur.
Communicatie-templates zijn voorbereid: intern (directie, medewerkers), extern (klanten, pers, toezichthouders).
Meldverplichtingen
Per AI-systeem is vastgelegd welke meldverplichtingen gelden (AI Act, AVG, NIS2, sectoraal) en de bijbehorende termijnen.
Meldtemplates per regime zijn voorbereid met standaardinformatie over de organisatie al ingevuld.
Toegang tot meldportalen (AP-datalekportaal, CSIRT-portaal) is geregeld en getest; logingegevens zijn veilig opgeslagen.
Procedure voor informeren van aanbieder als deployer (Art. 26 lid 5) is vastgelegd met contactgegevens en escalatieroute.
Drempels voor melding aan betrokkenen (AVG Art. 34: hoog risico) zijn uitgewerkt met voorbeelden.
Evaluatie en verbetering
Post-incident review template is beschikbaar met standaardvragen en format voor verbeteracties.
Tabletop-oefening is gepland (minimaal jaarlijks) met scenario dat alle drie regimes triggert.
Incidentlog wordt bijgehouden (ook lage severity) voor trendanalyse en patronen.
Jaarlijkse review van het gehele incident response plan is ingepland met datum en verantwoordelijke.
Verbeteracties uit eerdere reviews zijn afgerond of in uitvoering met eigenaar en deadline.
Leveranciers en derden
SLA's met AI-leveranciers bevatten bepalingen over incidentmelding, responstijden en medewerking bij onderzoek.
Verwerkersovereenkomsten met AI-leveranciers bevatten datalek-meldplicht conform AVG Art. 33 lid 2.
Externe cybersecurity-partner is geïdentificeerd en inzetbaar bij ernstige incidenten (retainer of oproepbasis).
Externe juridisch adviseur met AI Act-kennis is geïdentificeerd voor consultatie bij complexe incidenten.
Cyberverzekering dekt AI-incidenten en de bijbehorende kosten (respons, melding, aansprakelijkheid). Polisvoorwaarden zijn gecontroleerd.
Veelgestelde vragen over AI incident response
Tien vragen over AI-incidenten, meldverplichtingen en de praktische invulling van het incident response plan.
Wat is een ernstig incident onder de AI Act?
Artikel 3 lid 49 van de AI Act definieert een ernstig incident als een incident of storing van een AI-systeem dat direct of indirect leidt tot: overlijden of ernstige schade aan de gezondheid van een persoon, een ernstige en onomkeerbare verstoring van het beheer of de werking van kritieke infrastructuur, een schending van verplichtingen uit het Unierecht ter bescherming van de grondrechten, of ernstige schade aan eigendom of het milieu. Alleen high-risk AI-systemen vallen onder de meldplicht van Artikel 73. De aanbieder moet het incident melden bij de markttoezichtautoriteit van de lidstaat waar het incident heeft plaatsgevonden.
Binnen welke termijn moet een AI-incident worden gemeld?
Er gelden drie parallelle meldtermijnen. Onder de AI Act Artikel 73: de aanbieder meldt een ernstig incident binnen 15 dagen bij de markttoezichtautoriteit. Bij overlijden of ernstige gezondheidsschade is een eerste melding nodig binnen 2 dagen, gevolgd door een volledige melding binnen 15 dagen. Onder de AVG Artikel 33: een datalek moet binnen 72 uur worden gemeld bij de Autoriteit Persoonsgegevens. Onder NIS2 Artikel 23: een significant cybersecurity-incident vereist een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindverslag binnen een maand. Een AI-incident kan onder alle drie regimes tegelijk vallen, waardoor je drie meldprocedures parallel moet uitvoeren.
Wie is verantwoordelijk voor het melden van AI-incidenten?
Onder Artikel 73 AI Act is de aanbieder van het high-risk AI-systeem verantwoordelijk voor melding aan de markttoezichtautoriteit. De deployer moet onder Artikel 26 lid 5 de aanbieder informeren over ernstige incidenten. Onder de AVG is de verwerkingsverantwoordelijke verantwoordelijk voor datalekmelding bij de AP. Onder NIS2 is de entiteit zelf verantwoordelijk voor melding bij het CSIRT. Een MKB-organisatie die als deployer een AI-systeem inzet, kan tegelijk verwerkingsverantwoordelijke en NIS2-entiteit zijn, en dus meerdere meldverplichtingen parallel moeten uitvoeren. Een duidelijke RACI-matrix voorkomt dat meldingen te laat of niet worden gedaan.
Hoe classificeer je de ernst van een AI-incident?
Gebruik een matrix met vier niveaus. Kritiek: direct gevaar voor leven of gezondheid, grootschalig datalek met bijzondere persoonsgegevens, volledige uitval van kritieke bedrijfsprocessen. Hoog: significante schade aan betrokkenen, datalek met meer dan 1.000 betrokkenen, langdurige uitval van high-risk AI. Midden: beperkte schade die snel is gecorrigeerd, datalek met beperkt aantal betrokkenen, tijdelijke uitval met werkende fallback. Laag: geen directe schade, intern gedetecteerde fout, prestatie-afwijking zonder impact. Het severity-niveau bepaalt welk responseteam wordt geactiveerd, welke escalatieprocedure geldt en welke meldtermijnen van toepassing zijn.
Wat moet er in een AI incident response plan staan?
Een compleet plan bevat scope en doelstelling, definities, AI-systeemregister, classificatiematrix met vier severity-niveaus, en rollen en verantwoordelijkheden als RACI-matrix. Daarnaast bevat het een responsprocedure in zeven fasen. Dat zijn detectie, triage, indamming, onderzoek, herstel, melding en evaluatie. Ook bevat het een meldprotocol per regime (AI Act, AVG, NIS2) met termijnen en templates, en een communicatieplan voor interne en externe communicatie. Verder bevat het fallback-procedures per AI-systeem, post-incident review template, test- en oefenschema, en bijlagen met contactlijsten. Het plan moet concreet genoeg zijn om onder druk te gebruiken, en jaarlijks worden gereviewed en getest.
Moet een deployer ook incidenten melden onder de AI Act?
De formele meldplicht onder Artikel 73 ligt alleen bij de aanbieder. Maar de deployer heeft onder Artikel 26 lid 5 een informatieplicht richting de aanbieder bij ernstige incidenten. Dat betekent dat de deployer een intern proces moet hebben om incidenten te detecteren, te beoordelen en door te geven aan de aanbieder. Daarnaast kan de deployer als verwerkingsverantwoordelijke onder de AVG een eigen meldplicht hebben voor datalekken, en als NIS2-entiteit een meldplicht voor cybersecurity-incidenten. De deployer is dus niet vrijgesteld van incident-management.
Hoe vaak moet je het incident response plan testen?
De AI Act schrijft geen specifieke testfrequentie voor. Best practice uit cybersecurity en NIS2-kaders is minimaal een keer per jaar een tabletop-oefening uitvoeren waarin het team een fictief AI-incident doorloopt. Daarnaast na elk werkelijk incident een evaluatie die ook het plan zelf toetst. Bij significante wijzigingen aan AI-systemen: aanvullende test. Voor NIS2-plichtige organisaties is regelmatig testen onderdeel van de wettelijke eis voor risicobeheersmaatregelen. Een jaarlijkse oefening gecombineerd met ad-hoc tests bij wijzigingen is een werkbaar minimum voor de meeste MKB-organisaties.
Wat is het verschil tussen een AI-incident en een datalek?
Een AI-incident is breder dan een datalek. Een AI-incident omvat elke situatie waarin een AI-systeem niet functioneert zoals bedoeld en dit leidt of kan leiden tot schade: verkeerde output, discriminerende resultaten, ongeautoriseerde modelmanipulatie, systeemuitval, onbedoeld verboden gebruik. Een datalek is specifiek een inbreuk op de beveiliging die leidt tot ongeoorloofde toegang tot, vernietiging, wijziging of vrijgave van persoonsgegevens. Een AI-incident kan een datalek bevatten (als persoonsgegevens zijn geraakt), maar niet elk AI-incident is een datalek en niet elk datalek komt voort uit AI. De overlap bepaalt welke meldverplichtingen van toepassing zijn.
Welke rol speelt de FG bij AI-incidenten?
De Functionaris Gegevensbescherming speelt een adviserende en toezichthoudende rol bij AI-incidenten die persoonsgegevens raken. De FG adviseert over de meldplicht richting de AP en betrokkenen, beoordeelt of het datalek de melddrempel haalt, en houdt toezicht op de melding. De FG is niet de incident commander en niet operationeel verantwoordelijk voor de response. Wel moet de FG tijdig worden geinformeerd en betrokken bij de beoordeling. In de RACI-matrix is de FG doorgaans Consulted bij classificatie en Informed bij alle operationele fasen. Bij incidenten zonder persoonsgegevenscomponent is de rol van de FG beperkt tot advisering op verzoek.
Hoe koppel je AI incident response aan je bestaande BCP?
Het AI incident response plan is een aanvulling op je bestaande bedrijfscontinuiteitsplan en incident-response-procedure. Gebruik dezelfde severity-niveaus en escalatiestructuur. Voeg AI-specifieke criteria toe aan de classificatiematrix. Neem AI-systemen op in je business impact analyse met recovery time objectives. Definieer fallback-procedures voor als een AI-systeem moet worden uitgeschakeld. Zorg dat het AI-response-team aansluit op je bestaande crisisteam. Test AI-scenario's als onderdeel van je reguliere BCP-oefeningen. Dit voorkomt dat je twee parallelle processen hebt die bij een werkelijk incident botsen of elkaar tegenspreken.
Gerelateerde gidsen
Deze pagina's sluiten direct aan op het incident response plan en geven verdere verdieping per onderwerp.
Opgesteld met AI-ondersteuning door de redactie van Prometheus21, laatst bijgewerkt op . Hoe wij content maken
AI incident response plan voor jouw organisatie
We helpen je bij het opstellen van een compleet incident response plan dat past bij jouw AI-systemen, organisatieomvang en wettelijke verplichtingen. Met werkbare procedures die je team onder druk kan volgen.
