"Privacy by design" staat in heel veel offertes. Bij ons is het geen kreet maar een set keuzes die de architectuur van iedere oplossing stuurt, lang voordat er één regel code wordt geschreven. In dit artikel laten wij zien wat dat concreet betekent voor de hosting, de dataverwerking en de modelkeuzes in een typische deployment.
Wij werken bijna uitsluitend voor overheidsorganisaties. Dat brengt drie eisen met zich mee die in onze ervaring vaak verkeerd worden ingeschat: data mag niet zomaar de EU verlaten, het moet altijd te herleiden zijn waar een antwoord vandaan komt, en sommige gegevens horen sowieso niet in een cloud-LLM thuis. Hieronder leest u hoe wij deze drie eisen vertalen naar concrete componenten.
1. Hosting binnen de EU is het uitgangspunt, niet de optie
Wij draaien onze AI-componenten standaard op infrastructuur in de EU. Voor klanten die met Microsoft Azure werken kiezen wij regio's als West Europe of North Europe, en zetten wij de model-endpoints zo in dat verkeer de EU niet verlaat. Voor open source modellen die wij zelf hosten geldt hetzelfde: alle inference-servers staan in een EU-datacenter, met een netwerkconfiguratie die uitgaand verkeer naar buiten de EU blokkeert.
Klanten die nog strenger willen zitten, kunnen onze stack volledig binnen hun eigen Azure-tenant of on-premise omgeving laten draaien. Wij leveren dan de architectuur, de modellen en het beheer, en de klant houdt fysieke controle over de infrastructuur. Dat is met name relevant voor sociaal domein en bepaalde belastingfunctionaliteiten.
2. Persoonsgegevens worden gemaskeerd voordat ze de pipeline ingaan
Voor elke pipeline die documenten of gesprekken verwerkt, draait een PII-detectiestap aan het begin van de keten. Wij combineren regex-patronen voor gestructureerde gevallen zoals BSN's, postcodes en e-mailadressen met open source named entity recognition modellen die personen, locaties en organisaties herkennen die niet in een vast patroon vallen.
Het effect is dat een document waaruit context wordt gehaald, gestript wordt voordat het bij een LLM aankomt. Voor een AI-assistent die op basis van interne kennis een vraag beantwoordt, is dat vaak voldoende: de assistent leert de structuur en het beleid, niet de individuele dossiers. Bij gesprekstranscripties, zoals onze WMO-oplossing, blijft de informatie wel in de samenvatting maar wordt deze nooit verzonden naar externe modellen.
3. Bron-trouw als bouwblok van het antwoord
Een groot deel van wat een gebruiker als "vertrouwen" ervaart, komt voort uit herleidbaarheid. Onze RAG-pipelines zijn zo gebouwd dat ieder antwoord verwijst naar de exacte passages waaruit het is samengesteld. Dat is niet cosmetisch: het is een ontwerpkeuze die zorgt dat het model niet kan "improviseren" buiten de aangereikte bronnen om.
Praktisch betekent dit dat onze prompts modellen instrueren om alleen te antwoorden vanuit de meegegeven context, en de evaluatie-pipeline meet hoe vaak het antwoord daadwerkelijk steunt op die context (bron-grounding). Een wijziging gaat pas live als deze metric op groen staat.
4. Voor extra gevoelige data: lokaal verwerken
Niet elke verwerking past in een gedeelde cloud, hoe goed beveiligd ook. Voor specifieke use cases bouwen wij offline oplossingen die volledig binnen de fysieke infrastructuur van de organisatie draaien. Een voorbeeld is onze voorleesoplossing voor laaggeletterde inwoners: brieven worden ingelezen, voorgelezen en vertaald op een apparaat in het gemeentehuis, zonder dat ook maar een byte naar buiten gaat.
Dat brengt eigen uitdagingen mee, zoals modelgrootte, updates en monitoring zonder cloud-telemetrie, maar het is de enige verantwoorde keuze voor data die letterlijk persoonlijke post is.
5. Auditeerbaarheid: wat is er gebeurd, wanneer en waarom
In een overheidsomgeving is achteraf kunnen reconstrueren minstens zo belangrijk als het draaien zelf. Wij loggen per request welke versie van de prompt-componenten is gebruikt, welke documenten in de retrieval terecht zijn gekomen, welk model heeft geantwoord, en wat er aan de gebruiker is teruggegeven. Persoonsgegevens worden in deze logs gepseudonimiseerd, zodat ze inhoudelijk geanalyseerd kunnen worden zonder dat ze herleidbaar zijn naar individuen.
Wat dit betekent voor uw architectuur
Privacy by design is geen vinkje op een lijst. Het is de optelsom van een aantal kleine, soms saai-praktische, keuzes: in welke regio draait de inference, wat doet de eerste stap van de pipeline met PII, hoeveel context geeft u het model mee, en kunt u achteraf precies reconstrueren wat er is gebeurd. Wij maken die keuzes per oplossing expliciet, en leggen ze vast in een document dat klant, DPO en ontwikkelaar allemaal begrijpen.
Het mooie is dat veel van deze keuzes geen prestatie of bruikbaarheid kosten. Een goed ontworpen RAG-pipeline met EU-hosting en bron-trouw voelt voor de gebruiker exact hetzelfde als een snelle generieke chatbot, maar is uitlegbaar, controleerbaar en past binnen de regels die wij voor de publieke sector belangrijk vinden.