Het invoerformulier van het algoritmeregister telt tientallen velden. Doel en impact, gegevens, technische werking, menselijke tussenkomst, begindatum, leverancier. Wie het de eerste keer invult, gaat op zoek naar antwoorden die in de draaiende software zitten en zelden ergens zijn opgeschreven.
Daarmee wordt het register een eis aan je applicatie. Het stelt vragen die je systeem elke keer opnieuw moet kunnen beantwoorden, ook na een release waarin de beslisregels veranderen.
Hieronder lees je welke gegevens het register vraagt, welke velden uit je eigen applicatie komen, hoe je ze logt en versiebeheert, hoe je de uitleg voor de burger bijhoudt en hoe je publicatie automatiseert. Wij bouwen al ruim dertig jaar bedrijfssoftware waarin beslisregels en herleidbaarheid samenkomen.
Wat het algoritmeregister van je vraagt
Het algoritmeregister van de Nederlandse overheid verzamelt beschrijvingen van algoritmes die overheidsorganisaties in hun processen gebruiken. Burgers, journalisten en toezichthouders zien er op één plek wat er draait en waarvoor. Het register bevat op dit moment 1.564 algoritmebeschrijvingen. Op 1 januari 2025 waren dat er 675.
Welke informatie je aanlevert, ligt vast in de publicatiestandaard. Versie 1.0.0 kent 32 velden in vier groepen: algemene informatie, verantwoord gebruik, werking en metadata. Per beschrijving kies je een publicatiecategorie: hoogrisico AI, impactvolle algoritmes of overige algoritmes. Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties beheert het register samen met ICTU.
Aanleveren is voor overheidsorganisaties nog niet wettelijk verplicht. De organisatie die het algoritme inzet blijft verantwoordelijk voor de beschrijving en voor de juistheid ervan, ook wanneer het algoritme uit een ingekocht pakket komt. Voor teams die software bouwen voor de overheid verschuift het werk daarmee naar de bouwfase. Het systeem moet zelf kunnen vertellen wat het doet.
Welke velden van het algoritmeregister uit je applicatie komen
Een deel van de 32 velden komt uit stukken die naast de software leven. De wettelijke basis, de uitgevoerde impacttoetsen en de verwijzing naar het verwerkingsregister haal je uit documentatie van de organisatie. Deze velden komen uit de applicatie zelf:
- Status, begindatum en einddatum. In ontwikkeling, in gebruik of buiten gebruik, met de maand waarin dat gebeurde. Dat zijn releasegegevens.
- Doel en impact. Waarvoor de regelset is gebouwd en hoe burgers of bedrijven ermee te maken krijgen.
- Gegevens. Een overzicht van de invoer die het algoritme gebruikt.
- Technische werking. Invoer, werking en uitvoer, met minstens de vermelding of het zelflerend is.
- Menselijke tussenkomst. Hoe een medewerker de uitkomst gebruikt, controleert en bijstelt.
- Risicobeheer. Hoe je omgaat met de risico's die je hebt gezien, inclusief de monitoring die je hebt ingebouwd.
- Leverancier. De naam van de externe partij of de vermelding dat het intern is ontwikkeld.
- Link naar broncode. De pagina waar de code staat, wanneer die openbaar is.
- Eigen bronidentificatie. De verwijzing naar het algoritme in je eigen database.
Dat laatste veld is klein en verdient aandacht. Zodra je systeem een eigen sleutel per regelset kent en die sleutel in het register staat, kun je beide kanten op zoeken zonder een lijst in een spreadsheet bij te houden.
Leg doel, beslisregels en beslisser vast in je datamodel
De meeste applicaties bewaren de uitkomst van een beslissing en laten de redenering erachter verdampen. Voor het register heb je die redenering nodig, in een vorm die blijft staan wanneer een ontwikkelaar code verplaatst.
Maak de regelset daarom een eigen object in je datamodel, met een naam, een doel in gewone taal, een eigenaar, een status en een ingangsdatum. Zet de regels zelf als gegevens in de database in plaats van verspreid door de code. Een beheerder ziet dan welke regels gelden, en het veld over technische werking komt uit dezelfde bron als de uitvoering.
Leg daarnaast per besluit vast wie of wat het nam: welke regel afging, welke waarde de doorslag gaf en of een medewerker het overnam. Daarmee vul je het veld over menselijke tussenkomst met een beschrijving die klopt. Draait het proces volledig automatisch, dan is ook dat een antwoord dat het register verwacht.
Wij bouwden een platform voor subsidieadministratie, waarin aanvragen langs vaste regels lopen. In zulke systemen is herleidbaarheid onderdeel van het ontwerp. Je wilt bij elke beoordeling kunnen terugzien welke regel gold en waar iemand heeft ingegrepen, en die gegevens ontstaan alleen wanneer je ze vanaf de eerste release bewaart.
Gegevensbronnen: welke invoer het algoritme gebruikt
Het veld over gegevens vraagt om een overzicht van wat het algoritme gebruikt. Bij een applicatie die uit vijf systemen leest, is dat geen zin die iemand uit zijn hoofd opschrijft.
Declareer de invoer daarom per regelset in je eigen applicatie: welk veld, uit welk bronsysteem, via welke koppeling en hoe vers de waarde is. Uit die declaratie rolt het overzicht dat het register vraagt, en er komt een tweede opbrengst bij. Wijzigt een leverancier zijn API, dan zie je meteen welke regelsets erop leunen.
Veel van die kennis bestaat al. De mappingtabel die je bij een koppeling bijhoudt, met veldnamen aan beide kanten en afspraken over waarden die niet passen, is precies de bron voor dit veld. Wij leggen die tabellen vast bij het koppelen van systemen, omdat je ze ook voor foutafhandeling en beheer nodig hebt.
Versiebeheer en logging: welke versie nam dit besluit
Een algoritmebeschrijving veroudert zodra de regels veranderen. Het register vraagt informatie die actueel blijft, en dat lukt alleen wanneer je applicatie haar eigen versies kent.
Geef elke regelset en elk model een versienummer en een geldigheidsperiode. Bewaar bij elk besluit welke versie het nam. Een vraag van een burger over een brief uit maart wordt dan een zoekopdracht van een minuut. Houd oude versies leesbaar, ook wanneer ze niet meer draaien. Het register ondersteunt zelf ook meerdere versies van de standaard naast elkaar, dus je hoeft bestaande beschrijvingen niet in één keer om te zetten.
Log daarnaast hoe vaak het algoritme draait. Een planner, een wachtrij of een aanroep vanuit een formulier geeft een ander beeld dan de aanduiding "dagelijks". Met een teller per periode vul je de technische werking met cijfers uit de praktijk, en je ziet het meteen wanneer een koppeling uitvalt.
Dat principe kennen we uit onderhoudssoftware voor de luchtvaart, waar bij elk onderdeel herleidbaar moet zijn welke procedure en welke versie golden. Software die dat bijhoudt, beantwoordt de vragen van het register bijna vanzelf.
Uitleg voor de burger naast de technische uitleg
Het register bedient twee groepen lezers: mensen zonder veel kennis van algoritmes en mensen die de techniek willen zien. Voor de brede groep is taalniveau B1 het streven, en dat geldt juist voor de velden die het meest gelezen worden.
In de praktijk betekent dat twee teksten per regelset: een korte uitleg in gewone taal en een technische beschrijving. Bewaar ze bij de regels zelf, in dezelfde repository, en koppel ze aan de versie. De uitleg verandert dan mee wanneer de regels veranderen.
Zet die koppeling ook in je werkafspraken. Een wijziging in een beslisregel gaat pas mee in een release wanneer de publieksuitleg is bijgewerkt en gelezen door iemand die de regel zelf niet heeft geschreven. Dat kost een kwartier per wijziging en voorkomt dat het register een beschrijving toont die drie releases achterloopt.
Publicatie in het algoritmeregister automatiseren
Aanleveren kan op twee manieren: via het webformulier of via de API. Het webformulier werkt goed voor de eerste beschrijvingen. Zodra je tien regelsets hebt die een paar keer per jaar wijzigen, wordt handmatig bijwerken de zwakste schakel.
De aanleverapi van het register is beschreven volgens OpenAPI en staat op algoritmes.overheid.nl/aanleverapi. In het pad staat de versie van de publicatiestandaard, daarachter de organisatie namens wie je aanlevert. Je haalt eerst een token op, stuurt dat mee in de header en plaatst daarna de beschrijving als JSON. Een nieuw algoritme krijgt een eigen code terug, de lars_code, die je naast je eigen sleutel bewaart. De sessie verloopt na een paar minuten, dus haal het token op per run.
Daarmee wordt publiceren een stap in je releaseproces. Bij elke release verzamelt een klein script de velden uit je database, controleert ze tegen het schema en stuurt ze door. Wat overblijft is een verschil dat iemand goedkeurt.
Aansluiten gaat via een vaste route. Je meldt je aan bij het register, ICTU neemt binnen drie werkdagen contact op en na een online sessie krijg je een account. Publiceren via de API wordt daarna ingeregeld tussen jouw ontwikkelaars en die van ICTU. Elke vrijgave wordt handmatig gecontroleerd en staat binnen één werkdag online. Heeft je organisatie een eigen register op de website, dan hoeft dat geen tweede administratie te worden: de standaard bevat een veld voor de link naar die bronregistratie.
Wij bouwen deze laag als onderdeel van maatwerk software en als aanvulling op een systeem dat al draait, met 30+ engineers in Nijmegen en Sarajevo en volgens ISO 9001 en ISO 27001. Hoe we dat bij andere systemen aanpakten, zie je in onze cases, en onze werkwijze rond koppelingen staat op de pagina over API development. Het werk begint met een inventarisatie: welke regelsets, welke invoer, welke versies en wat je vandaag al vastlegt. Plan een gesprek en we lopen die lijst met je door.
Veelgestelde vragen
Welke gegevens vraagt het algoritmeregister?
De publicatiestandaard 1.0.0 kent 32 velden in vier groepen: algemene informatie, verantwoord gebruik, werking en metadata. Denk aan naam, organisatie, status, publicatiecategorie, doel en impact, menselijke tussenkomst, risicobeheer, de gebruikte gegevens, de technische werking en de leverancier. Een deel komt uit documentatie van de organisatie, de rest uit de applicatie die het algoritme draait.
Is publicatie in het algoritmeregister verplicht?
Voor overheidsorganisaties is aanleveren op dit moment niet wettelijk verplicht. Het register richt zich op impactvolle algoritmes, waaronder hoogrisico AI. De organisatie die het algoritme inzet is verantwoordelijk voor de beschrijving en voor het actueel houden ervan.
Kun je publiceren in het algoritmeregister automatiseren?
Ja. Naast het webformulier is er een API waarmee je beschrijvingen aanlevert als JSON. Je logt in, haalt een token op en plaatst de beschrijving namens je organisatie. Elk algoritme krijgt een eigen code terug die je in je eigen database bewaart naast je interne sleutel. Na vrijgave staat een wijziging binnen één werkdag online.
Wat als het algoritme van een leverancier komt?
De organisatie die het algoritme gebruikt blijft verantwoordelijk voor de beschrijving. De standaard heeft een veld voor de leverancier, en de handreiking bij het register adviseert om eisen over transparantie in de inkoopvoorwaarden op te nemen. In de praktijk levert de leverancier de technische werking aan en schrijft de organisatie zelf het doel en de impact.
