Om dit te illustreren, baseren we ons op de dataset “urgences data”, beschikbaar op Kaggle.
 Het betreft een CSV-bestand van ~430 MB, bestaande uit 336.253 rijen en 39 kolommen, zonder bijbehorende metadata. Elke rij komt overeen met een bezoek van een patiënt aan de spoeddienst van een (niet nader genoemd) ziekenhuis in Noord-Frankrijk, tussen 6 januari 2016 en 6 december 2020. Het bevat een schat aan informatie: datum en tijdstip van aankomst en vertrek, vervoermiddel, oorzaak, leeftijd, een aantal medische parameters, zoals hartslag, bloeddruk, temperatuur, zuurstofsaturatie, evenals booleaanse waarden die lijken aan te geven of aanvullende onderzoeken zijn voorgeschreven (bloedonderzoek, röntgenfoto, echografie, CT-scan, MRI…)

We gaan gebruikmaken van “Data Analyst”, een van de “GPT’s” die in ChatGPT worden aangeboden. Aangezien de gratis versie beperkt is tot een zeer klein aantal vragen, hebben we een betaalde versie (“Personal Plus”) gebruikt. Voor deze oefening hebben we in het Engels gecommuniceerd, maar vergelijkbare resultaten zouden waarschijnlijk ook in het Frans of Nederlands zijn verkregen.

Voorafgaande analyse

Een eerste stap kan bestaan uit het simpelweg indienen van het te analyseren bestand bij “Data Analyst” en hem te vragen wat hij daarin kan vinden. Meer formeel levert een vraag als “What useful insight can you extract from those data?” ons het onderstaande resultaat op.

We verkrijgen een resultaat dat een structuur volgt die in bijna alle antwoorden terug te vinden is:

1. Een reeks grafieken. Hier zien we een leeftijdsverdeling van de patiënten, de gemiddelde verdeling per tijdstip van de dag, evenals de verdeling van de bestemming (terug naar huis, interne overplaatsing…). Merk op dat ChatGPT, zonder dat wij daar iets over hebben gezegd, begrepen heeft dat het om patiënten van een spoeddienst ging;
2. Een gestructureerde tekstanalyse van wat het uit de gegevens heeft kunnen opmaken. De demografische gegevens van de patiënten, de piekuren, waar de patiënten na vertrek naartoe gaan en hoe ze zijn aangekomen;
3. Strategische voorstellen;
4. Voorstellen voor de volgende stappen. “If you’d like, I can next:”, gevolgd door een reeks relevante prompts om de analyse voort te zetten (die je helaas moet kopiëren en plakken).

Bovendien eindigt de tekst altijd met een link “</>”, die niet voorkomt in een “standaard” ChatGPT-chat en waarop je kan klikken om de Python-code te verkrijgen waarop deze analyse is gebaseerd. Deze code, die is gemaakt met behulp van de Python-library “Pandas” (een van de meest gebruikte open-source tools voor data-analyse en data science), maakt het mogelijk om de voorgestelde grafieken te genereren, evenals alle cijfers die in de beschrijvingen worden gebruikt. Het is dus volkomen mogelijk om deze code niet alleen direct te gebruiken, maar ook om er zeker van te zijn dat de cijfers niet volledig verzonnen zijn, maar gebaseerd zijn op algemene statistische modellen en zorgvuldig berekend zijn op basis van de verstrekte gegevens.

Zo konden we met één enkele zin en na amper een minuut wachten drie grafieken, Python-code en een beschrijvende tekst verkrijgen, waar een data scientist normaal gesproken meerdere uren over zou hebben gedaan. Dit is natuurlijk een zeer beknopte eerste benadering. Maar we kunnen nog verder gaan.

We kunnen bijvoorbeeld vragen naar een statistische beschrijving voor elke kolom. Het resultaat is hier een lange, zeer gestructureerde beschrijving, per type variabele (numeriek of categorisch), met een reeks indicatoren: gemiddelde, minimum/maximum, aantal ontbrekende waarden… evenals een opmerking (“Not usable for analysis”, “Vital signs moderately complete”, “Excellent for resource utilization analysis”, “Likely categorical indicator”…). De tool biedt ons ook enkele opmerkingen met betrekking tot de kwaliteit van de gegevens (bijvoorbeeld: “Outliers: Age max = 218 (likely error)”).

Op dezelfde manier kunnen we een “EDA” (Exploratory Data Analysis) aanvragen, die een vergelijkbare analyse oplevert, die deels overlapt maar ook andere aspecten behandelt.

Met dit soort “prompt” hebben we dus binnen enkele minuten een eerste gedetailleerd, cijfermatig maar duidelijk en begrijpelijk overzicht van een redelijk omvangrijke dataset. ChatGPT begrijpt, of gedraagt zich in ieder geval alsof het de inhoud van de gegevens begrijpt:

• De tool berekent een “length of stay” en interpreteert dus duidelijk twee kolommen (DH_arrivee en DH_sortie). Er is echter een klein probleempje: in de gegevens bevat het aankomsttijdstip een datum en een uur, maar de “DH_sortie” bevat alleen de datum (met 00:00 als uur), waardoor de berekening weinig relevant is, vooral voor korte verblijven. Maar als we hem vragen hoe hij deze “length of stay” heeft berekend, wijst hij op het probleem;
• Hij ‘begrijpt’ dat de kolom ‘Code_CCMU’ (met de codes 1, 2, 3, 4, 5, P of D) verwijst naar de Franse nomenclatuur van de ‘Classification Clinique des Malades aux Urgences’ en de ernst aangeeft. Hij stelt voor om een “severity analysis (CCMU code distribution)” uit te voeren, waarin hij de codes correct interpreteert;
• Hij komt met voorstellen die weliswaar enigszins naïef zijn, maar relevant in deze context. Hier volgen twee voorbeelden:

Analyse per categorie

Bij het bekijken van de gegevens viel ons op dat er twee kolommen zijn die betrekking hebben op de reden van opname van de patiënt: een kolom “motif_entree”, die zeer weinig gestructureerd is ( “Trauma cheville G”, “A avalé une LED avec une pile”…) en een andere “semi-gestructureerde” kolom: “Cardiologie: Douleur thoracique atypique”, “Pneumologie: Dyspnée sans détresse”, “Toxicologie: Alcoolisation/Ivresse aigue”… Het zou interessant zijn om bepaalde elementen te kunnen analyseren op basis van een “categorie”: “Cardiologie”, “Pneumologie”, “Toxicologie”…

We kunnen ChatGPT eenvoudigweg vragen “extract categories from motif_venue”, zonder het enige informatie te geven over hoe dit moet gebeuren. Als antwoord krijgen we dan een overzicht van deze nieuwe attributen, met uitleg over hoe dit tot stand is gekomen, evenals enkele relevante opmerkingen over de kwaliteit van de gegevens:

Een vraag die dan natuurlijk in ons opkomt, is hoe deze zich in de loop van de tijd gedragen. We kunnen ons bijvoorbeeld voorstellen dat longproblemen vooral in de winter voorkomen, in de periode waarin griep en andere virussen heersen. Maar hoe zit het met de andere aandoeningen?

Laten we ChatGPT vragen: “Plot occurrence line charts grouped by cleansed categories, for the top 10“. We krijgen dan de grafiek tegenover deze tekst te zien, samen met een reeks opmerkingen. Men kan verrast zijn door de duizelingwekkende daling van de cijfers, over alle categorieën heen, die zich begin 2020 voordeed. Maar iedereen die in deze periode niet onder een steen heeft geleefd, zal de reden hiervoor snel hebben begrepen… wat ChatGPT ook niet is ontgaan, zoals blijkt uit een van zijn opmerkingen:

“The sharp drop in early 2020 is visible across all categories — a clear COVID shock to ED visit“

Om seizoensgebonden trends te verkrijgen, kunnen we vragen om de drie jaren waarvoor we volledige gegevens hebben bij elkaar op te tellen en de gegevens af te vlakken, waarbij we uitgaan van een voortschrijdend gemiddelde over 7 dagen: “For the top 10 cleansed categories, plot the number of visits per date in year (summing up values for 2017, 2018 and 2019, excluding 2016 and 2020), with a moving average of 7 days“.

Na wat vallen en opstaan met prompts om de grafieklegende weer te geven of diverse aspecten aan te passen, verkrijgen we het volgende resultaat:

Zoals verwacht merken we dat longziekten (in het bruin) in de winter vaker voorkomen dan in de zomer, maar wat verrassend is, is die enorme piek in de stomatologie helemaal aan het einde van het jaar. Nadat we ons ervan hadden verzekerd dat de piek zich inderdaad elk jaar voordeed, met enkele uitschieters die we hier buiten beschouwing laten, stelden we de vraag: “how to explain the peak of total visits for stomatology for the last week?”.We waren duidelijk onder de indruk van de relevantie van het antwoord.

Twee verklaringen, die ChatGPT niet in de dataset heeft kunnen vinden, maar alleen door een verband te leggen met zijn “algemene kennis”, lijken ons zeer aannemelijk:

• Tandartspraktijken zijn tijdens de feestdagen grotendeels gesloten (of meer in het algemeen tijdens de vakantie, gezien de twee kleinere pieken);
• Veel mensen willen hun vergoedingsmogelijkheden vóór het einde van het jaar ‘volledig benutten’.

Het spreekt voor zich dat nader onderzoek nodig is alvorens hieruit operationele beslissingen te trekken, maar we hebben hier al tegen zeer lage kosten een reeks hypothesen om te onderzoeken.

Beperkingen

Hoewel een eerste overzicht indrukwekkend kan lijken, is voorzichtigheid geboden. Het is duidelijk dat een dergelijk hulpmiddel een waardevolle bondgenoot kan zijn voor een data scientist, en zelfs professionals met beperkte technische vaardigheden in staat kan stellen toegang te krijgen tot een eerste analyse. Hier volgen enkele aandachtspunten uit onze ervaring met deze dataset.

• Je wordt geen “data scientist” alleen omdat je mooie grafieken kunt maken of cijfers kunt leveren. Je moet ze ook kunnen interpreteren en ervoor zorgen dat je niet in een van de vele valkuilen van de statistiek trapt;
• In ons voorbeeld hebben we onze volledige dataset naar ChatGPT gestuurd. We hebben geen enkele controle over wat ermee gebeurt. In dit geval ging het om openbare gegevens, maar hoe zit het met vertrouwelijke gegevens? Het is altijd mogelijk om een LLM on-premise te installeren, maar de kosten zijn aanzienlijk hoger en de prestaties lager;
• We hebben slechts één voorbeeld met één tabel getest. De literatuur lijkt aan te geven dat dit ook geldt voor een complexere database, maar we zullen dit nog moeten uitproberen;
• De modus “vraag-antwoord” maakt alleen een lange, lineaire dialoog mogelijk. Al snel ontstaat er een lange, zeer rommelige discussie, met meerdere pogingen om de tool duidelijk te maken wat we willen. Als we bijvoorbeeld een criterium willen aanpassen voorafgaand aan een reeds uitgevoerde analyse (bijvoorbeeld door deze te beperken tot een bepaalde periode of bepaalde soorten gegevens te verwijderen), kunnen we niet teruggaan. Je moet dan een nieuwe chat starten of alle vragen opnieuw stellen;
• In dezelfde lijn: als de invoergegevens worden bijgewerkt, moet het hele gesprek opnieuw worden gevoerd;
• Naast het weinig gestructureerde karakter valt ook een gebrek aan consistentie op:
  • Bij het extraheren van de “categorie” hebben we gevraagd om, naast de scheiding op basis van de “:”, ook bepaalde kwaliteitsproblemen te corrigeren (bijvoorbeeld door “Cardiovasculaire” te vervangen door “Cardiologie” of “Intoxications” door “Toxicologie”). De vragen die kort na deze opschoning volgden, hielden rekening met de meest uitgebreide versie. Maar enkele dagen later, toen we het hadden over “cleansed categories”, hield ChatGPT het bij splitsen op basis van de “:”,
  • We hebben precies dezelfde vraag met een onderbreking van een maand gesteld. De numerieke waarden in het antwoord bleven consistent, maar de tekst was qua vorm radicaal anders (hoewel qua inhoud vergelijkbaar);
• De Python-code die bij elke vraag wordt voorgesteld, wordt daadwerkelijk uitgevoerd op de servers van ChatGPT, dat het resultaat gebruikt om zijn antwoord te genereren. Maar de beschikbare uitvoeringstijd is vrij beperkt. Het trainen van een eenvoudig machine learning-model (bijvoorbeeld “Compute feature importance using Random Forest, with ‘scanner’ as target”) leidt vaak tot een time-out. ChatGPT doet dan echter een reeks voorstellen om de benodigde rekentijd te verminderen (stratificatie, vermindering van het aantal bomen, vermindering van de cardinaliteit van bepaalde variabelen…).

Een relevante aanpak zou waarschijnlijk zijn om ChatGPT of een van zijn concurrenten te gebruiken om de gegevens te verkennen, snel afwijkingen of kwaliteitsproblemen te identificeren, mogelijke benaderingen te vinden, geschikte voorspellingsmodellen te selecteren… Je zou ook kunnen vragen om grafieken, tabellen en cijfers te genereren… Vervolgens kunnen de voorgestelde stukjes code worden opgehaald en geïntegreerd in een script of een geconsolideerd notebook. Merk op dat er ook kan worden geïnterageerd met de API’s van ChatGPT en anderen, zoals Gemini. We zullen deze aanpak in een volgend artikel bespreken.

Als we naar de toekomst kijken, zijn we niet bang dat GenAI data scientists zal vervangen. Het is duidelijk dat de onvermijdelijke toename van steeds grotere en complexere datavolumes de behoefte aan personeel dat deze analyse kan uitvoeren alleen maar zal vergroten. Maar GenAI zal hun beroep ongetwijfeld veranderen. En GenAI zal zeker de data scientists die het niet gebruiken, vervangen door data scientists die er effectief mee kunnen omgaan.

Digital Twin verschijnt echter pas als onderwerp op de radar van Gartner eind 2016. Ook de Wikipedia-pagina over het onderwerp is een relatief recent gegeven, aangemaakt in 2015, veel later dan die over Virtual Reality (2001) en Internet of Things (2007). Het idee van Digital Twins werd echter snel populair, daarbij geholpen door het Europese Horizon-2020 programma dat er brood in zag en verschillende projecten rond het thema financierde voor miljoenen euro’s ([1], [2], [3], [4]). Alvast in Vlaanderen heeft men die kans gretig gegrepen, met IMEC in een centrale rol, bijgestaan door een enthousiast Digitaal Vlaanderen, en ook VITO is overtuigd.

Marketinggewijs heeft de Digital Twin zijn waarde dus alvast bewezen. Maar kan het een concrete meerwaarde zijn voor publieke administraties? Ook daar worden workflows snel complex, kunnen wijzigingen duur zijn, en wil men misschien éen en ander kunnen simuleren alvorens het effectief te implementeren. In dit artikel onderzoeken we wat de Digital Twin kan betekenen in een administratieve context.

Definities

Er bestaan nogal wat verschillende interpretaties van Digital Twin. De essentie is alleszins niet nieuw: een systeem wordt digitaal weergegeven zodat het kan worden geobserveerd, getest en verbeterd zonder de daadwerkelijke werking direct aan te tasten. Het belangrijkste onderscheidende kenmerk is de continue (of in ieder geval regelmatige) synchronisatie tussen het reële systeem (de ‘doelentiteit’ of ‘target entity’), en zijn digitale tegenhanger. De EU JRC hanteert een maturiteitsmodel dat verschillende niveau’s van integratie onderscheidt; enkel in het geval van tweerichtings-datauitwisseling tussen target en twin wordt echt van een twin gesproken. Op internationaal vlak worden pogingen ondernomen tot standaardisering van terminologie.

Om nuttig te kunnen zijn moet een Digital Twin uitgewerkt zijn in voldoende detail. Al naargelang de toepassing zal het niveau van granulariteit of resolutie variëren. De twin moet de doelentiteit gedurende diens volledige life cycle getrouw kunnen weergeven, maar dat betekent niet dat elk detail tot in de puntjes gesimuleerd moet zijn. In de medische sector zien we digital twins opduiken op het niveau van de cel, van het orgaan, van een persoon of van de populatie. Niets belet ook dat een Digital Twin slechts een onderdeeltje vormt van een groter systeem – het kan bijvoorbeeld alleen maar uitgewerkt zijn voor 1 kritische component.

We kunnen twee stromingen van Digital Twins onderscheiden:

• Hoogwaardige technologische twins (luchtvaart, industrie, infrastructuur), waarbij de twin wordt gebruikt voor diagnostiek, voorspellend onderhoud of iteratief ontwerp op basis van operationele gegevens – bij NASA, voor elektriciteitsdistributie, …
• Informatiesysteem- of socio-technische twins (steden, organisaties, dienstverlening), waarbij de doelentiteit niet zozeer een machine is maar eerder een complex systeem met meerdere belanghebbenden, bestaande uit processen, regels, mensen en gegevensstromen. Deze tweede stroom is waar de publieke sector in past, maar het is ook waar de definities vaag worden en Digital Twin soms wordt gebruikt als marketingterm voor ‘dashboard+model’.

Waar beleidsmatig enige vaagheid misschien onvermijdelijk is, willen we in de praktijk toch een meer operationele interpretatie. We zouden een administratieve digital twin kunnen definiëren als: een continu geüpdatete, testbare, digitale representatie van de realiteit van de dienstverlening. Dit omvat processen, dossiers en de status waarin die zich bevinden, een uitvoerbaar systeem van de regels die van toepassing zijn, en alle dataverkeer dat nodig is om het geheel te doen werken. Dat moet toelaten de huidige realiteit van nabij te monitoren, en eventuele wijzigingen vooraf te simuleren voordat ze worden toegepast.

Voor een industrieel proces gedreven door sensordata en de onveranderlijke wetten van de fysica, ligt dat gemakkelijker dan voor het overheidswezen, waar men vaak gevoelige gegevens verwerkt en afhangt van regelmatig wijzigende regels die ruimte laten voor interpretatie (zie ook onze eerder gepubliceerde artikels over Rules As Code). Bezorgdheden rond data governance (GDPR etc.) kunnen het moeilijk maken om synchronisatie met real-time gegevens op te zetten. Beslissingslogica is vaak nauw verweven met de code van applicaties, wat aanpassingen en compliance checking bemoeilijkt. Het is daarom vaak al een hele prestatie als men in overheidscontext tot een Digital Shadow komt, die we ergens kunnen situeren tussen een “dom” model en een echte gesynchroniseerde twin.

Toonaangevende projecten

In Europa gaan de opvallendste Digital Twin projecten overwegend over klimaat en wetenschap:

• Destination Earth of DestinE combineert grootschalige gegevens van (weer)satellieten en Copernicus in een data lake. Op basis daarvan zagen 2 Digital Twins het licht: Climate Change Adaptation (langetermijn) en Weather-induced Extremes (kortetermijn). Daarvoor ontwikkelden ze hun eigen Digital Twin Engine. Het project wordt voortgezet, waarbij men gemakkelijker “downstream applicaties” van externe gebruikers wil faciliteren die deelaspecten of specifieke onderzoeksvragen verder kunnen uitdiepen. Dat alles moet gedeeld worden via 1 platform gecoördineerd door ESA.
• Het EDITO project probeert gelijkaardige doelstellingen te bereiken maar dan voor oceanen. Hiervoor wordt data van EMODnet en Copernicus samengebracht. Toegang verloopt via een Datalab dat ook een reeks andere bouwblokken en services aanbiedt, en de applicaties die erop gebouwd worden kunnen een plaats krijgen op het digitaal platform van het initiatief.
• Verschillende use cases worden ook opgelijst in het kader van het recent afgelopen (en Europees gefinancierde) interTwin onderzoeksproject, dat een enigszins gestandaardiseerde architectuur met herbruikbare componenten voor Digital Twins trachtte ontwikkelen. Zij benaderden het onderwerp eerder vanuit de wereld van het CERN, en onafhankelijk van de twee eerder vermelde initiatieven. Onderweg leerden ze wel van elkaars bestaan en werd een mogelijke interoperabiliteit met het ESA-gelinkte DestinE alvast onderzocht.

In een administratieve context hebben we minder boodschap aan gegevens van satellieten of deeltjesversnellers. Omwille van de governance-vereisten komt de nadruk veeleer te liggen op correcte interoperabiliteit en data-uitwisseling, conform alle geldende wettelijke kaders. In dat opzicht zijn de nuttigste Europese initiatieven misschien nog de Data Spaces – voor een “policy twin” bijvoorbeeld de Legal Data Space. Er zijn ook raakvlakken met het idee van Regulatory Sandboxes zoals dat opduikt in o.a. de Interoperable Europe Act of recenter de AI Act: een administratieve digital twin kan de rol van zo’n sandbox vervullen als er goede mechanismen voor scenario-ontwikkeling en -evaluatie zijn.

Administratieve Use Cases

Voordat we zelf aan de slag zouden gaan in complexe sectoren zoals gezondheidszorg en sociale zekerheid, moeten we ons toch afvragen of Digital Twins echt iets kunnen toevoegen aan wat vandaag al bestaat – want hype op zich draagt niets bij.

Inzake policy modeling voor sociale zekerheid, is er bijvoorbeeld al een sterke basis met het EUROMOD microsimulatie model, waarvan de Belgische variant BELMOD heet. Dit zijn statische microsimulaties waarbij gegevens op fijnmazig niveau worden gecombineerd met gecodeerde regels zodat het mogelijk wordt om hervormingen aan de parameters van de sociale zekerheid te simuleren (bijdragen, uitkeringen, etc.). Zulke studies worden typisch uitgevoerd aan universiteiten, men kan een idee krijgen van wat dat inhoudt via EUROMOD Online.

In zekere zin komt dit type model al in de buurt van een digital twin voor sociaal beleid, maar het mist nog twee cruciale lagen:

• actuele/live koppelingen met administratieve gegevens: hiermee kan men dan budgettaire en verdelingseffecten simuleren op de situatie van vandaag, in plaats van op verouderde data van enkele jaren geleden.
• procesinformatie over de dienstverlening (doorlooptijden van dossiers, behandelingscapaciteit etc): dit zou toelaten ook de operationele impact van hervormingen in te schatten op de uitvoerende diensten.

Het zou allerminst eenvoudig zijn om dat toe te voegen: de gegevens in kwestie zijn zeer gevoelig van aard. De echte data gebruiken als real-time databron voor simulaties zou al zeker verregaande anonymisering vereisen (voortvloeiend uit de GDPR), naast een resem andere veiligheidsmaatregelen. Dat is een complexe oefening op zich, waarbij mogelijk ook nuttige informatie verloren gaat.

De status van een persoon binnen de sociale zekerheid wordt daarenboven bepaald door een opeenvolging van gebeurtenissen die lang kunnen doorwerken en met elkaar interageren (werk, ontslag, ziekte, ongeval, pensioen, geboorte van een kind, …). Om echt waardevol te kunnen zijn zou een twin de hele weg moeten kunnen modelleren die een individu aflegt in het systeem. Niet alleen de individuele status, maar ook die van dossiers (worden er deadlines gemist) en administratie (is er behandelingsachterstand) evolueert doorheen de tijd.

Als er vandaag al een goede digital shadow beschikbaar is van een dienst, dan kan met de toevoeging van evolutieve gegevens over werklastverdeling, capaciteit, dossiervoortgang, … een volgende stap gezet worden, zoals de toevoeging van simulatie van caseflow. Zulke selectieve simulaties kunnen dienen voor tegenfeitelijke (“wat-als”) analyses die de impact van verandering (organisatorisch, of in de regelgeving) beter in te schatten maakt. Andersom kan men zoiets ook zien als een framework voor regressietesten: berekeningen op representatieve steekproeven kunnen herhaald worden telkens iets wijzigt, om na te gaan waar de grootste impact ligt.

De administratie van de gezondheidszorg kent andere prioriteiten: opvolging van patiënten en consultaties is tijdskritisch, de toekenning van mensen en middelen is een complexe planningspuzzel, allerlei terugbetalingen en verzekeringen, … Om daarin richting Digital Twin te evolueren kan er een grote rol weggelegd zijn voor de European Health Data Spaces, en voor nieuwe oplossingen die men momenteel tracht uit te denken voor secundair gebruik van gezondheidsdata.

We staan nog ver van de droom van individueel geoptimaliseerde gezondheidszorg op basis van een persoonlijke digital twin van een patiënt – idee dat trouwens ook gepaard gaat met heel wat niet triviale risico’s inzake ethiek en privacy. Op kortere termijn liggen de mogelijkheden eerder op niveau van de organisatie. Met gegevens over opnames, wachtlijsten, personeelsinzet en activiteit, toegevoegd aan een bestaande digital shadow, kunnen strategische en operationele wijzigingen mogelijk beter opgevangen worden.

Implementatie: een kostelijke affaire?

Om de focus te behouden op wat vandaag of op korte termijn mogelijk is, kunnen administraties zich inspireren op “reference stacks” van technologische componenten, die uitgebouwd zijn in het kader van bestaande digital twins. Enkele daarvan haalden we reeds eerder aan en herhalen we hier niet.

Een Digital Twin moet een representatie kunnen bevatten van de huidige staat van een systeem, en moet gebeurtenissen kunnen verwerken die daarop een impact hebben. In het kader van de Europese FIWARE initiatieven (Future Internet) werd daarvoor door een werkgroep Context Information Management bij ETSI de NSGI-LD standaard en API ontwikkeld. Het lijkt er echter op dat er nog niet veel adoptie is van deze standaard buiten het eigen netwerk van voornamelijk Smart City en IoT-initiatieven.

Administratieve systemen bestaan niet louter uit beslissingen. De processen omvatten interactie, documenten, en soms ook enige beoordelingsvrijheid. Open standaarden uit de business process management wereld komen hier van pas. DMN (decision modeling), BPMN (business processes) en CMMN (case management) zijn complementair aan elkaar en laten het modelleren van deze aspecten toe. Op deze initiatieven verschijnen ook uitbreidingen, zoals het aan de KULeuven ontwikkelde Constraint DMN (cDMN) dat complexere logica toelaat. Een Digital Twin kunnen we dan samenstellen uit een DMN beslissingsmotor die berekent “wat de regels zeggen” (hier kan Rules As Code eventueel een plaats krijgen), verrijkt met lagen die de processen en caseflow voor hun rekening nemen (status, deadlines, ondersteunende documenten), en tot slot een regelmatige synchronisatie om de operationele status (of context) te kunnen updaten. Dit is compatibel met het JRC maturiteitsmodel (model -> schaduw -> twin).

Digital Twins zijn niet duur omdat ze veel visualisatie bevatten of rapporteringsmogelijkheden ingebouwd hebben. Ze zijn duur omdat ze een duplicaat vormen van het doelsysteem, dat net zoals het origineel, doorheen de tijd correct moet blijven werken. Om meer te zijn dan enkel hype, is constante investering in onderhoud nodig. Die recurrente kosten omvatten ten minste het volgende:

• monitoring en validatie: een digital twin moet elke verandering aan het doelsysteem zo accuraat mogelijk volgen, dit vraagt regelmatige updates,
• onderhoud van de regels en traceerbaarheid: zeker wanneer regels vaak wijzigen is dit een grote kost. Hier spelen versionering, test suites en veranderingsmanagement een rol,
• functioneren van data pipelines en interoperabiliteit: omvat ook semantiek, toegangscontrole, datakwaliteit, accuraatheid en beveiliging,
• privacy en compliance: onontbeerlijk, zeker voor systemen die persoonsgegevens verwerken (gezondheid, inkomen, familie)

Voor een administratieve use case is de beste eerste stap daarom een stelselmatige uitbouw van wat we een privacy-aware digital shadow zouden kunnen noemen: initieel beperkt tot monitoring + replay functionaliteit, met strikte toegangscontrole en dataminimalisatie. Daarna kan gedacht worden aan uitbreiding met simulaties op geanonimiseerde of synthetische datasets. Eventuele near-real-time synchronisatie met gegevens uit het echte doelsysteem, om een echte Digital Twin te vormen, kan pas op het einde volgen, en heeft vaak nogal wat voeten in de aarde.

Conclusie

Is een Digital Twin het juiste type oplossing, of kan het ook eenvoudiger? Samengevat zijn Digital Twins pas te overwegen als al het volgende waar is (anders kan een andere aanpak efficiënter zijn en beter aansluiten):

• Het doelsysteem dat gemodelleerd wordt is dynamisch: uitkomsten hangen af van evoluerende situaties (caseflow, wachtrijen, levenscyclus van gebeurtenissen), niet enkel van eligibility checks of formulieren.
• Je kan authoritatieve databronnen identificeren en doorlopende synchronisatie volhouden. Zonder regelmatige updates met operationele data, bouw je een model en geen twin.
• Simulaties leiden tot echte beslissingen. Als de organisatie niet voldoende vrijheid heeft om in te grijpen (beleid veranderen, caseflow wijzigen, prioritisering, personeelstaken, …), zal een reeks dashboards waarschijnlijk volstaan.
• Er is een geloofwaardig plan voor audit en permanente kwaliteitsbewaking. Dit mag niet achteraf komen maar moet een acceptatiecriterium zijn. Het heeft geen zin een twin te bouwen die sneller rot dan het doelsysteem.
• De wettelijke/compliance omgeving is compatibel. Als er persoonsgegevens aan te pas komen kunnen GDPR en AI Act verplichtingen met zich meebrengen die de haalbaarheid en de kostprijs erg beïnvloeden. Dat kan een Twin limiteren tot een veredeld testsysteem in plaats van een echte bijdrage tot operationele automatisering te leveren.

Een niet-Twin kan ook waardevol zijn – met gecodeerde regels + testharnas + monitoring heb je ook al een transparante setup waarmee allerlei inzichten verworven kunnen worden, zonder de complexiteit en kost van volledige synchronisatie of simulatie-infrastructuur. In een administratieve omgeving kan zulk policy model al veel noden lenigen zonder operationele digital twin, al zal dat misschien teleurstellend zijn voor wie graag uitpakt met trendy buzzwords.

(Nederlandstalige tekst : zie onder)

Webinar Smals, WebEx

Koen Vanderkimpen
Smals Research

04/06/2026  10h30 – 11h45

Language: Dutch / Slides in English

Containercertificering

Het gebruik van Kubernetes-pods als abstractielaag voor vertrouwelijke container-workloads introduceert diverse uitdagingen. Door hun dynamische karakter – het maken, verwijderen, updaten van de containers – en de invloed van de Kubernetesomgeving (omgevingsvariabelen, toelatingscontrollers, enz.) valt het moeilijk te garanderen dat enkel de door de gebruiker bedoelde code wordt uitgevoerd. Zo kan het injecteren van kwaadaardige variabelen of het wijzigen van de specificatie van een pod voordat deze wordt gestart, de vertrouwelijkheid in gevaar brengen.

Het CoCo-project stelt een elegante oplossing voor, namelijk het gebruik van een engine voor beveiligingsbeleid, geïntegreerd in de containerruntime-omgeving binnen de trusted execution environment (TEE), die de door de gebruiker gedefinieerde regels toepast. Deze engine kan bijvoorbeeld alleen bepaalde images of commando’s toestaan en problematische verzoeken (zoals het uitvoeren van ongeoorloofde processen) afwijzen. Figuur 1 toont een voorbeeld van zo’n beleid.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figuur 1 – Voorbeeld van een beperkend beveiligingsbeleid voor images die kunnen worden uitgevoerd en de commando’s die in de image kunnen worden aangeroepen. Dit beleid wordt toegepast door een agent die in de vertrouwelijke VM zit.

Vier componenten van de vertrouwelijke virtuele guestmachine worden altijd gecontroleerd om te bepalen of ze nog goed werken: de firmware (bijvoorbeeld OVMF), de kernel van het besturingssysteem, de kernel commandoregel en het rootbestandssysteem (Figuur 2). Een vertrouwelijke externe entiteit, vaak Trustee genoemd, zorgt ervoor dat de vertrouwensketen versterkt wordt.

Vertrouwelijke containers hebben echter meestal initialisatiedata nodig die niet direct in de image van de virtuele machine of de toepassingscontainer kunnen worden opgenomen, zoals certificaten, adressen van certificeringsdiensten of toe te passen beveiligingsbeleidsregels. Deze data zijn weliswaar niet geheim, maar moeten wel worden beschermd tegen wijzigingen.

Deze initialisatiedata, ook wel init-data genoemd, kunnen worden opgegeven in de vorm van een woordenboek (bijv. JSON-bestanden, TOML, YAML), gecodeerd in base64 en doorgegeven aan de Kubernetes-pod via een Kubernetes annotation (Figuur 3). Om de integriteit ervan te garanderen, wordt hun cryptografische hashwaarde door de certificeringsagent (die in de vertrouwelijke virtuele machine draait) als data voor de berekening van de certificering verstrekt (dit kan worden gedaan met behulp van het veld “HostData” van SEV-SNP). Het is dan mogelijk om de initialisatiedata die naar de hostmachine zijn gestuurd voor het starten van de container te vergelijken met de hashwaarde die op het moment van de certificering is ontvangen, zodat elke wijziging tijdens de certificering op afstand kan worden gedetecteerd.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figuur 3 – Voorbeeld van initialisatiedata die (in gecodeerde vorm) via een Kubernetes-annotatie aan de CoCo-guestagent in de vertrouwelijke virtuele machine worden geleverd.

Sleutelbeheer

Een externe sleutelbemiddelingsdienst (key broker service), die kan worden gekoppeld aan een transactionele ‘black box’, stelt de container in staat om dynamisch de resources op te halen die nodig zijn voor de werking ervan. Indien de client nog niet in het bezit is van een eerder verkregen authenticatietoken van de sleutelbemiddelingsdienst, moet hij zich eerst authenticeren, waarna de sleutelbemiddelingsdienst hem een challenge stuurt die hij moet beantwoorden (Figuur 4).

De client genereert een paar cryptografische sleutels en vraagt de processor om een certificaat te verstrekken met daarin de hashwaarde van zijn openbare sleutel en een unieke willekeurige waarde die door de dienst in zijn challenge is verzonden. Het certificaat dat de openbare sleutel van de client, de unieke willekeurige waarde die door de service is gestuurd en de meting van de vertrouwelijke VM die de client bevat aan elkaar koppelt, wordt door de processor ondertekend. De service gebruikt een certificeringsagent die het certificaat controleert door de handtekening te verifiëren en de meting te vergelijken met een referentiewaarde.

Installatie en testen

Om de CoCo-omgeving te testen, hebben we gekozen voor een EPYC 9335-microprocessor van AMD. Deze maakt gebruik van SEV-SNP-technologie voor versleuteling en bescherming van de integriteit van het RAM-geheugen. We hebben een machine geassembleerd met een moederbord dat deze microprocessor ondersteunt (Supermicro MBD-H13SSL-NT-O) en 128 GB RAM-geheugen. Vervolgens moesten we het BIOS configureren om ervoor te zorgen dat de gewenste beveiligingsfuncties van de microprocessor goed waren geactiveerd. We hebben ook gekozen voor de Ubuntu 24.04.3 LTS-distributie van het Linux-besturingssysteem. Voordat we de beveiligingsfuncties van de processor konden testen, moesten we ten slotte de kernel van het besturingssysteem opnieuw compileren. Dit is eigenlijk vrij simpel dankzij de scripts die AMD heeft meegegeven.

Eenmaal het systeem is ingesteld, kun je het Docker-platform installeren (om containerimages te maken), de containeruitvoeringsinterface containerd (inbegrepen in de Docker-distributie) en het Kubernetes-beheersysteem. Het instellen van deze tools is best lastig en afhankelijk van de versie. Er zijn verschillende scripts beschikbaar om deze installatie te vergemakkelijken.

Nadat het systeem was geïnstalleerd, konden we een bestaande toepassing in vertrouwelijke containers zetten: je hoeft alleen maar de naam van de runtimeklasse die Kubernetes gebruikt (runtimeClassName) in het YAML-configuratiebestand van Kubernetes te veranderen in een van de CoCo-klassen (bijvoorbeeld kata-qemu-snp). Natuurlijk is deze simpele wijziging niet genoeg om te profiteren van de beveiligingsfuncties van CoCo. Je moet de productiecyclus aanpassen om de volgende stappen toe te voegen:

• Versleuteling van de containerimage
• Ondertekening van de containerimage
• Beschikbaar stellen van versleutelings- en ondertekeningssleutels

Zodra de containerimage op de gebruikelijke manier is gemaakt, bijvoorbeeld met docker build, kan deze worden versleuteld met de tool skopeo, die verschillende algoritmen ondersteunt: JWE (RFC7516), PGP (RFC4880) en PKCS7 (RFC2315). Deze versleutelde image kan vervolgens worden ondertekend met de tool cosign en ten slotte worden geüpload naar een imageregister.

Bij het opstarten van de container moeten de CoCo-componenten in de vertrouwelijke virtuele machine de handtekening kunnen verifiëren en de image kunnen ontsleutelen. Hiervoor moeten de benodigde sleutels beschikbaar worden gesteld. Hier komt het sleutelbemiddelingssysteem om de hoek kijken. Zoals we eerder hebben gezien, voert dit systeem een certificeringsprotocol uit voordat het de sleutels verstrekt.

De implementatie van confidential ccontainers is transparant voor de gebruiker van Kubernetes. Zodra het gebruikelijke commando kubectl apply wordt aangeroepen, wordt een lichte Kata-virtuele machine aangemaakt. Deze moet bij de sleutelbemiddelaar de toegangssleutel tot het imageregister (als dit niet openbaar is), het toe te passen beveiligingsbeleid, de sleutel voor handtekeningverificatie en de sleutel voor het ontsleutelen van de image ophalen. Deze informatie wordt pas verstrekt nadat de virtuele machine is geverifieerd (zie hierboven). De agents in de virtuele machine kunnen dan het beveiligingsbeleid toepassen, de image downloaden, de handtekening controleren en deze decoderen voordat de toepassingscontainer in de virtuele machine wordt gestart.

Wat betreft de communicatie van de gecontaineriseerde toepassing met externe diensten, moeten wederzijds erkende versleutelingssleutels worden ingesteld. Een eerste mogelijkheid is dat de vertrouwde container bij het opstarten een cryptografisch sleutelpaar aanmaakt en de cryptografische hashwaarde van deze openbare sleutel bij de certificering verstrekt. Dit wordt gebruikt binnen het authenticatieprotocol dat in Figuur 4 wordt beschreven. Een andere optie is om de openbare sleutel van een certificeringsinstantie in de versleutelde en vervolgens ondertekende image te verstrekken. De container kan dan de certificaten checken die deze autoriteit heeft ondertekend en de encryptiesleutels aanvaarden. Een derde optie bestaat erin om te steunen op de sleutelbemiddelingsdienst: hiermee kan de container op een veilige manier geheimen ophalen. Afhankelijk van de gekozen optie moet de code van de toepassing al dan niet worden aangepast.

Bescherming tegen een beheerder

Wat kan een beheerder van de hostmachine doen?  In principe niet veel, behalve de container opstarten.

Het certificeringsmechanisme zorgt er namelijk voor dat hij niets kan vervangen of simuleren wat betreft de onderdelen van de virtuele machine die wordt gebruikt om de containers te starten. Door de versleuteling van het geheugen dat aan de virtuele machine is toegewezen, heeft hij geen toegang tot de data die in de virtuele machine en de container worden verwerkt. Door de versleuteling en ondertekening van de containerimage kan hij geen andere container vervangen of de aard van de container achterhalen. In de veronderstelling dat de toepassing geconfigureerd is om versleuteld te communiceren met externe diensten waarmee ze moet interageren, kan de beheerder ook geen toegang krijgen tot gevoelige data door het netwerkverkeer te observeren, tenzij hij ook bevoorrechte toegang heeft tot het systeem voor het aanmaken van sleutels. Ten slotte kan hij de container ook niet ondervragen via het commando kubectl exec, omdat het kan worden beperkt door een beveiligingsbeleid (zie Figuur 1).

De beheerder kan daarentegen de toepassingslogboeken lezen die door Kubernetes op de host zijn opgeslagen. Daarom is het belangrijk dat de workload provider ervoor zorgt dat zijn code geen gevoelige informatie onthult in de gelogde berichten van de toepassing.

Tot slot, zoals we in de vorige blogpost al stelden, zijn vertrouwde uitvoeringsomgevingen niet perfect en houdt hun beveiligingsmodel meestal geen rekening met fysieke aanvallen. In een omgeving zoals de G-Cloud biedt de toevoeging ervan tal van mogelijkheden. In een omgeving waar echter noch SMALS, noch haar klanten, noch zelfs de Belgische Staat enige technische of juridische controle hebben over de infrastructuur, zijn er aanzienlijke risico’s die serieus moeten worden geëvalueerd.

Conclusie

In deze blogpost en de vorige hebben we de echte voordelen belicht op het gebied van beveiliging die microprocessors kunnen bieden om “vertrouwde uitvoeringsomgevingen” binnen een IT-infrastructuur te creëren. Vooral het “on-premise” gebruik ervan  maakt het mogelijk om gecontaineriseerde toepassingen beter te beschermen tegen kwaadwillige beheerders of indringers en zo onze leden nog meer garanties te bieden.

Omdat ze eenvoudiger in gebruik zijn dan geavanceerde cryptografische methoden, kunnen dergelijke systemen ons ook helpen om meer generieke problemen op te lossen dan met cryptografie alleen, of problemen die we tot nu toe simpelweg niet konden oplossen.

Cet article est aussi disponible en français.

Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?

Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.

In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moeilijkheidsgraad” van Legacy projecten beter illustreren.

“Oude” code: een spectrum aan mogelijkheden

Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.

AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.

Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.

Gebruik van LLMs op Legacy Codebases

Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.

Herschrijven van Legacy Code

Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding (de standaardcode om tot iets werkend te komen) van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.

Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.

Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClaw of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.

Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met beperkte functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.

Documenteren van Legacy Code

Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.

Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.

We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.

Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.

Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.

Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)

Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.

Besluit: vakmannen gevraagd

Zoals we hebben aangekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.

We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.

Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.

Wat als je systeembeheerders toegang zouden hebben tot je gevoelige data zonder dat je het weet? Confidential Computing biedt een oplossing: data isoleren, zelfs voor degenen die de infrastructuur beheren. Maar hoe?

Confidential Computing omvat een geheel van technologieën waarmee gevoelige data zodanig worden beschermd dat ze niet hoeven te worden ontsleuteld om te worden verwerkt. Hoewel sommige technologieën, zoals homomorfe versleuteling, nog steeds erg complex zijn om te implementeren, zijn Trusted Execution Environments (TEE’s) inmiddels zo ver ontwikkeld dat ze kunnen worden beschouwd als belangrijke technologie bij databescherming.

Het belangrijkste doel van TEE’s is om een buffer te vormen tegen de nieuwsgierigheid van de entiteiten die de infrastructuur beheren. Technische bescherming lost echter niet alles op. Extraterritoriale wetten [1-5] en het gebruik van eigen softwarelibrary’s die door sommige IT-infrastructuurproviders worden opgelegd, kunnen deze isolatie ondermijnen.

In deze en de volgende blogpost kijken we naar de mogelijkheid om TEE’s op onze eigen infrastructuur (on-premise) te gebruiken. Het doel is drieledig: gebruikmaken van de kracht van confidential computing om data te beschermen en nieuwe toepassingen mogelijk te maken, terwijl we een zekere controle behouden over de software- en hardwarestack, en zo het vertrouwen van onze klanten versterken.

Scheiding van rollen

Laten we beginnen met een overzicht van de verschillende spelers die betrokken zijn bij de implementatie van een toepassing op een IT-infrastructuur. Hun rollen moeten strikt gescheiden zijn om de integriteit van het systeem te garanderen.

• De infrastructure operator beheert de hardware en infrastructuur (computing, storage, network) en onderhoudt de beveiligde runtime-omgevingen. Hij beheert de firmware-updates en de toewijzing van middelen, maar zou geen toegang mogen hebben tot de data of de uitgevoerde workloads.
• De orchestration operator, die dezelfde kan zijn als de infrastructure operator, is verantwoordelijk voor het beheer van de serverclusters en de implementatie van de workloads. Hij configureert de benodigde middelen voor de toepassing en houdt toezicht op de bijbehorende diensten (logging, monitoring). Ook zijn rechten zouden strikt beperkt moeten blijven om elke vorm van inbreuk op de toepassing te voorkomen, terwijl de noodzakelijke orchestratie wel mogelijk blijft.
• De workload provider ontwerpt de specificaties van de toepassingen en kiest de juiste container images, waarbij hij de conformiteit en integriteit ervan garandeert. Hij moet aan de data owners (zie hieronder) laten zien dat de gebruikte code veilig is en de privacy respecteert, zonder direct toegang te geven tot gevoelige data.
• De container image provider bouwt, ondertekent en versleutelt de container images, zodat hun herkomst en veiligheid gegarandeerd zijn. Hij verstrekt de verificatie en decryptiesleutel. Zijn samenwerking met de toepassingsprovider is cruciaal om de softwareketen te garanderen en ervoor te zorgen dat de geïmplementeerde code precies dezelfde is als de geauditeerde code.
• Ten slotte bezit de data owner de data die door de toepassingen worden verwerkt en eist hij de vertrouwelijkheid en integriteit ervan. Hij vertrouwt op de code van de toepassing (de container) en de cryptografische bewijzen die door de microprocessor worden geleverd, waardoor infrastructure en orchestration operators buiten zijn vertrouwensbereik vallen. Hij kan extra controles opleggen om ervoor te zorgen dat zijn data niet zichtbaar zijn voor of gemanipuleerd worden door onbevoegde personen.

De relaties tussen deze spelers brengen specifieke uitdagingen met zich mee: de data owner moet bijvoorbeeld kunnen vertrouwen op de code van de containers (geleverd door de workload provider) om zijn data te verwerken, terwijl hij deze tegelijkertijd moet beschermen tegen andere spelers, zoals de infrastructure of orchestration operator. Met name de beheerders van deze operators mogen in geen geval toegang hebben tot de data die door de containers worden verwerkt.

Betrouwbare runtime-omgeving

Met TEE’s kan een technische barrière worden gecreëerd die het vertrouwen van de data owner in de toepassingscontainer versterkt. We hebben al uitvoerig uitgelegd hoe ze werken en wat hun voor- en nadelen zijn in een technisch rapport [6] en blogposts [7], [8]. Hier gaan we even de belangrijkste punten herhalen alvorens we de technologische keuzes voor een implementatie op onze onderzoeksinfrastructuur voorstellen.

Het goed functioneren van TEE’s hangt af van de hardware. Sommige moderne microprocessors maken het mogelijk om een deel van het RAM-geheugen dat is toegewezen aan een specifieke virtuele machine (VM) te reserveren en te versleutelen. Zo zal een beheerder van de hostmachine, zelfs met de hoogste privileges, alleen versleutelde data zien als hij dit geheugengebied probeert te inspecteren. Hoewel er aanvallen via side-channels bestaan (bijv. [9]), vereisen deze vanwege hun complexiteit doorgaans langdurige fysieke toegang en de toevoeging van kwaadaardige hardwarecomponenten, waardoor ze in de praktijk uiterst moeilijk uit te voeren zijn.

Opdat de data owner er zeker van kan zijn dat zijn toepassing in een veilige omgeving draait, gebruikt hij het certificeringsmechanisme. Dit proces genereert een cryptografische handtekening van de inhoud van het geheugen van de VM op het moment dat deze wordt opgestart. Deze handtekening wordt gecertificeerd door de fabrikant van de microprocessor.

Dit proces heeft zijn beperkingen, vooral als de infrastructure operator een buitenlandse onderneming is (bijvoorbeeld Amazon AWS, Google Cloud of Microsoft Azure) die zijn eigen libraries in de VM oplegt om bijvoorbeeld de juiste hardware-abstractielaag te bieden.

Dit heeft ons ertoe aangezet om dit soort hardware op onze eigen infrastructuur binnen het onderzoekslabo te testen, in afwachting van de mogelijkheid om dit op een dag op G-Cloud toe te passen. Het voordeel hiervan is dat een klant van SMALS een toepassingscontainer op een veilige manier kan gebruiken, zonder dat een beheerder van SMALS toegang heeft tot de inhoud van de container.

Maar het nut van TEE’s gaat verder dan alleen bescherming tegen beheerders. Het opent de deur naar andere toepassingen.

Use case

Een eerste voorbeeld is te vinden in de Europese infrastructuur voor digitale gezondheidsdiensten (eHDSI). Daar kunnen zorgverleners in het land waar de behandeling plaatsvindt de relevante gezondheidsdata van de patiënt opvragen in het land waar de patiënt is aangesloten. Technisch gezien wordt de aanvraag via de gateway van het nationale contactpunt voor gezondheidszorg (NCPeH) van het land waar de onverwachte gezondheidsgebeurtenis plaatsvindt, doorgestuurd naar het land waar de patiënt is aangesloten. De gevraagde info moet dan worden opgehaald uit de nationale infrastructuur van het land van aansluiting, vertaald naar het Engels en getranscodeerd (de gezondheidsdata worden omgezet van het nationale coderingssysteem naar het algemeen aanvaarde coderingssysteem, bijvoorbeeld van het FHIR– of KMEHR-formaat naar CDA), en vervolgens teruggestuurd en gepresenteerd worden aan de zorgverlener in het land van behandeling. Vanwege het gevoelige karakter van de data moeten deze van begin tot eind worden versleuteld, vanaf de gegevensbron op de infrastructuur van het land van aansluiting tot aan de zorgverlener in het land van behandeling. In de praktijk is dit nog niet mogelijk vanwege de grote verschillen tussen de Europese landen. Het zou echter op zijn minst mogelijk moeten zijn om te garanderen dat de data versleuteld en ontoegankelijk blijven voor alle gebruikers of beheerders tussen de bron van de data en de uitgang van de NCPeH-gateway. Een mogelijkheid is dan om TEE’s te gebruiken voor het vertalen en transcoderen van de data.

Een ander voorbeeld van het gebruik van TEE’s is de beveiligde samenwerking tussen entiteiten die hun ruwe data niet willen delen. In de onderwijs- en werkgelegenheidssector heeft een experiment van Bogdanov et al. in Estland [10] de kracht van confidential computertechnieken aangetoond. De auteurs van deze studie wilden achterhalen of werken naast een hogere opleiding ertoe leidt dat je je diploma niet op tijd behaalt – een vraag die vooral belangrijk is voor de sector van de informatie- en communicatietechnologie (ICT) in Estland. Om deze probleemstelling te beantwoorden zonder de privacy van persoonlijke data in gevaar te brengen, hebben de onderzoekers de onderwijsregisters van het ministerie van Onderwijs en Onderzoek gecombineerd met de data van de belastingdienst, dankzij een speciale techniek van confidential computing. Maar een simpelere variant met een TEE zou net zo goed hebben gewerkt voor de analyse, terwijl de fiscale vertrouwelijkheid en databescherming gewaarborgd bleven.

CoCo

Om TEE’s te gebruiken in onze eigen onderzoeksinfrastructuur bestaan er verschillende softwareoplossingen. We hebben gekozen voor het project “Confidential Containers (CoCo)“, waarvan de broncode vrij toegankelijk is. Dit project zorgt voor een goede isolatie van de toepassingscontainers en ondersteunt het certificeringsmechanisme op een transparante manier, terwijl de flexibiliteit van de implementatie en de compatibiliteit met het Kubernetes-platform waarop het is gebaseerd, behouden blijven. Elke Kubernetes-pod is geïsoleerd in een zeer lichte Confidential Virtual Machine, om te garanderen dat alleen geautoriseerde applicaties toegang hebben tot gevoelige gegevens.

CoCo’s bevatten naast de toepassing zelf enkele noodzakelijke softwarecomponenten. Deze maken het mogelijk om de uit te voeren containerimage te downloaden, de verificatie van de certificering te vergemakkelijken en bepaalde beveiligingsbeleidsregels toe te passen. Hun programmeerinterface is relatief klein, vooral vergeleken met een oplossing waarbij een hele Kubernetes-node in een Confidential Virtual Machine wordt geplaatst. Bovendien is de image van de guest-VM statisch en generiek voor alle workloads en zelfs platforms, waardoor het eenvoudiger is om veiligheidsgaranties te bieden. Tegelijkertijd is het makkelijk om dingen te delen tussen containers in dezelfde Kubernetes-pod. De naamruimte van het netwerk van de pod blijft bijvoorbeeld binnen de confidential VM, waardoor de containers daarin zonder extra kosten vertrouwelijk met elkaar kunnen communiceren.

CoCo is gebaseerd op Kata-containers, een ander open source-project, waarmee Kubernetes-pods kunnen worden uitgevoerd binnen zeer lichte Confidential Virtual Machines (zie Figuur 1). CoCo voegt echter twee cruciale componenten toe om vertrouwelijkheid en veiligheid te garanderen (zie Figuur 2).

• De eerste heeft te maken met het ophalen van containerimages: deze worden meestal gedownload door de Kubernetes-hoofdnode met behulp van een Container Runtime Interface (CRI) zoals “containerd”, waardoor de images via het bestandssysteem zichtbaar worden voor de hostmachine. Met CoCo worden de images binnen de Confidential Virtual Machine ontsleuteld en uitgepakt, vandaar de noodzaak van de bovengenoemde componenten.
• Het tweede onderdeel is het certificaat, dat, zoals we al hebben gezien, essentieel is voor het opzetten van een betrouwbare uitvoeringsomgeving. Om bijvoorbeeld een image te ontsleutelen, dient de guest de geheime ontsleutelingssleutel te kunnen verkrijgen, maar deze wordt alleen verstrekt als de guest zijn authenticiteit kan aantonen. Dit is de rol van twee componenten die steunen op een zogenaamd “Trustee”-systeem, dat buiten de virtuele machine staat en uit twee diensten bestaat: een certificeringsdienst om de vertrouwde runtime te valideren en een key mediation-dienst om de geheime middelen te leveren die de virtuele machine en de toepassing nodig hebben.

CoCo levert dus de basis voor het bouwen van confidential toepassingscontainers door het mogelijk te maken deze containers binnen confidential virtuel machines uit te voeren, waarbij de geëncrypteerde en ondertekende images van de containers, de verzegelde geheimen en andere kenmerken worden beheerd. Elke container of groep containers van dezelfde toepassing kan worden toegewezen aan een confidential virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de confidential VM op de host wordt als onbetrouwbaar beschouwd, inclusief de kubelet-tool, de runtime-interface van de containers en de kernel van het besturingssysteem van de host. De uitwisseling van informatie tussen vertrouwde en niet-vertrouwde contexten wordt streng gecontroleerd, met name via dynamische en configureerbare beveiligingsbeleidsregels. Ten slotte wordt de Kubernetes-orkestratie zelf als niet-vertrouwd beschouwd, waardoor de garanties met betrekking tot de planning of de volgorde van uitvoering van de workloads beperkt zijn, met uitzondering van de implementatie ervan in een geauthenticeerde enclave.

Conclusie

Confidential containers maken deel uit van een algemene beveiligingsaanpak, waarbij certificering, verificatie van images en best practices in de softwaretoeleveringsketen worden gecombineerd. Ze maken het mogelijk om use cases eenvoudiger te verwerken dan geavanceerde cryptografie (confidential collaboration, private set intersection, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van confidential containers minder veilig is, maar in de praktijk zal deze waarschijnlijk volstaan in een on-premise omgeving, des te meer omdat het veel aspecten vereenvoudigt zodra het eenmaal is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van confidential CoCo’s.

Referenties

[1]        C. Bômont, “Strategic Brief no.70 – 2024 – Extension of the FISA Law European ‘digital sovereignty’ far from American concerns – IRSEM”, Institut de Recherche Stratégique de l’Ecole Militaire. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, “Europeans, forget the US Cloud Act… worry about FISA instead (!)”. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        Paul Kunert, “Microsoft exec admits it ‘cannot guarantee’ data sovereignty”. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[4]        M. Rochefort, “Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française”, clubic.com. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[5]        D. Deridder, “Understanding Sovereignty: Who Rules your Cloud?”, Dirk Deridder. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[6]        F. A. P. Petitcolas, “Informatique confidentielle – État de l’art”, Smals Research, jul. 2023. [Online]. Beschikbaar op: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, “Outils pour l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, en J. V. Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing”, gepresenteerd bij 47th IEEE Symposium on Security and Privacy (S&P), mei 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, en R. Talviste, “Students and taxes: a Privacy-preserving study using secure computation”, Proc. Priv. Enhancing Technol., vol. 2016, nr. 3, pp. 117-135, jul. 2016, doi: 10.1515/popets-2016-0019.

Het opmerkelijke meertalige potentieel van grote taalmodellen (LLM’s) heeft bijgedragen aan de brede verspreiding en integratie ervan binnen AI-gebaseerde toepassingen. Er bestaan echter prestatieverschillen tussen het Engels en andere talen, met name talen met beperkte middelen.

Bij de evaluatie van een door ons ontwikkelde RAG-chatbot stelden we een duidelijk verschil vast in de kwaliteit van de antwoorden, afhankelijk van de gebruikte taal. De chatbot leverde namelijk betere antwoorden in het Frans dan in het Nederlands. De in het Frans gegenereerde antwoorden waren vlotter en betrouwbaarder ten opzichte van de door de gebruiker gevraagde informatie. De antwoorden in het Nederlands waren over het algemeen minder relevant. Deze resultaten wijzen op een cruciale uitdaging bij de ontwikkeling van LLM’s die door chatbots worden gebruikt: hoewel deze indrukwekkende meertalige capaciteiten hebben, vertonen de huidige modellen vaak een uitgesproken voorkeur voor talen met veel middelen, zoals het Engels.

In deze blogpost beschrijven we de resultaten van ons onderzoek naar de door ons vastgestelde taalkloof en tonen we de bevindingen van ons onderzoek.

Prestatieverschil tussen het Engels en de andere talen: oorzaken en factoren

Verschillende factoren dragen bij aan de taalvoorkeur voor het Engels. Deze omvatten:

• Onevenwichtige datasets: het trainingsproces van grote taalmodellen is gebaseerd op omvangrijke tekstcorpora, maar deze worden sterk gedomineerd door het Engels, gevolgd door talen met veel taalkundige middelen zoals het Chinees, het Frans en het Spaans. Daarentegen zijn de data in talen met beperkte middelen vaak van mindere kwaliteit vanwege het beperkte aantal bronnen. Dit onevenwicht in de data leidt tot slechte prestaties in andere talen dan het Engels, met hogere foutpercentages en hallucinaties tot gevolg. Om dit probleem op te lossen, maken modelontwikkelaars gebruik van een techniek die “interlinguïstische overdracht” genoemd wordt. Hierbij verbetert een model zijn prestaties in minder goed uitgeruste talen door universele of gedeelde taalkundige patronen af te leiden uit talen met veel middelen. Hoewel het exacte percentage Engelstalige data in propriëtaire modellen niet openbaar bekend is, is 93% van de data die worden gebruikt om GPT-3 te trainen in het Engels. Leveranciers van grote taalmodellen, zoals OpenAI en Google, maken vaak gebruik van het Common Crawl-webgegevensarchief, dat zelf wordt gekenmerkt door een dataset waarin het Engels overheerst (44% in het Engels, 4% in het Frans, 2% in het Nederlands). Deze vertekening wordt nog versterkt in gespecialiseerde domeinen zoals financiën en gezondheidszorg, waar hoogwaardige data bijzonder schaars is. Het is belangrijk op te merken dat het Nederlands wordt beschouwd als een taal met hoge middelen in het domein van automatische natuurlijke taalverwerking (NLP), hoewel het over minder middelen beschikt dan het Frans of het Engels.
• Morfologie en tokenisatie: modelarchitecturen zijn vaak geoptimaliseerd voor het Engels. Tokenisatieprocessen kunnen ingewikkeld zijn voor talen die niet met het Latijns alfabet worden geschreven, zoals het Chinees of het Japans, alsook voor talen met een gemiddelde tot hoge morfologische complexiteit, zoals het Nederlands. Engelse tokenizers kunnen het moeilijk hebben met het verwerken van samengestelde woorden (de combinatie van meerdere zelfstandige naamwoorden in een woord), wat kan leiden tot grammaticaal foute resultaten wanneer modellen tekst genereren.

Zeer weinig studies hebben de prestaties geanalyseerd van grote taalmodellen in het Frans en het Nederlands. Een onderzoek naar de taalkundige kwaliteit van LLM’s in deze twee talen bracht aan het licht dat de prestaties algemeen beter waren in het Frans dan in het Nederlands, in het bijzonder bij taken waarbij tekst moest worden gegenereerd [1]. Een ander onderzoek rapporteerde betere prestaties van LLM’s in het Engels in vergelijking met het Nederlands bij een vraag-antwoordtaak [2].

In de industrie blijven er grote uitdagingen bestaan met betrekking tot de toepassing van grote taalmodellen op niet-Engelse technische domeinen, met name in de medische en financiële sector. De huidige implementaties vereisen vaak een verfijning van de vooraf getrainde modellen zoals Mistral en Llama om bevredigende prestaties te bereiken.

Een andere bekende uitdaging bij de toepassing van AI-modellen in de Nederlandse taalomgeving is spraakherkenning. Dit is grotendeels een gevolg van de grote variatie in regionale accenten. Onze experimenten met het transcriberen van opnames van Teams-vergaderingen hebben aangetoond dat de Franse transcripties systematisch van betere kwaliteit waren dan de Nederlandse. Gespecialiseerde tools zoals Sembly leveren echter acceptabele transcriptieresultaten in het Nederlands.

Vergelijkende analyse van de prestaties van het Nederlands en het Frans in een chatbot

Er is een vergelijkende analyse van de prestaties uitgevoerd op een chatbot die is ontwikkeld om vragen van burgers te beantwoorden. Voor de eerste evaluatie van de chatbot hebben we een reeks vragen gebruikt die door experts zijn opgesteld. Deze vragen werden in het Frans en het Nederlands aan de chatbot voorgelegd, waarna de antwoorden door dezelfde expert werden beoordeeld en door twee andere personen werden gecontroleerd. Uit de eerste evaluatie blijkt een aanzienlijk verschil in prestaties tussen de twee talen: de chatbot behaalde een nauwkeurigheid van 95% in het Frans, tegenover 82% in het Nederlands.

Na de implementatie van de chatbot in een productieomgeving werd een tweede evaluatiefase uitgevoerd op basis van vragen die door gebruikers waren ingediend en in een database waren opgeslagen. We merkten opnieuw een verschil in prestaties: 82% nauwkeurigheid in het Frans en 69% in het Nederlands.

Verschillende factoren kunnen bijdragen aan deze waargenomen verschillen, waaronder:

• de vooringenomenheid van de beoordelaars – beoordelaars zijn minder of meer streng in hun beoordelingen;
• de variatie in het soort vragen (dubbelzinnig, slecht geformuleerd, niet ter zake) – dezelfde vragen werden niet systematisch in beide talen beoordeeld;
• het kwaliteitsverschil bij het ophalen van de bronnen (retrieval) – er zijn verschillen tussen de talen in de data-bronnen die worden opgehaald om de generatie te voeden;
• de intrinsieke capaciteiten van het generatieve model (GPT-4o) in beide talen.

Er was dus aanvullend onderzoek nodig om de waargenomen verschillen in het Frans en het Nederlands volledig te begrijpen en deze factoren te verminderen.

Test

Om de prestaties van LLM’s in zowel het Frans als het Nederlands grondig te evalueren, werd een experiment uitgevoerd met de chatbot. We selecteerden een aantal vragen waarvan de eerdere antwoorden van LLM’s als onjuist waren beoordeeld, waarbij we ervoor zorgden dat de vragen niet te complex of te simplistisch waren. Het was van cruciaal belang dat elke vraag van een gebruiker tussen het Frans en het Nederlands werd vertaald om een directe vergelijking te vergemakkelijken. Bij het evaluatieproces waren twee onafhankelijke evaluatoren betrokken, een vakexpert en een technisch expert, om vooringenomenheid te beperken en een robuuste evaluatie te garanderen. De evaluatoren beoordeelden de nauwkeurigheid, relevantie en vlotheid van de gegenereerde antwoorden. Daarnaast werden ook andere modellen dan GPT-4o getest.

Naast de tests in het Nederlands en het Frans hebben we ook een test uitgevoerd waarbij vragen in het Nederlands naar het Engels werden vertaald. De antwoorden werden in het Engels gegenereerd en vervolgens opnieuw naar het Nederlands vertaald.

Resultaten

Vraag in het Nederlands, antwoord in het Engels

Het experiment waarbij vragen in het Nederlands naar het Engels werden vertaald en hierna de antwoorden naar het Nederlands werden vertaald leverde een genuanceerd resultaat. Hoewel de vertaling van Nederlandstalige vragen naar het Engels leidde tot ietwat betere antwoorden, van 67% naar 73%, verslechterde de kwaliteit van de antwoorden bij het omgekeerde proces, namelijk het vertalen van de gegenereerde Engelse antwoorden naar het Nederlands.

Nauwkeurigheid van Franse antwoorden versus nauwkeurigheid van Nederlands antwoorden

Tijdens ons experiment hebben we de antwoorden gegenereerd op basis van Nederlandstalige vragen vergeleken met hun Franse equivalenten in verschillende tekstreeksen. We hebben vastgesteld dat de samenstelling van deze reeksen een invloed had op de evaluatie van het model. De scores varieerden namelijk van set tot set voor elk model en elke taal, en de prestatieverschillen tussen de talen kwamen niet altijd tot uiting. Dit onderstreept het belang van het selectieproces van de testvragen: voor onze laatste test hebben we een evenwichtige testset samengesteld met voorbeelden van vragen die door gebruikers in beide talen zijn ingediend en vragen die door domeinexperts zijn opgesteld. In tegenstelling tot wat aanvankelijk werd waargenomen, laten de onderstaande resultaten slechts een klein verschil in nauwkeurigheid zien tussen het Frans en het Nederlands voor onze use case.

Tabel 1. Resultaten van de eindevaluatie van de chatbot.

Opmerking: slecht geformuleerde vragen in het Frans of Nederlands werden uit de testset verwijderd omdat ze moeilijk nauwkeurig in de andere taal te vertalen bleken.

Vergelijking van de LLM’s

GPT-5 presteerde goed op het vlak van nauwkeurigheid en beknoptheid. Het vertoonde echter een groter verschil in nauwkeurigheid tussen het Frans en het Nederlands dan de andere modellen. Gemini presteerde weliswaar beter in zowel het Frans als het Nederlands, maar genereerde aanzienlijk langere antwoorden, wat leidde tot een hoger tokengebruik. We hebben ook vastgesteld dat Claude Sonnet, met een vergelijkbare nauwkeurigheid als Gemini, soms Engelse termen invoegde in het gegenereerde antwoord, en dit vaker in het Nederlands dan in het Frans. Na evaluatie concludeerden de experts op dit gebied dat Gemini het meest geschikte model was voor hun use case.

Effect van de retrieval

Het proces van retrieval bestaat erin om relevante tekstfragmenten te extraheren om een vraag te beantwoorden vanuit de vector database, afhankelijk van de gelijkenis tussen de vraag en deze fragmenten. Deze gelijkenis wordt berekend met behulp van vectorrepresentaties van de teksten, gegenereerd door een embeddingmodel. We hebben vragen geanalyseerd die aanvankelijk betere resultaten opleverden in het Frans dan in het Nederlands en hebben vastgesteld dat ongeveer 50% van de opgehaalde informatie (context) in beide talen voorkwam. Om de impact van de resterende 50% afwijkende informatie te evalueren, hebben we het model (Gemini) aan identieke contexten onderworpen om zowel Franstalige als Nederlandstalige antwoorden te genereren. Ondanks het gebruik van deze identieke contexten bleef het model prestatieverschillen vertonen tussen het Frans en het Nederlands. Het retrievalproces lijkt dus een beperkte invloed te hebben op het waargenomen prestatieverschil tussen de twee talen.

Conclusie en aanbevelingen

Het prestatieverschil tussen het Nederlands en het Engels in grote taalmodellen is een vaststaand feit, dat geworteld is in de overweldigende dominantie van het Engels in de trainingscorpora. Dit verschil wordt nog versterkt door de specifieke morfologie van het Nederlands. Ter vergelijking: als LLM’s over het algemeen betere resultaten opleveren in het Frans, is dat te danken aan een betere vertegenwoordiging van de taal in de trainingscorpora.

Ons experiment heeft waardevolle informatie opgeleverd over de prestaties van LLM’s in een RAG-toepassing (Retrieval Augmented Generation) in het Nederlands en het Frans. Hoewel we aanvankelijk een significant verschil in nauwkeurigheid tussen de antwoorden in het Nederlands en de antwoorden in het Frans constateerden, bleek uit grondig onderzoek dat andere factoren dan de capaciteit van het model de resultaten konden beïnvloeden. Het prestatieverschil is dus minder groot dan we dachten. Bovendien hebben we vastgesteld dat variaties in de samenstelling van de testset kleine schommelingen in de resultaten veroorzaakten. Deze conclusies tonen aan dat de prestaties van LLM’s zeer gevoelig zijn voor de context en de specifieke formulering van de vragen. We hebben ook een lichte kwaliteitsverbetering  van de antwoorden waargenomen bij de Engelse vertaling van Nederlandstalige vragen; dit voordeel werd echter grotendeels tenietgedaan door de daaropvolgende Nederlandse vertaling van deze Engelse antwoorden.

De bovenstaande conclusies gelden voor een chatbot die zorgvuldig opgestelde inhoud in algemene taal gebruikt om vragen te beantwoorden. Ze zijn niet noodzakelijkerwijs van toepassing op andere use cases. Het is daarom essentieel om voor elk geval grondige evaluaties uit te voeren, zeker wanneer men in specifieke domeinen zoals gezondheidszorg, financiën, recht, enzovoort werkt.

Moeten we een eentalig model gebruiken?

We hebben deze vraag niet grondig kunnen onderzoeken. Ons literatuuronderzoek heeft geen overtuigend bewijs opgeleverd dat LLM’s voor het Nederlands de prestaties verbeteren; integendeel, de aanwezigheid van talen met veel bronnen in meertalige modellen lijkt de prestaties van minder goed bedeelde talen tot op zekere hoogte te verbeteren. Er zijn echter verschillende initiatieven genomen om LLM’s voor het Nederlands te ontwikkelen. De meest opvallende zijn:

–           GEITje: model gebaseerd op Mistral 7B en verfijnd voor het Nederlands. Dit model is niet langer beschikbaar vanwege auteursrechtelijke problemen.

–           GPT-NL: lopend initiatief, ondersteund door Nederland, om een LLM te ontwikkelen die is aangepast aan de Nederlandse taal en cultuur.

Referenties

1. Exploratory Study on the Impact of English Bias of Generative Large Language Models in Dutch and French (Rigouts Terryn & de Lhoneux, HumEval 2024)
2. Performance of Large Language Models in Domain-Specific and Underrepresented Languages: A Case Study on the Transportation Domain and Dutch Language (UHasselt)
3. MEGA: Multilingual Evaluation of Generative AI (Ahuja et al., 2023)
4. A Dutch Financial Large Language Model (Sander Noels, Jorne De Blaere & Tijl De Bie, 2024)
5. Multilingual LLMs: Progress, Challenges, and Future Directions (PremAI blogpost)
6. https://hogent-cads.github.io/blog/posts/vlaamse-spraakherkenning/ (HoGent blogpost)
7. Webinar Smals Research – Generatieve AI: verder dan de hype | Smals Research

Digitale persoonsgegevens vormen binnen een overheidscontext een bron van inzichten die innovatie, welzijn en beleidsvorming ten goede komen. Die persoonsgegevens zijn over heel wat organisaties verspreid; de ene organisatie heeft informatie over kanker, de andere over medicijngebruik en nog een andere bewaart inkomensgegevens. In de praktijk worden geregeld persoonsgegevens afkomstig van verschillende organisaties samengevoegd om op specifieke vragen van onderzoekers en beleidsmakers te kunnen antwoorden.

De huidige processen garanderen dat dit met respect voor de privacy gebeurt. Helaas is het – mede daardoor – ook te vaak een complexe, dure en tijdrovende aangelegenheid. In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom aan een prototype om met behulp van geavanceerde cryptografie deze processen aanzienlijk te vereenvoudigen.

Probleemstellig op basis van concrete case

We vertrokken van een concrete onderzoeksvraag:

Lopen MS-patiënten die medicijnen met de moleculen teriflunomide of alemtuzumab gebruiken een verhoogd risico op kanker in vergelijking met MS-patiënten die met andere medicijnen worden behandeld?

Om die – op zich eenvoudige – vraag te kunnen beantwoorden moeten medische gegevens over MS-patiënten afkomstig van twee organisaties, met name het Belgisch Kankerregister (BCR) en het InterMutualistisch Agentschap (IMA) gekruist worden.

Beide organisaties beheren de gegevens onder aparte pseudoniemen voor meer privacy; unieke codes ter vervanging van rijksregisternummers.

• Het BCR beheert gegevens met betrekking tot kanker over mensen die een kankerdiagnose kregen. Het BCR weet niet welke records betrekking hebben op MS-patiënten.
• Het IMA kent gegevens m.b.t. voorgeschreven medicijnen en kan de records selecteren van MS-patiënten.

De onderzoekers dienen in een beveiligde omgeving (SPE = Secure Processing Environment) toegang te krijgen tot gegevens afkomstig van het BCR en het IMA, over alle MS-patiënten. Gegevens over dezelfde patiënt maar afkomstig van verschillende bronnen moeten aan elkaar gekoppeld kunnen worden op basis van een uniek pseudoniem dat enkel gebruikt wordt in het kader van die specifieke onderzoeksvraag. Dit wordt geïllustreerd in figuur 1.

De centrale vraag luidt als volgt:

Hoe kan het BCR enkel records over MS-patiënten aanleveren aan de beveiligde omgeving zonder te weten te komen wie MS heeft of welke records die het beheert betrekking hebben op MS-patiënten?

In een klassieke benadering zal ofwel het BCR te veel informatie naar de beveiligde omgeving sturen – met name gegevens over elke kankerpatiënt – ofwel lekt er informatie naar het BCR – waarbij het BCR te weten komt welke records betrekking hebben op MS-patiënten. Een laatste mogelijkheid is het inschakelen van een vertrouwde centrale partij die weliswaar persoonsgegevens te weten komt, maar vertrouwd wordt daar niets onrechtmatigs mee te doen.

Geen van deze aanpakken is ideaal. Vandaag wordt in binnen- en buitenland ofwel beroep gedaan op – sterk gereguleerde – centrale partijen ofwel is duur en traag maatwerk vereist, waarbij voor elke onderzoeksvraag een nieuwe flow uitgetekend, gevalideerd en uitgevoerd wordt om de privacy maximaal te beschermen.

We geven nog mee dat de onderzoeker doorgaans toegang nodig heeft tot de ruwe data, waardoor oplossingen gebaseerd op secure multi-party computation ongeschikt zijn. 

Ons voorstel tot oplossing

Laat ons even vertrekken van een fictief scenario waarbij gewerkt wordt met een vertrouwde intermediaire partij en het – voor de eenvoud – IMA en BCR de persoonsgegevens niet onder pseudoniemen beheren, maar onder rijksregisternummers. IMA en BCR sturen beiden alle gegevens die potentieel relevant zijn naar de vertrouwde tussenpartij.

Het BCR stuurt naar de intermediaire partij geïdentificeerde kankergegevens over alle burgers die de kankerdiagnose kregen, wat uiteraard veel meer is dan nodig voor de onderzoeker. De intermediaire partij krijgt ook alle geïdentificeerde medicatiegegevens over MS-patiënten van het IMA en weet op basis daarvan welke door het BCR aangeleverde records betrekking hebben op MS-patiënten en dus relevant zijn in het kader van de onderzoeksvraag. De intermediaire partij voert nu de volgende stappen uit:

1. Het verwijdert de niet relevante records, dus de records over alle burgers die de kankerdiagnose kregen maar geen MS hebben.
2. Het voegt records over dezelfde burgers samen en vervangt in de samengevoegde records de rijksregisternummers door unieke pseudoniemen
3. Het stuurt het resultaat – enkel samengevoegde records – naar de beveiligde omgeving.
4. Het verwijdert alle ontvangen en afgeleide gegevens.

In dit scenario zijn er geen onbedoelde datalekken naar de databronnen en ontvangt de beveiligde omgeving enkel de minimaal noodzakelijke, gepseudonimiseerde persoonsgegevens.

Ons prototype doet exact dit, maar dan zonder de vertrouwde partij. De rol van de vertrouwde partij wordt gedistribueerd: Data holders – in dit geval het IMA en het BCR – en een data collector – in dit geval de beveiligde omgeving – interageren met elkaar om samen de rol van de vertrouwde partij over te nemen. Daarbij worden de veiligheidseigenschappen uit de vorige paragraaf behouden; er lekt dus niet onbedoeld informatie naar de data holders en de data collector komt enkel de minimaal noodzakelijke gepseudonimiseerde gegevens te weten. De oplossing blijft niettemin praktisch en efficiënt. Dit alles is mogelijk dankzij geavanceerde cryptografie.

We schreven eerder dat het IMA en het BCR de data bewaren onder pseudoniemen. Er bestaan procedures om die op een gecontroleerde wijze om te zetten in rijksregisternummers. De partij die data beheert komt daarbij nooit rijksregisternummers te weten en de partij die pseudoniemen kan koppelen aan rijksregisternummers heeft op geen enkel moment toegang tot de eigenlijke persoonsgegevens. Om redenen van eenvoud gaan we er de rest van dit artikel vanuit dat de data holders de data kennen onder rijksregisternummers. Ons concept kan ook op een veilige manier overweg weg met de meer realistische situaties waarbij dit niet het geval is.

In de praktijk

Smals Research werkte samen met academische partners het concept uit. Initieel luisterde het naar de naam Oblivious Join, maar in academische context werd het herdoopt naar LetheLink. Lethe (Λήθη) is in de Griekse mythologie de godin van de vergetelheid en een van de vijf rivieren in de onderwereld, waaruit de doden drinken om hun aardse leven te vergeten. Ondanks die vergetelheid – of beter, gebrek aan kennis – slagen de interagerende partijen er toch in de noodzakelijke data aan elkaar te linken. Centraal in de ontwikkeling van dit concept stonden gebruiksvriendelijkheid en efficiëntie.

Smals Research heeft een demonstreerbaar prototype uitgewerkt dat alvast een zicht geeft op hoe een enterprise-ready oplossing zou kunnen werken. Het gebruik van het prototype wordt geïllustreerd in figuur 2 en bestaat uit de volgende stappen:

1. Creatie JSON-bestand. Een organisatie die als aanspreekpunt kan dienen (vb, de HDA of de KSZ) krijgt een vraag binnen van een onderzoeker. Wanneer de juridische basis voor deze gegevensverwerking er is, stelt deze organisatie een digitaal ondertekend JSON-bestand op. Dat bestand bevat in een gestructureerde vorm alle informatie om het protocol voor het beveiligd kruisen van de gegevens van de data holders op een correcte manier uit te kunnen voeren: connectiegegevens van de clients van zowel data holders als de data collector, de cryptografische parameters, publieke sleutels, informatie over welke data holder welke data moet aanleveren, etc. In de praktijk zal men vertrekken van templates, van waaruit met een minimale inspanning JSON-bestanden afgeleid kunnen worden.
2. Distributie JSON-bestand. Dit JSON-bestand wordt bezorgd aan zowel de data collector als de data holders. Allen verifiëren de digitale handtekening. Alle betrokken partijen weten nu hoe ze het protocol moeten uitvoeren en hoe ze de andere betrokken partijen veilig kunnen contacteren.
3. Downloaden client. Indien dit nog niet gebeurd is, downloaden de data collector en data holders de LetheLink client.
4. Creatie CSV-bestanden. Op basis van het JSON-bestand genereert elke data holder een CSV-bestand die alle potentieel relevante geïdentificeerde data bevat. In de eerder geschetste use case zou dit voor het SKR alle gevraagde geïdentificeerde informatie bevatten over alle burgers die de kankerdiagnose kregen. De creatie van dit bestand valt buiten de scope van LetheLink. In ons prototype worden enkel CSV-bestanden ondersteund, maar dit kan uitgebreid worden.
5. Invoer client. Elke participant geeft het JSON-bestand als invoer aan zijn lokale LetheLink client. De data holders geven daarnaast ook hun lokaal gegenereerde CSV-bestand aan hun client. Data worden in klaar aangeleverd en de client neemt de versleuteling op zich.
6. Uitvoering protocol. Het protocol wordt uitgevoerd. Dit resulteert aan de kant van de data collector (SPE) in een CSV bestand dat enkel de gepseudonimiseerde, minimaal noodzakelijke gegevens bevat.  

Het voordeel van deze benadering is de flexibele inzetbaarheid. Er zijn data holders die maar heel af en toe in dergelijke kruisingsprojecten betrokken zijn en niet alle data holders beschikken over evenveel middelen. Dankzij de LetheLink benadering zijn geen grote investeringen of voorbereidingen nodig. De installatie van de client en creatie van de CSV file volstaan.

Figuur 3 geeft een fictief voorbeeld van dergelijke CSV bestanden. Bovenaan staan extracten van CSV bestanden  die de – in dit geval drie – data holders elk als invoer aan hun LetheLink client geven. Onderaan de figuur is een extract te zien van het CSV bestand dat de client van de data collector als output genereert als resultaat van de protocoluitvoering. In ons fictieve voorbeeld is de onderzoeker enkel geïnteresseerd in data in de doorsnede; dus in data over de 50 000 MS-patiënten die de kankerdiagnose kregen en een hoog risicoprofiel hebben. De persoon met rijksregisternummer 60.01.05-045.05 behoort tot die groep. De data collector ziet de gecombineerde informatie over deze burger, niet onder dit rijksregisternummer, maar onder het pseudoniem “153807…”.

Performantie

In het kader van de academische samenwerking werd de performantie in meerdere iteraties grondig verbeterd, zowel op het niveau van het algoritme, als op het niveau van de implementatie. De voornaamste testresultaten zijn weergegeven in tabel 1. Een beetje duiding:

• De testen werden uitgevoerd op op AWS EC2 r7i.8xlarge VMs, met 32 vCPU’s (Intel Xeon Platinum 8588C @ 3.2 GHz) en 256 GB RAM.
• Er wordt een onderscheid gemaakt tussen een uitvoering op een LAN aan een snelheid van 1 Gbps en op een WAN aan een snelheid van 150 Mbps.
• De variable m representeert het aantal records dat door elk van de databronnen meegegeven wordt. Het is in onze testen minimaal 2¹⁶ = 65 536 en maximaal 2²⁴ = 16 777 216. In werkelijkheid is het aantal records uiteraard verschillend per databron, maar deze resultaten geven alvast een bovengrens.
• De variable κ (kappa) representeert het computationele veiligheidsniveau. 128 bit security volstaat vandaag, al wordt voor data die lange tijd gevoelig blijft toch 192 of zelfs 256 bit security aanbevolen. De variable λ (lambda) representeert de corresponderende statistische veiligheidsparameter. 
• De variabele n representeert het aantal data holders. We deden testen met 3, 5 en 7 data holders, maar er zijn geen technische beperkingen voor een veel groter aantal.

Nu we weten hoe deze tabel te interpreteren, zien we dat er bijvoorbeeld 25 seconden nodig zijn om het protocol uit te voeren waarbij drie databronnen elk 1 miljoen (2²⁰) records aanleveren over een WAN, met een veiligheidsniveau van 256 bits. De hoeveelheid meegeleverde data heeft eveneens impact op de uitvoeringstijd, maar daarvoor verwijzen we naar tabel 3 in onze gemeenschappelijke publicatie. Samengevat zijn zowel het protocol als de implementatie ervan bijzonder efficiënt. Figuur 4 geeft, ter afronding, een sfeerbeeld van het uitvoeren van de testen.

Verhouding tot eHealths Blinde Pseudonimiseringsdienst

Smals Research ontwikkelde in de periode 2021-2022 de blinde pseudonimiseringsdienst voor eHealth. Daarmee kunnen rijksregisternummers omgezet worden in pseudoniemen – unieke codes – en vice versa. Die omzetting gebeurt door een pseudonimiseringsdienst die echter blind is: het ziet rijksregisternummers noch pseudoniemen. Deze dienst kan eveneens gebruikt worden om gegevens te pseudonimiseren én te kruisen. Wat zijn dan de verschillen?

• Status. De blinde pseudonimiseringsdienst staat reeds in productie, terwijl LetheLink slechts een prototype is.
• Datalekkage. Voor complexere kruisingsprojecten, zoals diegene waar in dit artikel van vertrokken wordt, zal de blinde pseudonimiseringsdienst niet altijd kunnen verhinderen dat er datalekken optreden. Met name zal er sprake zijn van gegevenslekkage wanneer een databron niet autonoom kan bepalen welke records relevant zijn om de onderzoeksvraag te kunnen beantwoorden. Afhankelijk van de use case kan dit gaan om een aanvaardbaar residuele datalekkage, of het kan gaan over meer substantiële datalekken, die effectief de privacy van betrokkenen aantasten. Anderzijds ontstaan er bij LetheLink risico’s wanneer één entiteit zowel data holder als data collector is.
• Snelheid. eHealths blinde pseudonimiseringsdienst is weliswaar erg snel – het kan duizenden conversies per seconde aan -, maar LetheLink is bliksemsnel – het doet tienduizenden conversies per seconde en onder bepaalde omstandigheden kan het over de honderduizend gaan. Veel zal natuurlijk afhangen van de gebruikte infrastructuur.
• Infrastructuur. eHealths blinde pseudonimiseringsdienst is sowieso een centrale entiteit die over voldoende capaciteit moet beschikken. LetheLink daarentegen is gedistribueerd, waardoor een dergelijke centrale partij niet langer vereist is: het volstaat dat elke partij de LetheLink client draait op zijn bestaande machines. Dat kunnen zelfs reguliere laptops zijn.
• Integratie. Om gebruik te maken van de blinde pseudonimiseringsdienst moet een organisatie logica integreren in zijn clienttoepassing. Uit ervaring weten we dat dit gelukkig relatief eenvoudig is, maar het blijft niettemin een investering. LetheLink is een standalone client en dus is er geen integratietraject nodig.
• Type aanvragen. eHealths blinde pseudonimiseringsdienst kan overweg met zowel batch aanvragen als met aanvragen die in real-time afgehandeld moeten worden. LetheLink kan enkel overweg met verwerkingen in batch.

Deze positionering van LetheLink en eHealths blinde pseudonimiseringsdienst ten opzichte van elkaar zou organisaties moeten helpen om te bepalen welke technologie het meest geschikt is voor hun use cases.

Uitbreidingen

Er zullen een aantal uitbreidingen van LetheLink nodig zijn om het ook daadwerkelijk in de praktijk te kunnen inzetten. Alle voorgestelde uitbreidingen zijn conceptueel alvast mogelijk, maar niet steeds in het prototype geïntegreerd. Dit zal enkel gebeuren indien er een concrete vraag komt.

• Minimale grootte resultaatset. Indien de gepseudonimiseerde resultaatset voor de data collector onvoldoende records bevat is er een risico voor de privacy van de betrokkenen en is het onmogelijk om statistisch relevant onderzoek te doen. Daarom ondersteunt het prototype vandaag reeds de mogelijkheid om een minimale grootte mee te geven in het JSON bestand.
• Gecontroleerde re-identificatie. Indien onderzoekers merken dat een bepaalde burger een hoog risico heeft om een bepaalde ziekte te ontwikkelen, moet het mogelijk zijn deze burger daarvan op de hoogte te stellen. Ook wanneer bij een fraudeonderzoek er een sterk vermoeden van fraude is door bepaalde burgers, moet het mogelijk zijn de bevoegde instantie op de hoogte te brengen. Er moet dus in een mogelijkheid voorzien worden om in uitzonderlijke situaties op gecontroleerde wijze de identiteit van een burger te achterhalen.
• Data holder pseudoniemen. Zoals eerder in dit artikel aangegeven, hebben data holders vaak zelf geen toegang tot het rijksregisternummer van de burgers waarover ze data beheren. Ook in dergelijk gevallen moet het protocol efficiënt uit te voeren zijn.
• Selectieve prijsgave. Momenteel focust het prototype op doorsnedes; enkel indien alle data holders records over eenzelfde burger aanleveren, wordt het samengestelde record zichtbaar voor de data collector. In de praktijk is er meer flexibiliteit nodig, zoals aangegeven in figuur 5. In de use case waarmee we dit artikel begonnen had de onderzoeker gepseudonimiseerde gegevens nodig over alle MS-patiënten, terwijl ons protoype op dit moment enkel gepseudonimiseerde gegevens aanlevert over alle MS-patiënten die ook de kankerdiagnose kregen. 
• Multi-batch transfer. In sommige gevallen moeten data holders meermaals data aanleveren aan de data collector, bijvoorbeeld in het kader van longitudinaal onderzoek. De data collector moet in staat zijn doorheen de tijd data over eenzelfde burger aan elkaar te koppelen.
• Vereenvoudigde communicatie. In het prototype communiceren alle betrokken data holders met elkaar, om vervolgens individueel vercijferde data naar de data collector te sturen. In een aangepast protocol zouden data holders enkel data uitwisselen met en via de data collector, bijvoorbeeld via een REST-interface. In de praktijk is dit de meer wenselijke benadering.

Laat ons weten indien u andere nuttige uitbreidingen ziet.

Referenties

Het initiële concept alsook het prototype en de performantietesten werden uitgevoerd door Smals Research. De academische partners, met name de COSIC groep en de DistriNet groep aan de KU Leuven, alsook de CrySP groep aan Waterloo University in Canada, focusten zich op de theoretische uitwerking. Dit resulteerde in 2025 in twee publicaties:

• Springer publicatie – Privacy-By-Design in the Belgian Public Sector. Dit toegankelijke document bespreekt twee innovatieve oplossingen bedacht door Smals Research voor het pseudonimiseren en kruisen van persoonsgegevens; Lethelink en eHealths blinde pseudonimiseringsdienst.
• Arxiv publicatie – Labeled Delegated PSI and its Applications in the Public Sector.  Dit academisch artikel beschijft formeel LetheLink, bewijst de correctheid, bespreekt de performantie en positioneert het werkt t.o.v. bestaand academisch werk.

Daarnaast verwijs ik graag naar mijn Devoxx talk en Webinar uit 2024 getiteld “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join is één van de drie pseudonimiseringstechnieken die ik er bespreek.

Ten slotte zijn er nog slides beschikbaar voor diegenen die graag snel een intuïtief beeld ontwikkelen over de basisprincipes van Oblivious Join. De bijhorende nota’s geven extra uitleg.

Conclusie

Secundair gebruik van persoonsgegevens kan ons heel wat inzichten verschaffen die beleidsvorming ondersteunen en wetenschappelijk onderzoek stimuleren. Om die inzichten te ontsluiten moeten gegevens afkomstig van verschillende bronnen op een efficiënte wijze verzameld kunnen worden, met respect voor de privacy. Dat wil zeggen dat enkel de noodzakelijke persoonsgegevens gepseudonimiseerd en gekruist worden en dat participerende partijen in dit proces geen persoonsgegevens te weten komen. Dit was in de praktijk verre van evident.

In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom een concept uit dat met behulp van geavanceerde cryptografie dit op een efficiënte wijze mogelijk maakt. Verder werd een demonstreerbaar prototype gebouwd, wat een eerste stap is om dit effectief in de praktijk te kunnen gaan inzetten.

We hebben de voorbije jaren met heel wat partijen samen gezeten. Iedereen vindt het een zeer nuttige tool, maar vooralsnog missen we de commitment van onze partners om dit in de praktijk om te zetten.

De voornaamste uitdaging vandaag is dan ook het productieklaar krijgen van deze oplossing. Neem dus zeker contact met ons op indien u interesse heeft in deze oplossing en eventueel mee uw schouders hieronder wil zetten.

In een vorig artikel fileerden we Rules as Code, een aanpak die erop gericht is om de kloof tussen regelgeving en software te verkleinen. We illustreerden daarbij dat er heel wat praktische obstakels te overkomen zijn, niettegenstaande het lovenswaardige doel. De uniforme encodering van regels met hun geschiedenis, verwevenheden en afhankelijkheden is een uitdaging die een aanzienlijke investering van mensen en middelen kan vergen. Permanent actief beheer is daarenboven nodig om elke wijziging aan de regels op te vangen. Zelfs op kleine schaal is een nauwe samenwerking tussen juristen en ontwikkelaars onontbeerlijk, want regelmatig zullen gemotiveerde beslissingen genomen moeten worden over interpretatie. Omdat industriestandaarden nog ontbreken en best practices nog volop in ontwikkeling zijn, riskeer je als early adopter de zogenaamde pioneer tax te moeten betalen. De complexe lasagna van overheidsbevoegdheden maakt een eventuele toepassing in België niet eenvoudiger.

Mede onder impuls van het uitgebreide rapport van de OESO uit 2020, hebben enkele overheden toch al volop ingezet op het uitwerken van, soms vrij grootschalige, proof-of-concepts. Er bestaan vandaag dan ook enkele frameworks die relatief matuur zijn. Ongetwijfeld is Frankrijk het voortrekkersland; het initiatief dat we hieronder zullen toelichten komt van Franse bodem. Ook in Nederland beweegt er wel wat: de Nederlandse fiscus gebruikt al enige tijd haar eigen domeintaal RegelSpraak die zij met de rule engine ALEF interpreteert en verwerkt, echter lijkt de daarover gepubliceerde broncode vooralsnog meer op methodologie dan op applicaties te focussen.

OpenFisca

OpenFisca is ontstaan in 2011 als open-source microsimulatie-motor om belasting- en uitkeringsregels (“tax & benefit system”) om te zetten naar uitvoerbare code. De effecten van die regelgeving, en eventuele wijzigingen, kunnen dan gesimuleerd worden voor zowel individuele cases als hele populaties. Websites met OpenFisca in de achtergrond zijn onder andere LexImpact (simulatie van wijzigingen in socio-fiscale wetgeving), Mes droits sociaux (simulatie van sociale rechten), en 1jeune1solution (allerhande steunmaatregelen). Buitenlandse voorbeelden zijn BenefitMe (Nieuw-Zeeland), Les meves ajudes (Barcelona), of PolicyEngine (UK/USA) – deze laatsten wel met grondige aanpassingen aan de engine.

Om ons eigen belasting- en/of sociale-zekerheidsstelsel te modelleren, moeten we een fork maken van het generieke OpenFisca country-template. Verschillende andere landen hebben er tenminste al mee geëxperimenteerd, zo vinden we in de lijst van repositories o.a. Senegal, Paraguay en Tunesië. Regionale of lokale wetgeving kan middels plugin-extensies toegevoegd worden aan een nationaal systeem, zoals deze voor Parijs. Eens de repository geïnitialiseerd, kunnen we beginnen werken aan wat misschien ooit openfisca-belgium kan worden. De modellering in OpenFisca gebeurt door het schrijven van Python-klassen en -methodes, die de entiteiten, variabelen en berekeningsformules uit de regelgeving vertegenwoordigen.

Helaas houdt het gemakkelijke deel daar ongeveer op. De country-template repository is minimalistisch en hoewel er wel documentatie, met een kleine tutorial, beschikbaar is om een eigen versie uit te bouwen, focust deze vooral op de eerste stappen. Richtlijnen over hoe we onze eigen fork best zouden structureren zodra het aantal variabelen en parameters groeit, ontbreken grotendeels. De repository van moederproject openfisca-france kan weliswaar als voorbeeld dienen, maar is dan weer erg groot, en het waarom van hun structurele of architecturale keuzes is er niet echt uit af te leiden.

Ook het aspect van een GUI of webinterface blijft onderbelicht. Nochtans is de interface van bijvoorbeeld de LexImpact simulator van de Franse inkomstenbelasting, net een sterk punt. Als leidraad voor bouwen van een webinterface verwijst men naar tutorials en slides van een workshop, waar men de eerste stappen toont in Svelte, React en VueJS. Het is echter een extra barrière voor adoptie, dat een GUI of webapp nog from scratch zelf te bouwen is bovenop een eigen OpenFisca-instantie. Het bouwen van een GUI is immers tijdrovend. Het zou nuttig zijn om OpenFisca-GUI-libraries te hebben met herbruikbare componenten voor de belangrijkste web frameworks, zodat een OpenFisca server misschien met een generieke default webinterface gebundeld kan worden. Een Drupal-plugin lijkt momenteel het enige project dat enigszins in die richting gaat.

AI to the rescue?

Gezien OpenFisca, Svelte, React en Vue allen nieuw zijn voor de auteur, en AI-tooling belooft om developers sneller te laten onboarden, grijpen we de kans om de AI-powered IDE Cursor tegelijk uit te testen. Deze kloon van Visual Studio Code is verrijkt met de mogelijkheid tot het aanroepen van (in ons geval public-cloud-gebaseerde) LLMs. Daarbij kunnen selecties uit bestanden in het project worden gemarkeerd als context bij de vraag. Cursor kan suggesties geven voor toevoegingen of wijzigingen aan bestanden die, eens goedgekeurd, direct geïntegreerd kunnen worden in de codebase.

Interageren met AI-modellen houdt privacy-risico’s in. Dit experiment vooral mogelijk omdat we werken met open-source code, gepubliceerde regelgeving, en de eveneens openbare documentatie daarvan, wat niet gevoelig is. Maar gezien alles wat zich in de IDE bevindt naar het taalmodel gestuurd kan worden, moeten we er nog steeds op letten dat we geen bestanden openen in de IDE die credentials, API keys of persoonlijke informatie bevatten. Dat blijft de verantwoordelijkheid van de individuele developer. Sowieso is het goede praktijk om voorbereid te zijn op het roteren van API keys of credentials, want in het heetst van een debugging-strijd is oversharing met een LLM snel gebeurd.

Tot slot moeten we vermelden dat dit experiment nog werd uitgevoerd met Cursor versies 1.6 en 1.7 in september-oktober 2025, met OpenAI’s GPT-4.5 en later GPT-5.0 als achterliggend taalmodel, gebruikt met een eigen API key (niet via Cursor). Latere versies hebben heel wat nieuwere features (waaronder meer agentic workflows) en het zou kunnen dat de ervaring vandaag (januari 2026) al heel anders zou zijn. De belangrijkste lessen blijven echter algemeen gelden voor alle AI-powered development, of dat nu via IDE, command line of beide gebeurt (vb. Anthropic Claude Code).

Als eerste stap voegen we de nodige documentatie toe aan ons project. Als case nemen we de Wet op de Maatschappelijke Integratie van 26 mei 2002. Samen met alle andere relevante wetten, koninklijke besluiten en omzendbrieven is die overzichtelijk geïnventariseerd op de website van de POD Maatschappelijke Integratie. Om de tekst gemakkelijk doorzoekbaar en interpreteerbaar te maken voor een LLM in een IDE, slaan we hem op als plat tekstbestand zonder opmaak, en dat voegen we toe aan een nieuw mapje voor relevant bronmateriaal in de source tree van het project. Of dat optimaal is, daar hebben we het raden naar, maar we moeten ergens beginnen.

Entiteiten

Entiteiten in OpenFisca drukken uit voor wie we de berekening maken. Dat kunnen individuen, gezinnen of andere groeperingen van mensen zijn (bedrijven, organisaties, …). Het zijn de basisbouwstenen waarvoor we later variabelen zullen kunnen specifiëren die samen een “situatie” vormen waarvoor we een berekening zullen kunnen doen. Person en Household zijn al aanwezig in de code. Een logische vraag is dus of we, op basis van de gegeven wettekst, andere entiteiten kunnen definiëren die nuttig zouden zijn.

Na het stellen van de vraag aan GPT-5 in Cursor, met de wettekst geselecteerd als context, wordt voorgesteld de volgende entiteiten toe te voegen:

• Eligible Person for Societal Integration
• Living Wage Recipient
• Employment Project Participant

De voorgestelde aanpassingen aan de code zijn syntactisch correct. Geen van deze 3 zijn echter nuttig of noodzakelijk: het gaat in alledrie de gevallen om varianten van Person. De eigenschappen die maken dat ze bijvoorbeeld een leefloon zouden ontvangen, zijn veeleer variabelen toegevoegd aan de reeds bestaande Person entiteit. De waarde van die variabelen hangt bovendien af van andere variabelen die eveneens aan datzelfde individu gebonden zijn, zoals een inkomen uit werk of een handicapstatus. Entiteiten, die vooral dienen voor op zichzelf staande concepten, zijn hiervoor niet de juiste keuze.

Daarnaast lijkt GPT-5 het concept van een “rol” binnen een OpenFisca groepsentiteit verkeerd te hebben begrepen. Hij probeert “Eligible Person for Societal Integration” op te bouwen met verschillende “rollen” als onderdelen: “Belgian National”, “EU Citizen”, “Foreigner”, “Stateless”, “Refugee”… Dit ongetwijfeld omdat deze mogelijkheden verschijnen in Art.3, 3° lid, van de wet. In OpenFisca is een groepsentiteit echter samengesteld uit Personen die elk een rol krijgen. Een Household bevat zo Adult en Child rollen. Het is vrij nonsensicaal dat een EligiblePerson meerdere Foreigners zou kunnen bevatten. Nationaliteit of herkomst, of andere voorwaarden die gesteld worden in deze wet, zijn ook hier variabelen die gebonden zijn aan de persoon, geen entiteit op zich.

Op een ander moment werd nog een aparte entiteit gecreëerd voor het OCMW. Hoewel het logisch lijkt om de OCMWs te modelleren en als een entiteit te beschouwen – ze worden immers vermeld in de wet – is het dat hier (nog) niet. Er zijn immers geen verschillende types OCMWs met verschillende eigenschappen of rollen, waarvoor we telkens andere berekeningen moeten maken. In de context van deze wet, waarbij het de burger is voor wie we het recht op maatschappelijke steun berekenen, is het OCMW vooral een constant, invariant gegeven. In OpenFisca kunnen we dat dus vooralsnog overslaan. (Een entiteitstype “instituut” is ook niet voorzien.)

We merken hier dus dat Cursor niet “nee” kan antwoorden op de vraag of er nuttige andere entiteiten kunnen toegevoegd worden. Het kan de denkrichting achter die vraag niet bekritiseren of corrigeren uit eigen beweging. Doorheen het hele experiment bleken Cursor en GPT-5 ook een neiging te vertonen tot onnodige complexiteit. Dit is voor developers die met onbekende code of frameworks werken een groot risico: indien men te snel te ver meegaat met zulke suggesties, dreigt men later de pedalen te verliezen en achteraf erg moeilijke correcties te moeten aanbrengen aan de fundamenten van het project. Eens een verkeerde route is ingeslagen, blijkt het ook moeilijk om op de stappen terug te keren en deze weer te doen vergeten. Zeker als men ze eerst onwetend heeft toegelaten, komen ze terecht in de context en wordt er in vervolgvragen op verdergebouwd. Deze sluipende “context rot” is ondertussen een bekend probleem en een belangrijke oorzaak van tijdverlies met AI-enabled coding.

Variabelen

De kern van het model zit in de variabelen die de rechten en voorwaarden uit de wet voorstellen. Artikel 2 van de wet somt de verschillende vormen van maatschappelijke integratie op waarop iemand recht kan hebben (o.a. tewerkstelling, leefloon, geïndividualiseerd project). Artikel 3 bevat de voorwaarden waaraan een persoon moet voldoen om van dat recht gebruik te maken. We hebben deze bepalingen stap voor stap in code omgezet.

Recht op maatschappelijke integratie betekent in de praktijk dat een OCMW een persoon moet ondersteunen via (1) een job of opleiding, (2) een leefloon, of (3) een geïndividualiseerd project voor maatschappelijke integratie. Dit kan vertaald worden naar drie boolean variabelen op de Persoon-entiteit, bijvoorbeeld employment_right, living_wage_right en individualized_project_right. Cursor geeft hier een goede code-suggestie, en voorziet een eenvoudige placeholder-formule: zolang iemand “in aanmerking komt voor integratie” (een andere variabele) zou het recht gelden. We bekomen een definitie van employment_right als volgt:

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

class employment_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  def formula(person, period, parameters):
    return person("eligible_for_integration", period)

De invulling van deze placeholder-formule komt aan bod in het daaropvolgende Artikel 3. Die modelleert de volgende voorwaarden om in aanmerking te komen:

• Verblijf in België (volgens de regels nader te bepalen bij KB).
• Leeftijd: De persoon is meerderjarig (18+), of als minderjarige gelijkgesteld aan een meerderjarige volgens de uitzonderingen in deze wet.
• Nationaliteit of verblijfsstatuut: De persoon is Belg, EU-burger (na 3 maanden verblijf), ingeschreven vreemdeling, staatloze, vluchteling of subsidiair beschermde.
• Onvoldoende bestaansmiddelen
• Werkbereidheid (tenzij onmogelijk om gezondheidsredenen of billijkheidsredenen).
• Rechten uit andere stelsels uitgeput

Al deze voorwaarden komen samen in één centrale boolean variabele societal_integration_right. Die variabele geeft aan of iemand, gegeven zijn persoonlijke situatie, recht kan hebben op maatschappelijke integratie. In feite is dit de vertaalslag van “voldoet de persoon aan alle voorwaarden van art.3?”. De formule combineert alle subvoorwaarden:

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

class societal_integration_right(Variable):
  value_type = bool
  entity = Person
  definition_period = MONTH
  label = "Right to societal integration"
  def formula(person, period, parameters):
    residency = person("residency_status", period)
    is_major = person("is_major", period)
    nationality = person("nationality_status", period) in ["belgian", "eu_citizen", "registered_foreigner", "stateless", "refugee"]
    insufficient_income = not person("has_sufficient_income", period)
    willing_to_work = person("willing_to_work", period)
    claiming_benefits = person("claiming_benefits", period)
    return (residency and is_major and nationality and insufficient_income and willing_to_work and claiming_benefits)

Let hier vooral op enkele vreemde lacunes in de suggestie van Cursor. Zo is de naam van de variabele societal_integration_right niet gelijk aan de eerder gedefinieerde placeholder eligible_for_integration, hoewel dat wel de bedoeling is. Daarnaast wordt in de nationaliteitsvoorwaarde de mogelijkheid van subsidiair beschermden simpelweg vergeten! Tot slot is de zesde voorwaarde, dat men eerst zijn rechten laat gelden op eventuele sociale uitkeringen, wel erg rudimentair benoemd als claiming_benefits – een variabelenaam die niet echt dekt wat bedoeld wordt.

We kunnen deze suggestie dus wel aanvaarden, maar we zijn al direct verplicht om 3 correcties door te voeren. De niet-overeenkomst van de variabelenaam kunnen we daarbij nog gemakkelijk detecteren omdat de tests niet zullen werken als er nog ongedeclareerde variabelen in de code zitten. Een mankerend element in de formule, zoals een vergeten voorwaarde, is echter veel gemakkelijker over het hoofd gezien, en leidt wanneer dat ongedetecteerd blijft gegarandeerd tot fouten in de uitvoering. Hier merken we dus echt wel de noodzaak om terug te koppelen naar de wettekst om te verifiëren dat de gegenereerde code wel degelijk overeenkomt met wat de wettekst zegt. Deze terugkoppeling moet aandachtig genoeg gebeuren om ook ongelukkige benamingen of subtiele misinterpretaties van te tekst te kunnen identificeren.

Eventuele correcties kunnen daarnaast ook best zo snel mogelijk gebeuren. Als foutieve code in de editor aanwezig blijft, gaat ze immers deel uitmaken van de context die het AI-model gebruikt en dient ze zelf als fundament voor daaropvolgende suggesties. Dit kan leiden tot een situatie waarbij men suggesties blijft ontvangen waarin steeds dezelfde fouten terugkomen, die men dus ook telkens weer moet corrigeren, wat niet bevorderlijk is voor de productiviteit.

De variabelen gebruikt in de formula() methode van societal_integration_right hierboven, moeten uiteraard op hun beurt ook gedefinieerd worden: voor elk van deze variabelen moeten we een klasse schrijven. Dit kan aanleiding geven tot complexe kettingen van afhankelijkheden. Zo zou is_major een eenvoudige booleaanse inputvariabele kunnen zijn, maar we kunnen dat ook berekenen op basis van de datum van vandaag en weer een nieuwe variabele birthdate. De berekening van de formule van de variabelen kan daarnaast ook gebruik maken van de parameters van een wet – zo is de meerderjarigheid in België pas vanaf 18 jaar sinds 1 mei 1990. Dat zou ons dan weer bij het Burgerlijk Wetboek brengen, en haar geschiedenis – om het beknopt te houden gaan we daar nu niet verder op in.

Laatste opmerking: het model zoals hier gebouwd is uiteraard een vereenvoudigde weerspiegeling. Merk wel op dat we zelfs dan, slechts 3 artikels ver in een wet, al snel 10 Python-klassen hebben gedefinieerd hebben, met potentieel voor meer als we echt in de diepte zouden willen gaan. Cursor en GPT-5 schrijven daarbij relatief verbose code, met vele hulpvariabelen en -methodes, die soms echt wel eenvoudiger kan. Sommige details uit de wet, zoals de 3-maanden wachttijd voor EU-burgers, of de uitzonderingen die bestaan voor bepaalde categorieën van minderjarigen (Art. 7), zouden in een volwaardig model nog heel wat extra variabelen of condities vergen.

AI en code: enkele valkuilen

Wat betreft best practices voor de inzet van AI-hulp bij zulke projecten, identificeren we nog enkele valkuilen, naast diegene die we tot nu toe al genoemd hebben.

Teveel documentatie toevoegen in het begin leidt snel tot “context confusion“, waarbij de suggesties of de antwoorden van de LLM gebaseerd gaan zijn op stukken informatie die (nog) niet relevant zijn. Het is beter de documentatie geleidelijk toe te voegen, in gelijke tred met de functionaliteit, in plaats van de volledige analyse en achtergrond op voorhand toe te voegen aan de IDE. In het geval van regelgeving: voeg de regels artikel per artikel toe aan de IDE, naarmate de projectontwikkeling vordert, en weersta de verleiding om de hele wettekst op voorhand als “encyclopedische referentie” te integreren in de IDE.

Context rot of context poisoning ontstaat dan weer wanneer de AI een verkeerde weg is ingeslagen,  daarop voortboomt, en uiteindelijk relevantere informatie vergeet zodat het ook moeilijker wordt om ervan te herstellen. “Context quarantining“, het opdelen van het probleem in kleinere deelproblemen elk met hun eigen context, is daarvoor een logische remedie. Dit is ook de weg die de meeste “deep research” of “multi-agentic” systemen inslaan. In een IDE zou dat impliceren dat een AI-systeem de codebase en de documentatie vanaf een zekere grootte zou moeten segmenteren. Hoe dat technisch uitgewerkt kan worden achter de schermen lijkt een uitdaging van formaat, en verschillende IDEs zullen daar in de nabije toekomst waarschijnlijk hun eigen approach voor ontwikkelen.

Een andere frustratie was dat de AI soms code of bestanden verkeerd plaatste of aannam dat bepaalde dingen bestonden. Zo refereerden gegenereerde formules naar variabelen die nog helemaal niet gedefinieerd waren. Dit zorgt bij het testen natuurlijk voor foutmeldingen. We moesten de AI dan bijsturen of zelf extra variabelen invoegen om die referenties af te dekken. Ook kleine zaken, zoals de formattering van documentatie of het wel/niet aanmaken van noodzakelijk imports, vergden manuele correctie. Dit soort inconsistenties tonen aan dat je AI-suggesties niet blindelings kunt vertrouwen. Een developer moet voortdurend valideren of de code die gegenereerd wordt strookt met de bedoeling, en zo niet, onmiddellijk ingrijpen.

publi.codes

We willen ook nog wijzen op het bestaan van publi.codes als eventueel alternatief voor OpenFisca. Recenter en moderner, moeten de regels daar gecodeerd worden in een YAML-formaat, wat veel hanteerbaarder is dan het schrijven van subklassen in Python, en veel leesbaarder voor niet-developers. Men is in ruil daarvoor echter wel beperkt tot de bewerkingen die zijn toegelaten door de achterliggende motor. Pas vanaf de nog in ontwikkeling zijnde versie 2 komen daar mogelijkheden bij om barema’s te encoderen, of abattementen (vrijgestelde bedragen), die in België erg veelvuldig voorkomen.

De huidige versie van publi.codes is bovendien afhankelijk van het NPM ecosysteem dat tegenwoordig regelmatig geplaagd wordt door supply chain aanvallen. Publi.codes v2 zou dan weer gecompileerd worden naar OCaml, een programmeertaal die we bij Smals niet gebruiken. Gezien de kans klein is dat Smals deze programmeertaal zou willen introduceren in haar portfolio (en een ondersteunend team ervoor zou willen uitbouwen), leek het weinig nuttig om voor deze oefening ook publi.codes in de diepte te bekijken. Het valt echter wel op dat op het vlak van UI-componenten, publi.codes wel enkele libraries heeft klaarliggen.

Conclusie

Zowel OpenFisca als publi.codes zijn als platform vooral sterk wanneer je regels kunt modelleren als expliciete, testbare berekeningen. Minder ideaal is het voor regels die vooral draaien op discretionaire beslissingen, vrije interpretatie, bewijswaardering, uitzonderingen zonder heldere parameters, of “case management”-workflows. Het zijn primair reken- en regelsystemen, geen dossierbehandelingsplatformen. Daarmee zijn ze eventueel wel geschikt als motor voor apps die belastingen of uitkeringen op niveau van persoon/huishouden kunnen berekenen (recht op iets + bedrag), of om beleidsimpact te simuleren van eventuele wijzigingen (“wat kost deze hervorming?”, “wie wint/verliest?”). Dat kan voor beleidsmakers én burgers interessant zijn.

Toch is een OpenFisca-project niet snel even opgezet. Conceptueel is OpenFisca enigszins verwarrend voor een developer: hoewel OpenFisca gebruikmaakt van Python-klassen, dienen deze niet om objecten te modelleren, maar om entiteiten, variabelen en berekeningsregels uit de regelgeving declaratief vast te leggen. Gegeven dat er 1 klasse per variabele moet geschreven worden, en er vlotjes tientallen variabelen kunnen meespelen in een fijnmazig wetsartikel, zit men met een snel groeiende stapel code die een uitdaging is om overzichtelijk georganiseerd te krijgen. Daarnaast vergt ook de ontwikkeling van een GUI veel extra werk. Het project mist nog de nodige tooling om deze recurrente problematieken te verlichten. (Het helpt natuurlijk niet wanneer de opdrachtgevende overheid in 2020 plots de kraan dichtdraait, schijnbaar van mening dat open-source projecten per definitie zelfbedruipend kunnen zijn.)

Tot slot kunnen we nog zeggen dat dit experiment tegelijk een nuttige en leerzame reality check was over wat LLMs kunnen bijdragen, en kunnen verknoeien, aan een developer-werkomgeving. Zelf de regie stevig in handen blijven houden en werken met kleine incrementele stapjes, blijft de beste raad. De ene AI tool zal daarbij al wat minder steken laten vallen dan de andere op allerlei vlakken. Het geven van negatieve antwoorden of het detecteren van fouten in de vraagstelling blijft erg uitdagend voor LLMs en dat brengt wat risico met zich mee. AI-assistentie in IDEs evolueert echter razendsnel, en een gelijkaardig experiment zal volgend jaar ongetwijfeld anders verlopen.

Rules As Code betekent zeker niet dat we vandaag een wettekst aan een AI kunnen geven om er een programma te laten uitrollen. Wel zal er op gespecialiseerde fora de komende jaren ongetwijfeld veel aandacht gaan naar de interactie tussen wet, implementatie, en AI-tooling. Vooralsnog blijft de complexiteit van de regelgeving zelf, ook met steeds betere AI, de grootste hinderpaal voor Rules As Code projecten.

(FR) Dans ce Research Talk (en Néerlandais, sous-titres FR sont disponibles), Joachim Ganseman, chercheur chez Smals, est interrogé sur ses expériences avec les systèmes « Rules as Code » (RaC) et leur mise en œuvre au sein du domaine — complexe — de la sécurité sociale. Joachim émet quelques réserves quant à l’applicabilité directe de ces systèmes dans notre contexte. Regardez et écoutez ici pourquoi.

(EN) In this Research Talk (Dutch speaking, EN subtitles available), Joachim Ganseman, researcher at Smals, is interviewed about his experiences with “Rules as Code” (RaC) systems and their implementation within the complex domain of social security. Joachim places some reservations regarding the direct applicability of these systems in our context. Watch and listen here to find out why.