SC-Logo2019_cmyk_2
Contact

Hoe weet u of uw AI-agent het goed doet? — observability en evals voor MKB-agents

Hoe weet u of uw AI-agent klanten geen onzin vertelt? Nuchtere uitleg van AI-agent observability en evals voor MKB — wat u meet en wie kijkt.
Acht papieren gesprekskaarten op een bureau; drie kaarten hebben een oranje afwijking, een paarse loep rust erop.

Vrijdagmiddag, de service-coördinator van een Nederlands installatiebedrijf scrolt voor het eerst in drie maanden door de gesprekken die de chat-agent op de website heeft gevoerd. Twintig willekeurige gesprekken. In drie daarvan heeft de agent met overtuiging het verkeerde antwoord gegeven. Een keer een verkeerde garantietermijn. Een keer een afspraak op een dag waarop de monteurs vrij zijn. Een keer een onderdeel aanbevolen dat al twee jaar uit het assortiment is.

Niemand had iets gemerkt. Geen klacht binnengekomen, geen alarm afgegaan. De agent draaide gewoon door, met klant na klant — drie maanden lang.

Dit is geen randgeval. Voor de meeste agents die het MKB in het voorjaar van 2026 in productie heeft staan, is er geen systematische manier om te weten of de antwoorden eigenlijk wel kloppen. Dat is wat observability en evals horen op te lossen — en het is de volgende stap die u, na een werkende agent met geheugen, niet kunt overslaan.

Wat “observability” voor een agent eigenlijk is

Observability is geen vinkje op de release-checklist. Het is een ontwerpkeuze, en voor de meeste MKB-toepassingen zijn er drie lagen die u uit elkaar moet houden:

  1. Traces. Het volledige spoor van één gesprek of taak: welke vraag, welke documenten zijn opgehaald, welk model heeft wat geantwoord, welke gereedschappen zijn aangeroepen, hoe lang het duurde, wat het kostte. Zonder traces ziet u alleen het eindresultaat — en kunt u nooit terugredeneren waar het misging.
  2. Evals. Een vaste set vragen of scenario’s waarmee u de agent periodiek doormeet, met een afgesproken oordeel: hier is een goed antwoord, hier is een fout antwoord, hier zit het ertussenin. Evals zijn de eenheidstests van een AI-toepassing — en net als bij gewone software draait u ze niet één keer, maar bij elke verandering.
  3. Productie-signalen. Wat de echte klanten in echte gesprekken doen: hoeveel keer breekt iemand af, hoe vaak vraagt iemand naar een mens, welke onderwerpen komen terug, welke gesprekken eindigen in een klacht. Productie-signalen vertellen u of het in het wild nog steeds werkt, niet alleen in uw testset.

Een goed ingerichte MKB-agent heeft alle drie. Voor elk laag maakt u expliciete keuzes: wat verzamelt u, hoe lang, wie kan erin kijken, en wie krijgt er een melding wanneer het scheef loopt.

Eén beige gesprekskaart met verticale balken; één balk oranje gemarkeerd, paarse vinkstreep in de marge.
De drie lagen — traces, evals en productie-signalen — moeten samen werken om stille fouten in een agent zichtbaar te maken.

Waarom dit nu trending is

Drie ontwikkelingen vallen samen.

  • Platforms voor agent-observability zijn volwassen. LangSmith (van de makers van LangChain), Braintrust, en het open-source Arize Phoenix bieden inmiddels een werkbare combinatie van traces, evals en dashboards. Voor wie liever op een open standaard bouwt: de OpenTelemetry-werkgroep voor GenAI heeft semantische conventies vastgelegd voor LLM- en agent-spans — uw bestaande monitoring-stack kan dus in principe meekijken.
  • Eval-routines worden onderdeel van de bouwketen. Anthropic en OpenAI documenteren expliciet hoe u evals draait — als testsets vooraf, als “LLM-as-judge”-oordelen, en als regressiechecks bij elke modelversie-bump. Open-source pakketten als Ragas, DeepEval en Promptfoo doen hetzelfde voor wie niet aan één leverancier vast wil zitten.
  • Het modellandschap blijft schuiven. Tussen 2024 en 2026 zijn de grote modellen meermalen versie-omhoog gegaan: Claude Sonnet 4 of nieuwer, GPT-4o-opvolgers, Gemini 2.5 of nieuwer. Elke versiewissel kan stilzwijgend het gedrag van uw agent veranderen — soms beter, soms slechter, vrijwel nooit identiek. Zonder evals merkt u dat pas in de klantcontacten.

Tegelijk komt de AVG/GDPR-kant scherper in beeld. Wat u in traces vastlegt is in veel gevallen persoonsgegeven — bewaartermijnen, inzage-rechten en register-plicht horen daar gewoon bij.

Wat het niet is

Een paar veelvoorkomende misverstanden:

  • Het is geen dashboard zonder beleid. Een mooie grafiek over “antwoorden per uur” zegt niets over de juistheid. Zonder eval-set en zonder iemand die de traces daadwerkelijk leest, is een dashboard alleen geruststelling.
  • Het is geen 100%-garantie. Geen enkele meting maakt een taalmodel feilloos. Wat u koopt is zichtbaarheid en bijstuurbaarheid — fouten worden detecteerbaar en regressies traceerbaar, niet uitgesloten.
  • Het is geen vervanging van menselijke review. Bij gevoelige onderwerpen — facturatie, juridisch advies, medische informatie — blijft een mens in de loop. Observability zegt u welke gesprekken voorrang krijgen bij die review.
  • Het is geen vrije licentie om alles te bewaren. Volledige conversatie-transcripten zijn persoonsgegevens. Bewaartermijn, doelbinding en wisbaarheid horen vooraf vast te liggen, niet pas na een AP-vraag.
  • Het is geen pure techniek-discussie. Wat noemen we een fout antwoord? Welke afwijkingen escaleren we, welke laten we toe? Die keuzes horen bij de operationele eigenaar van het proces, niet alleen bij de bouwer.

Drie signalen dat u dit nu moet regelen

In gesprekken met MKB-directies komen drie signalen telkens terug:

  1. Niemand kan zeggen hoe vaak de agent fout zit. Geen steekproef, geen kwaliteitscijfer, geen vergelijking met vorige maand. Het werkt “in principe goed” — een formulering waarmee geen accountant of toezichthouder uit de voeten kan.
  2. Een modelversie-update is een gok. De leverancier zet een nieuwe versie open, u zet hem aan, en in de week erna voelt het “anders” — beter of slechter weet niemand precies. Zonder eval-set is dat de stand van zaken.
  3. Klachten komen indirect binnen. Niet via een fout-knop in de chat, maar via een ervaren medewerker die toevallig iets opvangt, of via een klant die uiteindelijk belt. Tegen die tijd is het probleem oud — en mogelijk vaker voorgekomen dan iemand weet.

Komt één van de drie u bekend voor, dan zit u op het punt waarop dit een echte ontwerpvraag wordt.

Wat dit voor het MKB praktisch betekent

Goed nieuws: u hoeft geen MLOps-team te zijn om dit goed in te richten. Een werkbaar startpunt voor een MKB-agent met observability ziet er meestal zo uit:

  • Een trace-laag die elke vraag, elk opgehaald document, elk model-antwoord en elke gereedschap-aanroep vastlegt — met een bewust ingestelde bewaartermijn.
  • Een eval-set van twintig tot vijftig representatieve scenario’s, opgebouwd uit echte (geanonimiseerde) klantvragen, met door uw mensen vastgesteld goed/fout-oordeel.
  • Een regressie-check die u draait bij elke modelversie-bump, prompt-aanpassing of kennisbank-update — voordat de wijziging live gaat.
  • Een productie-monitor met een handvol signalen: afbreek-percentage, escalatie naar mens, repeat-onderwerp per klant, kosten per gesprek.
  • Een eigenaar en escalatieroute: wie kijkt wekelijks naar de traces, wie krijgt een melding bij regressie, wie beslist of de agent gepauzeerd wordt.

Wij hebben de essentiële vragen samengevat in een korte checklist: “Hoe weet u of uw AI-agent het goed doet?”. Eén A4’tje, geen verkooppraatje. Wilt u er na het invullen over doorpraten, dan plannen we een uur. Geen verkopers-script — een gesprek tussen ondernemer en ontwikkelaar.

Voor wie is dit niet?

Eerlijk afgebakend: dit artikel is niet voor u als u nog geen agent in productie heeft of slechts één geïsoleerde tool-use case binnen één gesprek draait. Begin dan met de basis. Het is ook niet voor u als uw agent uitsluitend interne medewerkers bedient onder strikt toezicht — daar volstaat in de regel een eenvoudiger logboek. Maar als uw agent klantcontact heeft, beslissingen ondersteunt over geld, afspraken of producten, of als u meer dan één modelversie of leverancier hebt overwogen: dan is dit precies het gesprek dat u nu wilt voorbereiden.

Download de checklist — gratis, één A4

Wij hebben de zes gebieden uit dit artikel samengebald in een checklist die u in een half uur doorloopt. Geen e-mailmuur, geen formulierenrace.

Download de checklist   Of plan een uur met Sam Spies →

Verder lezen

Bronnen

Elke harde claim in dit artikel is verifieerbaar via de bronnen hieronder. URL’s stonden op moment van schrijven (15 mei 2026) live; bij een doorverwijzing geldt de archiefversie als fallback.

Platforms voor agent-observability

Evals — leveranciers-documentatie

Evals — open-source pakketten

Modelversie-context

AVG/GDPR-context

Algemene context

Recente berichten