Een algoritmeregister vullen
algoritmeregister software design
16 februari 2023
Gisteren was er een bijeenkomst van de provincies in het kader van algoritmeregister, deze keer met een focus op het vullen van het algoritmeregister: wat moet erin (en wat niet).
Wat is een algoritme?
De vraag die iedere keer voorbij komt is: wat is een algoritme? Om dit in wetten vast te gaan leggen zal er vast en zeker een antwoord moeten komen op die vraag, alhoewel de juiste vraag dan volgens mij zou moeten zijn: “wat willen we vastleggen”, en daar dus het woord voor vinden, in plaats van vastklampen aan het woord “algoritme” en de betekenis daarvan danwel proberen vast te pinnen, danwel proberen zodanig op te rekken en te verleggen dat het past bij wat je eigenlijk vast wil leggen.
![]()
Als je een stapje terug doet kom je volgens mij bij een zinvoller inzicht: wat we proberen te voorkomen is dat er beslissingen worden genomen als onderdeel van de “implementatie” van techniek, die eigenlijk discretionair zijn en waar dus verantwoording voor moet worden afgelegd. Waar we nu nog regelmatig software inzetten zonder (al te kritisch) verantwoordelijkheid te nemen voor wat die software precies doet (“zo werkt het nu eenmaal”), moet de mindset veel meer gaan zijn: als die software op een bepaalde manier werkt, dan zijn wij daarvoor verantwoordelijk, dus willen we precies weten hoe dat is, en als dat niet overeenkomt met onze waarden (of de wet), dan moet die software buigen (en niet wij, de wet of de samenleving).
Wat is een algoritmeregister
Wat er dus moet worden vastgelegd is precies die beslissing. En waar je dus “algoritmeregister” lees, moet je eigenlijk denken “overzicht van verantwoording bij de inzet van algoritmische toepassingen”.
Vaak is er in discussies nog een onduidelijkheid: waar de een algoritmeregister zegt, doelt die op een intern overzicht van de ingezette algoritmische toepassingen, terwijl de ander doelt op een publiek toegankelijke plek (website) waarop deze informatie voor een bepaalde doelgroep beschikbaar wordt gesteld. In het ene geval betreft het dus een tool om meer grip te krijgen op de eigen inzet van algoritmes, in het andere geval gaat het om een manier van transparantie verschaffen aan de buitenwereld in het kader van een open overheid.
Vervolgens speelt dan ook nog de vraag: wat is in dat opzicht de rol van het “nationale algoritmeregister” en, als we daar “gebruik van maken”, is er dan nog een noodzaak om een eigen algoritmeregister te realiseren en onderhouden, bijvoorbeeld op de eigen website.
Wanneer moet een algoritme in het register?
Bij het bespreken van criteria voor het prioriteren en selecteren van welke algoritmes moeten worden opgenomen in het algoritmeregister, kwamen een aantal vanzelfsprekende/bekende naar voren:
- hoge impact op burgers en bedrijven
- gebruik van persoonsinformatie
- politieke “hot topics”
- onomkeerbaarheid van de besluiten
- volautomatisch proces: geen menselijke tussenkomst
Criteria die ik voor het eerst hoorde:
- “vakjes prakken”: er worden scores gegeven aan dingen die helemaal niet zo makkelijk met elkaar te vergelijken zijn
- grote belangenconflicten tussen de stakeholders
- niet erg duidelijk hoe een lerend algoritme zich in de toekomst zal gaan gedragen
- weinig zekerheid/vertrouwen in de kwaliteit van het algoritme
- hoge mogelijkheid van doelverschuiving
- type technologie is onbekend/spannend
En de - in mijn optiek - mooiste:
- verbaasdheid over het bestaan van een bepaalde gebruik van een algoritmische toepassing
What’s in a name
Tot slot was er nog de constatering dat de naam die gebruikt wordt voor de inzet van een algoritmische toepassing van invloed is op de inschatting van bovenstaande criteria. In combinatie met het feit dat veel van de bovenstaande vragen eigenlijk ook al antwoord zijn op de vragen die gesteld worden in de Algorithmic Transparency Standard, maakt dat mijn conclusie zou zijn: voor alle algoritmes die je tegen komt moet je even langs dit lijstje (en dus de basis van de registratie invullen), waarna je kunt bepalen of het publiceren in een publiek algoritmeregister zinvol is of eerder vervuilend.
Andere aantekeningen
Single Point of Failure
31 augustus 2025
We vrezen vaak het single point of failure — één plek waar alles kan vastlopen of lekken. Maar juist daar zit ook de sleutel: één plek om te sturen, te beveiligen en fouten te herstellen. Of het nu gaat om een AI-gateway die digitale autonomie waarborgt, of een centraal administratiekantoor voor medisch onderzoek dat privacy en toestemming strak beheert: kwetsbaarheid en mitigatie vallen samen. De crux is niet óf je centraliseert, maar hóe je dat ene punt zo inricht dat het een bron van vertrouwen wordt.
De vijf F-strategieën voor Digitale Autonomie
7 november 2024
Welke strategieën kan de overheid ontwikkelen om de (digitale) autonomie van zowel overheid als samenleving te waarborgen? In dit artikel een voorzet in de form van vijf F-woorden.
Wat projecten kunnen leren van Common Ground
15 januari 2025
Hoe kunnen publieke projecten effectiever samenwerken? Het Common Ground-model biedt hiervoor een interessante opzet.