Artikel 9 AI Act: risicomanagement-systeem voor high-risk AI.
Artikel 9 van de AI Act eist voor elk high-risk AI-systeem een risicomanagement-systeem dat je opzet, implementeert, documenteert en onderhoudt gedurende de hele levenscyclus. Het proces kent vier stappen: risico's identificeren, ze evalueren bij beoogd gebruik en voorzienbaar misbruik, signalen uit post-market monitoring meewegen en beheersmaatregelen vaststellen. Voor die maatregelen schrijft lid 5 een volgorde voor: eerst het risico wegontwerpen, dan technisch beheersen, en pas daarna waarschuwen in de instructies voor de deployer.
De kern-verplichting voor elk high-risk AI-systeem.
Artikel 9 is het hart van de AI Act-verplichtingen voor aanbieders van high-risk AI-systemen. Waar Artikel 5 bepaalt welke AI-praktijken onacceptabel zijn en Artikel 6 welke systemen als high-risk kwalificeren, bepaalt Artikel 9 hoe je de risico's van een high-risk systeem beheert gedurende de gehele lifecycle. Het is niet een eenmalige check maar een doorlopend proces dat bij elke wijziging en periodiek herzien moet worden.
Deze pagina doorloopt alle negen leden van Artikel 9, toont een lifecycle-diagram, vergelijkt de eisen met ISO 31000, somt de artefacten op die je moet produceren, en sluit af met een uitgebreide checklist en sector-cases. Voor een MKB is Artikel 9 vaak het meest omvangrijke compliance-werkpakket; goed voorbereid begint dit bij een helder proces en een werkbaar risico-register.
De officiele bron voor de bindende wettekst is de Europese Unie: Verordening 2024/1689 op EUR-Lex. Deze pagina geeft een werkbare uitleg en toepassingsgids voor Nederlandse MKB-context; raadpleeg altijd de officiele tekst bij juridische beoordelingen.
Wat Artikel 9 precies eist.
Elk lid heeft een concrete eis. Hieronder per lid de strekking met toelichting voor de MKB-praktijk.
Lid 1: systeem-verplichting
Een risicomanagement-systeem moet worden opgezet, geimplementeerd, gedocumenteerd en onderhouden voor elk high-risk AI-systeem. Vier werkwoorden: opzetten (ontwerpen en vastleggen hoe het werkt), implementeren (in de praktijk toepassen), documenteren (schriftelijk vastleggen) en onderhouden (bijhouden over tijd). Ontbreekt een van de vier, dan is compliance niet sluitend.
Lid 2: continu iteratief proces
Het risicomanagement-systeem wordt begrepen als een continu iteratief proces, gepland en uitgevoerd gedurende de gehele lifecycle van het high-risk AI-systeem. Regelmatige systematische review en update zijn vereist. Het systeem bestaat uit vier stappen:
- Sub a: identificatie en analyse van bekende en redelijkerwijs voorzienbare risico's voor gezondheid, veiligheid of grondrechten bij beoogd gebruik.
- Sub b: schatting en evaluatie van risico's bij beoogd gebruik en onder redelijk voorzienbaar misbruik.
- Sub c: evaluatie van aanvullende risico's op basis van post-market monitoring-data.
- Sub d: vaststelling van passende en gerichte risicobeheers-maatregelen voor de geidentificeerde risico's.
De vier stappen sluiten op elkaar aan en vormen een cyclus, niet een lineair traject. Sub c is de expliciete post-market-ingang; nieuwe risico's die in productie opduiken komen weer binnen bij sub a en sub b.
Lid 3: scope van risico's
De risico's die onder Artikel 9 vallen zijn uitsluitend die risico's welke redelijkerwijs kunnen worden gemitigeerd of geelimineerd door ontwikkeling of ontwerp van het high-risk AI-systeem. Risico's die volledig buiten de invloedssfeer van het systeem liggen (bijvoorbeeld maatschappelijke risico's die pas bij grootschalige adoptie spelen) vallen niet binnen scope.
Lid 4: combinatie-effecten
Bij het vaststellen van risicobeheers-maatregelen moet rekening gehouden worden met de combinatie-effecten van alle AI Act-vereisten: Artikelen 10 (data governance), 11 (technische documentatie), 12 (registratie), 13 (transparantie), 14 (menselijk toezicht), 15 (accuratesse en robuustheid). Maatregelen moeten onderling consistent zijn zodat implementatie over meerdere verplichtingen is gebalanceerd.
Lid 5: hierarchy van mitigatie
Risicobeheers-maatregelen zorgen ervoor dat het rest-risico acceptabel is. De implementatie volgt een hierarchy:
- Sub a: eliminatie of reductie via ontwerp, waar technisch haalbaar. Eerste keus.
- Sub b: mitigatie- en controlemaatregelen voor risico's die niet elimineerbaar zijn. Bijvoorbeeld menselijke review, drempelwaarden, fail-safes.
- Sub c: informatie aan deployers, rekening houdend met hun technische kennis en presumptieve context. Instructies, trainings-materiaal, waarschuwingen.
De hierarchy is belangrijk: eerst ontwerp, dan techniek, dan kennis-transfer. Een aanbieder die te veel leunt op sub c (alles in de instructies) zonder eerst sub a en b te hebben uitgeput voldoet niet aan het artikel.
Lid 6: testing-verplichting
High-risk AI-systemen moeten worden getest met als doel het identificeren van de meest geschikte en gerichte risicobeheers-maatregelen. Testing is geen optie maar een expliciet voorgeschreven element van het risicomanagement-systeem.
Lid 7: reele-omstandigheden-testen
Testing-procedures kunnen reele-omstandigheden-testen omvatten. De voorwaarden daarvoor staan in Artikelen 60 en 61 (testing plan, informed consent waar vereist, sandbox-benadering). Voor MKB is dit vooral relevant bij systemen met directe impact op personen: HR-AI, zorg-AI, onderwijs-AI.
Lid 8: timing en metrieken
Testing vindt plaats gedurende ontwikkeling en voorafgaand aan marktplaatsing. Het gebeurt aan de hand van vooraf gedefinieerde metrieken en probabilistische drempels die passen bij het beoogd doel van het systeem. Metrieken en drempels moeten schriftelijk zijn voor de test wordt uitgevoerd; ze mogen niet achteraf worden aangepast om resultaten in te passen.
Lid 9: kwetsbare groepen
Aanbieders moeten beoordelen of het high-risk AI-systeem waarschijnlijk nadelige impact heeft op personen onder 18 jaar of andere kwetsbare groepen. Deze beoordeling maakt deel uit van de risicoanalyse onder lid 2 sub a en b. Bij geidentificeerde impact: specifieke mitigaties ontwerpen en documenteren.
Vijf fasen van het continu iteratieve proces.
Artikel 9 spreekt van een continu iteratief proces. In de praktijk werkt dit als vijf fasen die elkaar opvolgen en dan herbeginnen. Elke doorloop verkort naarmate het systeem volwassener wordt, maar stopt nooit.
Wat je schriftelijk op de plank moet hebben.
Artikel 9 lid 1 eist documentatie. Bij een audit door Autoriteit Persoonsgegevens, een notified body of een sectorale toezichthouder moeten deze artefacten direct beschikbaar zijn. De onderstaande set is het minimum; grotere organisaties breiden uit met beleids- en strategie-documenten.
Generieke standaard versus AI Act-specifiek.
ISO 31000 is de internationale standaard voor risicomanagement in het algemeen. De logica is vergelijkbaar met Artikel 9, maar Artikel 9 legt specifieke accenten die generieke ISO-implementaties niet automatisch afdekken. Hergebruik van bestaande ISO-processen is mogelijk, mits uitgebreid met AI-specifieke elementen.
De belangrijkste praktische boodschap: als je organisatie al ISO 31000 toepast of ISO 27005 (information security risk), dan heb je een basis. Je moet uitbreiden met AI-specifieke risico-categorieen (bias, model drift, adversarial input, hallucinaties, data-lekken via prompt injection), met de expliciete AI Act-focus op grondrechten en kwetsbare groepen, en met de post-market loop die direct terugvloeit naar risico-identificatie.
Aanbieder primair, deployer via Artikel 26.
Artikel 9 richt zich primair op de aanbieder (provider) van het high-risk AI-systeem. Artikel 16 sub a benoemt expliciet dat de aanbieder zorgt dat het systeem voldoet aan Artikel 9. De aanbieder ontwerpt, bouwt, test en levert het systeem met een werkend risicomanagement-kader.
Rol van de deployer onder Artikel 26.
De deployer (gebruiker van het AI-systeem voor een eigen professioneel doel) heeft eigen verplichtingen die aansluiten op Artikel 9. Artikel 26 lid 1 eist dat de deployer passende technische en organisatorische maatregelen neemt om ervoor te zorgen dat het AI-systeem wordt gebruikt conform de instructies van de aanbieder. Artikel 26 lid 2 vraagt menselijk toezicht door bevoegde, getrainde personen. Artikel 26 lid 4 vereist monitoring op werking; bij afwijkingen moet de deployer de aanbieder informeren (Artikel 72 loop).
Bij substantiele modificatie neemt de deployer de aanbieder-rol over. Artikel 25 regelt dit: als een deployer het systeem materieel wijzigt (ander doel, andere architectuur, andere training-data) is de deployer aanbieder geworden en valt het aangepaste systeem onder Artikel 9 als eigen aanbieder-verplichting. Voor een MKB-deployer is dit cruciaal: fine-tuning van een GPAI-model voor een high-risk toepassing, of configuratie-wijziging die effect op output heeft, kan al substantieel zijn.
Gedeelde verantwoordelijkheid.
In de praktijk delen aanbieder en deployer verantwoordelijkheid:
- Aanbieder levert de basis: risicomanagement-systeem over de systeem-capabilities en bekende use-cases. Instructies, trainings-materiaal, grenswaarden.
- Deployer vult aan voor de concrete inzet-context: specifieke gebruikers-populatie, lokale data, organisatorische inbedding, menselijk toezicht.
- Beide werken samen in post-market loop: deployer stuurt operationele data naar aanbieder, aanbieder levert updates terug.
Voor MKB dat als deployer gebruik maakt van een third-party AI-systeem: check bij leverancier-selectie of de aanbieder een Artikel 9-conform risicomanagement-systeem heeft en of documentatie overlegbaar is bij audit. Zie onze deployer-gids. Ook relevant: check of het systeem uberhaupt high-risk is via onze risicoclassificatie-pagina.
Praktische inrichting in een kleiner team.
Artikel 9 is ontworpen op basis van enterprise-grade compliance-praktijken, maar de eisen zijn proportioneel toe te passen. Voor een MKB met 10 tot 250 FTE zijn vaak drie tot zes personen betrokken in het risicomanagement-systeem: een eigenaar, een product-lead, een tech-lead, een compliance-verantwoordelijke en bij grotere MKB ook een legal-expert en een operationeel manager.
Realistische rolverdeling.
- Eigenaar (directielid): eindverantwoordelijk. Approval van risico-register en review-planning. Bij grensgeval beslissen over acceptatie van rest-risico.
- Product-lead: dagelijkse regie. Plant workshops, beheert risico-register, coordineert reviews.
- Tech-lead: test-plannen en test-uitvoering. Technische mitigaties in ontwerp. Monitoring-metrieken.
- Compliance-verantwoordelijke: documentatie, audit-readiness, koppeling aan andere verplichtingen (Artikel 10 data, Artikel 11 technische documentatie, Artikel 72 post-market).
Tooling.
Voor een MKB is lichte tooling voldoende. Een gestructureerd spreadsheet of simpel GRC-platform kan werken. Minimum-kolommen in het risico-register: ID, omschrijving, categorie (gezondheid/veiligheid/grondrechten), sub-categorie, scenario (beoogd of misbruik), kans, impact, initiele risicoscore, mitigatie-maatregelen, rest-risico, verantwoordelijke, status, laatste review, volgende review. Koppeling met ticket-systeem voor incidenten en wijzigingen.
Review-cadans.
Minimaal elke zes maanden een volledige review. Plus bij elke trigger: significante wijziging in systeem, wijziging in data, wijziging in gebruikers-context, incident, klacht, updates in wetgeving of interpretaties, nieuwe use-case. Bij trigger-review kan scope beperkt zijn; bij half-jaarlijks review volledig.
Integratie met ander compliance-werk.
Het risicomanagement-systeem onder Artikel 9 staat niet op zichzelf. Het sluit aan op:
- Artikel 10 data governance: bias-risico's uit data-kwaliteit komen binnen via de risicoanalyse.
- Artikel 11 technische documentatie: het risicomanagement-systeem is onderdeel van de technische documentatie (Annex IV onderdeel 4).
- Artikel 14 menselijk toezicht: toezicht-maatregelen zijn vaak de concrete mitigatie-invulling.
- Artikel 15 accuratesse en robuustheid: performance-drempels uit Artikel 15 voeden de test-drempels van Artikel 9 lid 8.
- Artikel 72 post-market monitoring: directe feed naar Artikel 9 lid 2 sub c.
- AVG: AVG-DPIA en Artikel 9-assessment hebben raakvlakken, met name bij persoonsgegevens; coordineer documentatie. Zie onze AVG-AI-gids.
32 actiepunten voor Artikel 9-implementatie.
Doorloop deze checklist om te checken waar je staat. Elk actiepunt is traceerbaar naar een concreet lid van Artikel 9 of naar een aanvullend artikel dat aansluit.
Artikel 9 in vier Nederlandse MKB-contexten.
Hoe ziet het risicomanagement-systeem eruit in concrete situaties. Vier voorbeelden uit sectoren waar high-risk AI veel voorkomt bij MKB.
Veelgemaakte fouten bij Artikel 9-implementatie.
Zes patronen die bij compliance-audits regelmatig fout gaan. Vermijd ze van meet af aan.
Een: risicomanagement als eenmalig project.
De meest voorkomende fout. Een team levert een risicoanalyse op voor marktplaatsing en legt het document in de kast. Artikel 9 lid 2 eist continu iteratief met review en update. Zonder doorlopende cyclus is het systeem niet compliant. Oplossing: review-cadans plannen vanaf dag een, in kalender, met eigenaar.
Twee: alleen beoogd gebruik, geen misbruik-scenario's.
Lid 2 sub b vraagt expliciet evaluatie onder redelijk voorzienbaar misbruik. Teams die alleen happy-path-risico's analyseren missen een belangrijke klasse risico's. Oplossing: misbruik-workshops met rood-team-mindset. Wat als een gebruiker met kwade intentie het systeem voedt. Wat als data wordt geinjecteerd. Wat als output wordt herbestemd.
Drie: mitigatie-hierarchy omzeilen.
Lid 5 verplicht de volgorde: ontwerp, mitigatie, informatie. Teams die te snel naar sub c (instructies, waarschuwingen) springen zonder sub a (ontwerp) en sub b (controles) uitgeput te hebben, voldoen niet. Oplossing: bij elke mitigatie expliciet onderbouwen waarom sub a en b niet haalbaar waren.
Vier: testing zonder vooraf-metrieken.
Lid 8 vereist vooraf gedefinieerde metrieken en probabilistische drempels. Teams die testen en dan de drempels achteraf aanpassen om resultaten in te passen, schenden de bepaling. Oplossing: test-plan schrijven met harde metrieken en drempels voor de test begint, met sign-off door een niet-ontwikkelings-rol.
Vijf: post-market loop ontbreekt.
Lid 2 sub c eist dat post-market data terugvloeit naar risicoanalyse. Teams die Artikel 72 als aparte verplichting behandelen, zonder koppeling naar Artikel 9, missen de loop. Oplossing: proces waarbij post-market signalen direct het risico-register bijwerken met nieuwe of aangepaste risico's.
Zes: vulnerable-groups-assessment overslaan.
Lid 9 is een expliciete bepaling over personen onder 18 en kwetsbare groepen. Teams slaan dit geregeld over omdat de doel-gebruiker volwassen B2B-medewerkers zijn. Bedenk: indirecte impact telt ook. HR-AI raakt ook minderjarige sollicitanten, credit-AI raakt gezinnen met kinderen, zorg-AI raakt kwetsbare patienten. Oplossing: expliciet Lid 9-assessment als aparte stap in risicoanalyse-template.
Over Artikel 9 en risicomanagement.
Wat eist Artikel 9 precies?
Lid 1: opzetten, implementeren, documenteren en onderhouden van een risicomanagement-systeem. Lid 2: continu iteratief proces over de gehele lifecycle, met vier stappen (identificatie, evaluatie, post-market review, mitigatie). Leden 3 tot 8: scope, combinatie-effecten, hierarchy, testing-verplichting. Lid 9: kwetsbare groepen.
Voor welke systemen geldt Artikel 9?
Uitsluitend voor high-risk AI-systemen onder Artikel 6, dus Annex I (product-veiligheidsregelgeving) of Annex III (acht categorieen zoals werving, onderwijs, kritieke infrastructuur). Niet voor limited risk of minimal risk; voor GPAI-modellen geldt Artikel 53/55.
Wie is verantwoordelijk?
Primair de aanbieder via Artikel 16. Deployer heeft aansluitende verplichtingen via Artikel 26 (gebruik conform instructies, menselijk toezicht, monitoring). Bij substantiele modificatie wordt deployer aanbieder (Artikel 25).
Wat is de post-market feedback-loop?
Lid 2 sub c: post-market monitoring-data uit Artikel 72 voedt nieuwe risico-identificatie. Operationele signalen, incidenten en klachten worden systematisch beoordeeld en vertaald naar aanpassingen in het risico-register.
Hoe sluit Artikel 9 aan bij ISO 31000?
Vergelijkbare logica (identificeren, analyseren, behandelen, monitoren) maar met AI-specifieke accenten: grondrechten-focus, kwetsbare groepen (lid 9), post-market loop (lid 2 sub c), expliciete testing-verplichting (lid 6, 7, 8) en juridisch bindend karakter met sancties.
Welke testen eist Artikel 9?
Lid 6: verplicht met als doel identificatie van gerichte mitigaties. Lid 7: reele-omstandigheden-testen mogelijk onder Artikelen 60 en 61. Lid 8: testing gedurende ontwikkeling en voor marktplaatsing, met vooraf bepaalde metrieken en probabilistische drempels.
Wat zijn de eisen voor kwetsbare groepen?
Lid 9: beoordelen of het systeem waarschijnlijk nadelige impact heeft op personen onder 18 of andere kwetsbare groepen. Bij impact: specifieke mitigaties. Niet limitatief; denk aan ouderen, personen met beperking, sociaal-economisch kwetsbaren.
Moet het rest-risico nul zijn?
Nee. Lid 5 eist dat rest-risico acceptabel is, niet nul. Na toepassing van de hierarchy (ontwerp, mitigatie, informatie) blijft altijd een rest-risico; dit moet onderbouwd acceptabel zijn met directie-approval.
Hoe documenteer ik compliance?
Minimum: risicomanagement-beleid, risico-register, misbruik-scenario-matrix, test-plan en resultaten, post-market plan, vulnerable-groups-assessment, review-logboek, deployer-instructies. Integratie in technische documentatie Artikel 11 / Annex IV onderdeel 4.
Wat kost implementatie voor een MKB?
Enkelvoudig high-risk systeem: 60 tot 120 uur initieel, 1 a 2 FTE-dagen per maand doorlopend. Meervoudig: scale-up naar 200 uur initieel en 0,2 FTE doorlopend. Boete-alternatief onder Artikel 99 lid 4 is tot 15 miljoen of 3 procent omzet; investering is proportioneel. Zie onze compliance-roadmap.
Koppelingen in onze AI compliance-aanpak.
Artikel 9 staat in het midden van het bredere AI Act-compliance-werk. Deze vijf pagina's geven aansluitende context voor een MKB-traject.
Opgesteld met AI-ondersteuning door de redactie van Prometheus21, laatst bijgewerkt op 7 september 2026. Hoe wij content maken
Artikel 9-inrichting voor jouw high-risk AI.
Prometheus21 levert binnen vier weken een operationeel risicomanagement-systeem conform Artikel 9: beleid, risico-register, misbruik-matrix, test-plan, vulnerable-groups-assessment en post-market loop. Direct bruikbaar als compliance-evidence richting Autoriteit Persoonsgegevens of notified body.
Plan een Artikel 9-sessie