Een AI-chatbot op je bedrijfsdata geeft correcte antwoorden als hij weet wat je cijfers betekenen. Dat vraagt vier dingen: afgesproken definities voor je belangrijkste KPI's, een eigenaar per definitie, zicht op de datakwaliteit en toegang tot dezelfde bron als je dashboards. Meer data of een sterker model lost dat niet op. De chatbot leest dezelfde onduidelijke definities als je collega's, alleen sneller en met meer zelfvertrouwen.
Waarom meer data een chatbot niet slimmer maakt
Veel teams denken dat een chatbot betere antwoorden geeft als je hem meer tabellen en documenten geeft. Dat klopt niet. Meer bronnen betekent vaak meer versies van hetzelfde begrip, en dus meer kans dat hij de verkeerde kiest.
Een voorbeeld. Iemand vraagt de chatbot: "Wat was onze omzet in het tweede kwartaal?" Finance rekent omzet na kortingen. Het salesdashboard toont omzet vóór kortingen. In het datawarehouse staat nog een kolom met factuurbedragen inclusief btw. De chatbot kiest er een, rekent correct, en geeft een antwoord dat zeker klinkt.
Het cijfer is niet verzonnen. Het is gewoon niet het cijfer dat jouw CFO bedoelt. En de lezer kan niet zien welke definitie de chatbot gebruikte.
In de praktijk is dat hetzelfde probleem dat je al jaren hebt met dashboards. Twee rapporten, twee cijfers, een vergadering die over het cijfer gaat in plaats van over de beslissing. De chatbot maakt het alleen zichtbaarder, omdat hij het antwoord in één zin geeft.
Wat heeft een AI-chatbot op onze bedrijfsdata nodig?
Een taalmodel kan goed rekenen en goed formuleren. Wat het niet kan, is raden wat jouw organisatie met een woord bedoelt. Die context moet je aanleveren.
- Afgesproken definities. Eén zin per KPI die in een directie- of managementrapport staat, in gewone taal. Wat telt mee, wat niet, over welke periode.
- Een eigenaar per definitie. Eén persoon die de definitie mag wijzigen en bij wie je terechtkunt als het antwoord vreemd lijkt. Geen team, een naam.
- Context bij de data. Welke tabel of welke measure hoort bij welk begrip, welke filters standaard gelden, en welke kolommen je beter niet gebruikt.
- Zicht op datakwaliteit. Is de data van vandaag volledig geladen? Zijn er gekende problemen met een bron? Een chatbot die dat niet weet, rapporteert een half geladen dag als een slechte dag.
- Dezelfde bron als je dashboards. Als de chatbot op ruwe tabellen werkt en je dashboards op een semantisch model, krijg je per definitie twee waarheden.
Geen van die vijf is nieuw. Het is hetzelfde werk dat je dashboards betrouwbaar maakt. Het verschil is dat een chatbot het zonder dat werk niet kan verbergen.
Hoe zorg ik dat onze AI-chatbot dezelfde cijfers geeft als onze dashboards?
Laat de chatbot lezen uit dezelfde plek als je rapporten, en geef hem dezelfde definities mee.
- Kies je semantisch model als bron. In Power BI zitten je measures al in het semantisch model. Als de chatbot die measures gebruikt in plaats van zelf SQL te schrijven op ruwe tabellen, rekent hij op dezelfde manier als je dashboards.
- Leg de definitie vast naast de measure. De naam "Omzet" zegt te weinig. Een korte beschrijving in gewone taal helpt zowel de lezer van het rapport als de chatbot.
- Maak een testset. Neem twintig vragen waarvan je het antwoord kent uit een gecertificeerd dashboard. Stel ze aan de chatbot. Elk verschil is een signaal.
- Zoek bij een verschil eerst naar de definitie. Meestal gebruikt de chatbot een andere tabel, een ander filter of een andere periode. Dat los je op in de definitie, niet in de prompt.
- Laat de chatbot zijn bron tonen. Een antwoord met "volgens de measure Netto-omzet, eigenaar Finance" kan je controleren. Een kaal getal niet.
Hoe maak ik één bron van waarheid voor mensen en AI?
De verleiding is groot om voor de chatbot een apart document te maken: een lijst met definities die je in de systeemprompt of in een kennisbank stopt. Dat werkt een paar weken. Daarna heb je twee lijsten die uit elkaar groeien, een voor de mensen en een voor de AI.
Eén bron van waarheid betekent dat er één plek is waar een definitie, de eigenaar en de kwaliteitsstatus worden bijgehouden. Mensen lezen die in hun rapporten. De chatbot leest dezelfde plek. Als Finance de definitie van netto-omzet aanpast, verandert ze voor iedereen tegelijk.
Concreet vraagt dat drie dingen. Een plek die door de eigenaars zelf wordt bijgehouden, niet door één persoon in IT. Een koppeling met je rapporten, zodat mensen de definitie zien waar ze het cijfer lezen. En een manier waarop je AI-toepassingen dezelfde informatie kunnen opvragen.
Waar haalt een chatbot zijn context vandaan?
| Bron van context | Zelfde cijfer als je dashboard | Wie houdt het actueel | Ziet de lezer de definitie |
|---|---|---|---|
| Ruwe tabellen in het datawarehouse | Zelden | Niemand specifiek | Nee |
| Semantisch model met measures | Ja, als de chatbot de measures gebruikt | De bouwer van het model | Alleen als de beschrijving zichtbaar is |
| Apart document in de prompt of kennisbank | Soms, tot het verouderd is | Wie het document schreef | Nee |
| Gedeelde laag met definities, eigenaars en datakwaliteit | Ja, als ze op hetzelfde model wijst | De benoemde eigenaar | Ja, in het rapport en in het antwoord |
Een praktisch kader: Afspreken, Toewijzen, Koppelen, Controleren, Testen
- Afspreken: één definitie in gewone taal voor elke KPI die in een managementrapport staat.
- Toewijzen: één eigenaar per definitie, met naam, die ze mag wijzigen.
- Koppelen: elke definitie verwijst naar de measure of tabel waar het cijfer vandaan komt.
- Controleren: een kwaliteitsstatus per dataset, zodat mens en chatbot weten of de data van vandaag bruikbaar is.
- Testen: een vaste set vragen waarvan je het antwoord kent, die je na elke wijziging opnieuw stelt.
Waar dScribe past
Een semantische laag is geen code. Het is een businesslaag die je begrippen, hun eigenaars en de rapporten waarin ze voorkomen aan elkaar koppelt. dScribe helpt je die laag op te bouwen met slimme suggesties. Ze helpen je termen en KPI's te definiëren en koppelen ze aan de rapporten en datasets waarin ze lijken te worden gebruikt. Ze vinden ook dubbele definities en helpen de lineage vastleggen. Een KPI definiëren blijft deels handwerk, maar de eigenaar vertrekt van een voorstel in plaats van een leeg blad.
Die semantische laag blijft niet in dScribe zitten. Via een MCP-server stelt dScribe definities, eigenaars, koppelingen en gekende kwaliteitsproblemen ter beschikking van andere chatbots, AI-agents en workflows. Je chatbot leest zo dezelfde betekenis als je collega's, die in Power BI de definitie en de eigenaar naast het cijfer zien via de browserplugin.
In short
Een chatbot op je bedrijfsdata is zo goed als de afspraken eronder. Als je mensen vandaag nog discussiëren over wat omzet betekent, zal de chatbot die discussie niet beslechten. Hij kiest gewoon een kant. Spreek de definities eerst af, geef ze een eigenaar, en laat mensen en AI dezelfde bron lezen.
Veelgestelde vragen
Waarom geeft onze AI-chatbot andere cijfers dan onze dashboards?
Meestal omdat hij een andere definitie gebruikt: een andere tabel, een ander filter of een andere periode. Laat de chatbot rekenen op de measures uit je semantisch model en geef hem dezelfde definities die je rapporten gebruiken.
Heeft een chatbot op bedrijfsdata een semantisch model nodig?
Niet strikt, maar het helpt veel. Een semantisch model legt vast hoe een KPI berekend wordt. Zonder dat schrijft de chatbot zijn eigen berekening, en die wijkt vaak af van wat je dashboards tonen.
Volstaat het om onze definities in de prompt te zetten?
Voor een proefproject wel. Op langere termijn krijg je twee lijsten met definities die uit elkaar groeien. Beter is één plek die zowel je rapporten als je chatbot lezen.
Wie moet de definities voor een AI-chatbot beheren?
Dezelfde mensen die de definities voor je rapporten beheren: de business-eigenaar van elke KPI. Het BI-team of het AI-team kan de koppeling bouwen, maar de betekenis hoort bij de business.
Hoe test je of een AI-chatbot correcte antwoorden geeft op bedrijfsdata?
Stel een vaste set vragen waarvan je het antwoord kent uit een gecertificeerd dashboard. Herhaal die set na elke wijziging aan model, data of definities. Elk verschil wijst meestal naar een definitie die niet eenduidig is.