Art. 26.4, input-data: zorg voor relevante en representatieve data

Bijgewerkt: juni 2026

Inleiding: de deployer als databewaker

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 zo goed als de data die er in gaat. Art. 26.4 EU AI Act legt de verantwoordelijkheid voor inputdatakwaliteit expliciet bij de deployer: u bent verplicht om te waarborgen dat de data die u aan het systeem aanlevert, voldoet aan de specificaties en instructies van de provider. Dit is geen technische vanzelfsprekendheid, het is een juridische plicht met handhavingsrisico.

De verplichting geldt naast de datakwaliteitseis van Art. 10, die zich richt op de provider (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 →). Art. 26.4 richt zich op de inferentieinferentieDe fase waarin een getraind model uitvoer produceert op nieuwe invoer, in tegenstelling tot de trainingsfase waarin het zijn parameters leert. Zie machine learning, AI-systeem.Open full entry →-fase: de data die uw systeem daadwerkelijk verwerkt bij elke beslissing. Een model dat perfect is getraind, kan volledig ontsporen als de inputdata niet klopt.

Juridische context: Art. 26.4 in samenhang met Art. 10

Art. 10 verplicht providers om hoog-risico AI-systemen te trainen op data die voldoet aan hoge kwaliteitseisen: relevant, representatief, vrij van fouten en volledig. Art. 26.4 verplicht deployers om dezelfde kwaliteitsstandaard te handhaven voor de inputdata die zij operationeel inzetten.

Overweging 91 stelt dat de kwaliteit van inputdata een kritieke determinant is voor de betrouwbaarheid en non-discriminerende werking van hoog-risico AI. Als een systeem wordt gevoed met verouderde, incomplete of biased data, kunnen de resultaten systematisch onjuist zijn, ook als het model zelf correct functioneert.

Welke inputdata valt onder Art. 26.4?

Art. 26.4 richt zich op alle data die de deployer aanlevert aan het 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 → als input voor beslissingen. Afhankelijk van het type systeem kan dit zijn:

• Persoonsgegevens (naam, adres, gedragsdata, biometrische data)
• Documentdata (cv's, medische dossiers, financiële overzichten)
• Sensordata (camerabeelden, IoT-signalen, GPS-coördinaten)
• Transactiedata (betalingshistorie, gebruik van diensten)
• Contextdata (tijdstip, locatie, toesteltype)

Wat valt er NIET onder Art. 26.4: Data die het systeem zelf genereert of ophaalt (zoals webscraping door het model) is de verantwoordelijkheid van de provider, niet van de deployer. Wél is de deployer verantwoordelijk voor de configuratie die bepaalt welke externe bronnen het systeem mag raadplegen.

Concrete verplichtingen voor deployers

1. Specificaties kennen en toepassen: De gebruiksinstructies van de provider (Art. 13.3) moeten de vereiste inputdata beschrijven: formaat, volledigheid, actualiteit, toegestane waarden. De deployer moet deze specificaties vertalen naar interne databeheerprocessen.

2. Datakwaliteitscontroles implementeren: Vóórdat data wordt ingevoerd in het AI-systeem, moet de deployer technische en/of procedurele controles uitvoeren. Voorbeelden: validatieregels die onvolledigheid of outliers signaleren, data-enrichment om ontbrekende velden aan te vullen, deduplicatie om dubbele records te voorkomen.

3. Actualiteit waarborgen: Veel hoog-risico systemen zijn gevoelig voor verouderde data. Een kredietbeoordelingsmodel dat wordt gevoed met financiële data van 2 jaar geleden, produceert onbetrouwbare scores. De deployer moet refreshfrequenties vaststellen en bewaken.

4. RepresentativiteitrepresentativiteitHoe goed de trainingsdata de populatie en de omstandigheden weerspiegelt die het systeem bij inzet zal tegenkomen, de kern van datakwaliteit voor AI in termen van geschiktheid voor het doel. Zie eerlijkheid, trainingsdata.Open full entry → bewaken: Als de deployer het systeem inzet voor een populatie die niet vertegenwoordigd is in de trainingsdata van de provider, moet de deployer de provider hiervan op de hoogte stellen (Art. 26.5) en eventuele bias actief monitoren.

Interactie met de AVG

De meeste hoog-risico AI-systemen verwerken persoonsgegevens. Art. 26.4 EU AI Act en de datakwaliteitsbeginsel van Art. 5.1.d AVG (juistheid) lopen parallel. Een deployer die onnauwkeurige persoonsgegevens invoert in een AI-systeem schendt zowel Art. 26.4 EU AI Act als Art. 5.1.d AVG.

Praktische implicatie: als uw DPIADPIAData Protection Impact Assessment, vereist vóór verwerking met waarschijnlijk hoog risico (systematische profilering met aanzienlijke gevolgen, grootschalige bijzondere categorieën, publieke monitoring); AI-ontwikkeling roept het voortdurend op. Zie impactassessment, profilering.Open full entry → (Art. 35 AVG) gebreken in inputdatakwaliteit identificeert, moet u die ook adresseren in uw Art. 26.4-maatregelen. De twee compliance-trajecten overlappen hier.

Grensgevallen en praktijkdilemma's

Ontbrekende data: Wat doet u als verplichte inputvelden ontbreken? De provider-instructies moeten hier uitsluitsel over geven: is het systeem nog betrouwbaar bij partieel ontbrekende data, of moet de casus worden geëscaleerd naar handmatige verwerking? Als de instructies dit niet regelen, eis dit dan bij de provider.

Historisch biased data: Als uw bestaande databestanden historische bias bevatten (bijv. HR-data uit een periode met discriminatoire selectiepraktijken), mag u deze data niet ongewijzigd als inputdata gebruiken. Overleg met de provider over data-correctie of -uitsluiting.

Real-time vs. batch: Bij real-time systemen (bijv. fraudedetectie) is kwaliteitscontrole vóór inzending soms niet praktisch. Implementeer dan controles achteraf en een correctieprocedure voor gevallen waarbij de inputdata achteraf onjuist blijkt.

Handhaving en sancties

Niet-naleving van Art. 26.4 valt onder Art. 99.4: boetes tot €15.000.000 of 3% van de wereldwijde jaaromzet. De toezichthouder kan ook van de deployer eisen dat het gebruik van het systeem wordt opgeschort totdat adequate datakwaliteitsborging is aangetoond.

Veelgestelde vragen

V: Onze data wordt aangeleverd door een derde partij. Wie is verantwoordelijk voor de kwaliteit?
A: De deployer blijft verantwoordelijk voor de inputdata die hij aan het AI-systeem aanlevert, ongeacht de herkomstherkomstDe gedocumenteerde oorsprong en geschiedenis van data of inhoud, gebruikt om vast te stellen waar ze vandaan komt en of ze betrouwbaar of rechtmatig te gebruiken is. Zie trainingsdata, datasheet.Open full entry →. U kunt contractueel kwaliteitsgaranties eisen van uw dataleverancier, maar de Art. 26.4-verplichting rust op u. Implementeer altijd een eigen kwaliteitscontrole op ontvangen data voordat u deze aan het AI-systeem doorgeeft.

V: Het AI-systeem werkt met real-time sensordata. Hoe controleer ik die vóór inzending?
A: Bij real-time sensordata zijn pre-inzending-controles beperkt tot range-checks en outlier-detectie. Implementeer aanvullend een monitoring-systeem dat anomalieën in inputdata signaleert (Art. 26.5) en een rollback-procedure voor gevallen waarbij corrupte sensordata is verwerkt.

Checklist: Art. 26.4 compliance

1. Beschikt u voor elk hoog-risico AI-systeem over de inputdata-specificaties van de provider?
2. Zijn er technische validatieregels die inputdata toetsen op volledigheid, formaat en plausibiliteit?
3. Is er een vastgestelde refreshfrequentie voor tijdsgevoelige inputdata?
4. Is er een procedure voor het geval verplichte inputvelden ontbreken?
5. Worden datakwaliteitsincidenten (foutieve input die AI-beslissingen heeft beïnvloed) geregistreerd?
6. Is de inputdata gecontroleerd op historische bias die discriminerende outputs kan veroorzaken?
7. Voldoen uw inputdata-processen aan Art. 5.1.d AVG (juistheid van persoonsgegevens)?