RAG in productie: De governance-checklist die securityteams nodig hebben vóór livegang

Het verschil tussen een RAG-pilot en een productie-inzet is niet technisch — het is een governance-kloof. Pilots worden gebouwd om AI-capaciteiten te bewijzen, dus nemen ze kortere routes: brede serviceaccounttoegang, minimale logging, geen handhaving van beleid.

Precies die kortere routes zijn wat securityteams signaleren zodra een productiereview start. De meeste AI data governance-raamwerken zijn niet geschreven met AI retrieval pipelines in gedachten, waardoor organisaties die RAG naar productie brengen, moeten voldoen aan vereisten die nooit voor hen bedoeld waren.

Deze post biedt beide kanten — securityteams en AI-engineeringteams — een gedeeld raamwerk: de vijf governance-vereisten waaraan RAG moet voldoen voordat het een productiegoedkeuring krijgt.

Executive Summary

Belangrijkste idee: RAG-pilots omzeilen routinematig de toegangscontroles, auditvereisten en complianceverplichtingen die productie-inzet niet kan negeren. De kloof is geen technologisch probleem — het is een architectuurprobleem.

Waarom dit relevant is: Organisaties die governance overslaan om AI-inzet te versnellen, creëren compliance-risico’s die toezichthouders uiteindelijk zullen ontdekken en beveiligingsincidenten die direct te herleiden zijn naar ongecontroleerde AI-data toegang. De organisaties die het snelst gaan, zijn degenen die governance vanaf dag één hebben ingebouwd, niet degenen die het achteraf toevoegen nadat een securityreview hun lancering heeft vertraagd.

5 Belangrijkste Inzichten

1. RAG is data access op schaal. Dezelfde wettelijke complianceverplichtingen die gelden voor een mens die een gevoelig bestand opent, gelden ook voor een AI die dat bestand ophaalt voor een RAG-query — HIPAA, GDPR en SOX maken geen uitzonderingen voor AI, en toezichthouders geven dit actief aan.
2. De meeste RAG-pilots geven het AI-systeem brede repositorytoegang via overgeprivilegieerde serviceaccounts. Productie-inzet vereist autorisatie per verzoek via RBAC- en ABAC-engines die het minste privilege afdwingen op de retrieval-laag, niet alleen bij het maken van de verbinding.
3. Zonder een volledige audittrail die elke AI-dataopvraging toewijst aan een specifieke gebruiker, AI-systeem en tijdstempel, kunnen organisaties niet aantonen welke data hun AI heeft geraadpleegd — een kloof die niet voldoet aan HIPAA-, GDPR-, SOX- en FedRAMP-documentatievereisten.
4. Zero-trust architectuur moet worden uitgebreid naar AI-systemen. Een AI-pipeline is geen vertrouwde gebruiker. Elk data-verzoek moet onafhankelijk worden geauthenticeerd en geautoriseerd, en authenticatiegegevens mogen nooit toegankelijk zijn voor het AI-model zelf.
5. Een gecontroleerde datalaag tussen het AI-systeem en de datarepository is het architectuurpatroon dat de kloof tussen pilot en productie oplost — het handhaaft toegangscontrole, genereert audittrails en evalueert compliancebeleid zonder aparte AI-specifieke governance-infrastructuur nodig te hebben.

Waarom RAG-pilots je niet voorbereiden op productie

RAG-pilots zijn gebouwd om één vraag te beantwoorden: kan AI bruikbare antwoorden genereren op basis van onze interne data? Governance wordt bewust uitgesteld omdat het het proof of concept vertraagt. Het resultaat is een prototype-architectuur die niemand bedoelt voor productie, maar die vaak toch wordt ingezet — met een serviceaccount dat overal bij kan, geen gebruikersattributie in de logs en genegeerde dataclassificatielabels.

Securityteams blokkeren RAG niet als ze deze architecturen ter discussie stellen. Ze stellen dezelfde vragen als bij elk systeem dat gevoelige data verwerkt: wie kan wat benaderen, hoe weten we wat is geraadpleegd, en hoe bewijzen we aan auditors dat toegang is gecontroleerd. Het probleem is dat de meeste RAG-architecturen geen antwoord hebben op deze vragen. De AI-databeschermingsmaatregelen die enterprise data-omgevingen vereisen, waren simpelweg geen onderdeel van het pilotontwerp.

De onderstaande checklist geeft teams aan beide kanten een concreet pakket aan vereisten — en een gedeelde taal voor hoe gecontroleerde RAG eruitziet.

De Governance-kloof: Wat productie-RAG werkelijk vereist

Productie-RAG moet voldoen aan vijf governance-domeinen voordat het een security-goedkeuring krijgt. Dit zijn geen aspirerende beste practices — het zijn de minimale vereisten opgelegd door bestaande datacompliance-raamwerken, zero-trust beveiligingsprincipes en de praktische realiteit van AI op enterprise-schaal.

1. Toegangscontrole: Ziet de AI alleen wat de gebruiker mag zien?

De meest voorkomende governancefout in RAG-inzet is te ruime data-toegang. Een RAG-pipeline die via een geprivilegieerd serviceaccount verbinding maakt met een documentrepository, kan alles ophalen waartoe dat account toegang heeft — ongeacht of de gebruiker die de query indient, daarvoor geautoriseerd is. Dit is geen theoretisch risico. Het is de standaardarchitectuur voor de meeste RAG-pilots.

Productie-RAG vereist dat het AI-systeem de rechten erft van de gebruiker namens wie het handelt — niet meer en niet minder. Dat betekent RBAC- en ABAC-beleid geëvalueerd op de retrieval-laag bij elke query, niet alleen bij het maken van de verbinding. Een medewerker op een regiokantoor mag geen toegang krijgen tot directiebeloningsdata door simpelweg een vraag in natuurlijke taal te stellen. Een AI-pipeline mag de toegang niet uitbreiden tot buiten wat de onderliggende toegangscontroles via andere kanalen zouden toestaan.

Wat te verifiëren: het AI-systeem kan geen data ophalen die de geauthenticeerde gebruiker niet expliciet mag benaderen, en autorisatie wordt per verzoek geëvalueerd.

2. Audittrail: Kun je bewijzen wat de AI heeft geraadpleegd?

Een RAG-pipeline op schaal genereert duizenden dataopvragingen per dag over een gebruikerspopulatie. Elk van die opvragingen is een data access event. Elk data access event vereist attributie. Zonder deze attributie kunnen organisaties de vragen die compliance-raamwerken stellen niet beantwoorden: welke gevoelige data heeft de AI geraadpleegd, namens wie, wanneer, en wat is ermee gedaan?

De minimaal vereiste auditlog voor productie-RAG registreert de identiteit van het AI-systeem, de geauthenticeerde gebruiker, de specifieke geraadpleegde data, de tijdstempel en de uitgevoerde actie. Cruciaal is dat deze events in real time naar een SIEM moeten worden gestuurd — niet gebundeld, niet vertraagd, niet beperkt. Een securityteam dat pas drie dagen later hoort van een ongeautoriseerde AI-dataopvraging, kan niet effectief reageren.

Het praktische probleem waar de meeste organisaties tegenaan lopen, is niet dat ze geen loggingsysteem hebben — het is dat hun RAG-pipeline logs bevat als “AI-systeem heeft repository geraadpleegd” in plaats van de attributiedetails die HIPAA-, GDPR- en FedRAMP-complianceprogramma’s daadwerkelijk vereisen.

3. Compliance-afstemming: Voldoet AI-data toegang aan bestaande wettelijke verplichtingen?

HIPAA-, GDPR-, SOX- en FedRAMP-compliance maken geen uitzonderingen voor AI. Wanneer een RAG-pipeline een patiëntendossier ophaalt ter ondersteuning van een klinische beslissing, is dat een HIPAA-access event. Wanneer het financiële gegevens ophaalt voor een analyse, gelden de SOX-registratievereisten. Toezichthouders geven actief aan dat bestaande databeschermingsraamwerken ook gelden voor AI-data toegang — organisaties die wachten op AI-specifieke regelgeving voordat ze governance implementeren, lopen nu al achter.

Twee specifieke compliance-gaten komen het meest voor in RAG-architecturen. Ten eerste: omzeiling van gevoeligheidslabels. RAG-pipelines halen vaak data op zonder classificatie of Microsoft Information Protection (MIP)-labels te evalueren, waardoor de AI vertrouwelijke of beperkte data kan tonen die de toegangscontroles van het onderliggende systeem juist moesten beschermen. Ten tweede: documentatiegaten. Compliance-raamwerken vereisen dat organisaties aantonen dat toegang gecontroleerd was, niet alleen dat toegang plaatsvond. Een logregel met “AI heeft documenten opgehaald” is geen bewijs van governance.

Wat te verifiëren: gevoeligheidslabels worden geëvalueerd voordat data wordt teruggegeven, en de audittrail genereert het documentatieformaat dat vereist is voor HIPAA-compliance, GDPR-compliance en SOC 2-audit.

4. Zero-trust architectuur: Wordt jouw AI-systeem als vertrouwde actor behandeld?

Traditionele integratiepatronen behandelen een AI-systeem als vertrouwde service zodra het is verbonden — als de pipeline de repository kan bereiken, wordt aangenomen dat toegang geautoriseerd is. Zero-trust gegevensuitwisseling verwerpt deze aanname volledig. Een AI-systeem is geen vertrouwde gebruiker. Het is een accessor die voor elk verzoek onafhankelijk autorisatie moet aantonen, ongeacht wat het bij het vorige verzoek mocht doen.

Twee specifieke zero-trust vereisten verdienen bijzondere aandacht in RAG-architecturen. Ten eerste: credentialbeveiliging. Authenticatietokens mogen nooit toegankelijk zijn voor het AI-model zelf. Een RAG-pipeline die credentials opslaat in een configuratiebestand of tokens doorgeeft via AI-context, is kwetsbaar voor prompt injection-aanvallen die deze credentials kunnen uitlezen en gebruiken om data te benaderen buiten de oorspronkelijke query. Tokens moeten worden opgeslagen in de veilige credential store van het besturingssysteem — niet toegankelijk via AI-prompts. Ten tweede: assume-compromise architectuur. Het systeem moet ontworpen zijn met de aanname dat de AI-pipeline uiteindelijk gecompromitteerd wordt. Rate limiting op datarequests, padvalidatie en beleidshandhaving op de retrieval-laag zijn geen optionele hardeningmaatregelen — het zijn de controles die AI-risico beperken als er iets misgaat.

5. Data-exfiltratiecontroles: Kan jouw RAG-pipeline een extractievector worden?

Een RAG-pipeline met brede data-toegang en zonder rate limiting is een bulkextractietool die wacht om misbruikt te worden. Een aanvaller die een AI-systeem compromitteert — of een gebruiker die ontdekt dat de pipeline geen limieten per query heeft — kan veel meer data ophalen dan individuele bestandsopvragingen zouden toestaan. Dit is geen nieuw aanvalspatroon; het is hetzelfde bulkextractierisico dat DLP-programma’s aanpakken voor menselijke gebruikers, nu toegepast op een AI-actor die duizenden queries per seconde kan uitvoeren.

Productie-RAG vereist rate limiting op AI-datarequests, path traversal-preventie om toegang tot systeemfiles of mappen buiten de bedoelde scope te blokkeren, en absolute padrestricties als standaard. Ook is een gedragsbaseline vereist: hoe ziet normaal RAG-querygedrag eruit voor deze gebruikerspopulatie, en welke afwijking van die baseline moet een risicobeheer cyberbeveiliging-alert triggeren? Zonder deze baseline blijft afwijkende extractieactiviteit onzichtbaar tot de data de organisatie al heeft verlaten.

Pilot vs. Productie: De governance-kloof in één oogopslag

Hoe Kiteworks gecontroleerde RAG mogelijk maakt — en AI-operationeel inzetbaar maakt

De governance-vereisten in deze checklist zijn geen obstakels voor AI-adoptie. Ze zijn de voorwaarden waaronder productie-AI duurzaam wordt. Organisaties die governance als voorwaarde behandelen — in plaats van als bijzaak — bereiken productie sneller dan degenen die ongecontroleerde pilots lanceren en vervolgens vastlopen bij de securityreview. Het architectuurpatroon dat dit mogelijk maakt, is een gecontroleerde datalaag tussen het AI-systeem en de datarepository: afdwingen van toegangscontrole, genereren van audittrails, evalueren van compliancebeleid en implementeren van zero-trustprincipes zonder aparte AI-specifieke governance-infrastructuur.

De AI Data Gateway is de speciaal ontwikkelde implementatie van dit patroon door Kiteworks. Het biedt zero-trust AI-data toegang — elk verzoek van een RAG-pipeline of AI-assistent wordt geauthenticeerd, geautoriseerd tegen RBAC- en ABAC-beleid en gelogd voordat data wordt teruggegeven. Het ondersteunt compliant RAG door gevoeligheidsclassificaties en MIP-labels te evalueren op de retrieval-laag, en genereert de audittrail met attributieniveau die vereist is voor HIPAA-compliance, GDPR-compliance, SOX en FedRAMP-compliance. Real-time toegangstracking wordt direct naar SIEM gestuurd — geen batching, geen throttling, geen gaten. En omdat het is gebouwd op REST API’s en het Model Context Protocol (MCP), integreert het met elke RAG-implementatie en elk AI-platform zonder vendor lock-in.

Cruciaal is dat de AI Data Gateway de bestaande governance van een organisatie uitbreidt — dezelfde gegevensbeheerbeleid, dezelfde auditlogs, hetzelfde Private Data Network — naar elke AI-interactie. Er is geen parallelle governance-infrastructuur om te bouwen en te onderhouden. Securityteams krijgen inzicht in AI-data toegang via dezelfde dashboards die ze al gebruiken. Compliance officers krijgen AI-operaties opgenomen in dezelfde wettelijke rapportages die ze al opstellen. En AI-engineeringteams krijgen de gecontroleerde data toegang die ze nodig hebben om van pilot naar productie te gaan zonder een securityreview-stilstand.

Voor organisaties die klaar zijn om van AI-experimentatie naar AI-operationele inzet te gaan, is de bovenstaande checklist het startpunt. Kiteworks maakt het mogelijk om elk punt af te vinken. Wil je meer weten, plan vandaag nog een demo op maat.

Aanvullende bronnen

• Blog Post
  Zero‑Trust Strategieën voor betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt op AI-databeveiliging
• eBook
  AI Governance Gap: Waarom 91% van kleine bedrijven Russisch roulette speelt met databeveiliging in 2025
• Blog Post
  Er bestaat geen “–dangerously-skip-permissions” voor jouw data
• Blog Post
  Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.