Rules as Code, een hindernissenparcours?

Noot: dit artikel refereert naar Belgische wetgeving zoals deze gold op 15 oktober 2025, tenzij waar anders aangeduid. De interpretaties van wetteksten in dit artikel dienen slechts ter illustratie en zijn in geen geval autoritatief.

In een administratief utopia stemt het parlement een wet, of neemt de regering een besluit, dat iets wijzigt, en kan de software gebruikt voor de praktische uitwerking ervan haast automatisch aangepast worden aan de wijziging. Het concept van een nauwe koppeling tussen regelgeving en de softwarematige implementatie ervan, staat ook bekend onder de naam Rules as Code, afgekort RaC.

Initieel werd het vooral verkend in de juridische wereld, in academia, in incubatoren in de sector, onder juridische professionals, of bij innovatoren met interesse in LegalTech. Een hernieuwd elan kwam er in 2020 toen de OESO een lijvig rapport publiceerde waarin ze een stand van zaken geeft vanuit overheidsperspectief, daarbij refererend naar proof-of-concepts uit verschillende landen. Goed getimed, want de COVID-pandemie in datzelfde jaar had overheden en hun IT-leveranciers geconfronteerd met snel wijzigende richtlijnen en maatregelen naarmate de wetenschappelijke kennis over de ziekte toenam, en een ongeziene tijdsdruk om elke update zo snel mogelijk in de praktijk om te zetten. Technologie die een soepele implementatie van nieuwe regulering kan faciliteren, klinkt dan als muziek in de oren.

Sindsdien zijn enkele landen dan ook een versnelling hoger geschakeld. Frankrijk loopt op kop wat betreft werkende proof-of-concepts, waaronder simulatoren op Mes Droits Sociaux, LexImpact, en verscheidene projecten gebaseerd op publicodes. Ook in Canada, Australië, Nieuw-Zeeland en Nederland lopen er initiatieven. De EU publiceerde een informatief thema-artikel op haar GovTech Connect platform met vermelding van verschillende andere bronnen, en ook in de VS gaan stemmen op om er aandacht aan te besteden. Een diepgaande Nederlandse studie tenslotte voorziet ons van een handig en recent overzicht van Rules as Code oplossingen.

Toepassingsdomein

Het klinkt mooi om een wet semi-automatisch te kunnen omzetten in (liefst correcte) software. Ervaringen uit Nieuw-Zeeland zetten ons echter met de voeten op de grond en tonen overtuigend aan dat een 1-op-1 mapping tussen wet en bijhorende software, als dat al haalbaar is, in veel gevallen zelfs onwenselijk is.

De toepassing van regels vereist immers interpretatie. Zo wordt de verwoording van veel wetgeving met opzet enigszins abstract gehouden, om ze breed toepasbaar te maken, of om te voorkomen dat er te snel mazen ontstaan wanneer de samenleving evolueert. Voor elke praktische toepassing moeten die abstracte concepten concreet ingevuld worden. Dat is niet altijd gemakkelijk: wanneer zijn kleine reparaties aan een huurhuis “structureel van aard” (dus voor rekening van de huisbaas)? Wanneer zijn GDPR-maatregelen “voldoende”? Is een uitgave wel of niet een “aftrekbare beroepskost”? En wie zijn nu exact die vage “bevoegde instanties” waar de wettekst naar verwijst? Allemaal voer voor discussie.

Via omzendbrieven of rulings wordt de gewenste interpretatie soms wel verder verduidelijkt van overheidswege, maar dan nog kom je zelden tot een volledige en sluitende verzameling regels. Is er onduidelijkheid, dan kan een miniem verschil in interpretatie een zaak maken of kraken. Beelden we ons een volautomatische omzetting van wettekst naar software in, dan riskeren we deze interpretatieve stappen over te slaan of zonder veel finesse te laten invullen door voorgeprogrammeerde default-waarden. Elke jurist zal huiveren bij dat idee, en terecht.

Rules as Code is dus niet zaligmakend en vindt vooral toepassingen waar regels ondubbelzinnig zijn en weinig interpretatie behoeven, of wanneer vaagheden aanvaardbaar zijn en behouden kunnen blijven in het eindresultaat. Het klassieke voorbeeld is een set regels die te herleiden zijn tot een beslisboom op basis van objectief berekenbare criteria. Applicaties die daarmee gepaard gaan zijn bijvoorbeeld aanvraagformulieren, simulatoren of rekenmodules. Regelgeving die eerder normatief van aard is, zoals EU-verordeningen met hun veelvuldig gebruik van vage termen zoals “voldoende”, “adequaat”, “geschikt”, “relevant”, … leent zich er niet toe – wat enkele academici gevat verwoord hebben als: “rechtvaardigheid kan men niet automatiseren”.

Hindernissen

Eens men begint aan de oefening om regelgeving om te zetten in code, botst men al snel op de complexe interne verwevenheden tussen allerlei wetten en besluiten. Een mooie illustratie is de Nederlandse pensioenleeftijd: zelf vrij rechttoe rechtaan gedefinieerd in artikel 7a van de betreffende wet, heeft ze impact op, of wordt ernaar verwezen in, minstens 100 andere Nederlandse wetten of statuten. Als daaraan gemorreld wordt, riskeer je dus al snel grote domino-effecten.

Daarnaast komt de wetgever creatief uit de hoek als er oplossingen gevonden moeten worden voor bepaalde zeldzame situaties. Het herbekijken of uitbreiden van definities, of toevoegen van uitzonderingsbepalingen of extra voorwaarden, is courante praktijk. Elk amendement kan op zijn beurt verwijzen naar weer andere regels of wetten, wat een hele keten aan afhankelijkheden met zich meebrengt.

Neem het concept van meerderjarigheid. In theorie is dat een eenvoudige regel: wie 18 is of ouder, is meerderjarig en bijgevolg handelingsbekwaam (art. 488 oud B.W.). Dat piepkleine artikeltje wordt echter gevolgd door een resem veel langere artikels over de uitzonderingen daarop (art.488/1 e.v.), tot en met bewindvoering (art. 494–502). Als dat niet voldoet, kan ook de vrederechter ingrijpen (art.492) en oordelen over een waslijst aan bekwaamheden die op moment van schrijven al 42 afzonderlijke items bevat (art.492/1 §2 + §3).

Stel dat een overheidsdienst subsidies mag uitdelen op basis van een reglement dat meerderjarigheid als voorwaarde stelt, en we willen een website bouwen waar burgers een eligibility check kunnen doen, dan is if (x≥18) programmeren niet altijd voldoende. Iemand die onder bewindvoering staat en zijn eigen geldzaken niet mag beheren, moet mogelijk alsnog een ander antwoord krijgen. Dat staat niet noodzakelijk expliciet in dat subsidiereglement, maar is een gevolg van het hanteren van de definitie van meerderjarigheid uit het burgerlijk wetboek.

Daarmee is de kous nog niet af: wetten kunnen eerdere definities uitbreiden of wijzigen. Zo wordt het concept van meerderjarigheid in de wet op de Maatschappelijke Integratie verruimd: minderjarigen die gehuwd zijn, zwanger zijn, of kinderen ten laste hebben worden gelijkgesteld aan meerderjarig (Art. 7) – maar enkel voor de toepassing van die wet. Samengevat: elke meerderjarige is 18+, maar niet elke 18+er is ten volle zelfstandig meerderjarig, en wat begrepen mag worden onder meerderjarigheid kan bovendien per toepassingsgebied nog verschillen.

Het temporele aspect voegt daar nog een hele dimensie van complexiteit aan toe. Niet al deze regels golden immers altijd. De meerderjarigheid op 18 jaar is in België pas in werking getreden op 1 mei 1990 (wet van 19 januari 1990, gepubliceerd in het Belgisch staatsblad op 30 januari 1990). Voordien moest men 21 zijn. De hierboven aangehaalde algemene bewindvoering werd dan weer voorafgegaan door verschillende speciale statuten, waaronder “verlengde minderjarigheid” en “voorlopige bewindvoering”. Deze werden afgeschaft in 2014, maar door een overgangsbepaling doofden ze pas uit in de praktijk op 1 september 2019. Wijzigingen gebeuren ook door gemeentelijke fusies, staatshervormingen, landen die niet meer bestaan, tijdelijke regels zoals de COVID-steunmaatregelen, …

Al is oude wetgeving al jaren opgeheven, de effecten ervan kunnen nog lang nazinderen. Zo zien we op onze belastingaangifte in 2025 nog een aftrekpost voor “bijzondere bijdragen voor de sociale zekerheid van de jaren 1982 tot 1988” (vak VIII, code 1388-67). Ook sociale rechten opgebouwd in statuten of regimes die vandaag niet meer bestaan, tellen nog steeds mee. Als een berekening afhangt van een situatie uit het verleden en de destijds geldende wetgeving, kan het dus nodig zijn om in een applicatie naast de huidige regelgeving ook de hele voorgeschiedenis ervan te implementeren.

Met al deze complexiteit in zelfs eenvoudige concepten, kan het niet anders of er duiken onvolledigheden of inconsistenties op. De Raad van State heeft haar handen vol met het adviseren van de wetgever, en haalt regelmatig fouten uit ontwerpteksten. Zelfs dan moet het Staatsblad vaak nog errata publiceren. Soms wordt de invulling van inhoudelijke details overgelaten aan de regering, maar laten de Koninklijke of ministeriële besluiten lang op zich wachten, waardoor er een tijd lang een vacuüm ontstaat. Andere keren is men niet exact genoeg in de verwoording: men verduidelijkt bijvoorbeeld niet of men spreekt over kalenderdagen of werkdagen.

Daar waar onvolledigheid, ogenschijnlijke tegenspraak of interpretatie voor discussie zorgt, moet het Hof van Cassatie soms één en ander ophelderen. Al is dat geen garantie op minder spraakverwarring in de toekomst, getuige dit recente arrest waarin ze aanstippen dat een motorvoertuig in de Wegverkeerswet, niet begrepen mag worden als een motorvoertuig zoals gedefinieerd in de Wegcode…

Tot slot zijn er nog gevallen waar de wettekst zelf grammaticaal ambigu is. Zo wordt in het uitvoeringsbesluit van de Brusselse Hoofdstedelijke Regering over werken die vrijgesteld zijn van stedenbouwkundige vergunning, vermeld in art. 21/1, 3° lid: “[…] de plaatsing van isolatie […] op een mandelige muur of een gevel die niet zichtbaar is vanaf de openbare ruimte […]”. Het is hier onduidelijk of de bijzin (aangevat met die) enkel betrekking heeft op de gevel, of zowel op de gevel als op de gedeelde muur. Ongetwijfeld tot ergernis van homegrade.brussels, dat particulieren hierover moet adviseren, en in haar informatiefiche over het onderwerp moet toegeven: “Dit artikel is voor verschillende interpretaties vatbaar”.

Dit alles is bij klassieke applicatie-ontwikkeling al een hele kluif. Wordt het dan eenvoudiger als we onze app bouwen rond een Rules as Code-framework? Niet echt: een RaC-framework reikt misschien een vaste methodiek of werkwijze aan, maar dat neemt de complexiteit niet weg: dezelfde karrevracht informatie moet er nog steeds ingeprogrammeerd worden, en ambiguïteiten blijven voor dezelfde problemen zorgen. Sommige RaC-engines zullen toelaten om lacunes in de regels te detecteren, maar dan nog moet je beslissen wat je ermee doet. Het project goed afbakenen en grenzen stellen is nog steeds noodzakelijk, om te vermijden overdonderd te worden door een lawine van afhankelijkheden, verwijzingen, en wijzigingshistoriek.

De basis: wetsanalyse

Stel dat we een app willen maken die een bepaalde wetgeving implementeert, en bijvoorbeeld berekent of je recht hebt op een specifieke subsidie en zo ja, hoeveel.

Allereerst is dan een manier nodig om die wet om te zetten in een gestructureerde vorm die de omzetting naar code faciliteert. Via een wetsanalyse trachten we elke regel uit die wet te ontleden in haar onderdelen. Het analyseschema hieronder, afkomstig van het Nederlands ministerie van Binnenlandse Zaken, is generiek toepasbaar en voorziet een opdeling in 15 klassen:

De variabelen zijn eigenschappen die voor elk rechtssubject (persoon of entiteit) kunnen verschillen: voor een persoon zijn dat bijvoorbeeld het geslacht, de woonplaats, de naam, de burgerlijke staat. De parameters daarentegen zijn de eigenschappen van de regel die gelijk zijn voor iedereen: een toepassingsgebied, een startdatum, een indexwaarde, … Zo zal een omzendbrief vaak tot doel hebben om parameters zoals de indexwaarde aan te passen, en zal een wet definiëren welke variabelen onder welke voorwaarden bij de toepassing van een regel in rekening gebracht mogen worden. Het is soms moeilijk te beoordelen of een term nu onder de variabelen of de parameters valt. De makers van deze methode geven bij elke klasse een omschrijving en voorbeelden die verduidelijken hoe ze uitgedrukt kunnen worden in een wettekst.

Nemen we als voorbeeld het recht op het moederschapsverlof, geregeld in hoofdstuk IV, art. 39 e.v. van de Arbeidswet. De basisregel daarvan is, bondig samengevat, dat een zwangere vrouw recht heeft op dit verlof vanaf 6 weken vóór de door de arts geschatte datum van de bevalling (8 weken bij meerlingen), plus 9 weken na de bevalling. Een rudimentaire analyse van deze regel volgens bovenstaand schema kunnen we als volgt aanvangen:

• De vrouw, haar werkgever en haar arts zijn allen rechtssubjecten, met elkaar verbonden door een arbeidsrelatie resp. arts-patiëntrelatie die rechtsbetrekkingen zijn.
• Een van de voorwaarden in deze wet is dat de bevallingsdatum is ingeschat door een arts in een geneeskundig attest dat aan de werkgever wordt overgemaakt. Dat attest is hier een rechtsobject.
• De variabelen van toepassing op de vrouw zijn onder andere: hoeveel kinderen ze verwacht, haar woonplaats, arbeidsplaats, bevallingsdatum… dit is voor elke vrouw anders.
• Parameters van deze wet zijn o.a. de minimum- en maximumtermijnen waarvan sprake: 6 weken, 8 weken, 9 weken, … die zijn gelijk voor elke vrouw.
• Tijds– en plaatsaanduiding zeggen waar en wanneer de regel geldt: op Belgisch grondgebied, en sinds de laatste wetswijzigingen vanaf 1 juli 2004 voor het prenatale en 1 maart 2009 voor het postnatale deel van het moederschapsverlof. De voorgeschiedenis van parameters kan ook worden vastgelegd. Variabelen kunnen ook tijdsaanduidingen hebben als ze evolueren doorheen de tijd.

De eigenlijke regelgeving voorziet o.a. nog in uitzonderingssituaties voor kinderen die te vroeg, ziek, of levenloos geboren worden,… Dat meenemen in de analyse kan leiden tot de toevoeging van vele extra parameters en variabelen om al deze uitzonderingen te vatten.

De afleidingsregel neemt dan de vorm aan van een berekening, waarbij:

• de input bestaat uit een “situatie” die beschreven wordt als een verzameling variabelen,
• de voorwaarden toelaten om bepaalde componenten van de berekening te activeren of niet, zoals een beslisboom,
• de parameters aan componenten van de berekening een gewicht geven,
• de output zowel een categorische als numerieke waarde kan zijn,
• de berekening kan steunen op andere afleidingsregels met hun eigen parameters, voorwaarden en variabelen.

Het staat ons vrij om te kiezen hoe granulair we daarin willen zijn, of hoe diep we willen gaan in onze analyse. We kunnen pietje precies zijn en elk detail van de regelgeving proberen encoderen, maar even goed kunnen we vrede nemen met het maken van enkele veralgemeningen, al was het maar om te vermijden dat de uiteindelijke app meer knopjes heeft dan een vliegtuigcockpit. Zo namen we hierboven de vrouw als startpunt, maar eigenlijk spreekt de wet van werkneemster. Dat impliceert een geldig arbeidscontract. Dat kunnen we integreren met extra variabelen en voorwaarden, en zelfs met extra regels over arbeidscontracten, maar biedt dat ook meerwaarde? Het kan voldoende zijn om het zo te laten en in een disclaimer te zeggen dat de app enkel van toepassing is voor werkneemsters.

Wetgeving correct in code vertalen is dus niet eenvoudig, en vergt de nodige afwegingen. Het is daarbij nuttig om een nauwe samenwerking op te zetten tussen juristen, die de regels helder kunnen uitleggen, en de software-ontwikkelaars die dat in code moeten gieten, met of zonder RaC-framework. Daaruit komen ook nieuwe profielen voort met zowel juridische als technische vaardigheden: we zien stilaan “legal engineers” en “beleidsprogrammeurs” opduiken. 

Rules as Code frameworks

Het opzet van een Rules as Code framework is om wetten, regels, policies, … te hertalen in een gestructureerd formaat dat door een machine begrepen kan worden. Dit kan dan op zijn beurt direct geïntegreerd worden in applicaties of websites. Het idee is dat deze applicaties zo gemakkelijker kunnen aangepast worden aan snel evoluerende regelgeving, en dat ook gebruikers ervan door de directe link met de wetgeving op meer transparantie kunnen rekenen.

Er bestaan geen internationaal aanvaarde standaarden voor wetsanalyse, noch voor encodering van wettekst. Het Nederlandse voorbeeld hierboven is generiek toepasbaar, maar is nog een jong initiatief. Bestaande Rules as Code engines hanteren andere conventies, die sterk van elkaar kunnen verschillen. Ze definiëren meestal hun eigen encodering, in de vorm van een Domain-Specific Language of Controlled Natural Language, waarin de regelgeving eerst omgezet moet worden. Pas als die stap is gebeurd, kunnen er verder applicaties op worden gebouwd.

Het gebrek aan gestandaardiseerde formaten, modellen en ontologieën bemoeilijkt de adoptie van Rules as Code. Tussen de verschillende proof-of-concepts in verschillende landen, soms ook binnen hetzelfde land, is de interoperabiliteit nog steeds vrij laag. Ieder land of ieder departement dreigt zo een eigen taal, framework of methodiek te gaan hanteren, wat leidt tot fragmentatie en dubbel werk. Idealiter zou gestreefd moeten worden naar een gestandaardiseerd vocabularium, en regels gepubliceerd in een uniform formaat, zodat ze hergebruikt en uitgewisseld kunnen worden tussen verschillende systemen en overheidsdiensten.

Onder de bestaande Rules as Code frameworks van enige grootte vinden we OpenFisca, PubliCodes, Català en RegelSpraak. We houden met opzet wat afstand BPMN, CMMN, logische programmeertalen en klassieke rule engines, die niet toegespitst zijn op juridische teksten. In een volgend artikel gaan we verder in op de frameworks die wel specifiek gebouwd zijn voor wetgeving, waarbij we er eentje zullen kiezen om ons technisch in te verdiepen.

Tussentijdse conclusie

Rules as Code frameworks voorzien in een uniforme, generieke manier om aan wetsanalyse te doen. Voor programmeurs bieden ze een library met fundamentele bouwblokken om regelgeving te implementeren en testscenario’s op te zetten, ongeacht het domein waarin men actief is. Door de regelgeving te analyseren en om te zetten naar een domain-specific language, kan die door een rule engine of interpreter verwerkt worden. Belangrijk te noteren is dat deze omzetting vooralsnog minutieus analytisch mensenwerk vergt, omdat er interpretatie bij komt kijken. (Deze stap uitbesteden aan Large Language Models leidt niet tot onverdeeld positieve resultaten, maar daarover meer in een volgend artikel).

De mate van detail in veel regelgeving, maakt een analyse en omzetting naar een Rules as Code-formaat zelden een sinecure. Wil men tot een compleet en sluitend systeem komen dat rekening houdt met vele afhankelijkheden en uitzonderingssituaties, dan wordt men geconfronteerd met overdonderende hoeveelheden parameters en variabelen. Als berekeningen retroactief moeten kunnen zijn en ook de voorgeschiedenis van de wetgeving een rol speelt, komt daar nog een extra dimensie bij. De interne verwevenheden tussen alle regels maken dat men, om een Rules as Code-app van de grond te krijgen, al snel aankijkt tegen een grote initiële inspanning.

Eén van de argumenten voor Rules as Code is dat men bepaalde soorten apps generiek zou kunnen ontwikkelen voor eender welk domein: eligibility checkers, compliance tools, tax/benefit calculators, webformulieren, rekensimulatoren, dossierbeheer,… Zolang de onderliggende wetgeving maar duidelijk en concreet genoeg is, zou dan eenzelfde template-app zonder veel aanpassingen over de grenzen van overheidsdepartementen heen benut kunnen worden. Dit lovenswaardige idee stuit in de praktijk echter op moeilijkheden door de wetgeving zelf, die zichzelf haast heruitvindt in elk domein: zo kan je moeilijk gedeelde componenten ontwikkelen voor meerderjarigheid of motorvoertuigen als die termen verschillende definities hebben in verschillende wetten.

Een andere belofte van Rules as Code is dat apps ontwikkeld op basis van zulke frameworks een nauwe koppeling behouden met de wetgeving, die ook zichtbaar gemaakt kan worden. Deze koppeling moet transparantere garanties bieden dat een app wel degelijk conformeert aan de wetgeving, en dat dat ook zo blijft als die wetgeving morgen wijzigt. Daarnaast is er potentieel om te helpen bij het opstellen van regels. Een iteratief proces waarbij een RaC-versie van de regels wordt ontwikkeld in parallel met de ontwerpversie van de tekst, kan het mogelijk maken om vroegtijdig lacunes op te sporen en te verhelpen, of kan zelfs ex ante beleidsanalyse faciliteren door de impact van hypothetische wetswijzigingen eerst te simuleren (zie daarvoor ook het OESO-rapport). Maar ook hier komt men er niet onderuit dat de uitwerking daarvan, ook mét RaC-framework, dezelfde grote investeringen vergt.

Wie vreest dat computers het rechtssysteem binnenkort gaan overnemen kunnen we dus geruststellen, daar zijn we nog heel ver van weg. We herinneren ook nog even aan de GDPR, die in art.22 duidelijke grenzen stelt aan automatische besluitvorming. Daarnaast heeft een gecodeerde versie van een wet vooralsnog geen juridische status of rechtsgeldigheid – alleen de oorspronkelijke geschreven wettekst is bindend. Met andere woorden, zelfs al zetten we regelgeving om in code, is behoud van menselijk overzicht nog steeds een must, en heeft het Staatsblad nog steeds het laatste woord.

Wordt vervolgd!

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.