Veel teams horen “data governance” en denken aan een dataregister, bewaartermijnen en eigenaarschapstabellen. Onder de EU AI Act is Artikel 10 concreter en pittiger dan dat. Het gaat om de vraag of een aanbieder van een hoog-risico AI-systeem echt kan uitleggen en verdedigen welke data het systeem heeft gevormd.
Dat is belangrijk, omdat veel AI-fouten niet beginnen bij het model. Ze beginnen eerder, in aannames onder de data, in gaten die niemand heeft vastgelegd, en in bias waarvan iedereen hoopte dat die later wel zou middelen. Artikel 10 is het deel van de AI Act dat zegt: dat is niet genoeg.
Voor aanbieders van hoog-risico AI-systemen is dit artikel geen bijzaak. Het is een van de operationele fundamenten van de hele compliance-architectuur, naast Artikel 9 over risicobeheer, Artikel 13 over informatie voor gebruiksverantwoordelijken en Artikel 14 over menselijk toezicht.
Wat Artikel 10 precies vereist
De wettekst van Artikel 10 bevat zes leden, en die structuur doet ertoe.
Lid 1 zet de hoofdregel neer. Als een hoog-risico AI-systeem gebruikmaakt van technieken waarbij AI-modellen met data worden getraind, dan moet het systeem zijn ontwikkeld op basis van trainings-, validatie- en testdatasets die voldoen aan de kwaliteitscriteria uit lid 2 tot en met 5.
Lid 2 is de echte machinekamer. Dat lid eist passende data governance en data management voor het beoogde doel van het hoog-risico AI-systeem. Daarna volgt een lijst met acht concrete onderdelen die aanbieders moeten beheersen: ontwerpkeuzes, dataverzameling en herkomst, datapreparatie, aannames, beschikbaarheid en geschiktheid, bias-onderzoek, bias-mitigatie en relevante datagaten of tekortkomingen.
Lid 3 legt de kwaliteitslat neer. Trainings-, validatie- en testdata moeten relevant, voldoende representatief en, voor zover mogelijk, foutvrij en volledig zijn gezien het beoogde doel.
Lid 4 voegt context toe. De datasets moeten rekening houden met de geografische, contextuele, gedragsmatige en functionele setting waarin het systeem gebruikt gaat worden.
Lid 5 creëert een smalle en zwaar begrensde route om bijzondere categorieën van persoonsgegevens te verwerken wanneer dat strikt noodzakelijk is voor biasdetectie en biascorrectie.
Lid 6 maakt nog één ding duidelijk. Als het hoog-risico AI-systeem niet werkt met trainingstechnieken, dan gelden lid 2 tot en met 5 nog steeds, maar alleen voor testdata.
Dat laatste punt wordt vaak onderschat. Artikel 10 gaat dus niet alleen over foundation models of klassieke machine learning pipelines. Ook systemen waarbij testdata de cruciale validatielaag vormt, vallen binnen het bereik.
Lid 2 is waar compliance operationeel wordt
Het meeste Article 10-werk zit in lid 2. De wet vraagt niet of je “goede data” hebt in abstracte zin. De wet vraagt of je kunt uitleggen, documenteren en verdedigen hoe die data is gekozen en behandeld.
Ontwerpkeuzes en herkomst van data
Aanbieders moeten de ontwerpkeuzes achter hun datastrategie vastleggen. Waarom deze bronnen? Waarom deze labels? Waarom deze inclusie- en exclusiecriteria? Waarom deze mix van echte data en synthetische data?
Je moet dus vragen kunnen beantwoorden zoals:
- Voor welke populatie of omgeving is het systeem bedoeld?
- Welke databronnen zijn gebruikt om die omgeving te weerspiegelen?
- Welke bronnen zijn afgewezen, en waarom?
- Waar komen persoonsgegevens vandaan, en wat was het oorspronkelijke doel van de verzameling?
Hier raakt Artikel 10 direct aan AVG-realiteit. Als je trainingsdata uit oude operationele systemen, externe leveranciers, publieke datasets of samengestelde databronnen komt, dan doet het herkomstverhaal ertoe. Niet later, nu.
Datapreparatie en aannames
Artikel 10 noemt expliciet annotatie, labelling, cleaning, updating, enrichment en aggregatie. Dat is een nuttig signaal. De AI Act kijkt niet alleen naar ruwe dataverzameling, maar naar de hele keten van bewerking.
Veel aanbieders documenteren de menselijke keuzes in die keten nog steeds te dun. Terwijl juist die keuzes het model vormen.
Als een HR-model is getraind op uitkomsten van cv-screening, dan heeft iemand bepaald wat een “goede uitkomst” is. Als een fraudemodel is getraind op historische onderzoeken, dan heeft iemand bepaald welke dossiers als bevestigd gelden. Als een gemeentelijk systeem is getraind op interventiedata, dan heeft iemand bepaald wat de data eigenlijk hoort te meten.
Artikel 10 lid 2, onderdeel d, is daarom belangrijk. De wet eist dat aannames expliciet worden geformuleerd. Dat is een directe aanval op een hardnekkige AI-gewoonte: een proxy behandelen alsof het een feit is. Kosten zijn niet hetzelfde als behoefte. Eerdere interventie is niet hetzelfde als werkelijk risico. Historische aanname is niet hetzelfde als kwaliteit.
Bias-onderzoek, mitigatie en datagaten
Artikel 10 stopt niet bij het herkennen van bias. Het eist onderzoek naar bias, passende maatregelen om bias te detecteren, voorkomen en mitigeren, en expliciete identificatie van datagaten of tekortkomingen.
Dat is strenger dan veel aanbieders gewend zijn.
Een aanbieder kan niet geloofwaardig zeggen: “we weten dat de data niet perfect is, maar het model presteert gemiddeld goed.” Artikel 10 dwingt tot een lastiger vraag: goed voor wie, in welke context, onder welke aannames, en met welke resterende zwaktes?
Hier horen Artikel 9 en Artikel 10 bij elkaar. Als het risicobeheersysteem discriminatie, representativiteit of datadrift signaleert, dan is Artikel 10 een van de plekken waar dat risico echt moet worden aangepakt.
Representativiteit is contextueel, niet generiek
Lid 3 en 4 worden vaak onderschat als je ze te snel leest.
De wet vraagt niet om een soort universeel representatieve dataset. De wet vraagt om data die representatief is gezien het beoogde doel en gezien de echte omgeving waarin het systeem gebruikt zal worden.
Dat verandert de analyse.
Een kredietwaardigheidsmodel voor consumenten in één lidstaat kun je niet verdedigen met de opmerking dat de dataset groot is. De aanbieder moet kijken of de data echt aansluit op de relevante populatie, de juridische context, gedragspatronen en productomgeving.
Een recruitmenttool voor publieke werkgevers kun je niet rustig baseren op historische data uit vooral private-sector werving en dan doen alsof dat verschil er niet toe doet.
Een gemeentelijk risicoscoringsmodel kun je niet laten leunen op data die de lokale sociaal-economische context slecht weerspiegelt en daarna zeggen dat het systeem neutraal is omdat de code neutraal is.
Daarom is Artikel 10 lid 4 zo nuttig. Het snijdt door het luie verweer heen dat “de dataset een industriestandaard is.” Industriestandaard is niet de juridische standaard. Contextfit is dat wel.
Twijfel je nog of je use case binnen hoog-risico valt, gebruik dan de risicobeoordelingstool en leg die naast de relevante categorieën in Bijlage III.
2 minuten, geen account nodigLeer de EU AI Act door te doen
Geen slides. Geen saaie e-learning. Probeer een interactieve module.
LearnWizeProbeer het zelf
3 interactieve oefeningen. Verdien XP. Ontdek waarom dit beter werkt dan lezen.
Doe de volledige test op LearnWizeArtikel 10 is geen vrijbrief voor gevoelige data
Lid 5 is een van de meest verkeerd begrepen onderdelen van het artikel.
Ja, de AI Act laat aanbieders in uitzonderlijke gevallen bijzondere categorieën van persoonsgegevens verwerken voor biasdetectie en biascorrectie. Maar die route is bewust smal. Ze geldt alleen als dat strikt noodzakelijk is, en alleen als het doel niet effectief kan worden bereikt met andere data, waaronder synthetische of geanonimiseerde data.
Daarna volgen zes waarborgen. Er moeten beveiligings- en privacybeschermende maatregelen zijn. Toegang moet strikt zijn afgeschermd en gedocumenteerd. De data mag niet aan andere partijen worden verstrekt. De data moet worden verwijderd zodra het biasdoel is bereikt of de bewaartermijn eindigt. En in het verwerkingsregister moet staan waarom het gebruik van deze bijzondere categorieën strikt noodzakelijk was.
De praktische boodschap is dus simpel: lid 5 is een uitzondering, geen gemaksknop.
Als je gevoelige data nodig hebt om te testen of het systeem bepaalde groepen benadeelt, leg die noodzaak dan zorgvuldig vast. Als je die data niet nodig hebt, grijp er dan niet achteloos naar. Artikel 10 probeert biascorrectie mogelijk te maken zonder een achterdeur te openen voor slordige of buitensporige verwerking.
Post-market learning verandert het gesprek over Artikel 10
Artikel 10 is geschreven als datagovernancebepaling, maar in de praktijk kan die niet bevriezen in de ontwikkelfase.
Waarom niet? Omdat je pas in de echte wereld dingen ziet die je in een labsituatie mist. Populaties verschuiven. Gedrag verandert. Input wordt rommeliger. Gebruikers vertrouwen output op onverwachte manieren. Feedbackloops ontstaan.
Daarom behandelen sterke aanbieders Artikel 10 niet als een eenmalige datasetnotitie. Ze koppelen het aan:
- Artikel 9 risicobeheer
- Artikel 12 logging
- Artikel 13 informatie voor gebruiksverantwoordelijken
- Artikel 72 post-market monitoring
Als post-market signalen laten zien dat bepaalde groepen ondervertegenwoordigd zijn, dat bepaalde input instabiel is of dat in de praktijk slechtere uitkomsten ontstaan dan verwacht, dan moet de aanbieder de logica van Artikel 10 opnieuw openen. Data governance is niet klaar omdat versie 1 live staat.
Wat aanbieders nu moeten doen
Als je een hoog-risico AI-systeem op de markt brengt, bestaat een praktisch Artikel 10-programma meestal uit zes werkstromen.
- Breng de hele dataketen in kaart. Leg herkomst, verzamelingslogica, bewerkingsstappen en eigenaarschap vast voor trainings-, validatie- en testdata.
- Maak aannames expliciet. Schrijf op wat elke dataset hoort te meten, waar de proxies zitten en waar die proxies kunnen falen.
- Test representativiteit tegen de echte gebruikscontext. Niet tegen een generieke benchmark, maar tegen het beoogde doel, de doelgroep, geografie en werkomgeving.
- Voer gestructureerde biasanalyse uit. Kijk naar discriminatierisico, subgroepzwaktes en feedbackloops, zeker waar output later weer input kan worden.
- Houd datagaten en herstelmaatregelen bij. Artikel 10 verwacht dat je tekortkomingen aanwijst en uitlegt hoe je ze gaat repareren.
- Verbind Artikel 10 met lifecycle governance. Als je Artikel 10-dossier losstaat van monitoring, incidenten en versiebeheer, veroudert het snel.
Die discipline aan aanbiederskant helpt ook gebruiksverantwoordelijken. Een organisatie die aan Artikel 26 wil voldoen of een FRIA moet uitvoeren, heeft duidelijke aanbiedersdocumentatie nodig. Dunne Artikel 10-discipline levert meestal ook dunne Artikel 13-documentatie op, en dat wordt daarna iemands anders complianceprobleem.
Waar organisaties meestal de mist in gaan
De eerste fout is Artikel 10 behandelen als een data quality-slogan. De wet vraagt om gedocumenteerde governance, niet om algemeen vertrouwen.
De tweede fout is alleen naar trainingsdata kijken. Validatie- en testdata tellen ook mee, en bij niet-trainende systemen kan testdata juist de kern zijn.
De derde fout is schaal verwarren met representativiteit. Een enorme dataset kan nog steeds slecht aansluiten op het beoogde doel.
De vierde fout is alleen op modelniveau over fairness praten en bias in annotatie, proxy-ontwerp of historische labels buiten beeld laten.
De vijfde fout is aannemen dat synthetische data alles oplost. Soms helpt het. Soms maskeert het vooral het probleem. Artikel 10 laat niet toe dat je analyse daar stopt.
Veelgestelde vragen
De belangrijkste vragen en antwoorden bij dit onderwerp.