Algoritmeregisters zijn niet genoeg: waarom participatieve systeemanalyse de echte risico's blootlegt

Algoritmeregisters zijn geen risico-instrumenten. Ze zijn inventarislijsten. Ze vertellen je welke algoritmes een gemeente gebruikt, maar niet welke gevaren die algoritmes in samenhang met processen, mensen en systemen kunnen veroorzaken. Dat is geen kritiek op de registratieplicht, maar op de verwachting dat een register je veiligheid garandeert.

Een recente studie op arXiv laat precies dat zien. Onderzoekers pasten participatieve systeemanalyse (STPA) toe op het algoritmeregister van een Nederlandse gemeente. De resultaten zijn confronterend: het register zelf bleef blind voor systeemrisico's zoals onterechte uitkeringsweigering, prestatieverlies en de onmogelijkheid om besluiten te weerleggen. Pas toen ambtenaren, ombudsmannen en maatschappelijke organisaties samen om de tafel gingen, kwamen deze hazards bovendrijven.

Ik werk dagelijks met publieke organisaties die worstelen met AI-governance. Dit paper bevestigt wat ik in de praktijk zie: registers zijn een startpunt, geen eindpunt. De echte vraag is niet welke algoritmes je hebt, maar hoe ze interacteren met de sociotechnische context waarin ze draaien. En dat vraagt om een andere methode dan een spreadsheet.

Het register als rookgordijn

De Nederlandse Algoritmeverordening verplicht gemeenten om algoritmes te registreren. Dat is goed. Maar een register is een momentopname. Het bevat metadata: naam, doel, data, impact. Het bevat geen analyse van wat er gebeurt als het algoritme faalt, of erger, als het correct werkt maar in een systeem dat al kwetsbaar is.

Neem een uitkeringsalgoritme. Het register zegt: "Gebruikt voor fraudedetectie." Maar het zegt niet dat het algoritme een besluit kan genereren dat een burger niet kan aanvechten, omdat de onderliggende data niet transparant is. Het zegt niet dat het systeem prestaties kan verliezen onder piekbelasting, waardoor onterechte weigeringen ontstaan. Die risico's zitten niet in het register, maar in de interactie tussen het algoritme, de datapijplijn, de menselijke beslisser en de bezwaarprocedure.

De paper toont precies dat. De onderzoekers gebruikten STPA (System-Theoretic Process Analysis) om het systeem rond het algoritme in kaart te brengen. STPA is geen nieuwe technologie, maar een gestructureerde methode om veiligheidsrisico's te identificeren door systeeminteracties te modelleren. Het is afkomstig uit de lucht- en ruimtevaart, maar blijkt uitstekend toepasbaar op AI-governance.

Wat STPA anders doet

STPA vertrekt vanuit een systeemmodel, niet vanuit een componentenlijst. Je definieert het systeem als een set van controllers, actuatoren, sensoren en processen, met feedbackloops. Vervolgens identificeer je onveilige control-acties: acties die een controller kan uitvoeren en die leiden tot een hazard.

Formeel: laat (C) de set van controllers zijn, (P) de set van processen, en (A) de set van acties. Een onveilige control-actie is een tuple ((c, a, context)) zodanig dat het uitvoeren van (a) door (c) in die context leidt tot een systeemtoestand die een hazard veroorzaakt. STPA geeft vier categorieën: een actie die niet gegeven wordt, wel gegeven wordt maar te vroeg/te laat/te lang, een actie die stopt te vroeg, of een actie die correct is maar in de verkeerde context.

In de gemeentecasus vonden de onderzoekers hazards zoals:

• Onterechte uitkeringsweigering: het algoritme genereert een weigering op basis van incomplete data, maar de controller (de ambtenaar) heeft geen mechanisme om die data te valideren.
• Prestatieverlies: het systeem kan onder hoge belasting vertragen, waardoor time-outs optreden en besluiten automatisch worden doorgezet zonder menselijke controle.
• Onweerlegbaarheid: de burger kan een besluit niet aanvechten omdat de onderliggende datalogging ontbreekt of niet toegankelijk is.

Deze hazards zijn niet zichtbaar in het register. Ze ontstaan pas wanneer je het systeem als geheel bekijkt, inclusief de menselijke actoren en hun beperkingen.

Waarom participatie cruciaal is

STPA is geen solo-oefening. De paper benadrukt dat de analyse alleen werkt als je stakeholders betrekt die het systeem dagelijks ervaren. Ambtenaren weten hoe het algoritme in de praktijk wordt gebruikt, ombudsmannen zien de klachten, maatschappelijke organisaties kennen de impact op burgers. Zonder hen mis je de context die nodig is om hazards te identificeren.

Ik heb zelf gezien hoe een registerreview zonder stakeholders alleen technische risico's oplevert, zoals datalekken of modelbias. Maar de echte risico's zitten in de procesinteracties: een ambtenaar die het algoritme blind vertrouwt, een bezwaarprocedure die geen toegang heeft tot de onderliggende data, een systeem dat geen audit trail bijhoudt. Die risico's zijn niet technisch, maar sociotechnisch.

De paper gebruikt een participatieve variant van STPA, waarbij stakeholders in workshops het systeem gezamenlijk in kaart brengen. Dat is geen vrijblijvende brainstorm, maar een gestructureerde methode met duidelijke outputs: een systeemmodel, een lijst van onveilige control-acties, en een set van veiligheidseisen.

Een concreet voorbeeld: de uitkeringsweigering

Stel je een gemeente die een algoritme gebruikt om uitkeringsfraude te detecteren. Het register vermeldt: "Doel: risicoclassificatie van aanvragen." De STPA-analyse begint met het systeemmodel:

• Controller: het algoritme (classificatiemodel)
• Actuator: de output (risicoscore) die naar de ambtenaar gaat
• Sensor: de inputdata (inkomen, vermogen, adres)
• Proces: de besluitvorming over de uitkering

De stakeholders identificeren een onveilige control-actie: het algoritme geeft een hoge risicoscore op basis van een onjuist adres, omdat de adresdata niet geactualiseerd is. De ambtenaar, die de score als leidend beschouwt, weigert de uitkering zonder de adresdata te verifiëren. De burger kan geen bezwaar maken omdat de databron niet wordt vermeld.

Dit hazard is niet te vinden in het register. Het vereist kennis van de datakwaliteit, de werkwijze van de ambtenaar, en de juridische mogelijkheden van de burger. Participatieve STPA brengt die kennis bij elkaar.

Wat dit betekent voor Nederlandse publieke organisaties

De AI Act verplicht risicobeheer voor hoog-risico AI-systemen. Maar risicobeheer is geen papieren exercitie. Het vereist een methode die systeemrisico's identificeert, niet alleen componentrisico's. STPA is zo'n methode, en de paper toont dat het toepasbaar is op de Nederlandse context.

BIO2 (Baseline Informatiebeveiliging Overheid) eist dat je risico's inventariseert en beheerst. NIS2 legt de nadruk op ketenverantwoordelijkheid. NORA (Nederlandse Overheid Referentie Architectuur) vraagt om een samenhangende architectuur. Al deze kaders erkennen dat systemen meer zijn dan de som van hun onderdelen. STPA geeft je een concrete manier om die systeemgedachte in de praktijk te brengen.

De paper is een wake-upcall voor gemeenten die denken dat een register voldoende is. Het is een startpunt, maar je moet verder gaan. De vraag is niet "welke algoritmes hebben we?", maar "welke gevaren ontstaan door de interactie van die algoritmes met onze processen, mensen en data?"

Hoe je zelf aan de slag gaat

Je hoeft geen onderzoeker te zijn om STPA toe te passen. De methode is gestructureerd en reproduceerbaar. Hier is een praktische aanpak:

1. Selecteer een kritisch algoritme (bijvoorbeeld een dat een directe impact heeft op burgers).
2. Stel een multidisciplinair team samen: ambtenaren, juridisch adviseurs, een ombudsman, een vertegenwoordiger van een maatschappelijke organisatie.
3. Modelleer het systeem: teken de controllers, actuatoren, sensoren en processen. Gebruik een whiteboard of een tool zoals draw.io.
4. Identificeer onveilige control-acties: doorloop de vier categorieën (niet geven, wel geven maar fout getimed, stoppen te vroeg, correct maar verkeerde context).
5. Definieer veiligheidseisen: voor elke hazard formuleer je een eis, bijvoorbeeld "De ambtenaar moet de databron van de risicoscore kunnen inzien" of "Het systeem moet een audit trail bijhouden van alle besluiten."
6. Implementeer en monitor: vertaal de eisen naar concrete maatregelen, en evalueer periodiek.

De paper bevat een gedetailleerde casus die je als template kunt gebruiken. Het is geen rocket science, maar het vereist discipline en de bereidheid om buiten je eigen silo te denken.

De rol van de consultant

Als consultant zie ik mijn rol niet als het invullen van een register, maar als het faciliteren van dit soort analyses. Het is mijn taak om de methode te brengen, de stakeholders bij elkaar te brengen, en de resultaten te vertalen naar concrete verbeteringen. Dat is geen verkooppraatje, maar een noodzaak als je de risico's van AI in de publieke sector serieus neemt.

De paper bevestigt dat participatieve systeemanalyse werkt. Het is geen theoretisch concept, maar een bewezen aanpak met concrete resultaten. Voor elke gemeente die een algoritmeregister heeft, is de volgende stap logisch: voer een STPA-analyse uit op de meest kritieke algoritmes. Niet omdat het moet, maar omdat het de enige manier is om de echte risico's te zien.

Conclusie: van register naar systeem

Algoritmeregisters zijn een noodzakelijke eerste stap, maar ze zijn niet voldoende. De systeemrisico's die de paper blootlegt, zijn te belangrijk om te negeren. Participatieve STPA biedt een concrete, reproduceerbare methode om die risico's te identificeren en aan te pakken.

Wil je weten of jouw organisatie hier klaar voor is? Gebruik deze AI Act Self-Check om te bepalen welke algoritmes onder de hoog-risico categorie vallen. Daarna kun je gericht een STPA-analyse starten.

De paper is beschikbaar op arXiv: abstract en PDF. Lees het, en vraag jezelf af: wat staat er in mijn register, en wat staat er niet in?