Beleidsbeheer voor AI-agents is de manier waarop een supportteam de regels die een AI-agent volgt (wat hij mag doen, zijn limieten, zijn uitzonderingen en wanneer hij moet overdragen) één keer opschrijft, een eigenaar geeft, van versies voorziet en gelijk houdt met wat je medewerkers te horen krijgen. Een kennisbank geeft de agent feiten. Een beleidscentrum vertelt hem wat hij ermee mag doen.
In het kort
- Helpartikelen zijn geschreven voor mensen die gaten opvullen met hun oordeel; een AI-agent herhaalt hun impliciete uitzonderingen, oude versies en tegenstrijdigheden op grote schaal.
- Scheid kennis (feiten), beleid (wat de agent mag doen, limieten, uitzonderingen, escalatie) en procedure (de stappen): elk gaat anders mis en heeft een andere eigenaar.
- Houd één beleidskaart per regel bij, met een eigenaar, een versie, een reviewdatum, gekoppelde artikelen en testcases, en laat zowel de macro voor medewerkers als de instructie van de AI-agent ernaar verwijzen.
- Behandel elke beleidswijziging als een release: een benoemde goedkeurder per risiconiveau, een ingangsdatum, het opnieuw draaien van de gekoppelde testcases en een week strengere beoordeling.
- Sluit de cirkel: deel elk mislukt AI-gesprek in naar oorzaak, stuur beleidsoorzaken naar de eigenaar van de kaart en scoor opnieuw na de oplossing.
Deze gids is de hub voor beleid en kennis in onze reeks over AI-agent governance, geschreven voor het hoofd support of de AI-lead wiens AI-agent antwoorden blijft geven die “technisch gezien in het helpcenter stonden”.
Waarom breekt een kennisbank die voor mensen is geschreven bij AI-agents?
Een kennisbank die voor mensen is geschreven, breekt bij AI-agents omdat mensen tussen de regels door lezen en een AI-agent niet. Medewerkers weten welk artikel verouderd is, welke uitzondering de teamleider toestaat en welke twee pagina’s elkaar tegenspreken. De agent haalt op wat het best overeenkomt en brengt het elke keer met overtuiging.
Vier faalpatronen dekken het meeste van wat misgaat:
| Patroon | Wat een medewerker doet | Wat de AI-agent doet | Oplossing |
|---|---|---|---|
| Impliciete uitzonderingen (“meestal maken we een uitzondering voor…”) | Past de ongeschreven uitzondering toe als de case goed voelt | Past ze nooit toe, of past een gegokte versie toe op iedereen | Schrijf de uitzondering op de beleidskaart, met haar voorwaarden en limiet |
| Verouderde versies (de oude retourtermijn staat nog in één artikel) | Weet dat het beleid vorige maand veranderde | Citeert het artikel dat hij als eerste ophaalt | Eén eigenaar per beleid, oude artikelen uit de bronnen van de agent halen, elke wijziging een versie geven |
| Tegenstrijdige artikelen (twee pagina’s, twee getallen) | Vraagt een collega welke juist is | Kiest er één, of mengt ze | Eén bron van waarheid per beleid, andere pagina’s verwijzen ernaar in plaats van het te herhalen |
| Kennis in hoofden (regels in Slack, in het hoofd van de teamleider, in macro’s) | Leerde het tijdens de onboarding of van de collega ernaast | Heeft er helemaal geen toegang toe | Zet elke regel die een uitkomst verandert op een kaart voordat de agent de intent afhandelt |
De eigen gids van Intercom over kennisbanken voor chatbots (in het Engels) zegt het zonder omwegen: een AI-agent haalt trouw een verouderd artikel op en geeft een zelfverzekerd, verkeerd antwoord. De kosten zijn niet abstract. In Moffatt v. Air Canada (2024 BCCRT 149) suggereerde een chatbot dat een rouwende klant na de reis nog een rouwtarief kon aanvragen. Air Canada voerde aan dat de juiste informatie op haar eigen pagina over rouwtarieven stond, gelinkt in datzelfde antwoord, en dat de chatbot een aparte juridische entiteit was die verantwoordelijk was voor zijn eigen handelingen. Het tribunaal van British Columbia verwierp dat argument, zoals deze samenvatting van WeirFoulds (in het Engels) uitlegt. Het bedrijf was eigenaar van het antwoord.
Veel “hallucinaties” in support zijn contentproblemen. Onze gids over AI-hallucinaties laat zien hoe je een verzonnen antwoord onderscheidt van een trouw herhaald verkeerd antwoord, en waarom AI-gesprekken mislukken splitst de oorzaken verder uit.
Wat is het verschil tussen kennis en beleid voor een AI-agent?
Kennis is wat waar is: prijzen, retourtermijnen, levertijden, hoe een functie werkt. Beleid is wat de AI-agent eraan mag doen: welke acties hij mag uitvoeren, tot welke limiet, met welke uitzonderingen, en wanneer hij moet overdragen. Procedure is de volgorde van de stappen. De drie mengen in één artikel is de wortel van de meeste drift.
| Kennis | Beleid | Procedure | |
|---|---|---|---|
| Beantwoordt | Wat is waar? | Wat mag de agent doen, en waar stopt hij? | In welke volgorde gebeuren de stappen? |
| Voorbeeld | “Standaardbestellingen kun je binnen 30 dagen retourneren.” | “De agent mag tot 100 euro terugbetalen zonder goedkeuring; daarboven draagt hij over met het order-ID.” | “Controleer de bestelling, controleer de leverdatum, maak het retourlabel aan, bevestig per e-mail.” |
| Eigenaar | Content- of kennisteam | Zakelijke eigenaar (finance, legal, operations) | Support operations |
| Hoe het misgaat | Verkeerd of verouderd feit | Niet-toegestane actie, gemiste uitzondering, gemiste escalatie | Overgeslagen stap of stappen in de verkeerde volgorde |
De agentplatformen trekken deze lijn al. Intercom controleert de guidance van Fin voordat Fin in je helpcontent naar een antwoord zoekt (in het Engels), en de Fin Procedures (in het Engels) voegen voorwaarden en overdrachten aan een team toe. Decagon beschrijft zijn Agent Operating Procedures (in het Engels) als instructies in natuurlijke taal, ondersteund door code, geschreven zoals je medewerkers zou trainen op SOP’s. Elk platform geeft je een plek om instructies te schrijven. Geen ervan beslist welke regel de actuele is. Dat is de taak van een beleidscentrum.
Hoe bereid je een kennisbank voor op een AI-agent?
Om een kennisbank voor te bereiden op een AI-agent, begin je bij de intents die de agent gaat afhandelen, niet bij het hele helpcenter. Zoek per intent elk artikel dat erover gaat, verwijder dubbelingen en tegenstrijdigheden, schrijf voorwaarden expliciet uit, en haal elke regel die een uitkomst verandert naar een beleidskaart waarnaar het artikel verwijst.
- Zet de belangrijkste intents op een lijst voor het eerste kwartaal van de agent, gerangschikt op volume en risico (geld, recht op iets, juridische formulering).
- Verzamel elke bron die een intent beantwoordt: helpartikelen, macro’s, wikipagina’s, opgeslagen antwoorden, vastgezette berichten in Slack.
- Markeer elke zin als kennis, beleid of procedure. Beleidszinnen bevatten woorden als “mag”, “moet”, “tot”, “alleen als”, “behalve” en “neem contact op”.
- Los conflicten op vóór de lancering. Spreken twee bronnen elkaar tegen, dan beslist de beleidseigenaar, legt één kaart het antwoord vast, en wordt de verliezende pagina herschreven of uit de bronnen van de agent gehaald.
- Schrijf voorwaarden uit. “Als je een jaarabonnement hebt” werkt beter dan “afhankelijk van je abonnement”. De gids van Intercom raadt om dezelfde reden één vraag per artikel en expliciete voorwaarden aan.
- Baken varianten af. Varianten per regio, abonnement en product krijgen elk hun eigen kaart of doelgroep.
- Verwijs, kopieer niet. Helpartikelen en instructies voor de agent verwijzen naar de kaart; ze herhalen de limiet nooit in eigen woorden.
Voor het helpcenter zelf behandelt onze gids over het opbouwen van een kennisbank voor de klantenservice (in het Engels) structuur en schrijfregels voor menselijke lezers.
Wat moet er op een beleidskaart voor een AI-agent staan?
Een beleidskaart voor een AI-agent bevat het beleid in één zin, de scope, de toegestane acties en limieten, de uitzonderingen, de escalatieregel, een eigenaar, een reviewdatum, de gekoppelde helpartikelen en de testcases die bewijzen dat de agent het volgt. Voeg een versie en een ingangsdatum toe, zodat mensen en de agent tegelijk veranderen.
Hier is het template, ingevuld voor een terugbetaling bij een beschadigd artikel. Kopieer het naar een spreadsheet of wiki, één kaart per beleid.
| Veld | Wat je schrijft | Voorbeeld: artikel beschadigd bij aankomst |
|---|---|---|
| Beleids-ID en versie | Vast ID, versienummer, ingangsdatum | RF-DMG-02 · v3 · ingang 1 december |
| Beleid | Eén zin die een klant kan begrijpen | Artikelen die beschadigd aankomen, worden vervangen of terugbetaald als dat binnen 14 dagen na levering wordt gemeld |
| Scope | Kanalen, regio’s, abonnementen, producten, intents die het dekt | Chat en e-mail · Nederland en België · alle abonnementen · intents “beschadigd artikel”, “kapot aangekomen” |
| Toegestane acties en limieten | Wat de agent alleen mag doen, met numerieke limieten | Bestelling opzoeken: ja. Om een foto vragen: ja. Vervanging aanmaken: ja. Terugbetaling: tot 100 euro per bestelling. Tegoedbon: nee |
| Uitzonderingen | Elke uitzondering met haar voorwaarde en eigen limiet | Melding op dag 15 tot 30 met een foto: alleen vervanging, geen terugbetaling. Bederfelijke waren: terugbetaling zonder foto |
| Escalatieregel | Wanneer overdragen, aan wie, met welke context | Terugbetaling boven 100 euro, derde claim in 90 dagen, of een veiligheidsprobleem: overdragen aan het claimsteam met order-ID, foto en leverdatum |
| Nooit | Beloftes die de agent niet mag doen | Geen compensatie boven de orderwaarde; geen belofte over claims bij de vervoerder |
| Eigenaar | Eén benoemde rol, plus een vervanger | Hoofd customer operations (vervanger: lead claims) |
| Reviewdatum | Volgende geplande review, en de trigger voor een vervroegde review | 1 maart, of elke wijziging in de voorwaarden van de vervoerder |
| Gekoppelde helpartikelen | De pagina’s voor klanten die het beleid noemen | “Beschadigde of ontbrekende artikelen”, “Termijnen voor terugbetaling” |
| Instructie voor de agent | Waar de instructie in het agentplatform staat, via verwijzing | Guidance-regel “Beschadigde artikelen” verwijst naar RF-DMG-02 v3 |
| Macro voor medewerkers | De macro of het script dat je mensen gebruiken | Macro “Beschadigd artikel: vervanging of terugbetaling” |
| Testcases | ID’s van de cases die na elke wijziging moeten slagen | RF-014 (dag 15, geen foto), RF-015 (bederfelijk), RF-016 (derde claim) |
| Wijzigingslog | Datum, wijziging, goedkeurder | 12 november: termijn 30 naar 14 dagen, goedgekeurd door hoofd customer operations |
Twee regels houden de kaart eerlijk. Elke limiet staat op precies één plek, de kaart, en het artikel, de macro en de instructie voor de agent verwijzen ernaar. En een kaart zonder testcases is niet af. Onze gids over AI-agents testen heeft het template voor testcases dat aansluit op de laatste velden van deze kaart.
Hoe houd je procedures voor medewerkers en instructies voor AI-agents in één bron van waarheid?
Maak de beleidskaart de enige plek waar een regel wordt vastgelegd, en koppel zowel de macro voor medewerkers als de instructie voor de AI-agent eraan. Verandert de kaart, dan veranderen beide in dezelfde release, en niemand past een limiet rechtstreeks aan in een prompt of een macro.
De bron van waarheid is geen nieuwe tool. Het is een discipline over waar tekst staat:
| Laag | Bevat | Mag niet bevatten |
|---|---|---|
| Beleidskaart | De regel, limieten, uitzonderingen, escalatie, eigenaar, versie | Formuleringen voor klanten, klik-voor-klik-stappen |
| Helpartikel | De uitleg voor klanten, gekoppeld aan de kaart | Een limiet of uitzondering die afwijkt van de kaart |
| Macro en onboarding voor medewerkers | Het script en de stappen voor je mensen | Een eigen kopie van de limiet |
| Instructie voor de AI-agent (guidance, procedure, AOP) | Hoe de agent de kaart toepast: toon, stappen, overdracht | Een geplakte kopie van de beleidstekst die niemand bijwerkt |
Twee gewoontes laten dit werken. Geef instructies de naam van het kaart-ID, zodat een zoekopdracht naar “RF-DMG-02” elke plek vindt die ervan afhangt. En vergelijk uitkomsten, geen tekst: controleer elke maand of een medewerker en de AI-agent op hetzelfde soort case tot hetzelfde resultaat komen. Is dat niet zo, dan werkt een van beiden met een oude versie.
Instructies alleen halen een bron niet weg. De guidance van Intercom merkt op dat Fin nog steeds content kan tonen die zijn guidance-regels hem laten vermijden, en raadt aan die content te verwijderen of per doelgroep af te schermen. Een oud artikel uit de bronnen van de agent halen hoort bij elke beleidswijziging.
Wie keurt een beleidswijziging goed, en hoe bereikt die de AI-agent?
Een beleidswijziging wordt goedgekeurd door de zakelijke eigenaar van het beleid, met meer goedkeurders naarmate het risico stijgt. Ze bereikt de AI-agent in dezelfde release als de macro voor medewerkers en het helpartikel: kaart bijgewerkt, bronnen weggehaald, instructie bijgewerkt, testcases opnieuw gedraaid, ingangsdatum ingesteld, en daarna een week strengere beoordeling.
Koppel het goedkeuringspad aan wat de wijziging met de uitkomst voor de klant doet:
| Niveau | Wat verandert | Goedkeurder | Voordat het live gaat | Daarna |
|---|---|---|---|---|
| A. Formulering | Duidelijkere tekst, dezelfde uitkomst | Kenniseigenaar | De testcases van de kaart opnieuw draaien | Normale beoordeling |
| B. Limieten of voorwaarden | Een termijn, een bedrag, wie in aanmerking komt | Beleidseigenaar plus support operations | Volledige testcases voor de kaart, medewerkers ingelicht, ingangsdatum ingesteld in de agent | Elk gesprek over de intent 7 dagen lang beoordelen |
| C. Nieuwe actie of bevoegdheid | De agent mag nu terugbetalen, opzeggen, tegoed geven of een account wijzigen | Beleidseigenaar, AI-eigenaar, risk of compliance | Tests plus een periode onder toezicht waarin een persoon de actie goedkeurt | Pas verruimen als de beoordeling laat zien dat het standhoudt |
| D. Noodgeval | Terugroepactie, storing, gerechtelijk bevel | Eigenaar met dienst | Snel pad: eerst beperken of overdragen, later verfijnen | Evaluatie achteraf binnen 48 uur |
Niveau C is waar beleid en autonomie samenkomen. Welke acties een agent alleen mag uitvoeren, behandelt onze gids over autonomieniveaus van AI-agents, en de harde grenzen die gelden los van de instructies onze gids over AI-agent guardrails.
Dit sluit aan op de algemene praktijk van AI-risicobeheer: het NIST AI Risk Management Framework vraagt om transparante beleidsregels en procedures, geplande periodieke review en duidelijk afgebakende rollen (in het Engels). Een beleidskaart met een eigenaar, een reviewdatum en een wijzigingslog past dat toe op één terugbetalingsregel.
De stap die de meeste teams overslaan, is de ingangsdatum. Een beleid dat op 1 december verandert, moet de agent op 1 december bereiken, niet op 20 november of 5 december, op hetzelfde moment dat het menselijke team overstapt.
Hoe worden mislukte gesprekken beleidsoplossingen?
Mislukte gesprekken worden beleidsoplossingen als elke fout naar oorzaak wordt ingedeeld, beleidsoorzaken naar de eigenaar van de kaart gaan en de oplossing wordt gecontroleerd door dezelfde intent daarna opnieuw te scoren. Zonder indeling lijkt elke misser een AI-probleem, en tunet het team prompts terwijl de echte oorzaak in een verouderd artikel zit. De cirkel:
- Scoor gesprekken van de AI-agent op criteria die de soorten fouten scheiden: juistheid ten opzichte van je content, trouw aan het beleid, scope en escalatie.
- Deel de oorzaak in van elke fout: verouderde beleidsversie, ontbrekende uitzondering, tegenstrijdige bronnen, instructie niet gevolgd, ontbrekende toegang tot een tool of data, of een productbug. Onze gids over fout van de medewerker of fout in het proces (in het Engels) maakt dezelfde splitsing voor medewerkers.
- Stuur elke oorzaak naar de eigenaar: beleidsoorzaken naar de eigenaar van de kaart, instructieoorzaken naar de AI-eigenaar, toegangsoorzaken naar engineering.
- Los eerst de kaart op, daarna de artikelen, de macro en de instructie die ernaar verwijzen.
- Voeg een testcase toe op basis van het gesprek dat het gat blootlegde, en koppel die aan de kaart.
- Scoor de intent opnieuw in de week erna en vergelijk het foutpercentage met de week ervoor.
Een AI-agent verbeteren is niet hetzelfde als een persoon coachen; zie mensen coachen versus AI-agents verbeteren.
Een uitgewerkt voorbeeld (illustratie, geen klantdata)
Een AI-agent handelt 20.000 gesprekken per maand af, waarvan 3.000 over terugbetalingen en retouren. Als je ze allemaal scoort, blijkt voor die intent 3% te zakken op trouw aan het beleid: 90 gesprekken. De QA-lead deelt ze in:
| Oorzaak | Gesprekken | Aandeel | Eigenaar |
|---|---|---|---|
| Verouderde versie (oude termijn van 30 dagen in een afgevoerde FAQ die nog in de bronnen van de agent stond) | 38 | 42% | Kenniseigenaar |
| Ontbrekende uitzondering (bederfelijke waren terugbetaald zonder foto door medewerkers, nooit opgeschreven) | 27 | 30% | Beleidseigenaar |
| Tegenstrijdige artikelen (twee pagina’s, twee termijnen voor terugbetaling) | 14 | 16% | Kenniseigenaar |
| Instructie niet gevolgd (agent bood een tegoedbon aan, wat de kaart verbiedt) | 7 | 8% | AI-eigenaar |
| Tool of data (opzoeken van de bestelling mislukte, agent gokte) | 4 | 4% | Engineering |
| Totaal | 90 | 100% |
Twee contentoplossingen (de oude FAQ afvoeren, de uitzondering voor bederfelijke waren op de kaart zetten) pakken 65 van de 90 fouten aan, of 72%. Met de oplossing voor tegenstrijdige artikelen erbij wordt dat 79 van de 90, of 88%. Slechts 7 fouten, 8%, zijn een promptprobleem: een team dat begon met de prompt herschrijven, had het kleinste deel aangepakt. De scores van de week erna laten zien of de oplossingen standhouden.
Hoe ontdek je beleidsdrift voordat klanten het doen?
Je ontdekt beleidsdrift door op een vast ritme te controleren dat elk beleid één keer is vastgelegd, een eigenaar heeft, actueel is en door mensen en de AI-agent op dezelfde manier wordt toegepast. Drift wordt zichtbaar als een langzame stijging van escalaties met het label “onduidelijk”, of als mensen en de agent op dezelfde case tot verschillende uitkomsten komen.
Kopieer deze driftchecklist naar je maandelijkse beleidsreview:
| # | Controle | Signaal van drift | Ritme |
|---|---|---|---|
| 1 | Elk beleid dat de agent toepast heeft een kaart met een eigenaar en een reviewdatum in de toekomst | Kaarten voorbij hun reviewdatum | Maandelijks |
| 2 | De versie in de instructie van de agent komt overeen met de versie op de kaart | Instructie noemt een oudere versie | Bij elke wijziging |
| 3 | Geen twee helpartikelen noemen verschillende waarden voor dezelfde limiet | Een zoekopdracht naar het getal geeft twee waarden | Maandelijks |
| 4 | Afgevoerde artikelen zijn ook uit de bronnen van de agent gehaald | Afgevoerde pagina wordt nog geciteerd in AI-antwoorden | Bij elke wijziging |
| 5 | Instructies voor de agent verwijzen naar kaarten in plaats van beleidstekst te plakken | Een limiet staat in een prompt | Per kwartaal |
| 6 | Uitzonderingen die medewerkers toestaan, staan op de kaart | Coulance of overrides op een intent zonder vermelde uitzondering | Maandelijks |
| 7 | Escalaties met het label “beleid onduidelijk” zijn stabiel | Stijging van week tot week op één intent | Wekelijks |
| 8 | Fouten in trouw aan het beleid per kaart zijn stabiel | De fouten van één kaart stijgen na een wijziging | Wekelijks |
| 9 | Mensen en de AI-agent komen op hetzelfde type case tot dezelfde uitkomst | Verschillende uitkomsten op een vergelijkbare steekproef | Maandelijks |
| 10 | De testcases van elke kaart slaagden na de laatste wijziging | Wijziging live gezet zonder testronde | Bij elke wijziging |
| 11 | Toekomstige ingangsdata zijn ingepland in de agent | Een beleid is live voor mensen maar niet voor de agent, of andersom | Bij elke wijziging |
| 12 | Varianten per regio, abonnement en product zijn correct afgebakend | De agent antwoordt met de regel van een ander product of een andere regio | Per kwartaal |
Controles 7, 8 en 9 vragen gespreksdata, geen documentreview: een drift die 2% van één intent raakt, is onzichtbaar in een steekproef van 50 en overduidelijk in een volle week scores. Onze audit van het oplossingspercentage van AI-agents laat zien hoe je controleert of “opgeloste” gesprekken echt correct zijn opgelost.
Waar Kaizo past
Kaizo dekt de bewijskant van de cirkel: het scoren, de faalpatronen en het opnieuw scoren na een oplossing. AutoPilot scoort elk opgelost gesprek tegen je eigen scorecard.
Met kwaliteitscontrole van AI-agents voeg je de criteria toe waarop een bot zakt (feitelijke juistheid, trouw aan het beleid, scope en escalatie), in je eigen woorden, en koppel je je kennisbank zodat de AI beoordeelt tegen je eigen content. Elke score linkt naar het bewijs in het gesprek. Oorzaakanalyse groepeert de fouten achter een daling, zodat tien slechte antwoorden uit één artikel één oplossing worden. Scoor opnieuw na elke wijziging om te bevestigen dat de oplossing standhoudt.
Zie het op je eigen gesprekken. Boek een demo en neem één intent mee waarover je AI-agent en je team het oneens zijn.
Wanneer is een beleidscentrum meer dan je nodig hebt?
Een volledig beleidscentrum is nog niets voor jou als je AI-agent alleen vragen beantwoordt vanuit een klein helpcenter, geen acties uitvoert en een paar honderd gesprekken per maand afhandelt. Dan volstaan één eigenaar per artikel, een reviewdatum en elke maand de gesprekken van de agent lezen. De signalen dat je die lichte opzet bent ontgroeid:
- De agent voert acties uit (terugbetalingen, opzeggingen, accountwijzigingen) in plaats van alleen te antwoorden.
- Je beleid verschilt per regio, abonnement of product.
- Beleid verandert vaker dan één keer per kwartaal, of op een vaste ingangsdatum.
- Medewerkers staan uitzonderingen toe waar klanten de AI-agent daarna om vragen.
- Meer dan één AI-agent beantwoordt dezelfde klanten. Elk ervan moet naar dezelfde kaart verwijzen, als onderdeel van een veilige overstap naar agentische klantenservice.
Hoe je deze week begint
Begin met één intent, niet met het hele helpcenter. Eén week is genoeg om één beleidskaart te schrijven, de bronnen eromheen op te ruimen en te beginnen meten of de AI-agent die volgt.
- Kies één intent waar geld mee gemoeid is, meestal terugbetalingen of opzeggingen.
- Verzamel elke bron die de intent beantwoordt: artikelen, macro’s, wikipagina’s, vastgezette berichten in Slack, de instructies van de agent.
- Schrijf één beleidskaart met het template hierboven, en laat de zakelijke eigenaar de limieten en uitzonderingen ondertekenen.
- Voer af of herschrijf elke bron die de kaart tegenspreekt, en haal afgevoerde pagina’s uit de bronnen van de agent.
- Maak van drie eerder mislukte gesprekken testcases die aan de kaart gekoppeld zijn.
- Scoor die intent twee weken lang, deel elke fout in naar oorzaak, en loop de driftchecklist na voordat je aan de tweede kaart begint.
Veelgestelde vragen
Wat is een kennisbank in de klantenservice?
Een kennisbank is een bibliotheek met antwoorden waarin je klanten en medewerkers kunnen zoeken, zoals een helpcenter met artikelen als “Hoe retourneer ik een artikel?”. Ze wordt de kennisbank van een AI-agent zodra de agent die artikelen ophaalt om klanten te antwoorden, en daarom worden verouderde of tegenstrijdige artikelen verkeerde antwoorden op grote schaal. De regels erachter horen op beleidskaarten waarnaar de artikelen verwijzen.
Hoort beleid voor AI-agents in de prompt of in de kennisbank?
Geen van beide op zichzelf. Feiten horen in de kennisbank, regels op een beleidskaart met een eigenaar en een versie, en de instructie van de agent moet naar die kaart verwijzen in plaats van de tekst te plakken. Een limiet die naar een prompt is gekopieerd, veroudert als eerste.
Is een bedrijf aansprakelijk als zijn chatbot een beleid verkeerd weergeeft?
Dat kan. In Moffatt v. Air Canada (2024 BCCRT 149) stelde een tribunaal in British Columbia de luchtvaartmaatschappij aansprakelijk voor wat haar chatbot een klant vertelde, en verwierp het het argument dat de chatbot een aparte juridische entiteit was. Behandel elk antwoord van een AI-agent als je eigen beleidsverklaring, en vraag juridisch advies voor je markt.
Hoe vaak moet je beleid voor AI-agents reviewen?
Review elke kaart op een vaste datum die bij het risico past (maandelijks voor regels over geld en voorwaarden, per kwartaal voor de rest) en direct als de zakelijke regel verandert. Controleer elke week per kaart de fouten in trouw aan het beleid en de escalaties met “beleid onduidelijk”.
Wat is het verschil tussen een chatbot en een AI-agent die acties uitvoert?
Een chatbot beantwoordt vragen vanuit zijn content. Een AI-agent handelt ook: hij zoekt de bestelling op, past het beleid toe, doet de terugbetaling. Daarom heeft een agent beleid nodig met limieten, uitzonderingen en escalatieregels, niet alleen juiste artikelen.
