In gereguleerde omgevingen is het model het makkelijke deel

De servers zouden geen verbinding met internet krijgen, en daar zou niets aan veranderen. Het hoofd security van een nationaal digitaliseringsagentschap zei het in het eerste architectuuroverleg, en het bepaalde de rest van het project. Het agentschap wilde AI-triage van tickets voor zijn servicedesk: volledig on-premises, air-gapped en zonder afhankelijkheid van een modelleverancier.

Zo hebben we het gebouwd, en het draait in productie. De les reikt veel verder dan air-gapped omgevingen. In een gereguleerde organisatie is het kiezen en draaien van het model het makkelijke deel. Het moeilijke deel is alles wat bepaalt of het model mag draaien: waar de data naartoe gaat, wat elke stap mag zien, hoe wijzigingen worden goedgekeurd en welk bewijs er achteraf is.

Hosting is een uitgangspunt van het ontwerp

Teams ontwerpen vaak rond een gehost model en stellen de hostingvraag pas aan het eind. In een gereguleerde organisatie valt een deel van de opties al af met het antwoord op de vraag waar deze data verwerkt mag worden. Dat antwoord bepaalt of een gehoste model-API acceptabel is, in welke regio en onder welk contract, of dat de 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 ICT-dienstverleners als een risico dat beheerst, gedocumenteerd en zo nodig beëindigd moet worden, en een gehoste model-API is zo'n afhankelijkheid. Hosting, de goedgekeurde lijst van modellen en aanbieders en de exitstrategie worden daarom schriftelijk vastgelegd voordat het ontwerp begint, en ze worden onderdeel van het contract. De architectuur volgt daaruit.

Eén gevolg wordt vaak onderschat: ontwikkel in dezelfde omgeving als waarin u gaat draaien. Wie ontwikkelt op een gehost model en uitrolt op een lokaal model, krijgt verschillen in gedrag die tests niet volledig vangen. Het systeem van het agentschap is gebouwd op hetzelfde type model en in hetzelfde type omgeving als productie.

Elke stap ziet alleen de velden die hij nodig heeft

Dataminimalisatie wordt meestal als beleid opgeschreven. Wij behandelen het als een eigenschap van elke afzonderlijke stap. Een triagestap die bepaalt welk team een ticket oppakt, heeft de tekst van het ticket en de lijst van teams nodig. Het identificatienummer van de melder, diens eerdere tickets en de bijlagen heeft hij niet nodig. Deterministische code stelt een weergave met alleen die velden samen voordat het model wordt aangeroepen.

Dat beperkt wat er kan uitlekken, en de datastroom is zo in één tabel uit te leggen: stap, velden erin, velden eruit, waar het draait. Om die tabel vraagt een functionaris gegevensbescherming meestal als eerste, en hij is veel makkelijker uit het ontwerp te halen dan achteraf uit logbestanden te reconstrueren.

We rekenen er niet op dat persoonsgegevens uit vrije tekst worden weggefilterd voordat die tekst ergens anders naartoe gaat. Namen, adressen en identificatienummers betrouwbaar uit ongestructureerde tekst verwijderen is moeilijker dan het lijkt. Een anonimiseringsstap die bij de meeste tickets werkt, heeft bij de rest alsnog persoonsgegevens naar buiten gestuurd. Vrije tekst wordt daarom verwerkt op de plek waar de data mag staan.

Prompts, drempels en modellen zijn code

Wijzigingen aan productiesystemen lopen via wijzigingsbeheer: aanvraag, test, goedkeuring, registratie. Prompts, drempels en versies van het model horen bij het productiesysteem, maar ze lijken op configuratie, en iedereen met toegang kan ze in een minuut aanpassen.

In een gereguleerde omgeving zijn ze code. Een promptwijziging wordt getest op de acceptatieset en goedgekeurd zoals elke andere release. Versies van het model liggen vast en veranderen alleen via een release. Bij het agentschap dwong de omgeving dit zelf af: code, libraries en modelgewichten kwamen alleen binnen via het goedgekeurde overdrachtsproces, dus niets kon ongemerkt veranderen. Elders dwingen we het af door de configuratie onderdeel van de release te maken.

Eén onderdeel wordt makkelijk vergeten: de acceptatieset zelf. Elke wijziging wordt goedgekeurd omdat ze slaagt voor de acceptatieset, dus wie de set kan aanpassen, kan ongemerkt de lat lager leggen. Nieuwe gevallen komen erin via hetzelfde wijzigingsproces als code, en voor het verwijderen van een geval zijn een handtekening van de proceseigenaar en een schriftelijke reden nodig.

Elke release heeft een bewijsdossier

Als een toezichthouder, een interne auditor of een risicocommissie vraagt hoe het systeem werkt, moet het antwoord al klaarliggen. Bij elke release hoort een bewijsdossier: de tabel met datastromen, de gebruikte modellen en versies en waar ze draaien, de acceptatieresultaten vergeleken met de vorige release, de vastgelegde goedkeuringen en de lijst met wijzigingen. De releasepipeline stelt het samen. Niemand schrijft het speciaal voor de audit.

Het dossier maakt het ook voor het eigen team van de klant veilig om na de overdracht wijzigingen door te voeren, omdat het vastlegt hoe een goed werkend systeem er op de dag van de release uitzag.

Logging en minimalisatie trekken in tegengestelde richtingen

Deze spanning bestaat echt en wordt zelden benoemd. Controleerbaarheid vraagt om alles te loggen: elke invoer, elke uitvoer, elke tussenstap. De regels voor minimalisatie en bewaartermijnen vragen om zo weinig mogelijk persoonsgegevens, zo kort mogelijk bewaard. Een systeem dat de volledige tekst van alle tickets voor altijd bewaart, is uitstekend te controleren en onder de privacyregels nauwelijks te verdedigen.

Wij lossen dat op door te scheiden wat nodig is om een beslissing uit te leggen en wat nodig is om haar opnieuw uit te voeren. Het dossier bewaart de beslissing, verwijzingen naar het bewijs, de versies van model en regels, en een hash van de invoer. De volledige invoer blijft in het bronsysteem onder de bestaande bewaartermijnen, en het dossier verwijst ernaar. Wordt het bronrecord volgens schema verwijderd, dan is de beslissing nog steeds uit te leggen, maar niet meer opnieuw uit te voeren met de oorspronkelijke tekst. De klant stemt per workflow uitdrukkelijk in met die afweging, en die wordt in het ontwerp vastgelegd.

De beheersmaatregelen blijven, het model niet

De air gap maakte het systeem van het agentschap juist makkelijker te beheren: vaste versies, geen externe aanroepen, geen abonnement waarvan de prijs kon veranderen, niets dat het gebouw verliet. Het model zelf kan morgen worden vervangen. Het hostingbesluit, de datastroom, het wijzigingsbeheer en het bewijs blijven, want in een gereguleerde organisatie zijn dat het eigenlijke systeem.