Art. 26.5, monitoring: houd de werking van je AI in de gaten

Bijgewerkt: juni 2026

Inleiding: monitoring als continue compliance-plicht

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 zijn geen statische tools, ze opereren in dynamische omgevingen, verwerken steeds nieuwe data en produceren beslissingen met reële gevolgen voor mensen. Art. 26.5 EU AI ActEU AI ActVerordening (EU) 2024/1689, in het Nederlands de AI-verordening, de Europese wet over artificiële intelligentie. Ze hanteert een risicogebaseerde aanpak: verboden praktijken, eisen voor hoogrisico-AI-systemen, transparantieverplichtingen voor specifieke toepassingen en een apart regime voor AI-modellen voor algemene doeleinden (general-purpose AI). Verplichtingen zijn verdeeld tussen aanbieders en gebruiksverantwoordelijken. Zie hoogrisico-AI-systeem, general-purpose AI, conformiteitsbeoordeling.Open full entry → erkent dit door deployers te verplichten het systeem actief te monitoren in de operationele context. Compliance is niet afgerond bij ingebruikname; het is een doorlopende verantwoordelijkheid.

Art. 26.5 verplicht deployers om: (1) de werking van het 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 → te monitoren op basis van de gebruiksinstructies, (2) afwijkingen van de verwachte prestaties te signaleren, en (3) relevante bevindingen te melden aan de provider en, bij risico's voor derden, aan de bevoegde autoriteit.

Juridische context: Art. 26.5 en Art. 72

Art. 26.5 is de deployer-pendant van Art. 72, dat providers verplicht tot 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 → van hun systemen. Providers moeten een post-market monitoring plan opstellen; deployers moeten actief bijdragen aan de informatieverzameling in hun specifieke context.

Overweging 93 stelt dat deployers in een unieke positie zijn: zij kennen de operationele context, de eindgebruikers en de specifieke populatie waarop het systeem wordt ingezet. Afwijkingen die in de productieomgeving optreden, zijn voor de provider vaak onzichtbaar zonder feedback van de deployer. Art. 26.5 formuleert deze informatieplicht juridisch.

Wat moet gemonitord worden?

De gebruiksinstructies van de provider moeten specificeren welke prestatieparameters relevant zijn voor dit systeem. In het algemeen omvat monitoring bij hoog-risico AI:

Prestatiemonitoring:

• Nauwkeurigheid van voorspellingen of classificaties over tijd
• Vertrouwensscores en de distributie ervan
• Foutpercentages (false positives / false negatives) per subgroep
• Responsetijden en systeembeschikbaarheid

FairnessfairnessHet principe dat een AI-systeem geen groep systematisch benadeelt. Het breekt zelden openlijk: de gangbare routes zijn historische data die eerdere scheefheid meeneemt naar nieuwe beslissingen, en proxy-discriminatie, waarbij een model nooit een beschermd kenmerk ziet maar er een vervanger voor leert, zoals een postcode of een gat in een cv. Onder de EU AI Act moeten aanbieders van hoogrisico-AI-systemen hun datasets onderzoeken op mogelijke bias (artikel 10), en enkele discriminerende toepassingen zijn ronduit verboden (artikel 5). Zie bias, verantwoorde AI, hoogrisico-AI-systeem.Open full entry →-monitoring:

• Vergelijkende analyse van uitkomsten per demografische groep (geslacht, leeftijd, etniciteit)
• Detectie van disproportionele impact op kwetsbare groepen
• Trend-analyse: verslechtert de fairness over tijd?

Driftmonitoring:

• Concept driftdriftHet geleidelijk afwijken van het gedrag of de prestaties van een AI-systeem van zijn gevalideerde staat na ingebruikname, zonder codewijziging of fout. Drift is van nature stil: er breekt niets, de nauwkeurigheid neemt gewoon af totdat iemand meet. De oorzaken zijn het onderscheiden waard: een verschuiving in de binnenkomende zakenmix, een wijziging in het bronmateriaal, een wijziging in omliggende systemen, of een update van het onderliggende model door de aanbieder. Zie model drift, agent drift.Open full entry →: verandert de relatie tussen inputvariabelen en het te voorspellen fenomeen?
• Data drift: wijzigt de verdeling van inputdata significant ten opzichte van de trainingsdatatrainingsdataDe data die wordt gebruikt om de parameters van een AI-model te passen; de kwaliteit, de rechtmatige rechten en de representativiteit ervan zijn centrale governance-zorgen. Zie representativiteit, herkomst, datasheet.Open full entry →?
• Distributieverschuivingen die op modelveroudering kunnen duiden

Monitoringfrequentie en -methode

De provider-instructies bepalen de minimale monitoringfrequentie. Aanvullend geldt als uitgangspunt: hoe groter de impact van individuele AI-beslissingen, hoe hogere de monitoringfrequentie. Een hoog-risico systeem dat dagelijks honderden kredietbeslissingen neemt, vraagt om dagelijkse of wekelijkse monitoring. Een systeem dat maandelijks enkele beoordelingen uitvoert, kan volstaan met maandelijkse reviews.

Praktische monitoringmethoden:

• Geautomatiseerde dashboards die real-time KPIs tonen (aanbevolen voor hoge-volume systemen)
• Steekproefgewijze handmatige review van AI-beslissingen door een onafhankelijke medewerker
• Vergelijkende analyse van AI-beslissingen versus handmatige beslissingen in parallelle cases
• Klachtenanalyse: signaleren 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 → disproportioneel nadeel van AI-beslissingen?

Wanneer moet u de provider informeren?

Art. 26.5 verplicht deployers om afwijkingen aan de provider te melden. De gebruiksinstructies moeten beschrijven wat als "afwijking" geldt. Algemene meldingsdrempels zijn:

• Prestatiemetrieken die buiten de door de provider gespecificeerde bandbreedte vallen
• Systematische fouten die een bepaalde subgroep disproportioneel treffen
• Onverwacht systeemgedrag dat niet door de provider was voorzien
• Gevallen waarbij het systeem beslissingen produceert die aantoonbaar onjuist zijn

Naast de provider moet de deployer bij ernstige incidents ook de nationale toezichthouder informeren conform Art. 73 EU AI Act.

Deployer-specifieke implicaties

Monitoring-verantwoordelijkheid bij meerdere deployers: Als een hoog-risico AI-systeem door meerdere deployers wordt ingezet (bijv. een cloudplatform), draagt elke deployer een eigen monitoringverplichting voor zijn specifieke toepassingsomgeving. U kunt niet verwijzen naar monitoring door andere deployers.

Koppeling aan logretentie (Art. 26.6): Monitoring is alleen zinvol als de logs beschikbaar zijn voor analyse. Zorg dat uw monitoring-setup gebruik maakt van de logs die het systeem genereert (Art. 12) en die u conform Art. 26.6 bewaart.

Documentatie voor de toezichthouder: Leg uw monitoringresultaten vast: datum van review, gemeten metrieken, vergelijking met normen, geconstateerde afwijkingen, acties ondernomen. Dit is uw 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 → van due diligence bij een incident.

Handhaving en sancties

Niet-naleving van Art. 26.5 valt onder Art. 99.4: boetes tot €15.000.000 of 3% van de wereldwijde jaaromzet. Bij incidenten waarbij inadequate monitoring een rol speelde, is de deployer primair aansprakelijk.

Veelgestelde vragen

V: Onze provider levert geen monitoringtools. Moeten wij die zelf bouwen?
A: De provider is verplicht om de technische middelen voor monitoring te leveren (Art. 13.3, Art. 72). Als die ontbreken, kunt u de provider contractueel aanspreken. Intussen kunt u zelf basic monitoring opzetten via steekproefsgewijze handmatige review en klachtenanalyse, dit is niet ideaal maar beter dan geen monitoring.

V: Hoe detecteer ik concept drift als ik geen toegang heb tot de modelinternals?
A: Concept drift is detecteerbaar via output-analyse: monitort u of de uitkomstdistributie van het model over tijd significant verandert zonder dat de inputpopulatie verandert. Een plotselinge stijging van positieve scores bij een kredietmodel zonder duidelijke populatiewijziging kan duiden op drift. Meld dit aan de provider.

Checklist: Art. 26.5 compliance

1. Beschikt u voor elk hoog-risico AI-systeem over een schriftelijk monitoringplan met frequentie en metrieken?
2. Worden prestatiemetrieken periodiek vergeleken met de door de provider gespecificeerde normen?
3. Worden fairness-metrieken gemonitord (uitkomsten per demografische subgroep)?
4. Is er een procedure voor het melden van afwijkingen aan de provider?
5. Worden monitoringresultaten en -acties gedocumenteerd?
6. Is er een drempel gedefinieerd waarboven een bevinding als "incident" wordt gekwalificeerd (Art. 73)?
7. Wordt klachtdata van betrokkenen systematisch geanalyseerd als monitoring-input?