Gereguleerde AI is een operationeel vraagstuk

De servers zouden nooit verbinding met internet hebben. Het hoofd beveiliging van een nationaal digitaliseringsagentschap zei het in het eerste architectuuroverleg, en dat bepaalde de rest. Het agentschap wilde dat AI de tickets sorteerde die bij de servicedesk binnenkwamen: 100% in eigen huis, afgesloten van externe netwerken, zonder afhankelijkheid van een modelleverancier.

We hebben het zo gebouwd, en het draait dagelijks. De les reikt veel verder dan offline systemen. In een gereguleerde organisatie is het kiezen en draaien van het AI-model het makkelijke deel. Moeilijk is wat bepaalt of het mag draaien: waar data heen gaat, wat elke stap ziet, hoe wijzigingen worden goedgekeurd, welk bewijs er achteraf is.

Waar het draait, is input voor het ontwerp

Teams ontwerpen vaak rond het model van een leverancier en vragen pas aan het eind naar hosting. In een gereguleerde organisatie schrapt "waar mag deze data worden verwerkt" opties voordat het ontwerp begint. Het bepaalt of het model van een leverancier acceptabel is, in welke regio, onder welk contract, of dat modellen op de eigen hardware van de klant moeten draaien.

Voor financiële instellingen in de EU geldt sinds januari 2025 de Digital Operational Resilience Act (DORA). Die behandelt afhankelijkheid van externe technologieleveranciers als een risico dat beheerst, gedocumenteerd en zo nodig beëindigd moet worden, en het model van een leverancier is precies zo'n afhankelijkheid. Hosting, goedgekeurde modellen en leveranciers en de uitweg worden daarom voor het ontwerp schriftelijk vastgelegd en gaan het contract in. De architectuur volgt daaruit.

Een gevolg daarvan: bouw waar u gaat draaien. Bouw op het model van een leverancier, draai op een lokaal model, en ze gedragen zich anders op manieren die tests missen. Het agentschap bouwde in dezelfde soort omgeving als het live systeem.

Elke stap ziet alleen de data die hij nodig heeft

Dataminimalisatie is meestal beleid. Wij maken het een eigenschap van elke stap. Een stap die beslist welk team een ticket oppakt, heeft de tickettekst en de teamlijst nodig. Niet het identiteitsnummer van de aanvrager, niet diens geschiedenis en niet de bijlagen. Eenvoudige code stelt een overzicht met alleen die velden samen voor het model iets ziet.

Dat beperkt wat kan uitlekken en zet de datastroom in één tabel: stap, data erin, data eruit, waar hij draait. Een functionaris gegevensbescherming vraagt er meestal eerst om, en hem uit het ontwerp halen is veel makkelijker dan hem uit logs reconstrueren.

We vertrouwen er niet op dat persoonsgegevens uit vrije tekst worden gefilterd voordat die ergens anders heen gaat. Namen, adressen en nummers betrouwbaar uit vrije tekst halen is lastiger dan het lijkt, en een filter dat bij de meeste tickets werkt, heeft er toch een paar naar buiten gestuurd. Vrije tekst blijft waar de data mag zijn.

Instructies, drempels en modellen zijn software

Live systemen veranderen via wijzigingsbeheer: aanvraag, test, goedkeuring, vastlegging. De geschreven instructies aan het model (prompts), de drempels en de versie horen bij het live systeem, maar lijken instellingen die iedereen met toegang in een minuut aanpast.

In een gereguleerde omgeving worden ze behandeld als software. Een wijziging van de instructies wordt getest tegen een vaste set echte gevallen met bekende juiste antwoorden en goedgekeurd zoals elke release. De versie van het model ligt vast en verandert alleen via een release. Bij het agentschap dwong de omgeving dat zelf af: code en modellen kwamen alleen binnen via het goedgekeurde overdrachtsproces, dus niets kon ongemerkt veranderen. Elders maken we de instellingen deel van de release.

Elke wijziging als release behandelen heeft een eigen nadeel: heeft een correctie van één woord hetzelfde comité nodig als een nieuw model, dan stopt het team met kleine dingen verbeteren en raakt het systeem los van het werk. Voor de livegang spreken we daarom wijzigingsklassen af met het risicoteam van de klant, op papier, zodat niemand erover twist als een correctie nodig is.

Eén ding wordt makkelijk vergeten: de testset zelf. Elke wijziging wordt goedgekeurd omdat ze de set doorstaat, dus wie de set mag aanpassen, kan stilletjes de lat verlagen. Gevallen komen erbij via hetzelfde wijzigingsproces, en er een verwijderen vraagt akkoord van de proceseigenaar en een schriftelijke reden.

Elke release heeft een bewijsdossier

Vraagt een toezichthouder, auditor of risicocomité hoe het systeem werkt, dan is het antwoord er al. Elke release heeft een bewijsdossier: de tabel met de datastroom, de gebruikte modellen en versies en waar ze draaien, de testresultaten vergeleken met de vorige release, de goedkeuring en de lijst met wijzigingen. Het releaseproces maakt het; niemand schrijft het voor de audit. Het maakt wijzigen ook veilig voor het eigen team van de klant na de overdracht, omdat het vastlegt hoe werken eruitzag op de dag van de release.

Vastleggen en dataminimalisatie trekken in tegengestelde richtingen

Controleerbaarheid duwt richting alles vastleggen. Gegevensbescherming duwt richting zo weinig mogelijk persoonsgegevens zo kort mogelijk bewaren. Een systeem dat volledige tickettekst voor altijd vastlegt, is heel goed te controleren en heel moeilijk te verdedigen.

We scheiden wat een beslissing nodig heeft om uitgelegd te worden en wat ze nodig heeft om herhaald te worden. Het dossier van een geval bewaart de beslissing, verwijzingen naar het bewijs, de versies van model en regels, en een vingerafdruk van de invoer die bewijst wat die was zonder hem op te slaan. De volledige invoer blijft in het bronsysteem onder de bestaande bewaartermijnen. Wordt die volgens schema verwijderd, dan is de beslissing nog uit te leggen, maar niet meer opnieuw te draaien op de oorspronkelijke tekst. De klant stemt per workflow in met die afweging, in het ontwerp.

Er is een tweede reden om uitleg te beloven in plaats van herhaling. Zelfs met hetzelfde model, dezelfde instructies en instellingen geeft een taalmodel niet altijd twee keer hetzelfde antwoord. Horace He en collega's bij Thinking Machines Lab herleidden de hoofdoorzaak tot de serverbelasting, die verandert hoe verzoeken worden gebundeld en daarmee de rekensom achter elk antwoord ("Defeating Nondeterminism in LLM Inference", september 2025). Eén ander woord kan een indeling veranderen. Wie een toezichthouder belooft elke beslissing op verzoek te kunnen reproduceren, belooft iets wat de techniek niet betrouwbaar doet. Wij leggen de versie van het model, instellingen, vingerafdruk van de invoer en uitvoer vast, en beloven dat elke beslissing daaruit uit te leggen is. Die belofte kunnen we houden.

De terugvalroute is een controle

De vraag die de meeste ontwerpreviews in gereguleerde omgevingen afsluit: wat als u dit vandaag moet uitzetten? Een toezichthouder vraagt het na een incident elders, een leverancier trekt een model terug, of een nieuwe regel gaat in. DORA vraagt hetzelfde van elke technologiedienst achter een kritieke functie, als exitstrategie.

Daarom heeft elke stap die een model gebruikt een route zonder model. Bij het sorteren van tickets gaat een ticket dat het model niet kan indelen, of elk ticket zolang het model uit staat, naar een algemene wachtrij die mensen afhandelen zoals vroeger, met de velden die eenvoudige regels kunnen invullen al ingevuld. Elke release meet die terugvalroute ook, dus de voorsprong van het model staat op papier. Die beantwoordt wat risicocomités vroeg of laat vragen: waarom hier überhaupt een model? Het model uitzetten is een geteste routine met een benoemde eigenaar, geen noodgeval.

De controles overleven het model

Offline was het systeem van het agentschap makkelijker te beheren: vaste versies, geen externe aanroepen, geen abonnement waarvan de prijs kan stijgen, niets dat het gebouw verlaat. Het model erin kan morgen worden vervangen. De keuze waar het draait, de datastroom, het wijzigingsbeheer en het bewijs blijven, want in een gereguleerde organisatie zijn dat het systeem.