Veel bedrijven lezen "risicobeheersysteem" en denken aan een dik document dat ergens in een map verdwijnt. Dat is precies wat artikel 9 AI Act niet bedoelt. Een risicobeheersysteem is volgens de wet een doorlopend, iteratief en gedocumenteerd proces dat de gehele levenscyclus van een hoog-risico AI-systeem omvat. Geen one-shot, geen formaliteit.
In deze gids leggen we uit wat artikel 9 vraagt, hoe het in elkaar grijpt met andere artikelen en hoe u het zonder dure consultants in uw organisatie inricht.
Wat zegt artikel 9 letterlijk?
Artikel 9 lid 1 zegt: er moet een risicobeheersysteem opgezet, geimplementeerd, gedocumenteerd en onderhouden worden voor hoog-risico AI-systemen. Lid 2 maakt expliciet dat het een continu, iteratief proces is dat de hele levenscyclus bestrijkt en regelmatig systematisch wordt geupdatet. Lid 3 tot en met lid 9 omschrijft wat dat in de praktijk betekent.
De vier kernactiviteiten
1. Identificatie en analyse van bekende en redelijkerwijs voorzienbare risicos
U brengt in kaart welke risicos het systeem oplevert voor gezondheid, veiligheid en grondrechten, wanneer het wordt gebruikt voor het beoogde doel en bij redelijkerwijs voorzienbaar misbruik. Voorbeeld voor een HR-AI: foutieve afwijzingen, biasonderscheid op leeftijd of geslacht, kandidaten die het systeem manipuleren met spreuken in hun CV.
2. Schatting en evaluatie van het risico bij gebruik
Per geidentificeerd risico schat u ernst en waarschijnlijkheid in. Veel teams gebruiken hiervoor een eenvoudige matrix met laag/midden/hoog op beide assen. Een risico van hoog-hoog krijgt een andere behandeling dan een laag-laag.
3. Beoordeling van risicos die uit monitoring blijken
Het systeem gaat in productie. U houdt loggegevens bij, incidenten, gebruikersklachten en periodieke audits. Deze input voedt terug naar het risicoregister. Risicos die u niet had voorzien, worden alsnog meegenomen.
4. Goedkeuring van passende risicobeheersmaatregelen
Per risico kiest u een mitigatie: technisch (filters, drempelwaarden, modelaanpassing), procesmatig (extra menselijke controle, escalatieprocedure) of informatief (waarschuwingen in de gebruikersinterface). U documenteert waarom u die keuze maakte en wat het restrisico is.
De volgorde van mitigaties: hierarchy of controls
Artikel 9 lid 5 schrijft een verplichte volgorde voor. U gaat van zwaar naar licht:
- Risico wegnemen of verminderen door ontwerp en ontwikkeling. Eerste optie altijd: pas het AI-systeem zelf aan.
- Implementeer passende risicobeperkings- en controlemaatregelen. Tweede optie: zet er processen of controles omheen.
- Geef informatie en, indien nodig, training aan deployers. Pas als de eerste twee onvoldoende zijn: leg de verantwoordelijkheid bij de gebruiker met goede instructies.
Waarom deze volgorde belangrijk is: Een toezichthouder die uw dossier checkt, kijkt of u eerst de hogere mitigaties heeft geprobeerd. Als u meteen naar "training en instructies" springt zonder te overwegen of het probleem aan de bron op te lossen is, is dat een rode vlag.
Specifieke aandacht voor kwetsbare groepen
Artikel 9 lid 9 zegt dat u bijzonder aandacht moet besteden aan de mogelijke impact op kinderen onder de 18 of andere kwetsbare groepen. Voor een AI in de zorg of in onderwijs is dit nooit optioneel. Voor een productiviteits-AI bij een industrieel bedrijf valt het misschien weg, maar u moet de afweging gedocumenteerd hebben.
Testen voordat het systeem in productie gaat
Artikel 9 lid 6 t/m 8 verplicht u tot testen die specifiek gericht zijn op de geidentificeerde risicos. Niet alleen technische tests (accuracy, robustness) maar ook tests op echte misbruikscenarios. Voor een chatbot: bewust proberen jailbreaks te triggeren. Voor een kredietscore-model: bias-tests op demografische groepen.
De tests moeten gedaan worden voor ingebruikname, tijdens ontwikkeling en periodiek tijdens de levenscyclus. Bewaar de testresultaten als onderdeel van uw technisch dossier (artikel 11).
Praktische opzet: een risicobeheersysteem in vier documenten
Een spreadsheet met per risico: omschrijving, doelgroep, ernst, waarschijnlijkheid, gekozen mitigatie, eigenaar, status, laatst getoetst. Dit is het hart van uw systeem.
Documentatie van de tests die u heeft gedaan voor ingebruikname, met resultaten en hoe deze de risicos hebben afgedekt of niet.
Logging die u doorlopend bijhoudt en periodiek beoordeelt. Incidenten en klachten leiden terug naar het risicoregister.
Periodieke (minimaal jaarlijkse) review waarin u vaststelt of het systeem nog werkt, of nieuwe risicos zijn opgekomen en welke acties volgen.
Een DPIA onder de AVG is een andere oefening dan een AI Act-risicobeheersysteem. De DPIA gaat over privacy en persoonsgegevens. Het risicobeheersysteem omvat ook veiligheid, fysieke gezondheid en bredere grondrechten. U mag de twee samenvoegen in een document, maar dan moet duidelijk zijn dat alle aspecten gedekt zijn.
Wat als u deployer bent, niet provider?
Artikel 9 richt zich op providers. Maar in de praktijk lopen veel verplichtingen door naar u als deployer. U moet de instructies van de provider opvolgen (artikel 26), u moet menselijk toezicht inrichten (artikel 14) en u moet incidenten terugkoppelen.
In de praktijk loont het om een verkleind risicobeheersysteem voor uzelf op te zetten. Niet omdat de wet het strikt eist, maar omdat u zonder zo'n proces nooit kunt bewijzen dat u uw deployer-verplichtingen serieus neemt.
Risicobeheer zonder consultants
De ActCheck-scan loopt uw AI-portfolio door en geeft per systeem aan welke risicobeheer-maatregelen passend zijn. In 10 minuten heeft u een startdocument.
Start de gratis check