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

Bijgewerkt: juni 2026

Dit is een expliciete provider-verplichting onder de EU AI Act. Ze rust op degene die het 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-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 → 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 documentatietechnische documentatieRegistraties die een aanbieder voor een hoog-risico-AI-systeem moet samenstellen en bewaren om conformiteit aan te tonen, met dekking van het ontwerp, de data, het testen, het risicobeheer en de monitoring. Zie aanbieder, bewijs, model card.Open full entry → van Art. 11, de logging van Art. 12, de transparantietransparantieOpenheid over het feit dát AI wordt gebruikt en hoe het in het algemeen werkt: openbaarmakingen, documentatie, kennisgevingen. Vormt een paar met uitlegbaarheid, die over individuele uitkomsten gaat. Zie uitlegbaarheid, principe.Open full entry → van Art. 13, het menselijk toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry → van Art. 14, en de nauwkeurigheid en robuustheidrobuustheidHet vermogen van een systeem om betrouwbaar te presteren onder realistische omstandigheden, inclusief ruis, randgevallen en tegenwerkende druk, de technische kern van het principe veiligheid en betrouwbaarheid. Zie beveiliging en robuustheid, principe.Open full entry → 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 levenscycluslevenscyclusDe spanne van een enkel AI-systeem van eerste intake tot uitfasering, waarover het bestuurd moet worden. De horizontale as van governance: waar de governance-keten één principe borgt, voert de levenscyclus één systeem door de tijd. Doorgaans getekend als zes fasen, plan en ontwerp, data en ontwikkeling, verifieer en valideer, uitrol, gebruik en monitoring, en uitfasering, elk met controls die er eigen aan zijn en een anker-artefact. Een lus in plaats van een lijn, want een systeem in productie voert nieuw risico terug naar een verse beoordeling. Zie artefact, control, governance-keten.Open full entry →" 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. RestrisicorestrisicoHet risico dat overblijft nadat controls het hebben verminderd. Geen control brengt een risico tot nul terug, en niet elke control is zijn kosten waard, dus wordt er een bewuste afweging gemaakt: of de kosten van verdere control opwegen tegen de risicovermindering die het oplevert, en of het resterende risico aanvaardbaar is tegen de risicobereidheid van de organisatie. Dit is een afweging op inrichtingsniveau, waar de uitvoering terugrapporteert en governance het restrisico aanvaardt, om meer control vraagt, of de use case afwijst. EU AI Act Art. 9(5) vereist dat het per gevaar en in totaal aanvaardbaar wordt geoordeeld. Zie risico, control, risicobereidheid.Open full entry →'s die na mitigatie overblijven, moeten aanvaardbaar worden geacht en aan de deployer 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 bewijsbewijsHet concrete bewijs dat een control is ontworpen, geïmplementeerd en werkt: een testrapport, een audit trail, een impactassessment, een monitoringlog. Elke schakel in de governance-keten levert een artefact op, en samen zijn ze wat een organisatie overhandigt aan haar eigen bestuur, een toezichthouder, een klant of een betrokkene om te tonen, niet te zeggen, dat een systeem bestuurd is. De afwezigheid ervan is zelf het falen: een risicoregister zonder testresultaten, of een maatregel die wordt geclaimd zonder validatie, is een governance-gat, geen papierwerk-gat. De sluitende schakel van de governance-keten. Zie control, governance.Open full entry → dat de maatregel werkt, stroomt terug via testen en monitoring.

Waarom het ertoe doet

Voor een provider is het risicobeheerssysteem het document dat een conformiteitsbeoordelingconformiteitsbeoordelingHet proces vóór markttoelating waarmee wordt aangetoond dat een hoog-risico-AI-systeem voldoet aan de eisen van de EU AI Act, leidend tot CE-markering en registratie. Zie CE-markering, aangemelde instantie.Open full entry → 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 risicoregisterrisicoregisterHet levende overzicht van de geïdentificeerde risico's van een AI-systeem, hun inschatting, respons, eigenaren en herzieningsdata, actueel gehouden van ontwerp tot uitfasering. Zie risico, control, governance-keten.Open full entry → 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 incidenternstig incidentEen AI-incident dat de dood, ernstige schade aan gezondheid, eigendom, grondrechten of infrastructuur veroorzaakt (of bijna veroorzaakt), wat meldplichten aan toezichthouders activeert voor hoog-risicosystemen. Zie AI-incident, markttoezichtautoriteit.Open full entry →.

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 monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry →- en incidentdata terug in het register?