De IAPP stelt dat organisaties hun beproefde crisis- en cyberdraaiboeken moeten uitbreiden voor AI-incidenten, zoals een model dat zijn taakgrens overschrijdt. Houd daarom twee gekoppelde tracks aan: een conventioneel spoor voor gecompromitteerde systemen of data, en een AI-control-spoor voor onverwacht of ongeautoriseerd modelgedrag, met eigen criteria, monitoring en bewijsbehoud.
Op 19 oktober 2026 wees de International Association of Privacy Professionals (IAPP) in haar wekelijkse opinierubriek op een concreet gat in de voorbereiding: veel organisaties hebben hun crisis- en cybersecurityplannen getest, maar die plannen gaan niet over AI-incidenten. Dat is geen theoretisch probleem. Een AI-incident kan bijvoorbeeld iets anders zijn dan een datalek. Naar onze analyse kan het gaan om een model dat een actie uitvoert waarvoor het geen opdracht had, een gemanipuleerde monitor, of een agent die zijn bedoelde data- of toolgrens overschrijdt zonder dat er ooit een klassieke inbraak plaatsvindt.
Dat de voorbereiding achterloopt, is meetbaar. Uit het State of Cybersecurity-onderzoek van ISACA onder ruim 1.800 beveiligingsprofessionals blijkt dat slechts een klein deel van de organisaties regelmatig AI-specifieke responsoefeningen houdt, terwijl bijna de helft van de respondenten niet weet of de eigen organisatie een AI-incidentplaybook heeft, of aangeeft dat die er niet is. Tegelijk wordt AI al breed ingezet in beveiligingsoperaties. De inzet gaat dus sneller dan de voorbereiding op wat er misgaat.
Waarom volstaat een bestaand cyber-responsplan niet voor AI-incidenten?
Omdat een conventioneel plan doorgaans vooral is ingericht rond gecompromitteerde systemen en gelekte data, terwijl AI-incidenten ook kunnen draaien om gedrag van een model dat formeel binnen zijn rechten blijft maar iets onbedoelds doet. Een AI-incident kan draaien om een actie die technisch is toegestaan maar buiten de bedoelde taak valt, of om een bijna-incident dat nooit een meldbaar lek wordt.
Het klassieke draaiboek vraagt: welk systeem is binnengedrongen, welke data is weg? Een AI-control-incident vraagt iets anders: welk model deed wat, met welke rechten, via welke tools, en wie keurde dat goed? Naar onze inschatting is dit het kernpunt van de IAPP-observatie: de twee vragen overlappen, maar lossen elkaar niet op. Wie alleen de eerste vraag kan beantwoorden, mist precies het bewijs dat nodig is om de tweede te reconstrueren. Een voorbeeld van hoe fijn de scheidslijn is, beschreven we eerder bij een model dat zijn eigen testomgeving beschadigde.
Welke concrete maatregelen schrijft de NIST-richtlijn voor bij een AI-incident?
De aanbevelingen voor incident response van het National Institute of Standards and Technology (NIST) bieden de operationele basis. Ze vragen om het verzamelen en bewaren van model-, trainings-, evaluatie- en deploymentomgevingen, het behoud van configuratie, safeguards, tool-aanroepen, trajecten en beslissingen van beveiligingscontroles, en om manipulatiebestendige logs waarmee de activiteit van een agent en de getroffen systemen te reconstrueren zijn.
Vertaald naar een AI-incidentspoor betekent dat concreet:
- definieer vooraf wat een AI-incident en een bijna-incident is, zodat onverwacht modelgedrag een trigger wordt in plaats van een anekdote;
- houd een inventaris bij van modellen, de harness, tools, credentials en omgevingen die een agent kan bereiken;
- monitor model, host, netwerk en het traject van de agent; naar onze aanbeveling moeten monitoring en logs daarbij buiten de controle van de agent zelf blijven;
- bewaar manipulatiebestendig bewijs dat voldoende is om achteraf te reconstrueren wat er gebeurde;
- trek credentials in en beperk, isoleer of beëindig de activiteit bij een incident; dit is onze praktische vertaling van containment naar een AI-control-spoor;
- herbouw vanaf geverifieerde baselines en documenteer het restrisico voordat de dienst weer aangaat.
De NIST-aanbevelingen voor incident response vervangen uw bestaande praktijk niet; ze breiden die uit met AI-specifieke vastleggingen. Het idee om monitoring en bewijs buiten het bereik van het model te houden, sluit aan bij de redenering om geavanceerde AI te behandelen als een insider met te veel rechten.
Wat betekent dit voor bestuurders, juristen en CISO's die nu beslissen?
Onze analyse: omdat een AI-incident een ongeautoriseerde modelactie kan zijn zonder klassiek datalek, missen bestuurders bij één draaiboek het aangrijpingspunt om te beslissen of er iets meldbaar is; daarom moet de directie nu vaststellen welke twee tracks bestaan en wie welk spoor activeert. Omdat uit het ISACA-onderzoek blijkt dat bijna de helft niet weet of er een AI-playbook is, loopt de CISO het risico dat bewijs al verloren is op het moment dat het incident wordt herkend; daarom hoort integriteitsmonitoring van modellen en het manipulatiebestendig wegschrijven van tool-aanroepen en trajecten nu in het beheersplan, los van de agent. Omdat de NIST-richtlijn vraagt om reconstrueerbare logs, moet de jurist vóór inzet vastleggen wie welke modelactie mocht goedkeuren en hoe die goedkeuring wordt bewaard, zodat de meldplicht later op feiten rust in plaats van op reconstructie achteraf. En omdat voor sommige AI-incidenten wettelijke of contractuele rapportageverplichtingen kunnen gelden, moet de verantwoordelijke functionaris de interne AI-incidentcriteria nu laten toetsen aan de toepasselijke externe meldcriteria, met juridisch advies waar regelgeving zoals de EU AI Act mogelijk relevant is,
Voor de agenda van het eerstvolgende risicooverleg betekent dit: wijs eigenaren aan voor beide tracks, plan een tabletop-oefening met een AI-scenario, en toets of uw logging het traject van een agent überhaupt kan reconstrueren. Wie incidenttriage en meldplicht door elkaar laat lopen, maakt beide zwakker; we werkten die scheiding eerder uit bij het scheiden van incidenttriage en meldplicht bij AI-incidenten.
Hoe richt ik twee gekoppelde responsplaybooks in?
Houd één conventioneel spoor voor gecompromitteerde systemen of data en één AI-control-spoor voor ongeautoriseerd of onverwacht modelgedrag, met gedeelde escalatie maar eigen criteria en bewijsregels. De tracks zijn gekoppeld omdat een AI-incident kan overlopen in een klassiek lek en omgekeerd, maar ze hebben elk hun eigen eerste vraag.
- Conventioneel spoor: inbraak, malware, datalek; vraag: welk systeem, welke data, welke meldplicht onder de AVG?
- AI-control-spoor: ongeautoriseerde actie, gemanipuleerde monitor, grensoverschrijding door een agent, bijna-incident; welke toepasselijke wettelijke of contractuele meldcriteria gelden, waaronder — waar relevant — criteria uit de EU AI Act
- Gedeeld: één escalatielijn, één gedeelde bewijsstandaard, geïnformeerd door de NIST-aanbevelingen, één coördinatie van rapportage richting betrokkenen en toezichthouders.
Meer achtergrond over beheersing van AI-risico vindt u in onze themahub over AI-security en incidentbeheersing. De kern blijft nuchter: de IAPP roept niet op tot een nieuw apparaat, maar tot een gerichte uitbreiding van wat u al heeft.
Bronnen en referenties
Bronnen: Het artikel steunt op de opinierubriek van de IAPP, het State of Cybersecurity-onderzoek van ISACA en de incident-responsaanbevelingen van NIST (SP 800-61 Rev. 3).