EU AI-verordening Post-marktbewaking (Art. 72): Verplichtingen voor Aanbieders van Hoog-risico AI

Naleving eindigt niet bij markttoelating. Art. 72 verplicht aanbieders van hoog-risico AI-systemen een actief post-marktbewakingssysteem te onderhouden, prestatiegegevens te verzamelen en ernstige incidenten te rapporteren. Hier leest u wat u moet doen — en wanneer.

Wat is post-marktbewaking?

Conformiteitsbeoordeling en CE-markering zijn het toegangsbewijs tot de EU-markt voor een hoog-risico AI-systeem — niet de eindstreep. Artikel 72 van de EU AI-verordening legt een voortdurende verplichting op: aanbieders moeten een post-marktbewakingssysteem (PMB) opzetten en beheren dat actief prestatiegegevens uit de praktijk verzamelt, analyseert en erop handelt gedurende de operationele levensduur van het systeem.

De redenering is eenvoudig. Een AI-systeem dat is gevalideerd op een vaste dataset kan driften naarmate reële invoer verschuift, de gebruikerspopulatie verandert of de omgeving waarin het opereert evolueert. Statische conformiteitssnapshots kunnen dit niet vastleggen. PMB is het mechanisme dat naleving omzet in een continu proces in plaats van een eenmalige gebeurtenis.

Het PMB-systeem moet evenredig zijn aan de aard en risico's van het betrokken hoog-risico AI-systeem. Een kredietscoringsmodel ingezet op grote schaal voor miljoenen consumenten zal intensievere monitoring vereisen dan een nauw documentclassificatietool die intern door een gereguleerde onderneming wordt gebruikt.

Wie moet een PMB-systeem opzetten?

Verplicht voor:

• Aanbieders van zelfstandige hoog-risico AI-systemen van Bijlage III — systemen vermeld in Bijlage III die geen veiligheidscomponenten van een product zijn (bijv. AI gebruikt bij werkgelegenheidsbeslissingen, toegang tot onderwijs, rechtshandhaving, beoordeling van kredietwaardigheid, beheer van kritieke infrastructuur)
• Aanbieders van AI-systemen ingebed in producten van Bijlage I — AI-veiligheidscomponenten geïntegreerd in producten die vallen onder bestaande EU-harmonisatiewetgeving (medische hulpmiddelen, machines, voertuigen)

Niet vereist voor:

• Aanbieders van minimaal-risico AI-systemen (geen formele PMB-verplichting, hoewel goede praktijk van toepassing is)
• Aanbieders van uitsluitend transparantie AI-systemen (Art. 50-verplichtingen strekken zich niet uit tot PMB)
• Aanbieders van GPAI-modellen — deze zijn onderworpen aan een afzonderlijk regime op grond van Art. 61–62, dat incidentrapportage voor modellen met systemisch risico omvat maar anders is gestructureerd dan Art. 72 PMB

De rol van de gebruiker is ondersteunend maar niet optioneel. Gebruikers moeten het AI-systeem gebruiken in overeenstemming met de instructies van de aanbieder, de loggingfunctionaliteit ingebouwd in het systeem activeren en bewaren, en — cruciaal — eventuele ernstige incidenten waarvan zij op de hoogte zijn zonder onnodige vertraging aan de aanbieder melden. Een gebruiker die een ernstig incident observeert en de aanbieder niet informeert, voldoet niet.

Het post-marktbewakingsplan (Bijlage IV, punt 12)

Het PMB-plan is een verplicht onderdeel van de technische documentatie (Bijlage IV). Het kan geen generiek document zijn: het moet specifiek zijn voor het systeem, de inzetcontext en de geïdentificeerde risico's. Het moet minimaal definiëren:

1. Gegevensverzameling — welke prestatiemetrieken worden vastgelegd (nauwkeurigheid, foutpercentages, beslissingsresultaten), hoe gegevens worden verzameld (geautomatiseerde telemetrie, gebruikersrapporten, gebruikersfeedback) en met welke frequentie
2. Feedbackmechanismen — het mechanisme waarmee gebruikers prestatieproblemen, afwijkingen of incidenten op een gestructureerde en tijdige manier aan de aanbieder kunnen melden
3. Nauwkeurigheidsmonitoring — hoe de prestaties van het systeem worden bijgehouden aan de hand van de gevalideerde benchmark die is gebruikt tijdens de conformiteitsbeoordeling, inclusief een eventuele driftdetectiemethodologie
4. Vertekeningsmonitoring — voor systemen waarbij demografische resultaten materieel zijn (aanstelling, krediet, rechtshandhaving), doorlopende monitoring van statistische dispariteiten over beschermde groepen, met gedefinieerde methodologie en drempels
5. Updatetriggers — de specifieke kwantitatieve of kwalitatieve drempels die corrigerende actie triggeren, inclusief modelhertraining, parameteraanpassing of opschorting van inzet
6. Beoordelingsschema — hoe vaak het PMB-plan zelf wordt beoordeeld en bijgewerkt, zodat het doeltreffend blijft naarmate de inzetcontext evolueert

Het PMB-plan moet up-to-date worden gehouden. Een verouderd plan dat de werkelijke monitoringmethodologie niet meer weerspiegelt, voldoet niet aan Art. 72.

Melding van ernstige incidenten (Art. 73)

Wat vormt een ernstig incident?

Artikel 73 definieert een ernstig incident als elk incident of elke storing van een hoog-risico AI-systeem dat direct of indirect leidt tot:

• Overlijden of ernstig letsel voor de gezondheid (lichamelijk of psychologisch)
• Een ernstige en onomkeerbare verstoring van het beheer of de exploitatie van kritieke infrastructuur
• Een ernstige schending van grondrechten (privacy, non-discriminatie, rechtsgang)
• Een situatie waarin een persoon ternauwernood een van het bovenstaande heeft vermeden

Belangrijk is dat de AI-verordening niet vereist dat een causaal verband met het AI-systeem wordt vastgesteld vóór rapportage. Een redelijk vermoeden dat het AI-systeem heeft bijgedragen aan of de schade niet heeft voorkomen, is voldoende om de verplichting te triggeren. Aanbieders die wachten op zekerheid vóór rapportage riskeren niet-naleving.

Rapportagetermijnen

De termijn van 15 dagen begint wanneer de aanbieder op de hoogte is van het incident — wat in de praktijk betekent wanneer de gebruiker hen informeert. Aanbieders moeten hun kennisgevingsprocedures voor gebruikers zo ontwerpen dat informatie hen snel genoeg bereikt om de downstream-rapportagetermijn te halen.

Wat een incidentmelding moet bevatten

Een conforme incidentmelding aan de nationale markttoezichtautoriteit moet bevatten:

• Systeemidentificatie: naam, versie, EU-databaseregistratienummer
• Beschrijving van het incident: wat er is gebeurd, welke schade is opgetreden of ternauwernood is vermeden, datum en locatie
• Getroffen personen: aantal en categorieën getroffen gebruikers of derde partijen (geanonimiseerd waar vereist door de AVG)
• Voorlopige causaliteitsanalyse: het huidige inzicht van de aanbieder in hoe het incident is ontstaan, duidelijk gelabeld als voorlopig
• Onmiddellijk genomen corrigerende of veiligheidsmaatregelen: eventuele stappen die al zijn ondernomen om verdere schade of risico te beperken (bijv. opschorting van getroffen functionaliteit, meldingen aan gebruikers)
• Contactpunt: de persoon of het team dat verantwoordelijk is voor vervolgcorrespondentie met de autoriteit

Het rapport moet feitelijk en evenredig zijn. Voorlopige rapporten kunnen worden aangevuld met vervolgrapportages naarmate het onderzoek vordert.

Verplichte logging (Art. 12)

Artikel 12 vereist dat hoog-risico AI-systemen worden ontworpen en gebouwd met de mogelijkheid om automatisch logboeken te genereren op een granulariteitsniveau dat voldoende is om:

• Post-marktbewaking mogelijk te maken in overeenstemming met Art. 72
• Tracing van gebeurtenissen die hebben geleid tot een ernstig incident
• Onderzoek door nationale autoriteiten

Dit is een ontwerpvereiste opgelegd aan de aanbieder. De aanbieder moet de loggingmogelijkheid in het systeem inbouwen vóór het op de markt wordt gebracht.

De verplichting om die logboeken te activeren en te bewaren valt op de gebruiker. Gebruikers mogen loggingfunctionaliteit niet uitschakelen en moeten logboeken bewaren voor de periode die is gespecificeerd in de instructies en technische documentatie van de aanbieder. Wanneer geen specifieke bewaartermijn is gedefinieerd, moeten logboeken worden bewaard voor een periode die aansluit bij de operationele levenscyclus van het systeem en eventuele sectorspecifieke vereisten (bijv. financiële dienstverlening boekhoudingregelgeving op grond van DORA of MiFID II).

Substantiële wijzigingen en herbeoordeling

Niet elke wijziging aan een ingezet AI-systeem triggert een nieuwe conformiteitsbeoordeling. De verordening maakt onderscheid tussen kleine updates en substantiële wijzigingen.

Een wijziging is substantieel — en vereist een nieuwe conformiteitsbeoordeling en bijgewerkte technische documentatie — wanneer het:

• Het beoogde doel van het systeem wijzigt (zelfs gedeeltelijk)
• Een significante wijziging van de architectuur of trainingsmethodologie inhoudt
• Nieuwe trainingsgegevens gebruikt die de prestaties van het systeem materieel beïnvloeden op manieren die nalevingsrelevant gedrag kunnen beïnvloeden
• De prestaties verslechtert voorbij drempels gedefinieerd in de risicobeheerdocumentatie op manieren die veiligheid of grondrechten beïnvloeden

Kleine updates — beveiligingspatches, bugfixes die duidelijk geïdentificeerde defecten corrigeren zonder nalevingsrelevant gedrag te wijzigen, cosmetische interfacewijzigingen — vereisen geen volledige herbeoordeling. Ze moeten echter worden gedocumenteerd, en de aanbieder moet een schriftelijke beoordeling bewaren die bevestigt dat de wijziging geen substantiële wijziging is. Dat record is onderworpen aan inspectie door markttoezichtautoriteiten.

Praktische implementatiechecklist

De volgende checklist weerspiegelt de minimale operationele vereisten op grond van Art. 72, Art. 73 en Art. 12. Het is geen vervanging voor juridisch advies maar biedt een startpunt voor gap-analyse.

• [ ] PMB-plan gedocumenteerd in het technisch dossier (Bijlage IV, punt 12), specifiek voor het systeem en zijn inzetcontext
• [ ] Geautomatiseerde loggingmogelijkheid ontworpen en ingebouwd in het systeem vóór marktplaatsing
• [ ] Gebruikersinstructies bevatten een duidelijke, schriftelijke incidentrapportageprocedure met escalatiecontact
• [ ] Intern incidentrapportagecontactpunt opgericht en gemeld aan de relevante nationale markttoezichtautoriteit
• [ ] Vertekening- en nauwkeurigheidsmonitoringprocessen of -dashboards gedefinieerd, met gedocumenteerde methodologie en drempels
• [ ] Escalatiedrempels voor corrigerende actie gedocumenteerd en gekoppeld aan het risicobeheersysteem
• [ ] Substantiële-wijzigingsbeoordelingsprocedure van kracht, met een beslissingsrecordsjabloon voor elke update
• [ ] Logboekbewaardbeleid gedefinieerd, gecommuniceerd aan gebruikers en afgestemd op sectorspecifieke bewaardregels

Kruisverwijzingen: Technische Documentatie — Bijlage III Hoog-risico AI-systemen — Aanbieders versus Gebruikers