Veel organisaties denken dat risicomanagement begint zodra er iets misgaat. Onder de EU AI Act begint het veel eerder. Artikel 9 verplicht aanbieders van hoog-risico AI-systemen om een doorlopend risicobeheersysteem op te zetten vóór livegang, tijdens de ontwikkeling en gedurende de hele levenscyclus van het systeem.
Daarmee is artikel 9 een van de structurele kernbepalingen van de AI Act.
Als artikel 10 gaat over datagovernance, artikel 13 over transparantie en artikel 14 over menselijk toezicht, dan is artikel 9 de laag die al die maatregelen dwingt samen te komen in één gedisciplineerd proces. Het is geen beleidsnotitie. Het is geen eenmalig risicoregister. Het is een iteratief compliance-systeem dat moet blijven functioneren naarmate het AI-systeem verandert.
Wat artikel 9 precies vereist
Artikel 9(1) bepaalt dat er voor hoog-risico AI-systemen een risicobeheersysteem moet worden vastgesteld, geïmplementeerd, gedocumenteerd en onderhouden.
Die formulering is belangrijk. De verplichting is niet alleen om over risico's na te denken. De verplichting is om een systeem op te zetten dat in de praktijk bestaat, gedocumenteerd is en doorlopend actief blijft. Met andere woorden: dit is geen pre-launch checklist maar een werkend governance-mechanisme.
Artikel 9(2) definieert dat risicobeheersysteem vervolgens als een doorlopend iteratief proces dat over de volledige levenscyclus van het hoog-risico AI-systeem loopt en regelmatig systematisch wordt herzien en geactualiseerd.
De AI Act stuurt aanbieders dus bewust weg van een statische compliance-mentaliteit. Een hoog-risico AI-systeem kan veranderen omdat het model verandert, de data verandert, de gebruikscontext verandert of het gedrag van gebruikers verandert. Een risicobeheersysteem dat alleen bij de lancering is gebouwd, veroudert snel.
De vier kernstappen van artikel 9(2)
Artikel 9(2) verdeelt het proces in vier stappen.
1. Bekende en redelijkerwijs voorzienbare risico's identificeren en analyseren
Op grond van artikel 9(2)(a) moeten aanbieders zowel bekende als redelijkerwijs voorzienbare risico's identificeren en analyseren die het systeem kan opleveren voor gezondheid, veiligheid of grondrechten wanneer het systeem wordt gebruikt overeenkomstig het beoogde doel.
Dat betekent dat aanbieders zich niet mogen beperken tot evidente technische fouten. Ze moeten ook kijken naar discriminatie, oneerlijke uitsluiting, privacyrisico's, verlies van toegang tot essentiële diensten of downstream-effecten op menselijke autonomie. Juist daar wordt de categorie hoog-risico AI-systemen in de praktijk relevant.
Een AI-systeem voor recruitmentscreening brengt bijvoorbeeld niet alleen het risico van onjuiste sortering met zich mee. Het kan ook discriminatierisico's creëren als proxies voor geslacht, handicap, leeftijd of migratieachtergrond invloed hebben op de rankinglogica. Een medisch diagnostisch systeem brengt niet alleen veiligheidsrisico met zich mee als het tumoren mist. Het kan ook een grondrechtenrisico opleveren als het aantoonbaar slechter presteert voor ondervertegenwoordigde patiëntengroepen.
2. Risico's inschatten en evalueren, inclusief redelijkerwijs voorzienbaar misbruik
Artikel 9(2)(b) vereist dat risico's niet alleen onder normaal gebruik, maar ook onder omstandigheden van redelijkerwijs voorzienbaar misbruik worden ingeschat en geëvalueerd.
Dat is een van de strategisch belangrijkste zinnen van het artikel. Het betekent dat aanbieders zich niet kunnen verschuilen achter de redenering: "zo was het systeem niet bedoeld", als die vorm van misbruik voorspelbaar was.
Als een aanbieder weet dat klanten een scoringsmodel waarschijnlijk zullen hergebruiken in contexten buiten de gevalideerde scope, of dat gebruikers structureel te veel zullen vertrouwen op de uitkomsten, dan moet dat risico onderdeel zijn van de analyse. De AI Act verwacht dat aanbieders anticiperen op hoe systemen werkelijk gebruikt worden, niet alleen op hoe ze in productdocumentatie worden beschreven.
3. Risico's evalueren op basis van post-market monitoring
Artikel 9(2)(c) verbindt het risicobeheersysteem rechtstreeks met het post-market monitoring-systeem uit artikel 72. Dat betekent dat risicobeheer niet stopt bij de lancering. Zodra het systeem wordt gebruikt, moeten signalen uit de praktijk terugvloeien in de risico-evaluatie.
Dit is een cruciale brug tussen pre-market compliance en operationele governance. Als een aanbieder signalen krijgt dat bepaalde uitkomsten instabiel zijn, dat bepaalde groepen slechter worden bediend, of dat gebruikers het systeem structureel verkeerd interpreteren, dan moeten die bevindingen terug de artikel 9-cyclus in.
4. Gerichte risicobeheersmaatregelen nemen
Artikel 9(2)(d) vereist passende en gerichte risicobeheersmaatregelen voor de geïdentificeerde risico's.
Het woord "gericht" is belangrijk. Algemene zinnen als "er is menselijk toezicht" of "het model is getest" zijn niet genoeg. De maatregelen moeten aansluiten op de concrete gevaren die in de analyse zijn vastgesteld.
Als het risico automatiseringsbias is, kan de maatregel bestaan uit interface-aanpassingen, verplichte reviewprocedures en training voor gebruikers. Als het risico bias tegen ondervertegenwoordigde groepen is, kan de maatregel bestaan uit herontwerp van datasets, aanvullende tests, drempelaanpassingen of beperkingen op het beoogde gebruik.
Artikel 9 is smaller dan veel aanbieders denken
Artikel 9(3) trekt een belangrijke grens. De risico's waarop dit artikel ziet, zijn alleen die risico's die redelijkerwijs kunnen worden gemitigeerd of geëlimineerd door de ontwikkeling of het ontwerp van het hoog-risico AI-systeem, of door het verstrekken van adequate technische informatie.
Dat betekent dat aanbieders niet verantwoordelijk zijn voor ieder denkbaar downstream-risico in de wereld. Ze zijn verantwoordelijk voor de risico's die ze via systeemontwerp, ontwikkelkeuzes, documentatie en technische communicatie daadwerkelijk kunnen beïnvloeden.
Dat onderscheid houdt artikel 9 werkbaar. De AI Act vraagt aanbieders niet om ieder governance-probleem van iedere gebruiker op te lossen. Ze vraagt aanbieders om de risico's te beheersen die ze zelf realistisch kunnen sturen.
Het restrisico moet aanvaardbaar zijn
Artikel 9(5) introduceert een van de meest veeleisende begrippen uit hoofdstuk III: het relevante restrisico per gevaar, en het totale restrisico van het hoog-risico AI-systeem, moet aanvaardbaar worden geacht.
Dat klinkt abstract totdat je het uitpakt. Restrisico is wat overblijft nadat mitigatie is toegepast. De AI Act gaat er niet vanuit dat elk risico volledig kan worden weggewerkt. Maar ze eist wel een inhoudelijk oordeel dat wat overblijft aanvaardbaar is in het licht van het beoogde gebruik.
Dat dwingt aanbieders om verder te gaan dan een binaire compliance-logica. De vraag is niet alleen: hebben we safeguards toegevoegd? De vraag is: welk risico blijft over, voor wie, in welke situaties, en is dat restrisico aanvaardbaar?
Artikel 9(5) bevat ook een duidelijke volgorde:
- eerst risico's elimineren of reduceren via ontwerp en ontwikkeling, voor zover technisch haalbaar,
- daarna passende mitigatie- en controlemaatregelen toepassen voor risico's die niet volledig kunnen worden geëlimineerd,
- en vervolgens de informatie verstrekken die op grond van artikel 13 vereist is en waar passend training aanbieden aan gebruikers.
Die hiërarchie is belangrijk omdat documentatie geen vervanging is voor beter ontwerp. Aanbieders mogen vermijdbare schade niet laten bestaan en die vervolgens proberen op te lossen met waarschuwingen in een handleiding.
Risicobeheer staat niet los van de rest van hoofdstuk III
Artikel 9(4) vereist dat aanbieders rekening houden met de gecombineerde effecten van de andere eisen in dezelfde sectie van de AI Act.
Dat is subtiel maar zeer belangrijk. Het betekent dat risicobeheer de andere technische en governance-verplichtingen uit hoofdstuk III moet integreren, in plaats van ze als losse compliance-eilandjes te behandelen.
Bijvoorbeeld:
- zwakke datagovernance onder zowel artikel 10 als de praktische artikel 10-gids verslechtert de kwaliteit van de risicoanalyse,
- zwakke transparantie onder artikel 13 maakt veilig gebruik door deployers moeilijker,
- slecht ontworpen menselijk toezicht onder artikel 14 en de praktische gids over menselijk toezicht verhoogt het restrisico,
- zwakke logging onder artikel 12 maakt leren uit de praktijk lastiger.
In de praktijk is artikel 9 dus de coördinatiebepaling. Het is het artikel dat aanbieders dwingt al deze draden in één compliance-architectuur samen te brengen.
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 LearnWizeTesten is onderdeel van risicobeheer, geen aparte slotfase
Artikel 9(6), 9(7) en 9(8) maken testen formeel onderdeel van het risicobeheersysteem.
Hoog-risico AI-systemen moeten worden getest om de meest passende en gerichte risicobeheersmaatregelen te identificeren. Testen moet ook borgen dat het systeem consistent presteert voor het beoogde doel en voldoet aan de eisen uit deze sectie.
De AI Act gaat verder: testen moet, waar passend, op elk moment in het ontwikkelproces plaatsvinden en in elk geval voordat het systeem op de markt wordt gebracht of in gebruik wordt genomen. Testen moet gebeuren aan de hand van vooraf gedefinieerde metrics en probabilistische drempels die aansluiten bij het beoogde doel.
Dat is belangrijk omdat veel aanbieders nog steeds uitsluitend in enge technische termen testen, zoals accuracy of recall, terwijl fairness, robuustheid, interpreteerbaarheid of contextdrift buiten beeld blijven. Artikel 9 verwacht dat testen het risicobeheer voedt, niet alleen productvalidatie.
Waar passend kan testen ook reële omstandigheden omvatten overeenkomstig artikel 60. Voor bepaalde hoog-risico systemen zullen laboratoriumtests alleen nooit alle operationele risico's blootleggen.
Kwetsbare groepen horen expliciet in de analyse thuis
Artikel 9(9) verplicht aanbieders om te beoordelen of het hoog-risico AI-systeem, gelet op het beoogde doel, waarschijnlijk een nadelig effect zal hebben op personen onder de 18 jaar en, waar passend, andere kwetsbare groepen.
Dat is geen decoratieve verwijzing zoals in een overweging. Het is een operationele instructie.
Een systeem dat wordt gebruikt in onderwijs, zorg, welzijn, recruitment, verzekeringen of publieke dienstverlening kan effecten hebben op groepen voor wie kwetsbaarheid direct relevant is voor het risicoprofiel. Als een aanbieder die dimensie negeert, is het risicobeheersysteem onvolledig. In veel van deze contexten valt de toepassing ook onder bijlage III of leidt zij downstream tot een verplichte FRIA.
Juist in publieke sector- en HR-use cases speelt dit vaak. Een systeem kan gemiddeld genomen voldoende presteren en toch aantoonbaar slechtere uitkomsten genereren voor jongere gebruikers, mensen met lage geletterdheid, mensen met een beperking of mensen in een kwetsbare sociaal-economische positie. Artikel 9 verplicht aanbieders om die vraag ten minste expliciet mee te nemen.
Sectorwetgeving kan worden geïntegreerd, maar niet genegeerd
Artikel 9(10) erkent dat sommige aanbieders van hoog-risico AI-systemen al onderworpen zijn aan interne risicomanagementvereisten uit andere relevante Uniewetgeving. In die gevallen kunnen de aspecten uit artikel 9 onderdeel zijn van, of gecombineerd worden met, die bestaande procedures.
Dat is vooral relevant in de financiële sector, medische technologie en bepaalde gereguleerde infrastructuursectoren. Maar het woord "gecombineerd" betekent niet automatisch "afgevinkt". Aanbieders moeten nog steeds kunnen aantonen dat hun bestaande processen daadwerkelijk de elementen van artikel 9 afdekken.
Als een bank of fabrikant van medische technologie zich op bestaande governance-structuren wil beroepen, moet zij die duidelijk kunnen mappen op artikel 9(1) tot en met 9(10). Als dat niet kan, is integratie niet voldoende.
Wat organisaties het vaakst verkeerd doen
De eerste veelgemaakte fout is artikel 9 behandelen als een risicoregister. Een register kan één artifact binnen het systeem zijn, maar het is niet het systeem zelf. Artikel 9 vereist een doorlopend proces, bewijs van review, koppeling met testen en een onderbouwde manier om te beoordelen of restrisico aanvaardbaar is.
De tweede fout is de analyse beperken tot technische failure. Het artikel dekt expliciet risico's voor gezondheid, veiligheid en grondrechten. Dat betekent dat organisaties ook juridische, sociale en institutionele schade moeten beoordelen, niet alleen engineering defects.
De derde fout is veronderstellen dat training voor gebruikers of waarschuwingen in de handleiding zwak ontwerp kunnen compenseren. Artikel 9(5) legt een duidelijke hiërarchie op: eerst risico reduceren via ontwerp, daarna via controles, en pas daarna via informatie en training. Documentatie is de laatste verdedigingslinie, niet de eerste.
De vierde fout is het systeem lanceren en pas daarna proberen risicobeheer alsnog in te bouwen. Daarmee wordt de structuur van de bepaling precies omgekeerd. Artikel 9 verwacht dat risicobeheer vanaf het begin in de ontwikkeling wordt verweven.
Een praktisch artikel 9-framework voor aanbieders
Als u een hoog-risico AI-systeem ontwikkelt of op de markt brengt, bevat een werkbaar artikel 9-framework meestal vijf bouwstenen.
1. Hazard mapping. Definieer welke soorten schade het systeem kan veroorzaken voor gezondheid, veiligheid en grondrechten. Doe dit niet alleen voor ideaal gebruik, maar ook voor voorzienbaar misbruik.
2. Evidence design. Definieer welke metrics, drempels en tests aantonen of die risico's daadwerkelijk onder controle zijn. Dit omvat prestatietests, robuustheidstests, subgroup-tests en scenario-gebaseerde tests.
3. Mitigation planning. Bepaal welke risico's via ontwerp kunnen worden gereduceerd, welke operationele controles vereisen en welke vragen om gebruikersinformatie of training.
4. Residual risk judgment. Documenteer hoe u bepaalt of het overblijvende risico aanvaardbaar is, wie dat oordeel velt en welke triggers leiden tot herbeoordeling.
5. Lifecycle review. Verbind het systeem met post-market monitoring, incidentafhandeling, logging en periodieke review zodat de artikel 9-cyclus ook na livegang actief blijft.
Als dat framework bekend klinkt, is dat logisch. Het lijkt sterk op volwassen productgovernance in andere gereguleerde sectoren. De AI Act bedenkt governance niet opnieuw. Ze dwingt aanbieders van AI om met dezelfde discipline te werken die in andere high-impact domeinen al langer normaal is.
Veelgestelde vragen
De belangrijkste vragen en antwoorden bij dit onderwerp.