AI Act incidentrapportage: consultatie staat nú open

Hoe de nieuwe meldregels voor ernstige AI-incidenten uw incidentrespons fundamenteel veranderen

Waarom deze consultatie verder reikt dan alleen rapportageformulieren

Op 31 oktober 2025 publiceerde de Europese Commissie twee cruciale documenten die de praktische werking van de AI Act tastbaar maken. Het eerste is een concept-richtsnoer dat uitlegt wanneer een incident "ernstig" is en welke stappen providers en deployers moeten nemen. Het tweede is een gestandaardiseerd rapportagesjabloon voor meldingen bij nationale markttoezichthouders.

Deze meldplichten, gebaseerd op Artikel 73 van de AI Act, gaan daadwerkelijk gelden vanaf augustus 2026. Ze markeren een fundamentele verschuiving in hoe organisaties omgaan met AI-incidenten. Waar cybersecurity-incidenten al jaren rapportageplichten kennen onder NIS2 en datalekken onder de GDPR, brengt de AI Act nu een specifiek regime voor AI-gerelateerde schade aan gezondheid, veiligheid, fundamentele rechten en kritieke infrastructuur.

Voor organisaties die AI inzetten in zorg, onderwijs, mobiliteit, werkgelegenheid of rechtshandhaving is dit niet slechts een extra rapportageverplichting. Het vraagt om een fundamentele herijking van incidentrespons, waarbij niet alleen technische storingen maar ook onverwachte modeluitkomsten, discriminerende beslissingen en indirecte causale ketens onder de loep moeten.

Wat de AI Act precies verstaat onder een "ernstig incident"

De AI Act definieert een ernstig incident in Artikel 3(49) als een incident of storing die direct of indirect leidt tot één van de volgende uitkomsten:

Het concept-richtsnoer verduidelijkt dat ook indirecte causaliteit onder de meldplicht kan vallen. Dit is cruciaal omdat AI-systemen zelden direct schade veroorzaken, maar vaak als schakel in een beslisketen fungeren. Latham & Watkins wijst erop dat dit betekent dat een fout in een diagnostisch AI-advies dat pas via een daaropvolgende klinische beslissing tot schade leidt, wél onder de meldplicht valt.

Praktische voorbeelden per sector

Zorg en medische diagnostiek

Een triagetool die systematisch risicopatiënten onderschat, waardoor behandeling te laat start, valt onder de eerste trigger. Ook een radiologie-AI die bij bepaalde demografische groepen lagere sensitiviteit heeft en daardoor afwijkingen mist, kan leiden tot meldplichtige gezondheidsschade. Het concept benadrukt dat de provider moet melden zodra het causale verband redelijkerwijs kan worden aangenomen, niet pas na definitief bewijs.

Onderwijs en werving

Een beoordelingsmodel dat structureel bepaalde groepen benadeelt bij studieplaatsbeslissingen of een wervingsalgoritme dat systematisch kandidaten met bepaalde achtergronden afwijst, kunnen inbreuken op fundamentele rechten vormen. Taylor Wessing merkt op dat de AI Act discriminerende uitkomsten expliciet als mogelijke trigger noemt, ook als er géén sprake is van een technische storing in traditionele zin.

Mobiliteit en kritieke infrastructuur

Een computer vision-systeem in verkeersinfrastructuur dat objecten verkeerd classificeert en zo een onomkeerbare verstoring veroorzaakt, bijvoorbeeld door verkeerde signaalvoering of uitschakelen van verkeerstechnische middelen. Dit zou onder de tweede trigger vallen. Belangrijk detail: de verstoring moet ernstig en onomkeerbaar zijn, niet elke tijdelijke glitch.

Wie moet melden en binnen welke termijnen

De meldplicht ligt primair bij providers van hoog-risico AI-systemen. Zodra een provider weet, of redelijkerwijs moet aannemen, dat er een ernstig incident is met een oorzakelijk verband met zijn systeem, start de klok. De conceptrichtsnoeren stellen drie verschillende termijnen voor, afhankelijk van de ernst:

Deze termijnen zijn aanzienlijk korter dan wat veel organisaties gewend zijn bij bijvoorbeeld jaarlijkse veiligheidsrapportages. Het concept staat toe dat providers eerst een incomplete eerste melding indienen en later aanvullen met resultaten van het interne onderzoek. Na de melding volgt een verplicht onderzoek en moeten corrigerende maatregelen worden overwogen.

De rol van deployers

Deployers die een ernstig incident signaleren, moeten de provider onverwijld informeren. Het concept verduidelijkt dat dit pragmatisch gelezen wordt als binnen 24 uur. Dit sluit aan op bestaande incidentresponspraktijken, maar legt deze wél vast in een AI-specifieke context en creëert een formele informatieplicht richting de provider.

In de praktijk betekent dit dat deployers moeten kunnen detecteren wanneer een AI-systeem onverwachte uitkomsten produceert die mogelijk tot schade leiden, ook als het systeem technisch correct functioneert maar bijvoorbeeld onverwachte edge cases tegenkomt.

Samenloop met andere meldplichten: een complexe puzzel

Een van de meest praktische vragen die organisaties hebben, is hoe de AI Act-meldplicht zich verhoudt tot bestaande regimes zoals GDPR-datalekmeldingen (binnen 72 uur), NIS2-incidentmeldingen, MDR/IVDR voor medische hulpmiddelen, en DORA in de financiële sector.

De Commissie erkent in het concept dat dubbele lasten vermeden moeten worden. In sectoren waar al equivalente meldplichten bestaan, stelt het concept dat de AI-meldplicht zich kan beperken tot inbreuken op fundamentele rechten en dat andere gevolgen via het sectorspecifieke regime worden gemeld. De consultatie vraagt expliciet om praktijkvoorbeelden om dit verder te verfijnen.

Dit voorkomt twee keer hetzelfde verhaal opsturen, maar vereist wél dat u uw interne meldroutes exact in kaart brengt en per incident een quick assessment maakt van welke regimes van toepassing zijn.

Het rapportagesjabloon: wat moet er in de melding

Het rapportagesjabloon dat nu voorligt is gedetailleerd en dwingt tot traceerbaarheid. Het sjabloon vraagt onder meer om:

Administratieve identificatie Gegevens van de provider en deployer, contactpersonen voor follow-up, en identificatie van de bevoegde markttoezichthouder.

Technische systeemidentificatie EU-database-ID (zodra de database operationeel is), classificatie als hoog-risico systeem, versienummer en configuratie, plus datum van ingebruikname.

Incidentbeschrijving en causaliteit Feitelijke gebeurtenissen in chronologische volgorde, wanneer het incident ontdekt werd en door wie, causaal verband tussen AI-systeem en uitkomst, directe versus indirecte causaliteit, en aantal getroffen personen en ernst van impact.

Onderzoeksresultaten Oorzakenanalyse (root cause), welke systeemcomponent heeft gefaald of onverwacht gepresteerd, of dit een technische storing was of een design limitation, en of er eerdere signalen of near-misses waren.

Corrigerende maatregelen Reeds genomen acute mitigaties, geplande structurele aanpassingen, tijdlijn voor implementatie, en impact op andere deployments van hetzelfde systeem.

Het doel is vergelijkbare data te verzamelen voor toezicht en het identificeren van systemische risicotrends over verschillende organisaties en sectoren heen.

Wat dit betekent voor incidentrespons in de praktijk

Incidentrespons wordt breder dan cybersecurity. Onder de AI Act gaat het ook over modelgedrag, foutieve uitkomsten, en schade aan fundamentele rechten. Dat vraagt om een multidisciplinair playbook waarin legal, risk, data science, operations en communicatie samenwerken.

Nieuwe detectie-signalen

Traditionele security monitoring vangt technische storingen en inbraken. Voor AI-incidenten moet u ook signalen detecteren van model drift (prestaties verslechteren in productie), fairness-problemen (systematische verschillen in uitkomsten tussen groepen), onverwachte failure modes (systeem faalt op edge cases die niet in test set zaten), en ongewenste generalisatie (model extrapoleerd buiten zijn trainingsdomein).

Zonder deze signalen ziet u het incident te laat en haalt u de termijnen niet. Het concept benadrukt snelle melding en daarna verdiepend onderzoek, wat betekent dat uw detectiemechanismen real-time of near-real-time moeten zijn voor kritieke toepassingen.

Bewijswaarde en reconstructie

De meldtermijnen zijn kort. Zonder audit trail en herleidbare logging kunt u de causaliteit niet aannemelijk maken binnen de vereiste termijn. Denk aan het bewaren van model artifacts (welke modelversie draaide ten tijde van het incident), inference logs (welke input leidde tot welke output), training data provenance (herkomst en eigenschappen van trainingsdata), configuration geschiedenis (feature flags, hyperparameters, thresholds), human oversight logs (wanneer mensen interveneerden en waarom), en output samples (representatieve voorbeelden van systeemgedrag voor en tijdens incident).

Het concept waarschuwt bovendien om geen wijzigingen door te voeren die het onderzoek bemoeilijken zonder dit te melden. Dit betekent dat uw change management proces moet kunnen omgaan met een "freeze" voor forensische analyse, terwijl u tegelijkertijd acute risicomitigatie moet kunnen doorvoeren.

Drie checks die u vandaag kunt doen

1. Definities en drempels: wanneer telt iets als AI-incident?

Leg intern vast wanneer iets als meldplichtig AI-incident telt. Gebruik de vier uitkomsten uit de AI Act als kapstok en documenteer voorbeelden per domein. Betrek fundamentele-rechtenrisico's expliciet, ook als er géén datalek of technische storing is.

Praktische oefening: Neem uw drie meest kritieke AI-use-cases en beantwoord voor elk: welke van de vier triggers (gezondheid, infrastructuur, grondrechten, eigendom) zou kunnen spelen? Wat is een realistisch scenario waarbij indirecte causaliteit speelt? Wie zou dit incident als eerste detecteren (gebruikers, monitoring, externe klachten)? Binnen welke termijn moet u kunnen melden (2, 10 of 15 dagen)?

2. Bewijs en logging: kunt u binnen termijn feiten aanleveren?

Toets of u met de huidige logs binnen 2, 10 of 15 dagen voldoende feiten kunt aanleveren voor het rapportagesjabloon. Kijk niet alleen naar IT-logging maar ook naar model- en use-case-logging.

Gap-analyse: Kunnen we binnen 24 uur vaststellen welke modelversie actief was? Hebben we inference logs die input-output paren traceren? Kunnen we reconstructen of human oversight werd getriggerd? Is er logging van afwijkende modelgedrag (drift detection)? Bewaren we representatieve output samples voor baseline-vergelijking?

Regel dat u een eerste melding kunt doen met basisfeiten en later aanvult met onderzoeksresultaten, zoals het concept toestaat.

3. Meldroute en samenloop: wie belt wie, wanneer?

Map voor elke AI-use-case de meldroutes: welke toezichthouder is bevoegd voor AI Act-meldingen (waarschijnlijk de nationale markttoezichthouder), welke sectorale toezichthouder (bijv. IGJ voor zorg, AFM voor financieel), en welke privacytoezichthouder bij datalekken.

Neem de samenloop-regels mee zodat u niet dubbel meldt waar het concept equivalentie erkent, én niets mist waar aanvullende meldingen nodig zijn.

Hoe ziet een werkbaar playbook eruit?

Een effectief AI-incident playbook heeft de volgende componenten:

Trigger en triage Eén loket waar signalen binnenkomen (monitoring alerts, gebruikersklachten, interne escalaties), met triage op drie dimensies: veiligheid en gezondheid (trigger 1, 2 en 4), fundamentele rechten (trigger 3), en operationele impact. De triage bepaalt welke termijn geldt en welke toezichthouders geïnformeerd moeten worden.

Rolvast handelen Provider-rollen helder belegd met mandaat om te besluiten over meldingen, inclusief back-ups voor 24/7 beschikbaarheid. Deployers weten hoe en binnen welk tijdsframe (24 uur) zij de provider informeren. Legal, data science en operations hebben vooraf afgestemde verantwoordelijkheden in het onderzoek.

First notice procedure Een kort format dat de minimale velden van het EU-sjabloon dekt, zodat u binnen de termijn kunt melden met basisfeiten. Later vult u aan met volledige onderzoeksresultaten.

Onderzoek en behoud (forensics) Vastgestelde bewaartermijnen voor model artifacts, logs en configuraties die relevant zijn voor het incident. Een freeze-procedure die automatisch relevant materiaal beveiligt zodra een potentieel meldplichtig incident wordt getriggerd.

Remediatie en communicatie Set van mitigerende maatregelen per incidenttype. Communicatieplan richting betrokkenen (gebruikers die mogelijk impact ervaren), toezichthouders (verplichte meldingen), en eventueel het publiek bij wijdverspreide impact.

Lessen en updates Na afronding de use-case-risico's herijken op basis van lessons learned. FRIA en DPIA bijwerken met nieuwe risico-inzichten. Trainingsdata of modelkeuzes bijstellen als het incident een structureel probleem blootlegde.

Hoe u effectief reageert op de consultatie

De Commissie vraagt nadrukkelijk om praktijkvoorbeelden en samenloopcasuïstiek. Dit is uw kans om de definitieve richtsnoeren werkbaar te maken voor uw sector en use-cases.

Suggesties voor uw reactie

Concretiseer indirecte causaliteit Vraag om heldere voorbeelden wanneer een indirect verband voldoende is en hoe dat zich verhoudt tot de bewijslast in het sjabloon. Geef een sectorspecifiek voorbeeld uit uw domein waarbij de causale keten complex is.

Bespreek termijn-haalbaarheid Licht toe hoe u de termijnen praktisch haalt met een first-notice benadering en welke gegevens u realistisch binnen 2, 10 of 15 dagen kunt leveren versus wat langer onderzoek vereist.

Geef samenloop-voorbeelden Beschrijf scenario's waarin u wél of juist niet ook onder GDPR, MDR, NIS2 of DORA meldt en wat daar de knelpunten zijn.

Sector-specifieke complexiteit Als uw sector specifieke uitdagingen heeft, beschrijf dit met een concreet voorbeeld en stel pragmatische oplossingen voor.

De consultatie sluit vrijdag 7 november 2025. Reacties kunnen worden ingediend via het Have Your Say-portaal van de Europese Commissie.

Waarom nu handelen

De meldplichten gelden pas vanaf augustus 2026, maar de impact op uw processen, tooling en governance is direct. Het opzetten van adequate logging, monitoring en incidentrespons-procedures voor AI-systemen vergt maanden. Teams moeten getraind worden, playbooks getest, en tooling aangepast. Starten in 2026 betekent dat u de eerste maanden ad-hoc improviseert bij incidenten.

Gebruik het concept-sjabloon om een gap-analyse te doen van uw huidige datavoorziening en verantwoordelijkheden. Als u GPAI-modellen met systemisch risico aanbiedt of integreert, stem dan het nieuwe GPAI-meldsjabloon af met uw hoog-risico-proces, zodat u één coherent raamwerk heeft.

Drie concrete volgende stappen

1. Bepaal de scope Maak een inventaris van welke van uw AI-use-cases onder hoog-risico vallen volgens Annex III van de AI Act. Bepaal voor elke use-case wie juridisch de provider is versus de deployer.

2. Simuleer een incident en test de klok Kies een realistisch incidentscenario voor uw meest kritieke AI-systeem. Doorloop het playbook en meet of u binnen 2, 10 of 15 dagen de vereiste gegevens kunt rapporteren. Identificeer de gaps en maak een plan om deze te dichten.

3. Dien een reactie in op de consultatie Gebruik uw sector-expertise om de Commissie te helpen de richtlijnen werkbaar te maken. Eén of twee concrete cases zijn waardevoller dan abstracte opmerkingen. De consultatie sluit vrijdag 7 november 2025.

Bronnen en verdere verdieping

• Europese Commissie: AI Act: Draft guidance and reporting template on serious AI incidents (consultatie tot 7 november 2025)
• Europese Commissie: AI Act: Reporting template for serious incidents involving GPAI models with systemic risk (4 november 2025)
• Latham & Watkins: European Commission Publishes Draft Guidance on Reporting Serious AI Incidents (analyse oktober 2025)
• Taylor Wessing: EU AI Act in practice: A deep dive into reporting obligation (oktober 2025)
• EUR-Lex: Regulation (EU) 2024/1689 - AI Act (volledige wettekst)