EU AI Act: Eisen voor robuustheidstesten uitgelegd

De EU AI Act verplicht hoogrisico AI-systemen tot het ondergaan van strenge robuustheidstesten om betrouwbare prestaties te waarborgen onder fouten, storingen of onverwachte omstandigheden. Deze vereiste, uiteengezet in Artikel 15, geldt voor systemen in kritieke sectoren zoals gezondheidszorg, transport en rechtshandhaving. Hier is wat je moet weten:

• Robuustheid gedefinieerd: Het vermogen van AI-systemen om consistente prestaties te handhaven ondanks verstoringen, zoals beschreven in ISO/IEC 25059:2023.
• Hoogrisico AI-systemen: Omvat AI in biometrie, kritieke infrastructuur, onderwijs, werkgelegenheid en meer, zoals vermeld in Bijlage III. Handhaving begint op 2 augustus 2026.
• Testprotocollen: Omvat adversariale testen, belastingstesten en red teaming om kwetsbaarheden te identificeren.
• Documentatie: Aanbieders moeten gedetailleerde technische bestanden voorbereiden, conformiteitsbeoordelingen uitvoeren en records 10 jaar bewaren.
• Post-deployment monitoring: Continue prestatiebewaking en bescherming tegen schadelijke feedbacklussen zijn vereist.

Het niet opvolgen van de EU AI Act-nalevingschecklist kan leiden tot boetes tot €38 miljoen of 7% van de wereldwijde jaaromzet. Begin nu met de voorbereidingen om aan deze vereisten te voldoen voor de handhavingsdeadline.

::: @figure {EU AI Act: Eisen voor robuustheidstesten en nalevingsplanning} :::

Hoogrisico AI-systemen en toepasselijkheid

Wat kwalificeert als een hoogrisico AI-systeem?

De EU AI Act definieert hoogrisico AI-systemen via twee hoofdbenaderingen. Ten eerste omvat het AI-systemen die fungeren als veiligheidsonderdelen in producten die vallen onder EU-harmonisatiewetten (vermeld in Bijlage I). Voorbeelden zijn machines, medische apparatuur en automobielsystemen waarbij een storing gezondheids- of veiligheidsrisico’s kan opleveren [7]. Ten tweede omvat het systemen die zijn opgenomen in Bijlage III, die acht gebieden bestrijken die fundamentele rechten kunnen beïnvloeden [7][8].

Deze acht categorieën uit Bijlage III zijn:

• Biometrie: Systemen zoals afstandsidentificatie en emotieherkenning.
• Kritieke infrastructuur: Hulpmiddelen voor het beheren van wegverkeer of nutsvoorzieningen (bijv. water, gas, elektriciteit).
• Onderwijs: AI gebruikt bij toelatingsbeslissingen of examenbewaking.
• Werkgelegenheid: Toepassingen zoals cv-screening, promotiebeslissingen en werknemersmonitoring.
• Essentiële diensten: Systemen voor kredietbeoordeling of verzekeringspremies.
• Rechtshandhaving: Hulpmiddelen zoals leugendetectors of recidivevoorspellingsmodellen.
• Migratie en grenscontrole: AI gebruikt bij visumverwerking.
• Rechtspraak en democratie: Systemen ontwikkeld om rechterlijke instanties te ondersteunen [7][8].

Niet alle systemen in deze categorieën kwalificeren automatisch als hoogrisico. Artikel 6 staat vrijstellingen toe als een systeem beperkte taken uitvoert of menselijke activiteiten ondersteunt zonder beslissingen significant te beïnvloeden - mits profiling niet betrokken is. Om deze vrijstelling te claimen, moeten organisaties hun evaluatie documenteren met een beleidassistent en het systeem registreren in de EU-database voordat het op de markt wordt gebracht [8]. Aan de andere kant blijft een AI-systeem dat individuen profileert binnen een domein uit Bijlage III geclassificeerd als hoogrisico [8].

Voor alle hoogrisicosystemen schrijft Artikel 15 robuustheidstesten voor om betrouwbare prestaties gedurende de hele levenscyclus te waarborgen [4]. De handhaving van deze vereisten voor systemen uit Bijlage III begint op 2 augustus 2026 [8].

Dit classificatiekader vormt de basis voor de strenge robuustheidsnormen die de EU AI Act vereist.

Algemene AI en systemisch risico

De wet behandelt ook algemene AI-modellen (GPAI), die niet inherent hoogrisico zijn. Wanneer deze modellen echter worden geïntegreerd in hoogrisicosystemen - zoals het gebruik van een groot taalmodel in werving of kritieke infrastructuur - moeten ze voldoen aan de hoogrisicostandaarden [9][8]. Daarnaast zijn GPAI-modellen die worden geïdentificeerd als "systemisch risico" onderworpen aan specifieke robuustheidseisen, waaronder adversariale testen [9].

Om als systemisch risico te kwalificeren, moet het model een cumulatieve trainingscomputationele kracht hebben die 10^25 FLOPs overschrijdt [9]. Net als andere hoogrisicosystemen moeten deze modellen gedetailleerde evaluaties en adversariale testen ondergaan om kwetsbaarheden op te sporen [6]. De regels voor GPAI-modellen treden in werking op 2 augustus 2025, een jaar eerder dan de bredere vereisten voor hoogrisicosystemen [9].

Technische en organisatorische maatregelen voor robuustheid

Technische veerkracht opbouwen

Artikel 15 van de EU AI Act benadrukt het belang van veerkracht in hoogrisico AI-systemen, waarbij wordt gegarandeerd dat ze operationele verstoringen kunnen weerstaan. Deze systemen moeten fouten, storingen of inconsistenties in hun omgeving kunnen hanteren, zelfs wanneer ze worden geconfronteerd met hardwarestoringen, gecorrumpeerde invoer of onverwacht gebruikersgedrag [1].

Een cruciale benadering om veerkracht te bereiken is technische redundantie. Bijvoorbeeld kan containerisatie systeemoperaties isoleren, waardoor de betrouwbaarheid behouden blijft zelfs wanneer er infrastructuurproblemen optreden [2]. In kritieke omgevingen voegt het ontwerpen voor graceful degradation - waarbij het systeem overgaat op handmatige bediening of back-upsystemen in plaats van volledig uit te vallen - een extra laag betrouwbaarheid toe.

AI-specifieke kwetsbaarheden vereisen ook aandacht. Bedreigingen zoals datapoisoning (vervalsing van trainingsgegevens), modelpoisoning (inbedden van kwaadaardige code tijdens training) en adversariale voorbeelden (invoer ontworpen om de AI te misleiden) vereisen sterke verdedigingen [2]. Het MITRE ATLAS-kader biedt tools om deze risico’s te testen en te mitigeren [2]. Daarnaast kunnen geautomatiseerde monitoring- en waarschuwingssystemen prestatieproblemen of beschikbaarheidsproblemen in realtime identificeren. Gespecialiseerde tools zoals ISMS Copilot One kunnen helpen bij het automatiseren van deze complexe nalevingsworkflows.

Voor AI-systemen die na implementatie blijven leren, vormen feedbacklussen unieke uitdagingen. Als gebiaste resultaten worden gevoed in daaropvolgende trainingsgegevens, kunnen die vooroordelen versterkt worden. Om dit aan te pakken zijn maatregelen zoals selectieve datacuratatie en het beperken van de integratie van real-world feedback essentieel [1]. Gebeurlogen, zoals vereist onder Artikel 12, helpen bij het bijhouden van prestatieveranderingen en het detecteren van potentiële problemen [8].

Deze technische beveiligingen werken samen met organisatorische maatregelen om ervoor te zorgen dat systemen eerlijk en onbevooroordeeld blijven.

Vooroordelen en eerlijkheid aanpakken

Het mitigeren van vooroordelen is niet alleen een ethische verantwoordelijkheid, maar ook een wettelijke verplichting onder de wet. Hoogrisico AI-systemen moeten eerlijk opereren over alle demografische groepen, met name in gevoelige gebieden zoals werkgelegenheid, onderwijs of toegang tot essentiële diensten [8].

Regelmatige audits op eerlijkheid zijn cruciaal. Bijvoorbeeld, als een cv-screeningtool geen rekening houdt met diverse loopbanen of opleidingsachtergronden, kan dit bepaalde groepen oneerlijk benadelen. Dergelijke overtredingen kunnen leiden tot boetes tot €35 miljoen of 7% van de wereldwijde jaaromzet [10].

Menselijk toezicht, zoals voorgeschreven in Artikel 14, is een ander kritiek onderdeel. Mensen moeten de beperkingen van het systeem begrijpen, blind vertrouwen in de resultaten vermijden (automation bias) en ingrijpen wanneer nodig [8]. Een effectieve aanpak is een alleen-adviserend ontwerp, waarbij AI-resultaten door mensen worden beoordeeld voordat er actie wordt ondernomen.

Om vooroordelen systematisch aan te pakken, stel je een Kwaliteitsmanagementsysteem (QMS) op onder Artikel 17. Dit moet schriftelijke beleidslijnen omvatten voor het identificeren en corrigeren van vooroordelen, samen met continue risicobeheer gedurende de hele levenscyclus van het AI-systeem. Post-market monitoring is essentieel voor het evalueren van de prestaties in de praktijk, terwijl geautomatiseerde logs - die ten minste zes maanden worden bewaard - een datatrail creëren voor audits en incidentonderzoeken [8].

Testen en validatie voor robuustheid

Protocollen voor robuustheidstesten

Om ervoor te zorgen dat AI-systemen klaar zijn voor implementatie, schrijft de EU AI Act strenge pre-implementatietesten voor, met name voor hoogrisicosystemen. Deze tests zijn ontworpen om veerkracht te bevestigen tegen fouten, storingen en potentiële aanvallen [1].

Adversariale testen is een cruciale vereiste voor algemene AI-systemen met systemisch risico, evenals voor hoogrisicosystemen. Deze aanpak omvat het simuleren van aanvallen zoals promptinjectie, datapoisoning en model-evasie om te evalueren hoe goed het systeem dergelijke bedreigingen kan weerstaan [10][11]. Een andere kritieke methode is red teaming, waarbij interne of externe experts actief proberen het systeem te doorbreken, wat een uitgebreide beveiligingsevaluatie oplevert [10].

Belastingstesten evalueert hoe systemen omgaan met extreme of ongebruikelijke scenario’s, zoals randgevallen of opzettelijke foutinjecties, waardoor storingen op een gecontroleerde en voorspelbare manier plaatsvinden [10][11].

Testmethode	Beschrijving	Doelgerichte kwetsbaarheden
Adversariale testen	Simuleert aanvallen om invoer of trainingsgegevens te manipuleren	Promptinjectie, datapoisoning/modelpoisoning, model-evasie [10][3]
Belastingstesten	Beoordeelt gedrag onder extreme of ongebruikelijke omstandigheden	Randgeval-storingen, omgevingsinconsistenties [11][8]
Testen op vooroordelen	Analyseert resultaten over demografische groepen	Discriminerende patronen, feedbacklussen [11]
Red teaming	Beveiligingsevaluatie door interne of externe teams	Onbevoegde toegang, model-extractie, systemische risico’s [10]

Om vooroordelen in resultaten te minimaliseren, moeten testdatasets zorgvuldig worden samengesteld om relevant, representatief en zo foutloos mogelijk te zijn [1][11]. Daarnaast moeten aanbieders specifieke nauwkeurigheids- en veerkrachtbenchmarks in hun gebruiksinstructies vermelden, in lijn met de normen van de Europese Commissie [1][3].

"Kwaliteitsborging is geen optie meer - het is de basis voor naleving van regelgeving. Organisaties moeten aantonen dat hun AI-systemen veilig, eerlijk en betrouwbaar zijn voordat ze de EU-markt mogen betreden."

• Igor Kovalenko, QA Lead, TestFort [11]

Zodra deze pre-implementatieprotocollen zijn voltooid, zorgt continue monitoring ervoor dat de systemen ook na implementatie robuust blijven.

Continue monitoring na implementatie

Testen stopt niet wanneer een AI-systeem wordt geïmplementeerd. Volgens Artikel 72 moeten aanbieders post-market monitoringsystemen implementeren die continu prestatiegegevens verzamelen, documenteren en analyseren gedurende de hele levenscyclus van het systeem [4][12]. Dit zorgt ervoor dat het systeem zich aanpast aan evoluerende real-world omstandigheden terwijl de integriteit behouden blijft.

Hoogrisico AI-systemen moeten gebeurtenissen minimaal zes maanden loggen. Deze logs helpen bij het bijhouden van prestaties, het identificeren van potentiële risico’s en het documenteren van significante wijzigingen [6][8][12]. Tools zoals anomaliedetectie kunnen onverwachte dataverschuivingen of ruis flaggen die de robuustheid van het systeem kunnen ondermijnen [2][5].

Voor systemen die continu leren, moeten er waarborgen zijn om feedbacklussen te voorkomen, waarbij gebiaste resultaten de toekomstige trainingsgegevens kunnen beïnvloeden [4][2][1]. Monitoringtools volgen prestatieverslechtering in de loop van de tijd, terwijl containerisatie stabiele en reproduceerbare omgevingen voor systeemuitvoering garandeert [2].

Zowel aanbieders als implementatoren zijn verplicht om incidenten te melden [6][12]. Daarnaast maken mechanismen voor menselijk toezicht, zoals "stopknop"-procedures, directe interventie mogelijk als er problemen optreden [8].

"De EU AI Act vereist continue monitoring na implementatie, niet alleen eenmalige testen. Hoogrisico AI-systemen hebben geautomatiseerde logging en incidentrespons nodig vanaf het begin."

• Oleg Sivograkov, VP of IT Operations, TestFort [11]

De handhavingsdatum voor deze vereisten is vastgesteld op 2 augustus 2026 [8]. Het niet naleven hiervan kan leiden tot zware sancties, waaronder boetes tot €38 miljoen of 7% van de wereldwijde jaaromzet [10].

Deel 2: Navigeren door de EU AI Act: Essentiële nalevingsmaatregelen voor hoogrisico AI-systemen

::: @iframe https://www.youtube.com/embed/wsr6d6WG5Uo :::

Documentatie en nalevingsrapportage

Na grondige testen en continue monitoring is de juiste documentatie essentieel om naleving te waarborgen.

Standaarden voor technische documentatie

Voordat een product op de markt wordt gebracht, moet je een technisch bestand voorbereiden dat voldoet aan de normen van Bijlage IV. Dit bestand moet duidelijk aantonen dat wordt voldaan aan de robuustheidseisen uit Artikel 15 [13]. Het bestand moet negen secties bevatten, waarbij Sectie 4 zich specifiek richt op prestatiemetrieken. Hierin moeten de resultaten van robuustheidstesten, validatiemethoden en de redenering achter gekozen metrieken worden gedetailleerd [13].

Het opstellen van deze documentatie kan tussen de 40 en 80 uur in beslag nemen, mits nalevingsgegevens al zijn geïntegreerd in het ontwikkelingsproces met een AI-implementatieassistent [13]. Tools zoals MLflow kunnen dit proces stroomlijnen door logs, audittrails en ontwerpbeslissingen direct in je workflow vast te leggen.

Je technisch bestand moet ook de volgende elementen bevatten:

• Documentatie over risicobeheer (Artikel 9)
• Records over datagovernance (Artikel 10) die uitleggen hoe datasets zijn gebruikt om vooroordelen te beoordelen
• Een post-market monitoringsplan (Artikel 72)
• Gebruiksinstructies die robuustheidsniveaus en beperkingen beschrijven [1]

Alle technische documentatie moet 10 jaar worden bewaard na het op de markt brengen van het product. Niet-naleving kan leiden tot boetes tot €15 miljoen of 3% van de wereldwijde jaaromzet [13].

Conformiteitsbeoordelingen en CE-markering

Zodra het technische bestand is voltooid, is de volgende stap het bewijzen van naleving via een conformiteitsbeoordeling. De meeste hoogrisico AI-systemen kunnen worden beoordeeld via het interne controlesysteem zoals beschreven in Bijlage VI [15]. Systemen die worden gebruikt in gevoelige gebieden zoals biometrie, kritieke infrastructuur of rechtshandhaving vereisen echter een externe evaluatie door een aangemelde instantie. Deze derde-partijbeoordelaars zijn gemachtigd om je documentatie te beoordelen en naleving te waarborgen [14].

Aangemelde instanties kunnen aanvullend bewijs aanvragen of onafhankelijke testen uitvoeren als ze vinden dat je robuustheidstesten onvoldoende zijn [14]. Ze zullen verifiëren dat maatregelen zoals redundantie, back-upplannen en failsafes zijn gedocumenteerd en geïmplementeerd [1]. Voor AI-systemen die na implementatie blijven leren, zullen ze ook waarborgen tegen feedbacklussen controleren die vooroordelen kunnen introduceren in toekomstige trainingsgegevens [1].

Beoordelingstype	Wie voert het uit	Wanneer vereist	Certificaat afgegeven
Interne controle (Bijlage VI)	Aanbieder (zelfbeoordeling)	De meeste hoogrisicosystemen (Bijlage III, punten 2-8)	EU-verklaring van conformiteit
Aangemelde instantie (Bijlage VII/VIII)	Derde-partijbeoordelaar	Biometrie, kritieke infrastructuur, rechtshandhaving	Certificaat van technische documentatiebeoordeling van de Unie

Aangezien beoordelingen door aangemelde instanties 6 tot 18 maanden kunnen duren, moeten aanbieders van veiligheidskritische of biometrische systemen het proces ruim voor de deadline van 2 augustus 2026 starten [16]. Wees voorbereid om toegang te verlenen tot trainings-, validatie- en testdatasets via API of andere technische middelen indien gevraagd [14].

Na succesvolle afronding van de beoordeling moet je een EU-verklaring van conformiteit afgeven en de CE-markering op je systeem of de bijbehorende documentatie aanbrengen [15]. Deze markering dient als wettelijk bewijs dat je systeem voldoet aan de robuustheidsnormen. Als er significante wijzigingen worden aangebracht - zoals wijzigingen die de naleving of de beoogde toepassing van het systeem beïnvloeden - moet je de documentatie bijwerken en mogelijk een nieuwe conformiteitsbeoordeling ondergaan [13].

"Het technische document moet zodanig worden opgesteld dat het aantoont dat het hoogrisico AI-systeem voldoet aan de vereisten [...] en dat de nationale bevoegde autoriteiten en aangemelde instanties de nodige informatie op een duidelijke en begrijpelijke wijze kunnen verkrijgen om de naleving te beoordelen."

• Artikel 11, Verordening (EU) 2024/1689 [13]

Conformiteitsbeoordelingen, in combinatie met continue monitoring, vormen een compleet nalevingskader dat ervoor zorgt dat hoogrisico AI-systemen gedurende hun hele levenscyclus voldoen aan de robuustheidsnormen.

Robuustheid vs. cyberbeveiliging: Belangrijkste verschillen

Laten we de verschillen tussen robuustheid en cyberbeveiliging - twee concepten die misschien op elkaar lijken maar heel verschillende doelen dienen - onder de loep nemen.

Het verschil ligt in de intentie. Robuustheid, zoals uiteengezet in Artikel 15[1], gaat over onbedoelde verstoringen. Dit kunnen natuurlijke fouten, storingen of inconsistenties zijn die ontstaan tijdens normaal systeemgebruik. Cyberbeveiliging, daarentegen, zoals behandeld in Artikel 15[3], richt zich op opzettelijke, kwaadwillige aanvallen. Dit omvat scenario’s waarbij onbevoegde derde partijen actief proberen de systeemprestaties te manipuleren of te compromitteren. Terwijl eerdere secties de nadruk legden op het testen van robuustheid, benadrukt dit deel de scheidslijn tussen interne veerkracht en externe bedreigingen.

In technische termen verwijst robuustheid in machinaal leren naar niet-adversariale veerkracht. Dit omvat het testen van het vermogen van een AI-systeem om uitdagingen zoals distributieverschuivingen, omgevingsveranderingen of feedbacklussen - waarbij modelresultaten toekomstige trainingsgegevens beïnvloeden - het hoofd te bieden. Cyberbeveiliging richt zich echter op adversariale veerkracht, bescherming tegen bedreigingen zoals datapoisoning, evasieaanvallen of zelfs inbreuken die de vertrouwelijkheid van het model compromitteren, zoals diefstal.

Henrik Nolte van de Universiteit van Tübingen legt dit verschil duidelijk uit:

"De AIA splitst kunstmatig het concept van cyberbeveiliging door onbedoelde oorzaken te bestempelen als een kwestie van robuustheid en cyberbeveiliging te beperken tot opzettelijke acties."

Voor naleving vereisen zowel robuustheid als cyberbeveiliging verschillende strategieën. Organisaties kunnen AI-nalevingsassistenten trainen om deze complexiteiten te beheren. Robuustheid is afhankelijk van maatregelen zoals technische redundantie en continue monitoring om ervoor te zorgen dat systemen onbedoelde verstoringen kunnen weerstaan. Cyberbeveiliging vereist daarentegen actieve verdedigingen zoals bedreigingsdetectie, encryptie en adversariale training om opzettelijke aanvallen tegen te gaan. Het onderhouden van beide gedurende de hele levenscyclus van een AI-systeem vereist het evalueren van elk onderdeel afzonderlijk om alomvattende bescherming te garanderen.

Conclusie en belangrijkste inzichten

Laten we afsluiten met de essentiële stappen om ervoor te zorgen dat je AI-systemen betrouwbaar en compliant zijn met de aankomende regelgeving.

Robuustheidstesten vormen een hoeksteen voor het waarborgen dat hoogrisico AI-systemen consistente prestaties leveren onder praktische omstandigheden. Met de handhaving van de vereisten uit Bijlage III die gepland staat voor 2 augustus 2026 [8], moeten organisaties nu actie ondernemen om prestatiebenchmarks vast te stellen, redundantiemechanismen te integreren en continue monitoring gedurende de hele levenscyclus van de AI te implementeren.

Het concept van robuustheid is sterk afhankelijk van de context. Je zult prestatiemetrieken moeten definiëren die aansluiten bij de specifieke toepassing van je systeem en verstoringen zoals datadrift, omgevingsveranderingen of feedbacklussen moeten voorspellen. Testprotocollen moeten worden afgestemd op de unieke use case, datakwaliteiten en implementatieomgeving van elk AI-systeem.

Begin met het instellen van duidelijke prestatiebaselines onder normale omstandigheden. Test vervolgens systematisch hoe je systeem reageert op verschillende uitdagingen of verstoringen. Voeg redundantiemaatregelen toe - zoals back-upsystemen en failsafes - en zorg ervoor dat mechanismen voor menselijk toezicht aanwezig zijn om in te grijpen wanneer zich anomalieën voordoen. Daarnaast moeten je logsystemen naleving ondersteunen door onvervalsbare, append-only audittrails te bieden.

Volgens Artikel 11 zijn aanbieders hoofdzakelijk verantwoordelijk voor het uitvoeren van conformiteitsbeoordelingen en het voorbereiden van technische documentatie, terwijl implementatoren verantwoordelijk zijn voor het beheren van mens