Dynamic Context

Tot medio 2025 ging het gesprek over AI-kwaliteit vooral over prompt engineering: de kunst van de juiste instructie. Sinds juni 2025, toen Tobi Lütke (CEO Shopify) context engineering definieerde als “the art of providing all the context for the task to be plausibly solvable by the LLM”, is de focus verschoven. In juli 2025 verklaarde Gartner dat context engineering de prioriteit is geworden boven prompt engineering.

De aanleiding is pijnlijk concreet: MIT’s State of AI in Business 2025 rapporteerde dat 95% van enterprise AI-pilots geen meetbare ROI oplevert. De hoofdoorzaak was niet modelkeuze of prompting-kwaliteit, maar gebrek aan context.

Waarom prompt engineering niet genoeg is

Moderne modellen zijn slim genoeg om een taak te interpreteren. Wat ze niet weten, is wat jouw organisatie bedoelt met “top-10 klanten”. Voor Verkoop is dat contractwaarde; voor Productmanagement is het adoptie; voor Klantenservice is het de kans dat een klant blijft. Elk team heeft een eigen definitie en wanneer er geen definitie bekend is, zal het model er zelf één verzinnen. Een verkeerde definitie kan leiden tot slechte antwoorden; kortingen die goed worden gekeurd op basis van niet-correcte criteria, klantvragen die bij verkeerde teams terecht komen of contracten die worden gegenereerd met verkeerde voorwaarden.

Context engineering richt zich op dat gat: het ontwerpen van systemen die dynamisch de juiste informatie, tools en institutioneel geheugen samenstellen in het context window van het model, afgestemd op de taak.

Zes componenten van context: verdeeld over twee bouwstenen

Context engineering is overkoepelend: het beslaat zowel de statische laag die je ontwerpt (ingekapseld in Prompt Design, BB_04) als de dynamische laag die op uitvoeringstijd wordt samengesteld (Dynamic Context, BB_03). De zes componenten vallen niet allemaal onder één BB; ze verdelen zich als volgt:

• Systeeminstructies & rol-definities: wie is de agent, wat mag hij wel/niet. → Prompt Design, vooraf vastgelegd in de system prompt.

• Semantische & structurele context: definities, business glossaries en data-herkomst. → Gemengd: glossaries en definities leg je vooraf vast (Knowledge + Prompt Design); de herkomst per antwoord wordt live bepaald (Dynamic Context).

• Operationele context & procedureel geheugen: beslissingen, uitzonderingslogica en goedkeuringsroutes (wie moet waarvoor toestemming geven). → Prompt Design, vooraf vastgelegd als expliciete regels in de system prompt of workflow.

• Gespreks- & temporele context: wat is gezegd, hoe oud is deze data. → Dynamic Context, live opgebouwd uit de lopende conversatie en hoe recent de onderliggende data is.

• Retrieval & integratie: RAG, live data (realtime-gegevens uit bronsystemen) en het MCP. → Dynamic Context, live opgehaald uit kennisbank en bronsystemen.

• Tool-toegang & actie-capaciteiten: welke tools mag de agent gebruiken, onder welke voorwaarden. → Prompt Design + Tool Integration, vooraf vastgelegd.

Waarom dit onderscheid ertoe doet: “context engineering” klinkt alsof het alleen gaat over het ophalen van documenten en het onthouden van wat eerder is gezegd. Maar het grootste deel van wat het model op een gegeven moment “weet” zit vast in de laag die je vooraf hebt ontworpen. Dat is het domein van Prompt Design. Dynamic Context vult die vaste laag aan met wat variabel moet zijn: actuele data, gespreksgeschiedenis, domein-specifieke documenten. Beide zijn onmisbaar, en geen van beide kan het werk van de ander overnemen.

Vijf manieren waarop context faalt

Een context-laag faalt typisch op vijf manieren: gebrekkig (missing: informatie-gat → hallucinatie), verouderd (stale: zelfverzekerd fout antwoord), tegenstrijdig (conflicting: verschillende definities per bron → inconsistent), irrelevant (noise: aandacht verdund), en onbevoegd gebruikt (permission-violated: access control omzeild). Dit zijn diagnostische categorieën, geen implementatiefouten: elke organisatie herkent minstens drie ervan in de eigen omgeving.

Een hardnekkig misverstand in 2025–2026: als modellen grotere context windows krijgen (1M tokens, 10M tokens), verdwijnt het context-probleem. Het empirisch bewijs zegt het tegenovergestelde. Chroma’s onderzoek uit 2025 testte 18 frontier-modellen — inclusief GPT-4.1, Claude Opus 4, Gemini 2.5 Pro en Qwen3-235B — en vond dat elk model degradeert naarmate de context groeit. Dit fenomeen heet context rot.

Drie mechanismen werken samen

Lost-in-the-middle: Liu et al. (Stanford, TACL 2024) toonden aan dat modellen een U-curve vertonen: informatie aan begin en einde van de context krijgt hoge aandacht, maar informatie in het midden krijgt 30%+ lagere nauwkeurigheid. De 30%-cijfers komen van 2024-modellen; Chroma bevestigde het U-curve-patroon in 2025 op 18 frontier-modellen (inclusief GPT-4.1, Claude Opus 4 en Gemini 2.5 Pro). Absolute percentages schuiven per modelversie, het patroon blijft: het is een structurele eigenschap van de manier waarop taalmodellen hun aandacht over tokens verdelen; geen bug die met latere trainingsrondes van het model verdwijnt.

Attention dilution: een taalmodel werkt intern met attention (aandacht): voor elke token berekent het hoe relevant alle andere tokens zijn. Die berekening groeit kwadratisch (exponentieel: twee keer zoveel context = vier keer zoveel rekenwerk): bij 10.000 tokens zijn er 100 miljoen token-paren om te vergelijken, bij 100.000 tokens 10 miljard, bij 1 miljoen tokens een biljoen. De model-interne weegfunctie (softmax-normalisatie) verdeelt de totale aandacht over álle tokens, dus elke individuele token krijgt proportioneel minder gewicht naarmate er meer context bijkomt. In gewonemensentaal: hoe meer tekst je het model voert, hoe minder aandacht elke zin afzonderlijk krijgt.

Distractor interference: semantisch vergelijkbare maar feitelijk irrelevante content (denk: oude versies van beleid naast de huidige, of een klantdossier met vier verschillende adressen uit vier verschillende jaren) versterkt het lost-in-the-middle-effect nog verder. Opmerkelijk: Chroma vond dat goed gestructureerde, coherente documenten moeilijker te doorzoeken zijn dan willekeurig geordende, omdat coherentie meer plausibele “bijna-goede” antwoorden creëert.

Hoe erg degradeert het?

Adobe Research (februari 2025) mat wat er gebeurt op vragen die twee stappen vereisen: eerst een feit uit de context vinden, dan dat feit combineren met algemene kennis. Voorbeeld: “welke klant zit in onze grootste groeiregio?”. Om die vraag te beantwoorden moet het model zowel weten wat er in het klantdossier staat, als welke regio het hardst groeit.

Bij een korte prompt halen de meeste modellen 85 tot 99% nauwkeurigheid. Zodra de context opblaast naar 32K tokens zakken de scores dramatisch: afhankelijk van het model 30 tot 60 procentpunten omlaag. Sommige modellen halen dan nog maar 22% van de vragen correct. De exacte cijfers zijn inmiddels meer dan een jaar oud en gelden voor 2024-2025-modelversies; modernere modellen (Claude 4.7, GPT-5.4, Gemini 3) presteren doorgaans beter op hetzelfde type taken, maar de richting blijft consistent: langere context = lagere nauwkeurigheid op redeneertaken.

Dat is geen theoretisch probleem: doorsnee enterprise-queries consumeren 50K–100K tokens aan setup-context voordat de eigenlijke vraag überhaupt begint.

De oplossing is niet meer context, maar minder ruis

Achteraf samenvatten (post-hoc compressie: “we vatten de conversatie samen zodra het context window voor 95% vol zit”) komt te laat; de schade is dan al aangericht. Een sub-agent architectuur werkt wel: één lead-agent (coördinerend AI-systeem) delegeert deelvragen aan meerdere subagents (AI-systemen met elk hun eigen, schone context). Anthropic’s multi-agent research systeem (Opus als lead + Sonnet-subagents) scoorde 90,2% hoger op onderzoekstaken dan dezelfde Opus die in zijn eentje werkte; bijna een verdubbeling van de succes-score. Niet omdat subagents slimmer zijn: de lead-agent krijgt alleen gecondenseerde samenvattingen van ~50–200 tokens (ongeveer 40–150 woorden) terug, en hoeft nooit de 15+ verkende bestanden zelf door te spitten. Minder context, méér relevante informatie per token; dat is wat “signaal-dichtheid” betekent.

Praktisch voor Dynamic Context: méér ruimte in het context window lost het probleem niet op. Drie ontwerpdisciplines blijven cruciaal, ongeacht hoe groot de context windows van toekomstige modellen worden:

• bundle-engineering: bewust samenstellen welke stukjes context (chunks, documenten, voorbeelden) je op welk moment aan het model aanbiedt
• chunk-precisie: documenten zó opknippen dat elk stukje zelfstandig betekenisvol is en niet halverwege een alinea afbreekt
• context-isolatie: subvragen in aparte context-sessies afhandelen zodat hun zoek- en verwerpfase de hoofdcontext niet vervuilt

Dit raakt direct aan de Robustness-guardrail (GR_02: betrouwbaarheid onder alle omstandigheden): context rot geeft geen foutmelding, het geeft een plausibel maar verkeerd antwoord. Juist daarom moet een robuust AI-systeem vooraf ontworpen zijn om deze stille faalmodus op te vangen; je kunt niet monitoren wat niet zichtbaar faalt.

Retrieval is het ophalen van relevante documenten of fragmenten uit een kennisbank, zodat het model met actuele, organisatie-specifieke informatie kan werken in plaats van alleen met wat het tijdens training heeft geleerd. Dat ophalen klinkt eenvoudig, maar is in de praktijk de plek waar de meeste AI-toepassingen vastlopen.

RAG is in 2025–2026 geëvolueerd van een vaste reeks stappen (elke vraag doorloopt hetzelfde ophaalscript) naar een intelligente zoekmachine die per vraag beslist hoe hij zoekt. De naïeve versie — splits documenten in blokjes, maak er vector-representaties van en haal de top-K meest gelijkende op bij elke vraag — haalt in productie niet het kwaliteitsniveau dat zakelijke toepassingen vragen.

Chunking is de meest onderschatte kwaliteitsvariabele

Chunking — het opknippen van documenten in stukjes voor het ophalen — heeft meer impact op prestaties dan modelkeuze of embedding-model. Simpel splitsen van elke 512 tokens (ongeveer 350 woorden) zonder acht te slaan op zinsgrenzen is snel en consistent middelmatig. Een zin die halverwege wordt afgekapt, een tabel die over twee chunks is verdeeld, of een alinea zonder onderwerp zorgt dat het ophalen faalt nog vóór het model aan bod komt.

Richtlijnen per documenttype:

• Algemene tekst (blogs, rapporten): 256–512 tokens per chunk (ca. 180–350 woorden), met 20–30% overlap tussen opeenvolgende chunks.
• Beleid & procedure-documenten: hiërarchisch indexeren op alinea-niveau, maar bij een treffer de hele sectie teruggeven, zodat context rond het gevonden stuk meegaat.
• Technische documentatie: 1.000–1.500 tokens (ca. 700–1.050 woorden) met 10–20% overlap; langere stukken houden werkende code-voorbeelden bij elkaar.
• Chatgesprekken: 200–400 tokens (ca. 140–280 woorden), minimale overlap.

Kwaliteitstest: pak 50 willekeurige chunks en lees ze los van hun document. Als meer dan 1 op 5 in isolatie betekenisloos is (“de vennootschap groeide 3% het vorige kwartaal”; welke vennootschap?), zijn je chunks te klein of ontbreekt er overlap.

Contextual Retrieval: 67% minder ophaal-fouten

Anthropic publiceerde in 2024 Contextual Retrieval, een methode die het chunk-probleem oplost door per stukje een korte contextuele annotatie (50–100 tokens, ongeveer 40–75 woorden) te genereren vóór indexering. Die annotatie plakt het document, de periode en het onderwerp aan de chunk, zodat “de vennootschap groeide 3%” in de index staat als “ACME Corp — Q2 2023 — jaarverslag: de vennootschap groeide 3%”.

Kosten via prompt caching: ongeveer €1,02 per miljoen document-tokens aan eenmalige voorbewerking. Economisch haalbaar op bedrijfsschaal. De cijfers komen uit Anthropic’s onderzoek op peer-reviewed datasets in 2024; het effect is sindsdien in meerdere onafhankelijke tests gerepliceerd.

Hybride zoeken is de standaard

Pure vector-search (zoeken op semantische gelijkenis) verdunt exacte matches. Als een medewerker zoekt naar “foutcode TS-999” of “AVG Artikel 17”, wil je dat de exacte term hard meetelt; niet dat je een semantisch-vergelijkbaar document krijgt over foutcodes in het algemeen. BM25 vindt die exacte matches wel. Hybride zoeken combineert beide: typisch 75% semantisch + 25% keyword. Een reranker kijkt vervolgens nog eens kritisch naar de top-K treffers; waar de eerste ophaalslag vraag en document los vergelijkt, leest de reranker ze sámen en kan daardoor beter beoordelen welke treffer écht relevant is voor deze vraag.

Gebruik altijd hetzelfde embedding-model

Een embedding-model is een taalmodel dat tekst omzet naar een reeks getallen, zodat een computer kan uitrekenen hoe sterk twee stukken tekst op elkaar lijken. Twee verschillende embedding-modellen spreken echter elk hun eigen “taal” van getallen: wat model A teruggeeft kun je niet vergelijken met wat model B teruggeeft.

Heb je je documenten met model A geïndexeerd, maar vertaal je een nieuwe vraag met model B, dan vind je niets meer terug. Zelfs upgraden naar een nieuwere versie van hetzelfde model breekt dit. Wil je overstappen op een ander embedding-model, dan moet je de hele kennisbank opnieuw indexeren.

RAG is niet voor elke toepassing

Voor kleine kennisbanken met simpele vragen (onder ~200.000 tokens, zo’n 500 pagina’s): je kunt het hele corpus in de prompt zetten en de model-aanbieder het laten cachen (zie prompt caching). Zonder RAG-pijplijn heb je geen ophaalfouten meer, maar let op: dit werkt alleen voor rechttoe-rechtaan vragen waar het antwoord letterlijk in de context staat. Zodra het model over meerdere stappen moet redeneren over die 200K tokens, loopt het alsnog tegen context rot aan (zie de sectie hierboven). Voor look-up-vragen: simpel en effectief. Voor redeneer-vragen: niet.

Voor complexe meervoudige relaties (“welke klanten werken samen met welke leveranciers in welke projecten?”): GraphRAG — RAG met een kennisnetwerk als tussenlaag, waarin entiteiten (klanten, leveranciers, projecten) als knooppunten staan en hun onderlinge relaties als verbindingen — kan toegevoegde waarde hebben. Maar let op: een expliciet netwerk van relaties verhoogt het PII-lekrisico, zie de Privacy-sectie verderop.

Voor classificatie- en routeringstaken met 5–20 categorieën (“welk team moet deze vraag oppakken?”): in plaats van een speciaal AI-model op jouw categorieën bij te scholen, kun je je categorie-definities zelf als “documenten” indexeren en de inkomende vraag daartegen laten zoeken. Het model pakt dan de best passende categorie op basis van semantische gelijkenis; Amazon noemt dit het REIC-patroon (EMNLP 2025). Deze aanpak presteert beter dan een bijgeschoold classificatiemodel (een bestaand taalmodel dat je extra hebt getraind op jouw specifieke categorieën) en past zich aan nieuwe categorieën aan zonder dat je het model opnieuw hoeft te trainen.

De meeste RAG-failures zijn geen retrieval-failures. Het zijn actualiteits-failures, en de meeste teams hebben geen manier om ze te meten.

Een kapotte auth-service geeft een 403. Een netwerk-timeout geeft een error. Een verouderde kennisbank geeft een antwoord; structureel correct, zelfverzekerd van toon, gebaseerd op informatie die uren, dagen of weken achterhaald is. Er is geen staleness-flag in de retrieval-response. Het model kan een actueel document niet onderscheiden van een verouderd. Het genereert uit wat er gegeven is.

Standaard RAG-metrics (faithfulness, answer relevancy, context recall) hebben geen temporele component. Een systeem kan 95% scoren op alle drie; en toch 22 uur lang verouderde informatie serveren.

Vier dimensies, apart te meten

Actualiteit in een kennisbank is geen enkel getal maar vier samenhangende metingen, die elk een ander faalscenario vangen:

• Leeftijd van de inhoud (content age): hoe lang geleden is het bron-document voor het laatst door een mens gecontroleerd of bijgewerkt?
• Indexering-vertraging (embedding lag): hoeveel tijd zit er tussen het moment dat een document wijzigt en het moment dat de nieuwe vector in de index staat?
• Verouderingspercentage (stale retrieval rate): welk deel van de live vragen levert een document terug waarvan de vector ouder is dan het document zelf? De meest operationeel kritieke meting: dit vertelt of eindgebruikers op dit moment verouderde antwoorden krijgen.
• Corpusdrift (coverage drift): welk deel van de totale kennisbank is inmiddels ouder dan de afgesproken houdbaarheidsgrens? Een vooruitziende meting: ook documenten die nu niet bevraagd worden tellen mee.

Houdbaarheid is niet uniform

Eén universele verouderingsgrens is ofwel te streng voor achtergrondmateriaal, ofwel te nalatig voor compliance. Differentieer per categorie:

Een samengestelde score over deze vier dimensies onder de 85% triggert automatische waarschuwingen; onder de 70% toont het systeem actief aan eindgebruikers dat de opgehaalde informatie mogelijk niet meer actueel is.

Reageren op wijzigingen is beter dan wachten op de klok

Drie aanpakken voor het bijwerken van de index, met hun typische achterstand:

• Nachtelijke batch-verwerking: tot 24 uur verouderd voordat een wijziging zichtbaar is
• Uurlijkse batch: tot 60 minuten verouderd
• Realtime verwerken op wijziging (via CDC): enkele seconden verouderd, maar alleen voor bronnen die change-events publiceren

Het patroon dat in productie wint: incrementeel herindexeren getriggerd door document-wijzigingen in de bron (pagina bijgewerkt in Confluence, bestand aangepast in SharePoint), niet door een schema.

Metadata is een voorwaarde, geen optie

Actualiteit meten lukt alleen als elk document drie velden draagt: wanneer voor het laatst gecontroleerd (last_verified), wanneer voor het laatst gewijzigd (updated_at), en wie de inhoudelijke eigenaar is (owner). Daarnaast moet per bevraging worden vastgelegd wanneer de vector is aangemaakt. Zonder die onderliggende registratie is een dashboard dat rood kleurt geen waarschuwing maar een dood bericht: je ziet het probleem, niemand weet wat eraan te doen.

Dit raakt direct aan twee andere onderdelen van het framework:

• Evaluation Loop (BB_07: meten, analyseren, verbeteren en opnieuw meten): dezelfde cyclus, toegepast op context-kwaliteit.
• Accountability-guardrail (GR_07: duidelijk wie verantwoordelijk is en hoe daarop wordt toegezien): zonder een aanwijsbare eigenaar per document blijft hercertificering liggen, en degradeert de kennisbank in stilte.

Wanneer een AI-systeem gebruikt wordt over meerdere sessies, dagen of maanden, wordt geheugen een aparte ontwerpdiscipline. Een agent die elk gesprek bij nul begint, is feitelijk een chatbot die telkens wordt teruggezet; iedere keer opnieuw uitleggen wie je bent, wat je eerder hebt besproken en welke voorkeuren je hebt. Een agent die alles onthoudt, raakt binnen enkele uren vervuild door context rot.

Drie lagen geheugen

In volwassen AI-systemen wordt geheugen opgesplitst in drie lagen, elk met een andere levensduur en een andere functie:

• Werkgeheugen (working memory): de huidige gespreksstatus, zoals die op dit moment in het context window van het model zit. Vluchtig, verdwijnt na de sessie. Te vergelijken met wat een medewerker op een notitieblokje schrijft tijdens één klantgesprek.
• Ervaringsgeheugen (episodic memory): losse gebeurtenissen en eerdere gesprekken, bewaard in een externe database. Doorzoekbaar, gekoppeld aan een gebruiker of dossier. Te vergelijken met een archief van klantcontacten.
• Kennisgeheugen (semantic memory): patronen en voorkeuren die uit het ervaringsgeheugen zijn gedestilleerd. Het langstlevend; dit is waar institutioneel geheugen zit (“deze klant wil altijd per mail worden benaderd, nooit telefonisch”).

Deze scheiding is geen theoretische luxe. Zonder haar vervuilt het werkgeheugen met irrelevante geschiedenis, en wordt afgeleide kennis ongrijpbaar omdat alles op één hoop wordt gegooid als “recent gesprek”.

De principes onder de motorkap

Voordat we naar concrete implementaties gaan: wat doet een volwassen geheugen-laag eigenlijk? Vier principes komen in elke serieuze oplossing terug:

• Passieve feit-extractie: het systeem “luistert mee” met lopende gesprekken en haalt er automatisch feiten uit (namen, voorkeuren, gemaakte afspraken), zonder dat je als ontwikkelaar elk detail handmatig hoeft te markeren.
• Intelligent overschrijven bij conflicten: als een nieuw feit een oud tegenspreekt (klant verhuist, voorkeur wijzigt), herkent het systeem dat en past het geheugen aan in plaats van beide feiten naast elkaar te bewaren.
• Gescheiden geheugenlagen: werkgeheugen (huidige sessie), ervaringsgeheugen (doorzoekbare geschiedenis) en kennisgeheugen (gedistilleerde patronen) leven in aparte opslag met eigen houdbaarheid, zodat het werkgeheugen niet vervuilt met alles wat ooit is gebeurd.
• Retrieval bij elke interactie: bij een nieuwe vraag wordt relevant geheugen opgehaald en in de context gezet; niet alle geheugen standaard, maar wat de vraag raakt.

Een vijfde keuze verschilt per architectuur: passief versus agent-driven. In de passieve variant stuurt jouw code de geheugen-updates aan. In de agent-driven variant krijgt het AI-model zelf tools om te onthouden, bij te werken of te vergeten tijdens het redeneren. Dat is een fundamentele ontwerpkeuze, geen implementatiedetail.

Twee open-source implementaties van deze principes

Twee projecten werken deze principes expliciet uit en zijn beide open-source (Apache 2.0-licentie), dus je kunt de broncode lezen en de keuzes precies zien.

Mem0 is een geheugen-laag die je toevoegt aan een bestaand AI-systeem: de passieve variant. Je stuurt gesprekken door, Mem0 haalt er zelf de belangrijke feiten uit en past die slim aan; verhuist een klant, dan verdwijnt het oude adres automatisch en komt het nieuwe ervoor in de plaats. In de onafhankelijke LongMemEval-benchmark (2025) scoort Mem0 49,0%. Vergeleken met de alternatieve aanpak “stuur de hele gespreksgeschiedenis mee aan het model”: 26% hogere nauwkeurigheid, 91% lagere responstijd, en meer dan 90% besparing op tokenkosten. Self-hostbaar via de open-source release; voor wie minder wil beheren is er ook een betaalde managed tier met SOC 2 en HIPAA-compliance. De inbedding is licht; als je later wilt overstappen, raak je alleen de geheugen-aanroepen aan, niet je hele AI-infrastructuur.

Letta (eerder MemGPT genoemd) is de agent-driven variant: het hele AI-systeem draait binnen Letta en de agent onderhoudt zelf zijn geheugen door tijdens het redeneren actief te kiezen wat hij bewaart, bijwerkt of verwijdert. Krachtiger voor autonome agents die zonder menselijk toezicht werken. Nadeel: je zit wel vast aan het Letta-runtime-model; overstappen betekent je hele AI-infrastructuur opnieuw opbouwen. Ook volledig open-source, ook self-hostbaar.

Kiesregel: bestaand AI-systeem uitbreiden met geheugen: Mem0. Een autonoom AI-platform vanaf nul bouwen, met agents die zelf hun geheugen sturen: Letta.

Zelf bouwen met deze principes

De principes hierboven zijn niet patent of magie; je kunt ze zelf combineren met standaard tools:

• Vector-database (PostgreSQL met pgvector, Qdrant, Weaviate) voor ervarings- en kennisgeheugen.
• LLM-call voor feit-extractie die na elke sessie (of elke N berichten) de gesprekshistorie omzet in een gestructureerde lijst feiten.
• Conflict-resolutie-prompt die een nieuw feit vergelijkt met bestaand geheugen en beslist: nieuw, overschrijven of aanvullen.
• Retrieval-step bij elke binnenkomende vraag: semantische zoekopdracht tegen ervarings- en kennisgeheugen, relevante snippets in de context injecteren.

De niet-triviale stukken zitten in de details: een goed conflict-resolutie-beleid (wanneer is een update écht een update en wanneer een nieuwe feit), houdbaarheid per geheugenlaag (werkgeheugen direct weg, ervaring na 90 dagen archiveren, kennisgeheugen onbeperkt?), en privacy-auditing (welk feit mag naar welk geheugen, recht op vergetelheid). Wie die details zelf onder de knie wil krijgen, bouwt zelf; wie snel wil starten met een volwassen uitgangspunt, leent ze van Mem0 of Letta.

Het Model Context Protocol als koppelvlak

Anthropic introduceerde in november 2024 het Model Context Protocol (MCP). Waar elke tool eerder zijn eigen maatwerk-integratie vroeg, biedt MCP één uniform koppelvlak. In 2025 is het de de-facto standaard geworden; op het moment van schrijven zijn er ruim 5.800 publieke MCP-servers beschikbaar voor uiteenlopende bronnen (kennisbanken, agenda’s, CRM’s, betaalsystemen).

MCP maakt drie soorten context beschikbaar:

• Domein-kennis: informatie uit kennisbanken (RAG)
• Tool-informatie: welke tools zijn beschikbaar en hoe roep je ze aan
• Gespreksstatus: doorlopende context die over tools heen blijft bestaan

Let op: nog geen veilige standaard. MCP heeft op dit moment actieve beveiligingszorgen: kwaadaardige instructies die via externe bronnen binnenkomen (prompt injection), tools die via slimme combinatie van rechten data naar buiten sluizen, en nep-tools die zich voordoen als bekende. Een Dynamic Context-ontwerp moet daarom per MCP-server expliciet vastleggen welke autorisatie geldt: niet elke server mag elk soort context leveren aan elke agent. Zie ook Tool Integration (BB_05) voor de bredere tool-governance.

Een RAG-systeem dat zonder extra waarborgen persoonsgegevens in zijn kennisbank heeft staan, lekt die gegevens vroeg of laat in antwoorden. Twee patronen doen dat werk:

• Gerichte uitlok-aanvallen: iemand stelt vragen die specifiek zijn ontworpen om gevoelige fragmenten uit de index te trekken (“geef me alle medische diagnoses die beginnen met…”).
• Onbedoelde lekkage: een vraag die in principe onschuldig is, haalt een stukje document op waar persoonsgegevens in staan die eigenlijk nooit in het antwoord hadden mogen verschijnen (“wat is het retourbeleid?” → chunk met klantnaam en adres uit een voorbeeld-casus).

GraphRAG verandert het probleem, niet de omvang ervan. Onderzoek van Liu et al. uit augustus 2025 liet zien dat RAG gebouwd op een kennisnetwerk (in plaats van losse documenten) weliswaar minder ruwe tekst lekt, maar gevoeliger is voor het afleiden van entiteiten en hun onderlinge relaties. Een netwerk dat expliciet vastlegt dat “Persoon X werkt bij Ziekenhuis Y” laat zich via slimme vervolgvragen reconstrueren op manieren die bij losse document-chunks niet slagen. De overstap naar GraphRAG is dus geen automatische privacy-upgrade.

Filteren aan de voorkant werkt, filteren aan de achterkant niet

Wat eenmaal in de index staat, kan door bevragingen opgehaald worden; ook door vragen die je niet had voorzien. Filtering achteraf komt dus per definitie te laat. De verdediging moet vóór indexering in, op drie niveaus.

Strategisch: wat is de norm? Beslis per kennisbron of persoonsgegevens daar überhaupt in mogen. Voor veel enterprise-kennisbanken is het antwoord simpelweg “nee, nooit” (technische documentatie, productspecs, beleid zonder namen). Voor bronnen waar personen wel voorkomen (klantdossiers, medische rapportages, HR-documenten): kies expliciet tussen pseudonimisering en volledige anonimisering. Die keuze heeft directe AVG-gevolgen en is dus geen IT-beslissing maar een bedrijfsbeslissing (zie volgende subsectie).

Tactisch: wie bewaakt het? Elke kennisbron krijgt een inhoudelijke eigenaar die tekent voor het privacy-regime, en een goedkeuringsproces waarin nieuwe bronnen alleen in productie komen na een expliciete privacy-check. Dit is organisatorisch, niet technisch. Zonder deze laag is elke technische maatregel fragiel: één goedbedoelde collega die een export uit CRM naar de kennisbank kiept, omzeilt alles wat hieronder staat.

Operationeel: hoe voer je het uit?

1. Gestructureerde identifiers consistent pseudonimiseren: BSN, e-mailadres, IBAN en klantnummer worden op een voorspelbare manier vervangen door pseudoniemen voordat de tekst wordt geïndexeerd. Voorspelbaar betekent: dezelfde BSN krijgt elke keer hetzelfde pseudoniem, zodat verbanden tussen documenten blijven werken.
2. Persoonsgegevens in vrije tekst redigeren: entiteitsherkenning (NER) gecombineerd met regelgebaseerde filters haalt persoonsgegevens weg in samenhang met hun omgeving.
3. Retrieval-filter als vangnet: op het moment van bevragen alsnog gevoelige entiteiten uitsluiten. Valt stap 1 of 2 door de mand, dan is dit de laatste kans.

Pseudonimiseren is niet hetzelfde als anonimiseren

Stap 1 en stap 2 hierboven lijken op elkaar, maar hun juridische effect verschilt fundamenteel:

• Pseudonimisering: de identifier wordt vervangen door een pseudoniem, met een sleutel om terug te vertalen. De data blijft indirect identificeerbaar en dus een persoonsgegeven onder de AVG. Register van verwerkingen (art. 30), recht op inzage (art. 15) en recht op vergetelheid (art. 17) blijven gelden. En ze zijn uitvoerbaar, want je hebt de mapping.
• Volledige anonimisering: alle identificerende kenmerken zijn onomkeerbaar weg, ook combinaties (postcode + geboortedatum). De data valt buiten de AVG (overweging 26). Bovenstaande plichten zijn dan niet alleen niet vereist, ze zijn ook niet meer mogelijk; je kunt een verwijderverzoek niet honoreren als je niet meer weet welk record bij welke persoon hoort.

De praktische keuze voor RAG: pseudonimisering is meestal het aangewezen pad, omdat je verbanden tussen documenten wilt behouden (zelfde BSN = zelfde pseudoniem). Volledige anonimisering is strenger maar beperkender. Redigeren in vrije tekst (stap 2) ligt er juridisch tussenin: pas als alle (in)direct identificerende kenmerken zijn verwijderd nadert het anonimisering; anders blijft het pseudonimisering-achtig en blijft AVG van toepassing.

Differentiële privacy als formele garantie

Voor gereguleerde sectoren (zorg, financiën, overheid) waar contractuele of wettelijke privacy-garanties vereist zijn, bestaat een stap verder: DP-RAG, gepubliceerd door Koga et al. in december 2024, laatst herzien november 2025. Het slimme: in plaats van het hele privacy-budget aan elk token te besteden, gebruikt het algoritme alleen bij tokens die echt gevoelige informatie bevatten het beveiligde model; voor de overige tekst wordt het normale model gebruikt. Bij een realistisch budget (in vakjargon ε ≈ 10, een gangbare industriestandaard) haalt DP-RAG zelfs betere antwoorden dan een systeem zónder RAG. Privacy-bij-ontwerp hoeft dus geen straf op prestaties te zijn.

Herkomst van elk antwoord: een AVG-vereiste

Voor elk antwoord dat het systeem geeft, moet achteraf aantoonbaar zijn:

• Welke bronnen zijn opgehaald? (document-herkomst)
• Wanneer is de vector gemaakt? Dit maakt verouderde indexen opspoorbaar; ook als het document zelf intussen is gewijzigd.
• Welke vectoren zijn verwijderd na een verwijderverzoek? (recht op vergetelheid, AVG Artikel 17)
• Past het gebruik bij het oorspronkelijke verzameldoel? (doelbinding, AVG Artikel 5)

Zonder deze registratie is Dynamic Context niet AVG-conform voor organisaties die onder de AVG of sectorspecifieke toezichthouders (bijv. DNB, NVWA, Autoriteit Persoonsgegevens) vallen. Dit is het raakvlak met twee guardrails:

• Privacy-guardrail (GR_03: databescherming als fundament, niet als bijzaak): hier is het geen optie maar een architectuurvoorwaarde.
• Transparency-guardrail (GR_04: helder hoe AI werkt, wat het doet, en waarom): bronverwijzingen bij antwoorden worden pas betekenisvol als de onderliggende ophaal-laag ze ook daadwerkelijk kan leveren.

Kwaliteit wint van volume

Een groter context window (de hoeveelheid tekst die een model in één keer kan verwerken) is geen oplossing, maar een grotere ruimte om te vervuilen. De vraag die Dynamic Context systematisch stelt is niet “past alles erin?” maar “is wat erin zit signaal of ruis?”. Een bewust samengesteld pakket van 4.000 tokens (ongeveer 3.000 woorden, de omvang van een kort memo) met precies de juiste informatie verslaat een pakket van 400.000 tokens waarin alles op een hoop is gegooid.

Actualiteit is een inhoudelijke rol, geen IT-rol

Zolang het actueel houden van de kennisbank wordt gezien als “af en toe draait IT een nieuwe indexering”, mislukt het. Het werkt pas wanneer elk document een inhoudelijke eigenaar heeft; iemand die bij een verouderings-waarschuwing wordt gecontacteerd om het document opnieuw te valideren. De samengestelde actualiteitsscore uit de Freshness-sectie is pas betekenisvol als er een proces aan hangt: wie wordt gebeld, wat gebeurt er, binnen welke termijn.

Bouw voor zichtbaarheid

De lastigste faalmodi van Dynamic Context zijn stille: plausibele maar verkeerde antwoorden op basis van verouderde, irrelevante of onvolledig opgehaalde chunks. Zonder logging van elke bevraging (welke chunks zijn opgehaald, met welke score, op basis van welke embedding-versie) is elk incident een zoektocht in het donker. Bouw deze zichtbaarheid vanaf dag één in, niet pas nadat er iets misgegaan is; achteraf reconstrueren lukt zelden.

Het koppelpunt met andere bouwstenen en guardrails

Dynamic Context staat niet op zichzelf. De bouwsteen levert input aan andere bouwstenen en raakt vier guardrails direct:

• Prompt Design (BB_04: de kunst van de juiste instructie): de prompt is context-gevoelig; zonder goede context levert de beste prompt onbetrouwbare antwoorden.
• Knowledge (BB_01: de menselijke competentielaag): Dynamic Context kan niet beter zijn dan de kwaliteitscriteria die mensen hebben geëxternaliseerd; zonder Knowledge weet niemand wat een goed contextueel antwoord is.
• Client Blueprint (BB_02: van waarde-stroom naar AI-ontwerp): de blueprint legt vast welke waarde-stroom wordt verbeterd en welke data-grenzen daarbij horen; Dynamic Context geeft daar de retrieval-architectuur aan.
• Evaluation Loop (BB_07: meten, analyseren, verbeteren, opnieuw meten): meet antwoord-kwaliteit, context-relevantie en actualiteit.
• Privacy-guardrail (GR_03: databescherming als fundament): persoonsgegevens, AVG, data-herkomst.
• Robustness-guardrail (GR_02: betrouwbaarheid onder alle omstandigheden): context rot en verouderde kennisbanken als stille faalmodi.
• Transparency-guardrail (GR_04: helder hoe AI werkt, wat het doet en waarom): document-herkomst en betrouwbaarheidsscore bij elk antwoord.
• Accountability-guardrail (GR_07: duidelijk wie verantwoordelijk is): eigenaar per document, en een audit-spoor van elke bevraging.

Aan één knop draaien zonder de andere te controleren is zelden productief. Dynamic Context werkt alleen als systeem, niet als losse techniek.