Art. 73, incident-rapportage: meld ernstige incidenten

Bijgewerkt: juni 2026

Inleiding: incidenten zijn onvermijdelijk, het meldproces is een keuze

Hoog-risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → AI-systemen zullen in de praktijk incidenten veroorzaken. Dat is geen pessimisme, het is een realistisch uitgangspunt van de EU AI Act zelf. Art. 73 regelt hoe deployers en providers met die incidenten moeten omgaan: transparant, tijdig en systematisch. Een goed incidentresponse-proces is niet alleen een wettelijke verplichting; het is ook de meest effectieve bescherming tegen aansprakelijkheid jegens de toezichthouder.

Art. 73 verplicht deployers om ernstige incidenten en storingen te melden aan de nationale markttoezichthouder. De verplichting gaat hand in hand met de logretentie (Art. 26.6) en de monitoringverplichting (Art. 26.5): incidenten kunnen alleen tijdig worden gesignaleerd als u actief monitort en logs bewaart.

Juridische context: Art. 73 in de handhavingsstructuur

Art. 73 staat in Hoofdstuk IX (Post-market monitoringpost-market monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry →, informatiedeling en markttoezicht). Het is onderdeel van een breder informatiedeelingsysteem: providers hebben een post-market monitoring plicht (Art. 72), deployers hebben een monitoringplicht (Art. 26.5) en een meldplicht bij incidenten (Art. 73). Het informatiekanaal loopt van deployer naar provider én naar de toezichthouder.

Art. 73 werkt naast de meldplicht voor datalekken (AVG Art. 33): een AI-incidentAI-incidentElke gebeurtenis waarbij de uitkomsten, handelingen of gegevensverwerking van een AI-systeem schade veroorzaakten of plausibel konden veroorzaken, of wezenlijk afweken van gevalideerd gedrag, inclusief schadelijke uitkomsten van een systeem dat technisch werkt. Zie ernstig incident, post-incident review.Open full entry → dat ook een datalek inhoudt, moet aan zowel de toezichthouder (Art. 73) als de AP (Art. 33 AVG) worden gemeld. De termijnen zijn verschillend.

Wat is een "ernstig incident"?

Art. 3.49 EU AI Act definieert een ernstig incidenternstig incidentEen AI-incident dat de dood, ernstige schade aan gezondheid, eigendom, grondrechten of infrastructuur veroorzaakt (of bijna veroorzaakt), wat meldplichten aan toezichthouders activeert voor hoog-risicosystemen. Zie AI-incident, markttoezichtautoriteit.Open full entry → als een incident of storing in de werking van een hoog-risico AI-systeemAI-systeemEen machinaal systeem dat voor expliciete of impliciete doelen uit invoer afleidt hoe het uitvoer genereert, voorspellingen, inhoud, aanbevelingen of beslissingen, die fysieke of virtuele omgevingen kunnen beïnvloeden. De OESO-achtige definitie die de EU AI Act volgt. Zie algoritme, machine learning.Open full entry → dat direct of indirect leidt tot:

• Overlijden of ernstig letsel van een persoon
• Ernstige verstoring van kritieke infrastructuur
• Schending van verplichtingen uit Unierecht ter bescherming van grondrechten
• Ernstige materiële of immateriële schadeschadeDe concrete schade die een AI-systeem kan aanrichten en die een principe van verantwoorde AI beoogt te voorkomen: in de termen van de EU AI Act schade aan iemands gezondheid, veiligheid of grondrechten. Schade is de brug tussen een abstract principe en een bestuurbaar risico; governance wordt operationeel op het moment dat een organisatie de specifieke schades benoemt die ze wil voorkomen. Voor eerlijkheid is een schade dat een groep stelselmatig slechtere uitkomsten krijgt vanwege een kenmerk dat niet had mogen meetellen. Zie principe, risico.Open full entry → (inclusief aanzienlijke discriminatie)

Het gaat om directe gevolgen van een fout of onverwacht gedrag van het AI-systeem, niet om incidenten die volledig door menselijke fouten zijn veroorzaakt zonder AI-component.

Wat valt er NIET onder: Suboptimale maar correcte AI-output die achteraf een slechte beslissing blijkt; tijdelijke systeemuitval zonder gevolgen voor betrokkenenbetrokkenenDe individuen of groepen die onderworpen zijn aan of geraakt worden door de uitkomsten of beslissingen van een AI-systeem, en wier rechten het governance-regime beoogt te beschermen. Zie schade, belanghebbendenanalyse.Open full entry →; edge cases die binnen de verwachte prestatiemarge van het systeem vallen.

Meldingstermijnen

Art. 73.3 stelt de volgende termijnen:

• Onmiddellijk (zo spoedig mogelijk, uiterlijk binnen 15 dagen): melding aan de toezichthouder van het incident
• Bij overlijden: melding zo spoedig mogelijk, maar uiterlijk 24 uur na constatering dat het incident waarschijnlijk heeft geleid tot overlijden
• Follow-up rapport: binnen 3 maanden na de initiële melding, met beschrijving van oorzaak, corrigerende maatregelen en aanbevelingen

De termijnen gelden vanaf het moment dat de deployer redelijkerwijs op de hoogte had kunnen zijn van het incident, niet alleen vanaf formele constatering. Bewuste vertraging in de detectie of rapportage is een verzwarende omstandigheid bij handhaving.

Wat moet de melding bevatten?

Art. 73.3 bepaalt de minimale inhoud van de initiële melding:

• Naam en contactgegevens van de deployer
• Beschrijving van het incident (wat is er gebeurd, wanneer, welke AI-systeem)
• Categorie en ernst van de schade
• Aantal betrokken personen
• Directe corrigerende maatregelen die al zijn getroffen
• Verwijzing naar de provider van het systeem

Bij de follow-up melding (binnen 3 maanden) voegt u toe:

• Resultaten van het root cause-onderzoek
• Structurele corrigerende maatregelen
• Aanbevelingen voor andere deployers of de provider

Deployer-specifieke implicaties

Incidentresponse-process: Bouw een gestructureerd incidentresponse-process dat beschrijft: (a) wie incidenten kan signaleren en melden (intern), (b) wie beslist of een incident meldingsplichtig is, (c) wie de melding aan de toezichthouder doet, en (d) hoe het root cause-onderzoek wordt gevoerd. Dit process moet schriftelijk zijn vastgelegd en jaarlijks worden geoefend.

Drempelwaarden voor interne escalatie: Definieer interne drempels die lager liggen dan de wettelijke melddrempel. Incidenten die de wettelijke drempel niet bereiken, moeten intern worden geanalyseerd en kunnen indicatoren zijn voor toekomstige ernstige incidenten. Meld ook "near misses" intern.

Informeer de provider: Art. 73.1 verplicht deployers om de provider te informeren over het incident. De provider heeft aanvullende meldverplichtingen (Art. 73.2) en kan corrigerende maatregelen op systeem-niveau doorvoeren. Stel de provider in kennis gelijktijdig met of vóór de melding aan de toezichthouder.

Koppeling aan logretentie (Art. 26.6): Bij een onderzoek door de toezichthouder naar een incident zijn de logs het primaire bewijsbewijsHet concrete bewijs dat een control is ontworpen, geïmplementeerd en werkt: een testrapport, een audit trail, een impactassessment, een monitoringlog. Elke schakel in de governance-keten levert een artefact op, en samen zijn ze wat een organisatie overhandigt aan haar eigen bestuur, een toezichthouder, een klant of een betrokkene om te tonen, niet te zeggen, dat een systeem bestuurd is. De afwezigheid ervan is zelf het falen: een risicoregister zonder testresultaten, of een maatregel die wordt geclaimd zonder validatie, is een governance-gat, geen papierwerk-gat. De sluitende schakel van de governance-keten. Zie control, governance.Open full entry →. Zorg dat logs van de periode rondom het incident zijn veiliggesteld en niet worden overschreven of verwijderd.

Samenloop met AVG-meldplicht

Als het AI-incident ook een inbreuk in verband met persoonsgegevens (datalek) inhoudt, gelden cumulatieve meldplichten:

• Toezichthouder: uiterlijk 15 dagen (Art. 73 EU AI Act)
• AP: uiterlijk 72 uur (Art. 33 AVG)

Coördineer de twee meldingen, ze mogen niet tegenstrijdig zijn. Stem de inhoud af met uw DPO en legal counsel vóór verzending.

Handhaving en sancties

Niet tijdig of niet volledig melden is een zelfstandige overtreding onder Art. 99.4: boetes tot €15.000.000 of 3% van de wereldwijde jaaromzet. Bovendien is vertraagde melding een verzwarende omstandigheid bij de beoordeling van de totale compliance van de deployer.

Veelgestelde vragen

V: Een AI-systeem heeft een foutieve aanbeveling gedaan. Is dat een ernstig incident?
A: Alleen als de foutieve aanbeveling heeft geleid tot de gevolgen beschreven in Art. 3.49 (overlijden, ernstig letsel, grondrechtenschending, ernstige materiële schade). Een foutieve aanbeveling die is gecorrigeerd door menselijk toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry →, zonder nadelige gevolgen, is geen meldingsplichtig incident. Documenteer het wel intern.

V: Waar is het meldpunt voor AI-incidenten?
A: De bevoegde markttoezichthouder kent een digitaal meldpunt voor AI Act-incidenten. Raadpleeg de website van de toezichthouder voor de actuele meldprocedure en het meldformulier.

V: Moeten wij elk AI-gerelateerde klacht van een betrokkene melden?
A: Nee. Klachten van betrokkenen zijn geen incidenten in de zin van Art. 73, tenzij ze de drempel van Art. 3.49 overstijgen. Wel moet u klachten intern analyseren als potentiële indicatoren van systemische problemen.

Checklist: Art. 73 incidentresponse

1. Is er een schriftelijk incidentresponse-process dat beschrijft wie incidenten signaleert, escaleert en meldt?
2. Zijn interne melddrempels gedefinieerd die lager liggen dan de wettelijke melddrempel?
3. Weet uw team wat de meldingstermijnen zijn (24 uur bij overlijden, 15 dagen standaard)?
4. Is er een procedure voor het veiligstellen van logs bij een incident?
5. Is vastgelegd wie de melding aan de toezichthouder doet en wie de provider informeert?
6. Is er een procedure voor samenloop met de AVG-meldplicht (72 uur bij de AP)?
7. Wordt het incidentresponse-process minimaal jaarlijks geoefend?
8. Worden near-misses intern geregistreerd en geanalyseerd?