Retrieval-Augmented Generation (RAG) is een AI-architectuur waarbij een taalmodel niet antwoordt op basis van alleen zijn trainingskennis, maar realtime relevante passages ophaalt uit een documentcorpus voordat het een antwoord formuleert. Wanneer dat gehele proces, van documentopslag tot embedding en inferentie, plaatsvindt op de eigen servers van een organisatie, spreekt men van een on-premise soevereine RAG. Voor gereguleerde sectoren zoals de juridische praktijk, de zorg en de overheid is dit onderscheid niet slechts technisch, maar ook juridisch bepalend.
Waarom cloudgebaseerde LLM-aanroepen een AVG-risico vormen
Zodra een prompt een externe LLM-dienst bereikt, is er sprake van gegevensverwerking door een derde partij, en in veel gevallen een doorgifte naar een derde land in de zin van de AVG.
De kern van het probleem is jurisdictioneel. Diensten zoals OpenAI API en Azure OpenAI worden aangeboden door Amerikaanse rechtspersonen die onder de werking van de CLOUD Act (2018) vallen. Die wet verplicht aanbieders om op bevel van een Amerikaanse rechtbank gegevens te verstrekken, ook als die gegevens op Europese servers staan. Zelfs als Microsoft garandeert dat data binnen de EU blijft, heft dat de Amerikaanse juridische reikwijdte niet op.
Het European Data Protection Board (EDPB) publiceerde in april 2025 richtsnoeren over LLM-privacyrisico’s, waarin wordt gesteld dat LLM-diensten waarbij prompts externe servers bereiken structurele risico’s meebrengen voor doorgifte van persoonsgegevens naar derde landen. Dit maakt een uitgebreide Transfer Impact Assessment (TIA) verplicht voor iedere organisatie die persoonsgegevens via cloudgebaseerde LLM-aanroepen verwerkt.
“Large language models present specific challenges for data protection because they can memorise and reproduce personal data from their training sets, and because inference calls expose prompts to processors in third countries.”
European Data Protection Board, EDPB Opinion on LLMs, april 2025
Ter vergelijking: bij een volledig on-premise RAG-architectuur verlaten gegevens de eigen infrastructuur niet. Er is geen verwerker, geen derde land, geen Transfer Impact Assessment vereist. De risicoanalyse beperkt zich tot interne beveiligingsmaatregelen.
AVG artikel 25 en 32 toegepast op lokale RAG
Twee AVG-artikelen zijn direct bepalend voor de architectuurkeuzes in een on-premise RAG-systeem.
Artikel 25 (privacy by design en by default) verplicht de verwerkingsverantwoordelijke om al bij het ontwerp van een systeem passende technische maatregelen te treffen. Voor een RAG-systeem betekent dit concreet: de vector-database mag uitsluitend embeddings bevatten van documenten waartoe de bevragende gebruiker toegang heeft. Toegangscontrole op documentniveau, niet slechts op systeemniveau, is een artikel 25-verplichting, niet een best practice.
Artikel 32 (beveiliging van de verwerking) vereist passende technische en organisatorische maatregelen, waaronder versleuteling van opgeslagen data. In een RAG-context omvat dit versleuteling van de vector-database op disk, versleutelde verbindingen tussen de applicatielaag en de modelserver, en logging van alle inferentieverzoeken met gebruikersidentiteit en tijdstempel.
“Privacy by design is not an option but an obligation: controllers must implement appropriate technical and organisational measures before processing begins, not as an afterthought.”
Andrea Jelinek, voormalig voorzitter European Data Protection Board, EDPB richtsnoeren artikel 25
Het verschil met cloudgebaseerde LLM-aanroepen is fundamenteel: bij een cloudoplossing is artikel 32 van toepassing op zowel de verwerkingsverantwoordelijke als de verwerker (de cloudaanbieder), wat een dubbele risicolaag creëert. Bij on-premise RAG is er slechts één verantwoordelijke partij.
Statistiek: De totale AVG-boetes in 2023 bedroegen meer dan 1,78 miljard euro, een record ten opzichte van voorgaande jaren (DLA Piper GDPR Fines Report, 2024). Een significant deel van die boetes betrof onvoldoende beveiliging van verwerkingssystemen en onrechtmatige doorgifte naar derde landen.
Open-weight modellen voor gereguleerde sectoren
De keuze van het taalmodel is in een soevereine architectuur bepalend voor zowel de prestaties als de hardwarevereisten.
| Model | Parameters | Minimale GPU VRAM | Geschikt voor | Licentie |
|---|---|---|---|---|
| Mistral 7B Instruct | 7 miljard | 8 GB (kwantisatie Q4), 16 GB (volledig) | Algemeen juridisch, HR-documenten | Apache 2.0 |
| LLaMA 3 8B | 8 miljard | 10 GB (kwantisatie), 20 GB (volledig) | Zorg, beleidsdocumenten | Meta Community License |
| LLaMA 3 70B | 70 miljard | 40+ GB (meerdere GPU’s of kwantisatie) | Complexe juridische analyse, compliance | Meta Community License |
| Falcon 40B | 40 miljard | 80 GB (meerdere GPU’s) | Meertalige Europese toepassingen | TII Falcon License |
Voor de meeste gereguleerde organisaties biedt Mistral 7B Instruct de beste verhouding tussen prestaties en hardwarekosten. Het model draait op een enkele NVIDIA RTX 4090 of A4000 (24 GB VRAM) en levert voor Nederlandse en Engelstalige juridische teksten aanvaardbare resultaten. LLaMA 3 70B is superieur voor complexe redeneerpatronen, maar vereist kwantisatie via GGUF-formaat met llama.cpp of meerdere GPU’s in een multi-GPU-server.
Modelservers zoals Ollama en LM Studio maken de lokale inzet van deze modellen aanzienlijk eenvoudiger. Ollama biedt een Docker-compatibele REST API waarmee applicaties op exact dezelfde manier met een lokaal model communiceren als met een externe API, zonder dat er ook maar één pakket data de server verlaat.
Statistiek: Verizon DBIR 2024 stelt dat 68% van de datalekken een menselijk element bevat, waaronder fouten van externe leveranciers en misconfiguraties in cloudoplossingen. Dit onderstreept de waarde van het elimineren van externe leveranciers in de verwerkingsketen.
Traceerbaarheid en de EU AI Act artikel 50
Een soevereine RAG-architectuur is van nature beter uitgerust voor audittrails dan een black-box cloudmodel, maar dit vereist een expliciete ontwerpkeuze.
Artikel 50 van de EU AI Act (Verordening (EU) 2024/1689) legt transparantieverplichtingen op voor AI-systemen die met mensen interageren. Gebruikers moeten weten dat ze met een AI communiceren, en bij systemen die documentretrieval gebruiken, moet duidelijk zijn op basis van welke bronnen een antwoord is gegenereerd.
In een goed ontworpen RAG-architectuur levert elk antwoord automatisch bronverwijzingen mee: de documentnaam, de paginanummers of paragraafaanduidingen, en de relevantiescore van de opgehaalde passages. Dit is niet alleen een technische eigenschap van RAG, maar moet ook worden vastgelegd in een auditlog per gebruikersinteractie, met tijdstempel, gebruikers-ID en de exacte passages die als context zijn meegegeven aan het model.
Dit auditlog dient beveiligd en onveranderbaar opgeslagen te worden, bij voorkeur in een afzonderlijk logsysteem met beperkte schrijfrechten. Zo vormt het tegelijk een bewijs van AVG-artikel 32-naleving en van AI Act-conformiteit.
Integratie met Nextcloud en on-premise documentbeheer
Een soevereine RAG-architectuur vereist een documentbron die volledig onder eigen beheer staat en die documenten beschikbaar stelt zonder externe API-aanroepen voor embeddings.
Nextcloud, als on-premise of Zwitsers gehoste documentwerkruimte, biedt twee integratiemogelijkheden: de WebDAV-interface en de Nextcloud REST API. Een lokale ingest-pipeline haalt via WebDAV periodiek nieuwe of gewijzigde documenten op, converteert deze naar platte tekst, en genereert embeddings via een lokaal embedding-model.
Voor de embedding-stap zijn open-source modellen beschikbaar die via Ollama worden geserveerd, zoals nomic-embed-text of mxbai-embed-large. Deze modellen zetten tekstpassages om in vectorrepresentaties volledig op de eigen GPU, zonder enige communicatie met externe embedding-diensten zoals OpenAI Embeddings of Cohere.
De gegenereerde vectoren worden opgeslagen in een lokale vector-database, zoals Chroma (eenvoudig te deployen, geschikt voor kleinere corpora) of Qdrant (productieklaar, ondersteunt filtering op metadata). Bij elke gebruikersvraag doorzoekt de RAG-pipeline deze vector-database, haalt de meest relevante passages op, en stuurt deze samen met de vraag als context naar het lokale taalmodel via Ollama. Het volledige informatiepad blijft binnen de eigen serveromgeving.
Toegangsbeheer sluit aan op de bestaande Nextcloud-permissies: als een gebruiker geen toegang heeft tot een document in Nextcloud, mag de RAG-pipeline dat document niet opnemen in de retrieval voor die gebruiker. Dit vereist metadata-filtering in de vector-database op basis van gebruikersrollen of documentlabels, een directe uitwerking van AVG artikel 25 (privacy by default).
Statistiek: Het EDPB stelde in april 2025 vast dat LLM-inferentie via externe API’s structurele risico’s meebrengt voor ongeoorloofde doorgifte van persoonsgegevens, en dat organisaties aanvullende waarborgen moeten documenteren als onderdeel van hun verwerkingsregister (EDPB, 2025).
Architectuuroverzicht: van document tot antwoord
Een volledige on-premise RAG-stack voor een gereguleerde organisatie omvat de volgende componenten, elk gehost op eigen infrastructuur.
| Laag | Component | Open-source optie | AVG-relevantie |
|---|---|---|---|
| Documentopslag | DMS / Nextcloud | Nextcloud (AGPLv3) | Bewaarlocatie, toegangsbeheer |
| Ingest en chunking | Document-parser | LangChain, LlamaIndex | Dataminimalisatie bij chunking |
| Embedding | Lokaal embedding-model | nomic-embed-text via Ollama | Geen externe API-aanroep |
| Vectoropslag | Vector-database | Chroma, Qdrant | Versleuteling at rest (art. 32) |
| Inferentie | LLM-modelserver | Ollama, LM Studio | Geen dataverwerking buiten EU |
| Auditlogging | Interactielog | Elasticsearch, Loki | AI Act art. 50, AVG art. 32 |
Deze architectuur sluit aansluiting op de NIS-2-richtlijn in, die voor organisaties in essentiële sectoren aanvullende beveiligingsverplichtingen oplegt op het vlak van incidentrespons en ketenbeveiliging. Omdat er geen externe verwerkers zijn, is de aanvalsvector aanzienlijk kleiner dan bij cloudgebaseerde alternatieven.
FAQ
Wat is het verschil tussen een cloudgebaseerde RAG via Azure OpenAI en een on-premise RAG voor AVG-doeleinden?
Bij Azure OpenAI verlaten prompts en mogelijk persoonsgegevens de EU-infrastructuur, of worden ze verwerkt door een entiteit die onder de Amerikaanse CLOUD Act valt. Een on-premise RAG verwerkt alle data binnen de eigen serveromgeving, waardoor er geen doorgifte naar een derde land plaatsvindt en de artikelen 44 tot 49 AVG niet van toepassing zijn.
Welke open-weight modellen zijn het meest geschikt voor juridische of zorgtoepassingen on-premise?
Mistral 7B en LLaMA 3 (8B en 70B) zijn breed ingezet in gereguleerde sectoren. Mistral 7B draait op een GPU met 24 GB VRAM, wat haalbaar is op een enkele NVIDIA RTX 4090 of A4000. Voor hogere nauwkeurigheid in complexe juridische teksten verdient LLaMA 3 70B de voorkeur, maar dat vereist meerdere GPU’s of een kwantisatiestrategie zoals GGUF via llama.cpp.
Hoe waarborgt een soevereine RAG-architectuur traceerbaarheid in het kader van de EU AI Act?
Elke RAG-respons verwijst naar de brondocumenten die via vectorzoekactie zijn opgehaald, inclusief documentnaam, versie en passage. Dit vastleggen in een auditlog voldoet aan de transparantieplicht van artikel 50 EU AI Act, dat vereist dat gebruikers weten wanneer ze met een AI-systeem interageren en op basis van welke input het antwoord is gegenereerd.
Kan een Nextcloud-instantie dienen als documentbron voor een on-premise RAG zonder externe API’s?
Ja. Via de Nextcloud REST API of WebDAV-interface haalt een lokale ingest-pipeline documenten op. Een open-source embedding-model zoals nomic-embed-text, geserveerd via Ollama, zet die documenten om in vectorrepresentaties die lokaal worden opgeslagen in een vector-database zoals Chroma of Qdrant. Er is geen enkel extern API-aanroep nodig.
Wat zijn de minimale hardwarevereisten voor een productie-waardige on-premise RAG-omgeving?
Voor een organisatie met enkele tientallen gebruikers volstaat een server met een NVIDIA GPU van 24 GB VRAM (bijvoorbeeld A4000 of RTX 4090) voor een 7B-model, 64 GB RAM en SSD-opslag voor de vector-database. Zwaardere modellen (70B) vereisen ofwel kwantisatie of meerdere GPU’s. CPU-only inferentie met llama.cpp is mogelijk maar aanzienlijk trager en minder geschikt voor productiegebruik.
