Een slimme chatbot met ERP-data: meer dan een zoekbalk met AI

Van algemene chatbot naar bedrijfsassistent

Een gewone chatbot formuleert antwoorden op basis van zijn model en de context die in het gesprek staat. Voor vragen als ‘wanneer wordt order 58214 geleverd?’ is dat niet genoeg. Het antwoord moet op dat moment uit het juiste bedrijfsrecord komen.

Microsoft beschrijft dit principe in Business Central: Copilot zoekt namens de gebruiker in bedrijfsdata en kan alleen gegevens benaderen waarvoor die gebruiker toestemming heeft. In Dynamics 365 kunnen bronverwijzingen de gebruiker naar het bijbehorende record brengen. SAP positioneert Joule op dezelfde manier als een laag die relevante bedrijfsinformatie uit gekoppelde processen samenbrengt binnen bestaande toegangscontroles.

Zo hoort de gegevensstroom te werken

De chatbot krijgt niet onbeperkt toegang tot een complete database. Eerst wordt vastgesteld wie de gebruiker is en welke informatie bij die rol hoort. Daarna vertaalt de toepassing de vraag naar een toegestane zoekactie in ERP, CRM of een andere bron.

Het gevonden record wordt vervolgens als context aan het model aangeboden. Het model formuleert een begrijpelijk antwoord, liefst met bron of doorklik naar het record. Een eventuele wijziging — zoals een adres aanpassen of een retour aanmelden — vraagt een afzonderlijke, gecontroleerde actie.

• Vraag begrijpen en de bedoeling vaststellen.
• Identiteit, rol en gegevensrechten toepassen.
• Actuele data uit een goedgekeurde bron ophalen.
• Antwoord formuleren en de gebruikte bron zichtbaar maken.
• Voor wijzigingen een expliciete bevestiging of menselijke goedkeuring vragen.

Wat levert dit in de praktijk op?

Voor medewerkers vermindert het zoekwerk tussen schermen, tabellen en dossiers. Een vraag in gewone taal kan direct leiden naar de juiste order, levering, factuur of klantafspraak. Voor klanten kan dezelfde techniek selfservice ondersteunen, maar dan met een veel beperktere dataset en duidelijke scheiding tussen organisaties.

De waarde zit vooral in snelheid en consistentie. Het systeem kan relevante feiten verzamelen en een antwoord voorbereiden, terwijl de medewerker uitzonderingen en klantcontext blijft beoordelen. Het hoeft daarvoor niet opnieuw op alle bedrijfsdata te worden getraind; de actuele gegevens worden tijdens de vraag gecontroleerd opgehaald.

• Sneller antwoord op terugkerende order- en leveringsvragen.
• Minder schakelen tussen chat, mail en ERP-schermen.
• Eenduidiger antwoord doordat actuele brondata wordt gebruikt.
• Meer selfservice zonder brede toegang tot interne systemen.

De beveiliging bepaalt de kwaliteit

Een koppeling met bedrijfsdata vergroot ook het risico. OWASP waarschuwt dat prompt injection een chatbot kan proberen te verleiden tot ongeoorloofde zoekacties of het uitvoeren van tools. De aanbevolen basis is least privilege: geef de toepassing alleen de minimale rechten die voor de taak nodig zijn en laat gevoelige acties in gewone code controleren.

NIST beschrijft bij de ontwikkeling van een interne RAG-chatbot risico’s rond hallucinaties, data-exposure en ongeautoriseerde toegang. In het prototype werden onder meer toegangscontrole en validatiefilters gebruikt. Voor een ERP-chatbot betekent dit: begin bij voorkeur read-only, log zoekacties, test met misleidende invoer en maak een veilige overdracht naar een medewerker.

Een verstandige eerste versie

Start met een afgebakende set vragen en één betrouwbare bron, bijvoorbeeld orderstatus en verwachte leverdatum. Laat gebruikers het bronrecord openen en feedback geven op het antwoord. Pas na voldoende betrouwbaarheid volgen bredere gegevensbronnen of acties.

Zo wordt de chatbot geen slimme voorkant bovenop onduidelijke data, maar een gecontroleerde toegang tot informatie die al in de organisatie aanwezig is.

Bronnen en verder lezen