Contextlaag (voor AI-agents)

Wat is een contextlaag voor AI-agents?

Een contextlaag zit tussen je data en een AI-agent en levert de betekenis van die data op het moment dat de agent ze opvraagt. Grijpt de agent naar een tabel, dan vertelt de laag hem wat het bedrijf onder omzet verstaat, welke measure de goedgekeurde is, waar de cijfers vandaan komen, of de laatste laadbeurt gelukt is en of de persoon die de vraag stelt het antwoord wel mag zien.

Het is een verzamelterm. Een businessbegrippenlijst, een semantisch model met measures, een data catalog, lineage, datakwaliteitscontroles en toegangsregels bestaan elk apart, en de meeste bedrijven hebben er al een paar van. Nieuw is dat je ze aan elkaar knoopt tot een dienst die een machine kan bevragen, want een agent kan niet even naar een collega stappen om iets te vragen.

Zo kan je het bekijken: alles wat een ervaren analist over jullie data weet maar nooit opschreef, opgeschreven en achter een endpoint gezet. De agent stelt een vraag, de laag antwoordt met definities, relaties en rechten, en pas daarna gaat de agent cijfers halen.

Waarom ruwe tabellen niet volstaan voor een agent

Zet een agent op een warehouse en hij vindt zijn weg in het schema. Alleen zegt het schema nergens wat iets betekent, en een taalmodel vult stilte op met een gok.

Kolomnamen liegen. Een kolom amount kan netto of bruto zijn, in euro of in de valuta van de bestelling, voor of na korting. De agent leest de naam en kiest de betekenis die hij elders het vaakst zag.

Hetzelfde woord betekent drie dingen. Sales noemt een getekende offerte omzet, finance noemt een verstuurde factuur omzet, en het directierapport rekent met erkende omzet na retours. Een agent die omzet per kwartaal moet geven, kiest er een en zegt niet welke.

De agent kan het niet vragen. Een analist die twijfelt over een veld belt de collega die het rapport bouwde. Wat nergens leesbaar opgeschreven staat, bestaat voor een agent niet.

Rechten zitten op de verkeerde plek. Veel bedrijven regelen wie wat ziet door te kiezen wie welk rapport krijgt. Zodra een agent aan de onderliggende tabel kan, valt die controle weg, tenzij de regel op de data zelf zit.

Gartner hing er op zijn Data and Analytics Summit in Londen in mei 2026 een cijfer aan: organisaties die semantiek in hun AI-ready data vooropstellen, halen tegen 2027 tot 80 procent meer nauwkeurigheid uit hun agents en tot 60 procent lagere kosten. Wat je ook van de percentages vindt, de richting klopt met wat wij zien: agents lopen veel vaker vast op betekenis dan op SQL.

Wat je al hebt, en de twee dingen die meestal ontbreken

Een contextlaag is grotendeels assemblage, geen nieuwbouw.

• Businessbegrippenlijst. De afgesproken definitie van elke term, met een eigenaar. Vaak in een catalog, soms in een wiki. De laag heeft ze nodig in een vorm die een machine kan lezen, dus de wiki-versie moet verhuizen.

• Measures in het semantisch model. In een semantisch model in Power BI zit al hoe omzet en marge berekend worden, in logica waar finance zijn handtekening onder zette. Dat is de beste input die je hebt.

• Metadata uit de catalog. Beschrijvingen van tabellen en kolommen, gevoeligheidslabels, certificeringsstatus. De catalog weet welke van de vier klanttabellen de gecertificeerde is.

• Lineage. Waar een cijfer vandaan komt en waarvan het afhangt, zodat de agent kan melden dat dit margecijfer door een mappingtabel loopt die vorige week aangepast werd.

• Datakwaliteitscontroles. De resultaten van je pipeline-tests op versheid en volledigheid, zodat de agent kan zeggen dat de verkooptabel sinds maandag niet meer geladen is, in plaats van met oude data te antwoorden.

• Toegangsregels. Row-level en column-level security, gevoeligheidslabels, workspace-rechten. De laag moet ze afdwingen op elke oproep, met de identiteit van wie de vraag stelt.

Twee dingen ontbreken meestal.

Een machineleesbare ontologie. Een begrippenlijst definieert termen een voor een. Een ontologie zegt hoe ze samenhangen: een klant plaatst bestellingen, een bestelling heeft lijnen, een lijn verwijst naar een product. Die relaties laten een agent een vraag over drie tabellen beantwoorden zonder de join te verzinnen. In de praktijk is dat een klein model met een twintigtal entiteitstypes, afgeleid uit het semantisch model dat je al hebt.

Een serveerinterface. Alles hierboven moet bereikbaar zijn van binnen de loop van de agent. In 2026 is dat meestal een MCP-server die de definities, measures en regels als resources en tools aanbiedt, of een API op de semantic layer zoals dbt die meelevert met zijn MCP-server. De interface maakt het verschil tussen context die in een document staat en context die een agent effectief gebruikt.

Voorbeeld: brutomarge per klant

Een salesdirecteur vraagt aan een agent wat de brutomarge op klant Vandenbroucke NV was in het tweede kwartaal.

Rechtstreeks uit de ruwe tabellen. De agent vindt sales_lines met de kolommen amount en cost, telt beide op voor die klant en die periode, en antwoordt: amount 121.000 euro, cost 70.000 euro, marge 51.000 euro of 42 procent. Drie dingen liepen fout die de agent niet kon weten. In de kolom amount zit 21 procent btw, dus de echte omzet is 100.000 euro. Creditnota's voor 8.000 euro staan in een aparte tabel die de agent nooit koppelde. En cost is de standaardkost op het moment van de bestelling, terwijl finance de brutomarge definieert op de aankoopkost inclusief transport, wat 4.000 euro inkomende vracht uit nog een andere tabel toevoegt.

Via de contextlaag. De agent vraagt eerst aan de laag wat brutomarge betekent. De laag geeft de goedgekeurde measure terug: netto-omzet na creditnota's, min de aankoopkost inclusief transport, met de opmerking dat netto-omzet exclusief btw is en dat creditnota's in credit_notes geboekt staan. Ze geeft ook mee dat de entiteit klant de facturatieklant is en niet het leveradres, dat de verkooptabel vanmorgen geladen werd, en dat de vraagsteller in de rol salesmanagement zit die marge per klant mag zien. De agent rekent nu 100.000 min 8.000 als omzet en 74.000 als kost, en antwoordt 18.000 euro, of 19,6 procent.

Dat is 42 tegenover 19,6 procent op dezelfde klant, en het eerste antwoord zag er volkomen zeker uit. Had een magazijnplanner dezelfde vraag gesteld, dan had de laag de definitie teruggegeven en de data geweigerd, want marge per klant zit niet in de regels van die rol. De agent zegt dat dan ook, in plaats van rond de beperking te gokken.

Contextlaag versus metrics layer en knowledge graph

Contextlaag versus metrics layer

Het duidelijkste onderscheid is wat een agent terugkrijgt. Van een metrics layer krijgt hij een getal: vraag brutomarge per klant en hij krijgt het cijfer, berekend volgens een beheerde definitie. Dat is precies wat die laag hoort te doen, en een goede contextlaag gebruikt de metrics layer daarvoor.

Van een contextlaag krijgt hij betekenis, relaties en rechten: wat brutomarge hier betekent, hoe klant samenhangt met bestelling en factuur, van welke tabellen de measure afhangt, wanneer die ververst werden, en of deze gebruiker het resultaat mag zien. De metrics layer beantwoordt de vraag. De contextlaag zegt de agent welke vraag hij moet stellen, aan welke bron, en of dat mag.

Contextlaag versus knowledge graph

Een knowledge graph is een manier om entiteiten en hun relaties op te slaan. Het is een logische opslagplaats voor het ontologie-deel van een contextlaag, en zowel Fabric IQ van Microsoft als DataHub bouwen onderaan op een graph. De contextlaag is de dienst erbovenop: de interface die een agent aanroept, de afdwinging van de regels op elke oproep, en de koppelingen die measures, kwaliteitsresultaten en lineage binnenhalen uit systemen die helemaal geen graph zijn. Je kan een contextlaag bouwen zonder graph, en je kan een graph hebben die niemand aan een agent serveert.

Hoe leveranciers het in 2026 verpakken

Microsoft kondigde Fabric IQ aan op Ignite in november 2025, met een ontologie-item in preview dat entiteitstypes, eigenschappen, relaties en regels vastlegt en ze koppelt aan lakehouse-tabellen, event streams en semantische modellen in Power BI. In de eigen documentatie omschrijft Microsoft die ontologie als een business context layer die agents in een gedeelde bedrijfstaal verankert. Een ontologie kan afgeleid worden uit een bestaand semantisch model, en de Fabric data agent bevraagt de data met de identiteit van de gebruiker, zodat row-level en column-level security blijven gelden.

Catalog-leveranciers hebben zich rond de term heruitgevonden. Atlan noemt zichzelf nu de context layer for AI en ziet een semantic layer als een onderdeel ervan. DataHub kondigde in mei 2026 een Context Platform voor analytics-agents aan, met een MCP-server die definities, beproefde querypatronen en join-logica serveert, en haalt een designpartner aan wiens agent van ongeveer de helft naar ongeveer 90 procent juiste antwoorden ging. Die nauwkeurigheidscijfers komen van de leverancier zelf, maar het mechanisme dat ze beschrijven is het mechanisme hierboven.

Decision traces en context graphs zijn de nieuwste toevoeging. Investeerder Foundation Capital stelde eind 2025 in een essay over context graphs dat het ontbrekende record in de meeste bedrijven niet de data is maar de beslissing: welke definitie gebruikt werd, onder welke policy, met welke uitzondering. Of dat een product wordt of een functie van de catalog is nog niet beslist, maar het is de richting waarin de verzamelterm opschuift: van wat de data betekent naar waarom de laatste beslissing erover genomen werd.

Waar een KMO begint

Je hebt geen graph database of nieuw platform nodig voor het grootste deel van de waarde. Vier dingen, in deze volgorde, dekken het gewone geval.

1. Twintig gedefinieerde measures in het semantisch model. Neem de vragen die mensen effectief stellen, volg ze terug naar de measures waarop ze steunen, en geef elke measure een goedgekeurde definitie en een beschrijving in gewone taal. In Power BI is dat de beschrijving op de measure plus de AI-instructies onder Prep data for AI, bewaard op het model.

2. Een begrippenlijst met eigenaars. Een pagina per term waar al discussie over geweest is, met de definitie en de naam van wie beslist.

3. Een read-only serveer-endpoint. Een MCP-server of een API op de semantic layer die de measures en de begrippenlijst aanbiedt, draait met de identiteit van de vraagsteller en niets kan wegschrijven. Begin met de eigen agent van je platform als die er is, want daar zit de doorgifte van rechten al in.

4. Een set testvragen. Dertig vragen met het antwoord dat je verwacht, inclusief een paar die de agent moet weigeren. Draai ze na elke wijziging aan het model of de begrippenlijst. Het is de enige manier om te weten of de laag werkt in plaats van alleen maar te bestaan.

Waar moet je op letten bij een contextlaag

Ze beslecht de discussie niet. Zijn sales en finance het niet eens over wat omzet betekent, dan serveert de laag die onenigheid met meer overtuiging aan de agent. Het definitiewerk komt eerst, en dat is een taak voor de directie.

Rechten horen in de laag, niet in de prompt. Een agent in zijn instructies zeggen dat hij geen lonen mag tonen, is geen controle. De regel moet afgedwongen worden op de data-oproep, met de identiteit van de gebruiker, zodat een prompt injection of een slimme vraag er niet omheen kan praten.

Een protocol verplaatst context, het maakt ze niet. Een MCP-server op een warehouse zonder definities erachter geeft de agent sneller toegang tot dezelfde dubbelzinnigheid. De serveerinterface is het laatste stuk, niet het eerste.