Agentic code in de zorg: waarom human-in-the-loop niet genoeg is

We laten AI steeds vaker zelfstandig code schrijven. In de zorg, bij financiële instellingen, bij uitvoeringsorganisaties. Agentic coding tools genereren niet alleen suggesties, maar hele features, refactoren autonoom en doen pull requests uit zichzelf. De vraag is niet langer óf we dit toelaten, maar wie er meekijkt, en wanneer.

Laatst zat ik bij een grote zorginstelling waar een team een AI-assistent had gekoppeld aan hun CI/CD-pipeline. De tool schreef validatieregels voor patiëntgegevens. De tech lead vertelde trots dat ze ‘human-in-the-loop’ hadden ingebouwd: elke gegenereerde regel werd handmatig gereviewed. Maar toen ik vroeg hoe ze bepaalden wélke regels extra aandacht nodig hadden, bleef het stil. Alles kreeg dezelfde review. Dat is niet alleen inefficiënt, het is gevaarlijk. Want een logging-functie is niet hetzelfe als een functie die medicatiedoseringen berekent.

Precies dit probleem wordt aangepakt in een nieuw paper dat deze week op arXiv verscheen: Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains.[^1] De auteurs introduceren een framework, GAIE, dat codegeneratie routeert naar drie niveaus van toezicht, afhankelijk van de regulatory impact van de wijziging. Geen binaire keuze tussen ‘alles handmatig’ of ‘alles automatisch’, maar een glijdende schaal.

De drie lagen van GAIE

Het framework definieert drie oversight-modi:

1. Human-in-the-loop (HITL), voor wijzigingen met hoge impact. Denk aan code die direct raakt aan patiëntveiligheid, financiële transacties boven een bepaalde drempel, of verwerking van bijzondere persoonsgegevens. Een mens moet elke stap expliciet goedkeuren voordat de code gemerged wordt.

2. Human-over-the-loop (HOTL), voor wijzigingen met gemiddelde impact. De AI werkt autonoom, maar een mens kan ingrijpen of moet achteraf steekproefsgewijs valideren. Denk aan aanpassingen in logging, monitoring, of niet-kritieke business logic.

3. Automated-with-monitoring (AwM), voor wijzigingen met lage impact. Denk aan code-formatting, documentatie-updates, of refactoring zonder semantische wijzigingen. Het systeem valideert zichzelf tegen vooraf gedefinieerde regels en constraints.

De crux zit in de routering: hoe bepaal je in welke categorie een gegenereerde wijziging valt? Het paper stelt een impact-classificator voor die kijkt naar drie dimensies: (1) het datatype dat de code verwerkt (persoonsgegevens, financiële data, medische data), (2) de systeemcontext (productie, staging, test), en (3) de aard van de wijziging (nieuwe feature, bugfix, refactor). Op basis daarvan wordt een regulatory impact score berekend die de oversight-modus bepaalt.

Concreet: hoe ziet dat eruit in een pipeline?

Stel, een agentic coding tool dient een pull request in. Een pre-merge check haalt de metadata op: welke bestanden zijn gewijzigd, welke functies, welke datavelden worden geraakt. Een policy engine, gevoed met regels uit de EU AI Act, ISO/IEC 42001 en NIST AI RMF, kent een score toe. Bij een score boven de 80 (schaal 0-100) wordt de PR geblokkeerd totdat een geautoriseerde reviewer expliciet akkoord geeft. Tussen 40 en 80 komt de PR in een queue voor steekproefreview, maar mag na een bepaalde tijd automatisch mergen als er geen bezwaar komt. Onder de 40 gaat hij direct door, mits alle geautomatiseerde tests slagen.

De auteurs mappen dit expliciet op de risicocategorieën van de EU AI Act. Code die raakt aan een AI-systeem met een ‘hoog risico’ (bijv. toegangscontrole tot essentiële diensten) valt onder HITL. Code voor een systeem met beperkt risico (bijv. een chatbot voor algemene vragen) kan onder HOTL of AwM vallen. Die mapping is geen theoretische exercitie, het geeft een praktisch handvat voor compliance officers die moeten aantonen dat hun organisatie passende menselijke controle heeft, zoals artikel 14 van de AI Act vereist.

Waarom dit voor Nederland urgent is

Nederlandse publieke organisaties zitten met steeds complexere AI-systemen. Denk aan slimme dienstverlening, automatische besluitvorming, of data-analyse in crisistijd. De EU AI Act stelt eisen, maar laat ruimte voor interpretatie. Hoe zorgen we dat die eisen ook in de praktijk worden nageleefd? Niet met een checklist, maar met structurele inbedding in de ontwikkelprocessen. GAIE biedt een blauwdruk om die inbedding concreet te maken, niet als een los staand beleidsdocument, maar als onderdeel van de codepipeline zelf. Dat is niet alleen beter voor compliance, het maakt ook de systemen veiliger en transparanter.