Tweede Kamer kan met 'digitale toets' beter vragen stellen over ict in wetgeving

Tweede Kamerleden die werken aan wetsvoorstellen kunnen daar in de toekomst een 'digitale toets' op loslaten. Dat is een reeks vragen waarmee beleidsmakers beter kunnen inschatten wat de mogelijke gevolgen zijn van hun wetten als die leunen op ict-systemen.

De Kamerleden Barbara Kathmann van GroenLinks-PvdA en Jesse Six Dijkstra van NSC hebben namens de Commissie Digitale Zaken in de Tweede Kamer de 'Digitale Toets' beschreven in een rapport. De toets bestaat uit tien vragen die bedoeld zijn om 'meer parlementaire grip op de digitale uitvoeringspraktijk van wetgeving' te krijgen. De toets wordt geen verplicht onderdeel van wetgeving, maar kan volgens de commissie helpen als een handvat wanneer politici wetten moeten maken waarbij 'de uitvoering sterk zal leunen op ict'. Dat zijn in de praktijk veel wetten: de commissie noemt onder andere 'wetsvoorstellen met rechten en plichten voor burgers waarover de overheid een besluit moet nemen'.

Bij het beoordelen van zulke wetten zouden beleidsmakers de volgende vragen moeten stellen:

  1. Hoe beoordelen de uitvoeringsorganisaties de kansen en risico’s van de digitale uitvoering van dit wetsvoorstel?
  2. Heeft bij de voorbereiding van het wetsvoorstel al een vertaling van wet naar beslisregels plaatsgevonden (dus naar als…dan-regels)? En is vervolgens de vertaling van deze beslisregels naar computercode getest?
  3. Is er in de wet- en regelgeving beoordelingsruimte overgelaten aan de uitvoerder (oftewel: kent de wet open normen)? Zo ja, is geborgd dat de vertaling naar beslisregels voor concrete situaties door uitvoeringsorganisaties transparant en herleidbaar is?
  4. Is duidelijk welke gegevens mogen worden gebruikt en is de kwaliteit van deze gegevens altijd in orde? Let bijvoorbeeld op risico’s bij hergebruik.
  5. Is de openbaarheid en toegankelijkheid van de code afgesproken? Hebben ambtenaren toegang tot de code en hebben zij voldoende begrip van de werking ervan?
  6. Is voorzien in niet-digitale contactmogelijkheden voor burgers met de overheid?
  7. Zijn risico’s in beeld voor (kwetsbare) burgers als digitale systemen falen (bijv. storingen of fouten
  8. Gaan er alarmbellen af op het juiste moment bij de juiste mensen wanneer de ict-systemen niet goed functioneren of onbedoelde uitkomsten genereren? Is er de mogelijkheid om fouten in het proces te herstellen, of om de ict-systemen los te laten zodat maatwerk geboden kan worden?
  9. Beschikken toezichthouders over voldoende toezichts- en handhavingsinstrumenten en capaciteit, over de benodigde ict-infrastructuur en voldoende technische kennis?
  10. Is vastgelegd wanneer de digitale uitvoering van de wet geëvalueerd wordt? En is duidelijk op basis waarvan?

De commissie keek in het rapport ook naar de digitale vaardigheden van de Tweede Kamer. Die zijn slecht: de Kamer 'heeft te weinig zicht op digitale wetsvertaling', stelt de commssie. "Om de digitale uitvoering van wetten mogelijk te maken, moet de menselijke taal van wetten omgezet worden naar gedetailleerde computercode (als…dan-regels, ofwel algoritmes)", schrijft de commissie. "In dat proces moeten soms ingrijpende keuzes worden gemaakt." De vertaalslag die de commissie beschrijft, wordt in de praktijk vaak niet door de beleidsmakers gemaakt, maar door de makers van de ict-systemen."

Door Tijs Hofmans

Nieuwscoördinator

05-07-2025 • 11:36

41

Submitter: wildhagen

Reacties (41)

41
41
20
1
0
20
Wijzig sortering

Sorteer op:

Weergave:

Nummer 5 had wel wat anders verwoord mogen worden. Nu is bij het gebruik van closed-source software het antwoord al snel "Nee" (wat prima is, als er geen alternatief is op dat moment), maar het draagt niet bij aan het kweken van begrip dat je uiteindelijk zeker moet weten dat de data die je met software verwerkt nog uit te lezen is met andere producten in de toekomst (om vendor lock-in te voorkomen). Was punt 5 anders geformuleerd als "wordt er gebruik gemaakt van open standaarden voor het opslaan van data zodat er in de toekomst ruimte over blijft naar een andere oplossing te migreren" dan dek je een en ander denk ik veel beter af.
Ik denk dat je niet goed begrijpt waar het om gaat. Het gaat daar niet om closed vs open source software of standaarden. Het gaat erom dat als een IT-systeem een beslissing neemt dat de verantwoordelijken moeten kunnen zien op basis van welke logica die beslissing wordt genomen. Dat maakt het gebruik van AI bijvoorbeeld lastig omdat je dan niet een uitdraai van de logica kunt maken. Maar je kunt best SQL in een proprietary database als Oracle of SQL Server gebruiken want daarvan kun je gewoon de code uitlezen en door een specialist laten controleren. Daarvoor hoef je niet de code van Oracle zelf te hebben want die voert gewoon jouw SQL code uit.
Dat neemt niet weg dat je geen idee hebt wat SQL Server uitspookt met je data. Een query is slechts een opdracht voor de database server die daar verder helemaal zijn eigen ding mee doet, maar als laatstgenoemde closed source is dan werk je in feite met een black box.

Gelukkig zijn er alternatieven in de vorm van PostgreSQL en MariaDB en als je netjes de ISO standaard van de SQL taal hanteert (dus zoveel mogelijk de verschillende dialecten negeert) dan kan je vrij makkelijk overstappen.
Dat is niet waar. SQL Server, net als elke andere database, spookt niets met jouw data uit. Je geeft zelf de opdrachten en een database doet niets waarvoor jij niet zelf de opdracht hebt gegeven. Dus als jij maar weet wat je doet, en goede SQL scripts maakt, dan weet je prima wat SQL Server met jouw data "uitspookt".
SQL Server is closed source dus strict genomen doe je hier slechts aannames.
Het gaat bij puntje 5 over het feit of er afspraken zijn. Puntje 5 legt niets op qua open source noch closed source. Het enige wat er staat is dat je jezelf de vraag moet stellen of er afspraken werden gemaakt rond de openbaarheid en toegankelijkheid.

De kernvraag bij de ontwikkeling is dus: “zijn er afspraken gemaakt” en niet “is de code openbaar en toegankelijk”.
Ik doe geen aannames. Dat kun je gewoon testen. Installeer SQL Server, maak een database, vul die met data, doe verder niets, wacht een jaar, en controleer dan de data. Ik kan je garanderen dat er niets aan de data is gewijzigd. Geen bit.
Dat kan, maar weet je ook zeker dat je data niet verstuurd is naar een monitoring server? Je reageerde eerder dat iemand niet begrijpt waar het over gaat, maar dat is hier van toepassing op jou.

Pak als ander voorbeeld een restaurant. Als jij een gerecht besteld, bijvoorbeeld een medium-rare biefstuk, dan ga je ervan uit dat de kok ook dat oplevert, maar helemaal zeker weten doe je dat niet want je kan niet zien wat de chef doet.
Bij de bedrijven waar ik gewerkt heb kon een database server helemaal geen connecties naar het internet maken. Dat is namelijk de enige manier om het zeker te weten.

En als ik een medium rare biefstuk bestel dan weet ik zeker dat de kok dat ook levert. Ik ga immers testen en als ie wat anders levert dan proef ik dat. Proef ik het niet, dan is het ook onzin om medium-rare te bestellen, want blijkbaar kan ik het verschil niet eens proeven. En laat een database server nou bij uitstek een systeem zijn waarvan je kunt testen of de output wel klopt.
Maar heeft hij er op gespuugd? Komt de saus uit een pakje? Met een keuken achter een deur (closed-source) ga je er maar van uit van niet.

Bij een open keuken (open source), kun je zelf zien controleren hoe het gemaakt wordt.

De ene is niet per se dan de ander, maar het is een mogelijkheid die open source echt biedt over closed source.
maar weet je ook zeker dat je data niet verstuurd is naar een monitoring server?
Ja. Waarom zou een database internet toegang moeten hebben? Dat zit gewoon in een apart VPC/VNET/Subnet. Dat is DB security 101
bijvoorbeeld een medium-rare biefstuk, dan ga je ervan uit dat de kok ook dat oplevert, maar helemaal zeker weten doe je dat niet want je kan niet zien wat de chef doet.
Ik kan dat toch direct controleren?

En als ik echt een pannekoek wil zijn kan dat zelfs met mijn prikthermometer.
Het gaat natuurlijk niet om je databases maar om wat er verder nog met die data gebeurt. SQL Sever doet bijv best een boel monitoring en stuurt nogal wat telemetrie naar MS. Het gaat erom dat je een closed source applicatie niet kunt checken omdat je simpelweg niet weet wat de software allemaal uitvreet. Gezien de huidige mondiale ontwikkelingen juich ik het wel toe als met name overheden daar wat kritischer mee omgaan.

SQL Server doet in de kern wat elke database server behoort te doen maar het gaat om al die andere dingen die je dus niet of niet goed kunt controleren.
Het is wel subtieler dan dat: je kunt niet controleren of iedere query dat doet wat de specificatie voorschrijft. Een voorbeeld van een ander systeem (c compiler) met een speciale mode die bij bepaalde invoer net iets anders deed.

In het algemeen: met testen kunnen hooguit aantonen dat het systeem bij een bepaalde invoer reageert zoals verwacht. Maar je kunt dit niet voor alle invoer doen. Het is wat theoretisch en niet waarschijnlijk maar zeker geen absolute waarheid.
Aannames? Dit wordt toch gewoon door iedereen getest? Iedere integratietest of black box test wijst dit uit. Wordt er met de data geknoeid (of dat nu met opzet is of niet) dan zie je dat direct.
Ik denk dat dat wel 2 hele verschillende dingen zijn. Mijns inziens gaat punt 5 vooral over de eigen code die voor een toepassing wordt gemaakt. Niet over of alle onderdelen van die toepassing volledig inzichtbaar zijn. Dat je dus niet de broncode van Windows, Android, .NET of iets anders nodig hebt om te weten of je dat mag gebruiken. Maar de .NET applicatie moet dan wel helemaal inzichtelijk zijn bv om te garanderen dat er dus volledige controle is.

Dat staat los van de open standaarden waar de tool wel of niet mee kan werken.

Verder heb je bij jouw vraagstelling weer dat een heleboel framework agnostisch wordt gemaakt terwijl dat vaak zo'n enorme overhead toevoegt en alles onnodig complex maakt, waardoor je vaak nog veel meer budget erdoorheen schiet. De vraagstelling kan beter, maar ik denk wel dat het handig is om zaken uit elkaar te houden over de code en de communicatie tussen code. Verder kun je je afvragen in welke mate vendor lock-in te voorkomen is. Is het draaien op AWS al vendor lock-in of niet? Is code hosten op github en daar github actions gebruiken al vendor lock-in? Ook als hetgeen je daar hebt staan nog wel over te bouwen is naar een ander platform, ware het niet direct maar wel binnen een maand oid? Wat is hierbij redelijkheid?
nieuws: Rechter: Broadcom moet VMware voorlopig ondersteunen voor Rijkswaterstaat

Hier moest de overheid naar de rechter om voor elkaar te krijgen dat ze genoeg tijd krijgen om te migreren, en hierbij gaat het waarschijnlijk nog om redelijke standaard bestanden (VHDs en/of ISOs) die je met elke andere visualisatiesoftware kunt draaien zonder aanpassingen.

Kan je nagaan hoeveel werk er in zit als de overheid moet migreren van Oracle naar SAP (ik noem maar wat) om wat voor reden dan ook, dat is vrijwel onmogelijk. In zo een geval zou je misschien op voorhand dus toch liever willen kiezen voor een oplossing met open standaarden of desnoods zelf iets schrijven ook al zijn de opstartkosten daarvan iets hoger.
2 is een beetje vreemd in die zin dat bij nieuwbouw van software vooraf al code getest moet zijn, zo interpreteer ik het in ieder geval.

8 is in die zin vaag dat er alarmbellen af moeten gaan als er functionele fouten optreden. In de praktijk zullen dit vaak bugs of onvoldoende gespecificeerde functies zijn. Dat moet in een proces geregeld zijn, in techniek wordt dat lastig.
De code hoeft niet per se getest te zijn, alleen dat de beslisregels om te zetten zijn naar code. Je moet dus iets opzetten om je regels te kunnen vertalen en dat moet getest zijn. Zo lees ik het.

8 zegt volgens mij vooral dat er gemonitord moet worden en dat er ergens een melding wordt gemaakt.
Ik vind de regels vrij basaal en ik kan me bijna niet voorstellen dat een groot gedeelte al niet "getoetst" werd voordat deze er was. Dit zijn bijna standaard projectmanagement vragen met een accent op digitaal/ICT.
Ik vind de regels vrij basaal en ik kan me bijna niet voorstellen dat een groot gedeelte al niet "getoetst" werd voordat deze er was. Dit zijn bijna standaard projectmanagement vragen met een accent op digitaal/ICT.
Zo werkt dat nu eenmaal. Leden van de Tweede Kamer zijn over het algemeen geen (IT-)specialisten. Die hebben veel hulp nodig bij alles.

Dat het bijna standaardvragen zijn is ook normaal, juist omdat het standaardvragen zijn moeten ze op dit lijstje. Het doel is te controleren of de basis op orde is, de zaken waar iedereen altijd aan zou moeten denken.
Er zit wat mij betreft geen enkele logica in je redenering.

Je vertrouwt de IT-aannemer (of wie dan ook) niet maar stelt een vragenlijst op zonder kennis om deze te controleren.

Hoe gaat dat functioneren?
Ik denk dat “toets” een ongelukkige benaming is wat ons terugbrengt naar de basisschool. Als je de meedenkt met deze vragen, is het een checklist wat je op bepaalde momenten op een investering, aanbesteding, projectplan/mijlpaal of wisseling van (minister)post kan gooien.

Het lijkt mij ook ern lijstje triggers voor een IT leek om te Googlen. Snap je de vragen redelijk? Begrijp je je eigen antwoorden? Dan is de kans groot dat het onderwerp degelijk wordt “getoetst”. En zo is mijn cirkel rond.
Ik denk dat bepaalde zaken al wel worden gedaan, maar een heleboel komt pas aan de beurt zodra het project is gestart, verwacht ik en andere zaken wordt wellicht wat te makkelijk over gedacht. Ze willen nu toch wat meer detail zien, waardoor de kans op slagen en binnen budget blijven, vast wat beter voor elkaar zal zijn.

De vraag is vooral hoeveel tijd dit proces gaat innemen en hoeveel het elke keer gaat kosten. Maar het is daarnaast voor de partijen die de projecten moeten gaan uitvoeren wel handig om dit soort dingen al uitgezocht te hebben.
Als ik zo lees, is dit een zeer grote stap vooruit, natuurlijk niet perfect (valt over te discussiëren).

In plaatsen van doodleuk iets opstellen en dan de uitvoering ervan zeer beneden niveau is, hier wordt duidelijk aangeven is het uitvoerbaar? In de zin vanuit technisch oogpunt. Daarom vind ik dit een zeer grote stap vooruit, nu nog hopelijk dat dit niet een ondergeschoven kindje wordt en paar dagen later allemaal in de stoffige ijskast wordt gezet.

Aub Iets minder agile, meer xp programming.
Ik lees het meer als een copy/paste wat er al gebeurt en op 60% waar het nu verplicht wordt, overbodig zal blijken en onnodig, laat staan relevant.


1 nvt

2 nvt

3 nvt

Etc.

Maar zeker, voor de missers (0,2%) timmer je zeker iets dicht. Ik vrees dat desinteresse bij het zitten in een ambtenaarszetel het doel van toetsen weinig uit zal halen.
Lijken mij wel meer dan 10 vragen.
Ik tel er ook ongeveer 15.
Och, dat geldt ook voor de 10 geboden :P
Of je kan iemand met kennis op die positie zetten?

Maar dat vind ik ook dat dit moet op andere posities.
'Op die positie'? In de kamer zitten 150 gekozen leden. Niemand 'zet' daar dus iemand, anders dan de kiezer.
Of de opdracht niet op die plek gooien. ‘Ja maar die moet ervoor tekenen’, Prima, geef die de cliffnotes van een al “getoetst” product of dienst. Zo gaat dat bij een normale contractmanagement, ik zie de waarde van het toetsen door een leek bij een getoetst dienst of product niet…

Kennen we de Corona-app succesjes nog :)?
Goed plan, zo goed als alle uitvoering gebeurt in ICT systemen. Zo flexibel als deze zijn is er nog steeds tijd aandacht en prioriteit nodig om dit goed te kunnen doen. Deze mogelijkheid zal hopelijk iets meer inzicht geven aan de besluitvormers bij het vaststellen van wijzigingen
Heeft bij de voorbereiding van het wetsvoorstel al een vertaling van wet naar beslisregels plaatsgevonden (dus naar als…dan-regels)? En is vervolgens de vertaling van deze beslisregels naar computercode getest?
Getest is wat anders dan beoordeeld. "Beoordeeld" zou ik interpreteren dat een functioneel analyst of technisch consultant heeft gekeken of er geen gaten in de logica is en de juiste data beschikbaar is als input. "Getest" klinkt voor mij als een proof-of-concept implementatie. Dat laatste zou elk wetvoorstel al duur maken om te maken.

[Reactie gewijzigd door Sebazzz op 5 juli 2025 11:57]

En dan hebben ze het lijstje doorgenomen waarna de lobbyisten langskomen en de desbetreffende minister met "goede" reden ompraat zodat de software van hun bedrijf aangekocht word.

In de Nederlandse regering zijn logica en logische besluitvorming niet altijd hetzelfde. Vooral door de lobbyisten uit het bedrijfsleven.

Niet dat ik zeg dat de mensen in de 2e kamer omgekocht worden (al kan ik niet, met hand op mijn hart, zeggen dat ik niet denk dat elke politici niet omgekocht kan worden of al omgekocht is.)
ICT is een vakgebied. Net als de bouw, de gezondheidszorg en defensie. Daar heb je experts voor nodig, vakmensen die weten hoe de hazen lopen, wat er wel kan, wat het echt kost en die ook gewoon "nee" moeten zeggen. Nu verzand het in een circus van consultants, lobbyisten, partij- en vriendjespolitiek, ambtenaren en vooral geen verantwoording nemen als een wet rampzalig uitpakt.

Die digitale toets is puur zo'n model zoals er al zoveel ICT plan modellen zijn. Met zo'n model kan men nog de grootste onzin "automatiseren" wat eigenlijk een organisatorisch probleem is. Helemaal met de gevleugelde kreet dat AI alles wel oplost. Dan is het niet meer het probleem van de Tweede Kamer.
elk "vakgebied" heeft zo zijn lobbygroepen, consultants en vriendjespolitiek. Het is allemaal zo ingewikkeld dat de politici er in de meeste gevallen zelf amper iets van snappen, want die praten elkaar maar na en naar de mond van de stemmers op het moment dat het er voor henzelf toe doet.
Als ik het goed lees laat dit geheel alsnog toe om hele systemen op te tuigen op basis van Amerikaanse clouddiensten. Dit lijkt me nou net een goed moment om dat ook nog even af te hechten. Waar draait de software, en van wiens humeur is de beschikbaarheid afhankelijk? Of valt dat in voldoende mate onder punt 5?

[Reactie gewijzigd door doltishDuke op 5 juli 2025 14:12]

Op dit item kan niet meer gereageerd worden.