Je semantische laag wordt de API voor AI

AI kan inmiddels prima SQL schrijven.

Geef een taalmodel toegang tot een database, vertel welke tabellen erin staan en vraag wat de omzet vorige maand was. De kans is groot dat er binnen enkele seconden een keurige query en een overtuigend antwoord uit komen.

Maar daarmee weet AI nog niet wat jullie onder omzet verstaan.

Gaat het om geboekte omzet, gefactureerde omzet of geleverde omzet? Tellen creditnota’s mee? Intercompany-omzet? Welke datum bepaalt de maand? En als iemand vraagt naar omzet in Nederland, bedoelen we dan het land van de klant, het afleveradres of de verkooporganisatie?

Dat is geen SQL-probleem. Het is een semantisch probleem.

En juist daarom krijgt een concept dat al decennia in Business Intelligence rondzingt ineens opnieuw veel aandacht: de semantic layer.

Sterker nog, ik denk dat de rol ervan fundamenteel verandert.

Tot nu toe bouwden we semantic models vooral om dashboards en rapportages van consistente businesslogica te voorzien. Straks gebruiken AI-agents diezelfde laag om onze organisaties te begrijpen.

Van BI-laag naar interface voor AI

De semantic layer is niet nieuw

Wie al wat langer in Business Intelligence rondloopt, zal het idee herkennen. In de klassieke BI-wereld was een semantic layer heel normaal. Een bekend voorbeeld is de BusinessObjects Universe. Een Universe plaatste een businessvriendelijke laag over de technische databasestructuur. Gebruikers werkten met herkenbare begrippen, dimensies, measures en hiërarchieën, zonder te hoeven weten hoe de tabellen en joins daaronder precies in elkaar zaten.

SAP omschrijft een Universe nog steeds als een verzameling metadata-objecten waarmee gebruikers data kunnen analyseren in niet-technische, begrijpelijke bedrijfstaal. (SAP Help Portal)

Cognos had met Framework Manager een vergelijkbaar concept.

Het idee was simpel en eigenlijk heel verstandig:

De database vertelt hoe data is opgeslagen, de semantic layer vertelt wat die data betekent.

Daar zat natuurlijk ook een keerzijde aan.

Deze klassieke BI-omgevingen konden behoorlijk zwaar worden. Voordat een gebruiker een rapport kon bouwen, moest er vaak eerst een datawarehouse zijn ontworpen, een centraal model zijn gebouwd, een Universe zijn ingericht en iemand toestemming hebben gegeven om ermee te werken.

Dat was niet bepaald agile.

Toen kwam self-service BI

Vanaf grofweg de tweede helft van de jaren 2000 veranderde het speelveld.

Producten zoals QlikView, later Qlik Sense en Tableau maakten het veel makkelijker om snel met data te werken. In plaats van maandenlang een centrale BI-laag te ontwerpen, kon een analyst of developer data laden, modelleren, visualiseren en vrijwel meteen iets bruikbaars opleveren.

Dat was een enorme vooruitgang.

Ik heb zelf jarenlang met Qlik gewerkt en juist die snelheid en vrijheid waren een groot deel van de aantrekkingskracht.

Maar er zat ook een consequentie aan die beweging: de expliciete, centraal beheerde semantic layer raakte wat uit beeld.

Dat wil niet zeggen dat Qlik, Tableau of later Power BI geen semantiek bevatten. Integendeel. Een Qlik-datamodel bevat relaties en businesslogica, Tableau kent logical models en Power BI heeft inmiddels uitgebreide semantic models.

Maar in de praktijk raakte die betekenis vaak verspreid over verschillende lagen. Zeker in Qlik werd veel businesslogica niet alleen in het datamodel vastgelegd, maar ook in variables, set analysis, master measures, scriptlogica en zelfs individuele objectexpressies.

Dat werkte prima zolang ervaren developers wisten waar alles stond en waarom iets zo was gebouwd. Maar het maakte de businessbetekenis minder expliciet, minder centraal en lastiger herbruikbaar buiten de oorspronkelijke applicatie.

De semantic layer als zelfstandig architectuurprincipe kreeg daardoor veel minder aandacht.

We gingen steeds vaker businesslogica vastleggen waar we die op dat moment nodig hadden:

• In een Qlik-app
• In een Tableau-workbook,
• In een Power BI semantic model,
• In een SQL-view,
• In een DAX-measure,
• In een ETL-script.

En soms op meerdere plaatsen tegelijk.

Self-service maakte analytics toegankelijker, maar maakte het ook heel makkelijk om meerdere versies van dezelfde waarheid te creëren.

Uiteindelijk liepen we tegen hetzelfde probleem aan

Zolang een organisatie een beperkt aantal dashboards heeft, valt het nog wel mee. Maar naarmate self-service BI succesvol wordt, verschijnen er tientallen of honderden modellen, apps en rapportages. Dan ontstaan bekende discussies.

Het opvallende is dat dit ongeveer dezelfde problemen zijn waarvoor de klassieke semantic layer ooit werd bedacht.

En dus kwam het concept terug.

Power BI spreekt tegenwoordig expliciet over semantic models. Looker bouwde een groot deel van zijn platform rond LookML. dbt ontwikkelde zijn Semantic Layer en MetricFlow. Data-platformleveranciers praten steeds vaker over metrics, data products, ontologies en semantic layers.

Ik kijk zelf soms met enige nostalgie terug op BusinessObjects. Universes waren zo gek nog niet. Maar de herwaardering van de semantic layer komt vooral doordat we opnieuw ontdekken dat toegang tot data iets anders is dan overeenstemming over de betekenis ervan.

En dan komt AI om de hoek kijken.

AI maakt het probleem veel groter

Neem opnieuw die vraag:

“Wat was onze omzet vorige maand?”

Een menselijke data-analist die onvoldoende context heeft, kan doorvragen:

Een analyst kan ook herkennen dat een resultaat vreemd lijkt. Als de omzet normaal rond de vijf miljoen ligt en er ineens 28 miljoen uit de query komt, gaat er waarschijnlijk ergens een alarmbel af.

Een AI-agent heeft die intuïtie niet automatisch.

Die kan een tabel vinden met een kolom Revenue, daar een andere tabel aan koppelen, een plausibele query genereren en met groot zelfvertrouwen een verkeerd antwoord presenteren.

Misschien is de join verkeerd. Misschien gebruikt hij bookings in plaats van revenue. Misschien wordt iedere orderregel drie keer geteld. Misschien kent hij een uitzondering van Finance niet.

Het antwoord kan er nog steeds uitstekend uitzien en dat maakt dit gevaarlijker dan een gewone foutmelding.

De uitdaging is niet meer om data vindbaar te maken

De afgelopen twintig jaar hebben we enorm veel energie gestoken in het toegankelijk maken van data.

Cloud datawarehouses, lakehouses, APIs, ELT, notebooks en self-service BI hebben ervoor gezorgd dat het technisch steeds eenvoudiger wordt om ergens bij te komen.

Generatieve AI doet daar nog een schep bovenop. Een gebruiker hoeft straks misschien niet eens meer te weten waar data staat. Hij stelt gewoon een vraag. Daarmee verschuift het probleem. De vraag is niet langer alleen:

“Kan AI bij onze data?”

De belangrijkere vraag wordt:

“Weet AI hoe onze organisatie die data interpreteert?”

Daar komt de semantic layer weer om de hoek kijken.

Het semantic model als contract

Ik vind het nuttig om een goed semantic model te zien als een soort contract. Het legt vast:

Technisch kan zo’n model bestaan uit measures, dimensies, relaties, berekende velden, hiërarchieën, metadata en securityregels, maar functioneel doet het iets belangrijkers. Het legt een gedeelte van de bedrijfstaal vast in een vorm die software kan gebruiken. Tot voor kort waren dashboards de belangrijkste afnemers van dat contract, nu komt daar een heel nieuw type consument bij: de AI-agent.

Microsoft bouwt hier al expliciet naartoe

Microsoft heeft inmiddels zelfs aparte richtlijnen gepubliceerd voor het AI-ready maken van Power BI semantic models. Daarin benadrukt Microsoft onder andere het belang van duidelijke namen, beschrijvingen, correcte relaties en het terugbrengen van ambiguïteit in het model. De kwaliteit van antwoorden van een Data Agent hangt volgens Microsoft sterk af van hoe goed de gebruikte databronnen en semantic models zijn voorbereid.

Dat is veelzeggend.

We hebben metadata jarenlang vaak gezien als documentatie. Iets wat je eigenlijk zou moeten bijhouden, maar waar in de praktijk zelden genoeg tijd voor is. Voor AI verandert metadata van documentatie in “runtime context”. Een omschrijving van een measure is dan niet alleen nuttig voor de volgende developer. Een agent gebruikt die beschrijving daadwerkelijk om te bepalen wat de measure betekent en wanneer deze toegepast moet worden.

En dan komt MCP erbij

Microsoft ondersteunt daarnaast het gebruik van een Fabric Data Agent als Model Context Protocol-server, op dit moment nog in preview. Via MCP kan zo’n agent zijn data en querymogelijkheden beschikbaar stellen aan externe AI-systemen.

MCP is een standaard waarmee AI-applicaties op een uniforme manier tools, context en databronnen kunnen ontdekken en gebruiken. Het interessante is niet eens zozeer MCP zelf. Misschien wordt MCP over een paar jaar vervangen door iets beters. Het interessante is het architectuurprincipe erachter.

De applicatie waarin iemand zijn vraag stelt, hoeft niet langer dezelfde applicatie te zijn waarin de businesslogica wordt beheerd. Een AI-assistent kan ergens anders draaien en toch een governed data- of analyticslaag raadplegen. Dat maakt de semantic layer ineens veel meer dan de achterkant van een dashboard.

Het wordt een service.

Qlik kiest dezelfde richting

Dat is een interessante ontwikkeling. Een traditionele discussie zou zijn:

“Gebruiken we Qlik of Power BI?”

Maar met deze architectuur kun je een andere vraag stellen:

“Waar beheren we de betrouwbare analytische context die onze gebruikers en agents nodig hebben?”

Een organisatie zou bijvoorbeeld Power BI als primaire rapportagetool kunnen gebruiken terwijl bepaalde governed data of analytische logica elders wordt beheerd.

Of een AI-assistent kan Qlik raadplegen zonder dat de gebruiker ooit een Qlik-dashboard opent. Dat maakt platformgrenzen minder vanzelfsprekend.

TimeXtender maakt het idee misschien nog explicieter

TimeXtender formuleert het probleem treffend: een AI-systeem kan zonder zo’n context een veld kiezen dat logisch klinkt, een uitzonderingsregel missen of een technisch geldige maar inhoudelijk verkeerde join leggen.

En dat brengt ons eigenlijk weer terug bij het BusinessObjects Universe. We plaatsen opnieuw een businessvriendelijke laag tussen fysieke data en de consument. Alleen is die consument nu niet uitsluitend een rapportagegebruiker. Het kan ook software zijn.

Eén semantic layer, meerdere consumenten

Dat vind ik de fundamentele verschuiving. We hebben een semantic model lang gezien als iets dat bij een BI-tool hoort. Een Power BI semantic model hoort bij Power BI reports. Een Qlik model of Master Items horen bij Qlik visualisaties. Een Universe hoort bij Web Intelligence (of Deski).

Maar stel je een architectuur voor waarin dezelfde governed businesslogica wordt gebruikt door:

• Dashboards;
• Excel;
• Operationele applicaties;
• API’s;
• Copilots;
• Chatinterfaces;
• AI-agents;
• Autonome processen.

Dan verandert de economische waarde van die semantic layer behoorlijk. Het dashboard wordt één van de mogelijke gebruikers. Niet langer noodzakelijk het eindproduct waar alles omheen wordt gebouwd.

AI maakt goede modellering belangrijker, niet overbodig

Er is ook een tegenovergestelde gedachtegang. Als AI zelf queries kan schrijven, waarom zouden we dan nog zoveel tijd besteden aan modellen, measures en businesslogica? Kan het model dat niet gewoon uitzoeken?

Technisch steeds vaker wel, maar inhoudelijk is dat precies wat je niet wilt.

Hoe makkelijker het wordt om willekeurige data te bevragen, hoe belangrijker een betrouwbare betekenislaag wordt.

Tien medewerkers die hetzelfde dashboard bekijken, zien tenminste dezelfde omzet. Geef diezelfde tien medewerkers ieder een AI-agent die zelfstandig SQL genereert over een complex datawarehouse en je kunt plotseling tien verschillende antwoorden krijgen.

AI democratiseert toegang tot data. Zonder governance democratiseert het ook de mogelijkheid om op grote schaal verschillende waarheden te produceren. Dat maakt goed gemodelleerde en beheerde semantiek belangrijker dan ooit.

Dit verandert ook het werk van BI-teams

Als deze ontwikkeling doorzet, verschuift een deel van het werk van analytics-teams. Vandaag krijgen BI-teams nog veel verzoeken als:

Wanneer gebruikers via AI zelf vervolgvragen kunnen stellen, zal een deel van dat werk waarschijnlijk verdwijnen. Maar dat betekent niet dat het werk verdwijnt. Iemand zal nog steeds moeten bepalen:

• Wat KPI’s precies betekenen;
• Waar de officiële definitie wordt beheerd;
• Welke relaties correct zijn;
• Welke data betrouwbaar is;
• Welke uitzonderingen gelden;
• Welke informatie iemand mag gebruiken;
• Welke modellen leidend zijn;
• Hoe veranderingen worden getest;
• Hoe lineage en ownership worden vastgelegd.

De waarde verschuift van iedere vraag visualiseren naar betrouwbare betekenis organiseren. Voor data- en analyticsprofessionals lijkt mij dat eigenlijk een gezonde ontwikkeling. Al moeten we wel eerlijk zijn: definities documenteren en metadata bijhouden is meestal iets minder leuk dan een mooie visual bouwen.

En onze semantic models zijn daar nog lang niet altijd klaar voor

Er is alleen één probleem. Veel bestaande semantic models zijn ontworpen voor menselijke developers.

Een Power BI-developer weet misschien precies wat een measure met de naam [NS Adj LY %] betekent. Een AI-agent niet.

Een Qlik-developer weet waarom een bepaalde set analysis expression een uitzonderlijke selectie toepast. Een agent die alleen het eindresultaat ziet, heeft geen idee waarom.

Voor AI-ready semantic models worden daardoor zaken belangrijk die we vroeger makkelijk als “nice to have” zagen.

Dit zijn geen exotische AI-technieken. Het zijn grotendeels dezelfde disciplines die we altijd al nodig hadden voor goede BI. AI verhoogt alleen de prijs van slordigheid.

Van semantic layer naar bedrijfsinfrastructuur

Daarom denk ik dat we semantic models opnieuw anders moeten gaan bekijken. Niet als een technisch onderdeel van Power BI. Niet als iets dat alleen in Qlik-apps leeft. Niet als een extra modelleringstool bovenop het datawarehouse.

Een goed opgebouwde semantic layer is in feite een machine-readable beschrijving van hoe een organisatie naar haar eigen data kijkt.

Dat is een waardevol bedrijfsmiddel. Misschien zelfs waardevoller dan veel van de dashboards die erop gebouwd worden. Dashboards komen en gaan, de definitie van omzet, klant, marge, voorraad, bezetting of churn zou veel stabieler moeten zijn. Als die betekenis netjes wordt beheerd, kunnen steeds meer toepassingen daarop aansluiten. Vandaag Power BI, morgen een Copilot, overmorgen een agent die automatisch afwijkingen onderzoekt of acties voorstelt.

We zijn terug bij het Universe, maar toch ook niet

Er zit iets ironisch in deze ontwikkeling. Na twintig jaar innovatie komen we gedeeltelijk terug bij een idee dat BusinessObjects al heel lang geleden had:

Zet een semantische laag tussen de technische data en degene die er iets mee wil doen.

Maar we zijn niet simpelweg terug bij af. De eerste generatie semantic layers was vooral bedoeld om mensen gemakkelijker rapportages te laten bouwen. De nieuwe generatie moet bruikbaar zijn voor mensen én machines.

En dat stelt andere eisen.

De semantic layer moet beter beschreven zijn, programmeerbaar zijn, via gestandaardiseerde interfaces beschikbaar zijn en voldoende governance bevatten om automatische systemen ermee te laten werken. Dat is wezenlijk iets anders.

Begin dus niet bij de chatbot

Veel organisaties die met AI en data willen experimenteren, beginnen logischerwijs bij de zichtbare technologie. Welke LLM gaan we gebruiken? Microsoft Copilot? ChatGPT? Claude? Een eigen agent? Welke vector database? Hebben we MCP nodig?

Als het doel is om betrouwbare antwoorden over de eigen bedrijfsvoering te krijgen, zou ik eerst een andere vraag stellen:

Waar hebben we eigenlijk vastgelegd wat onze data betekent?

Waar staat de officiële omzetdefinitie? Welke klantindeling is leidend? Waar ligt de logica voor brutomarge? Zijn die definities alleen bekend bij een paar ervaren developers? Staan ze verspreid over SQL, Power BI, Qlik en Excel? Of bestaan ze daadwerkelijk als herbruikbare, beheerde businesslogica?

Als het antwoord onduidelijk is, heb je nog niet in de eerste plaats een AI-probleem. Je hebt een semantic-layerprobleem. AI maakt dat probleem alleen ineens heel zichtbaar.

De semantic layer wordt bedrijfsinfrastructuur

Dashboards verdwijnen niet. Voor veel vormen van informatieoverdracht blijft een vooraf ontworpen visualisatie simpelweg beter dan een chatvenster. Maar het dashboard wordt steeds minder het enige eindstation van onze data-architectuur. Dezelfde businesscontext kan straks worden gebruikt door rapportages, applicaties en AI-agents.

Daarmee verandert de semantic layer van een onderdeel van de BI-stack naar een stuk bedrijfsinfrastructuur. Een plek waar we niet alleen vastleggen waar de data staat, maar vooral wat de data betekent. En zodra machines die betekenis rechtstreeks gaan gebruiken, krijgt het semantic model een heel nieuwe rol: het wordt de API waarmee AI jouw organisatie leert begrijpen.

Is jullie datafundament klaar voor AI?

AI-ready worden begint niet bij het kiezen van een taalmodel. Het begint bij betrouwbare data, duidelijke definities en goed beheerde businesslogica.

Wil je weten of jullie huidige data-architectuur, semantic models en governance daar klaar voor zijn? Met onze AI Readiness Assessment brengen we in kaart waar de belangrijkste hiaten zitten en welke stappen nodig zijn om AI betrouwbaar met bedrijfsdata te laten werken.