Art. 9 EU AI Act: het risicobeheerssysteem voor hoog-risico AI

Bijgewerkt: juni 2026

Dit is een expliciete providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry →-verplichting onder de EU AI Act. Ze rust op degene die het hoog-risico AI-systeem ontwikkelt of op de markt brengt. Deployers hebben een verwante, lichtere set plichten onder Art. 26.

Inleiding: de verplichting die de andere bijeenhoudt

Art. 9 is de eerste van de technische eisen die de EU AI Act aan providers van hoog-risico AI-systemen stelt, en dat is bewust. Het risicobeheerssysteem is het kader waarin de overige verplichtingen passen: de datagovernance van Art. 10, de technische documentatie van Art. 11, de logging van Art. 12, de transparantie van Art. 13, het menselijk toezicht van Art. 14, en de nauwkeurigheid en robuustheid van Art. 15 zijn alle, deels, mitigerende maatregelen die het Art. 9-systeem identificeert, onderbouwt en bewaakt.

Het bepalende kenmerk van Art. 9 is dat het doorlopend is. Het artikel gebruikt het woord "iteratief" en vereist dat het proces "gedurende de gehele levenscyclus" van het systeem draait. Een provider die één keer een risicobeoordeling uitvoert vóór de lancering, die archiveert, en er nooit op terugkomt, voldoet niet aan Art. 9, ongeacht hoe grondig die beoordeling was. De verplichting is om een levend systeem te bedienen, niet om een document te produceren.

Wat het risicobeheerssysteem moet doen

Art. 9 beschrijft een cyclus met vier terugkerende stappen:

1. Identificeer en analyseer de bekende en redelijkerwijs voorzienbare risico's die het systeem kan vormen voor gezondheid, veiligheid en grondrechten bij gebruik voor het beoogde doel.
2. Schat in en evalueer de risico's die kunnen ontstaan bij gebruik zoals beoogd en onder omstandigheden van redelijkerwijs voorzienbaar misbruik.
3. Evalueer andere risico's die voortkomen uit de analyse van post-market monitoringdata (de feedbacklus uit Art. 72).
4. Tref passende en gerichte risicobeheersmaatregelen om de geïdentificeerde risico's aan te pakken.

De maatregelen moeten elk risico zoveel als technisch haalbaar is terugbrengen, via het ontwerp en de bouw van het systeem zelf, via mitigatie- en controlemaatregelen waar het risico niet kan worden weggenomen, en via de informatie en training die aan deployers worden gegeven. Restrisico's die na mitigatie overblijven, moeten aanvaardbaar worden geacht en aan de deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → worden gecommuniceerd.

De relatie met de andere technische artikelen

Art. 9 staat niet op zichzelf. Het is het orkestrerende proces, en de andere artikelen zijn waar de maatregelen worden uitgevoerd:

• Een datakwaliteitsrisico dat onder Art. 9 wordt geïdentificeerd, wordt gemitigeerd via de datagovernance-maatregelen van Art. 10.
• Een risico op onvoldoende traceerbaarheid wordt gemitigeerd via de logging-capaciteit van Art. 12.
• Een risico dat een deployer het systeem verkeerd begrijpt, wordt gemitigeerd via de gebruiksinstructies van Art. 13.
• Een risico dat het systeem handelt zonder betekenisvolle menselijke controle, wordt gemitigeerd via het menselijk-toezicht-ontwerp van Art. 14.
• Een risico op onnauwkeurige of niet-robuuste prestaties wordt gemitigeerd via de maatregelen van Art. 15.

Daarom is Art. 9 de ruggengraat: een bevinding in het risicobeheerssysteem stroomt door naar een concrete maatregel in een van de andere artikelen, en het bewijs dat de maatregel werkt, stroomt terug via testen en monitoring.

Waarom het ertoe doet

Voor een provider is het risicobeheerssysteem het document dat een conformiteitsbeoordeling als eerste onderzoekt, omdat het laat zien of de naleving van de provider systematisch of geïmproviseerd is. Een coherent Art. 9-systeem, met elk geïdentificeerd risico gekoppeld aan een mitigerende maatregel en een bewijsstuk, signaleert een systeem onder controle. Een stapel losse beoordelingen zonder verbindend proces signaleert het tegendeel.

Voor een deployer doet Art. 9 er indirect maar wezenlijk toe: de restrisico's die de provider aanvaardbaar achtte, en de voorwaarden waaronder het systeem veilig te gebruiken is, worden gecommuniceerd via de gebruiksinstructies. Een deployer die het systeem buiten die voorwaarden inzet, erft het risico dat het Art. 9-systeem van de provider juist uitsloot.

Het risicobeheerssysteem besturen

De praktische uitdaging is het systeem levend houden ná de lancering, wanneer de druk om door te gaan naar de volgende release het grootst is. De onderstaande controls behandelen het risicobeheerssysteem als een proces met een hartslag, niet als een oplevering met een deadline.

Het kernartefact is een risicoregister dat, voor elk geïdentificeerd risico, vastlegt: de beschrijving, het geraakte recht of de veiligheidsdimensie, de ernst en waarschijnlijkheid, de mitigerende maatregel, het artikel waaronder die maatregel valt, het bewijs dat de maatregel werkt, en het restrisico na mitigatie. Dit register wordt bijgewerkt op een vaste cadans en bij triggergebeurtenissen: een systeemwijziging, een nieuw beoogd gebruik, een post-market monitoringsignaal, of een ernstig incident.

De feedbacklus is wat het systeem iteratief maakt. Post-market monitoringdata onder Art. 72 en meldingen van ernstige incidenten onder Art. 73 stromen terug in het register, waar ze ofwel bevestigen dat een risico juist is ingeschat, ofwel onthullen dat het is onderschat. Elk incident wordt afgesloten met het register bijgewerkt, zodat de volgende iteratie van het systeem de les meedraagt.

Checklist

1. Is er een gedocumenteerd risicobeheerssysteem dat de volledige levenscyclus van elk hoog-risico systeem bestrijkt, en niet een enkele beoordeling vóór de inzet?
2. Koppelt het risicoregister elk geïdentificeerd risico aan een specifieke mitigerende maatregel en het artikel waaronder het valt?
3. Is er bewijs dat elke mitigerende maatregel is getest en werkt?
4. Zijn restrisico's gedocumenteerd, aanvaardbaar geacht en aan deployers gecommuniceerd via de gebruiksinstructies?
5. Wordt het register bijgewerkt op een vaste cadans en bij triggergebeurtenissen (systeemwijziging, nieuw gebruik, monitoringsignaal, incident)?
6. Stromen post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use — the product-regulation half of continuous monitoring.Open full entry →- en incidentdata terug in het register?