Wat u moet kunnen terugkijken als een agent een fout maakt

Een klant belt op donderdagmiddag. Hij heeft een herinnering ontvangen voor een factuur die hij twee weken geleden al heeft betaald. Uw medewerker kijkt in het systeem, ziet dat de betaling inderdaad staat geboekt, en vraagt zich af hoe de agent die herinnering dan toch heeft verstuurd. Niemand weet het antwoord. De logs zijn er niet, of ze zeggen niets bruikbaars.

Dit is het moment waarop logging ophoudt een technisch detail te zijn en een bedrijfskundig probleem wordt. Niet omdat de fout zo erg is, maar omdat u hem niet kunt verklaren. En wat u niet kunt verklaren, kunt u niet voorkomen.

Een log is geen debuggerbestand, maar een beslisverslag

Veel mensen denken bij logging aan rijen technische foutmeldingen die alleen een ontwikkelaar kan lezen. Dat is één kant. De andere kant is wat u als ondernemer nodig heeft: een leesbaar verslag van wat de agent heeft gezien, welke beslissing hij heeft genomen, en waarom. Dat zijn fundamenteel andere dingen.

Een technische log zegt: "Request 4421 failed with status 422." Een beslisverslag zegt: "De agent controleerde factuur 8842, zag status 'openstaand' in het boekhoudpakket op 09:14, en zette een herinneringsmail klaar voor goedkeuring." Het tweede is bruikbaar. Het eerste vertelt u niets over wat er in uw bedrijfsproces is misgegaan.

Bij debiteurenbeheer automatiseren is dit bijzonder relevant. Een agent die herinneringen klaarzet, werkt op basis van gegevens uit uw boekhouding. Als die gegevens verouderd zijn op het moment dat de agent ze raadpleegt, is de fout niet in de agent zelf te vinden, maar in de timing van de synchronisatie. Dat kunt u alleen zien als u weet wanneer de agent welke data heeft gezien.

Vier dingen die elke actielog moet bevatten

Wij hanteren bij elke agent die wij bouwen een vaste minimumset voor logging van acties. Niet elke actie leidt tot een probleem, maar als er één misgaat, wilt u alle vier de elementen direct kunnen opvragen.

• ·Tijdstip: wanneer precies heeft de agent de actie gestart, en wanneer is hij afgerond? Verschil van minuten kan al verklarend zijn.
• ·Invoer: welke gegevens heeft de agent gebruikt om tot zijn beslissing te komen? Welke versie van die gegevens, op welk moment opgehaald?
• ·Redenering: welke regel of beleidsinstelling heeft de agent toegepast? Niet alleen de uitkomst, maar de stap daarvoor.
• ·Uitkomst: wat heeft de agent klaargezet of uitgevoerd, en wie heeft dat goedgekeurd of aangepast?

Het vierde punt is niet bijzaak. Elke uitgaande actie van een agent hoort langs menselijke goedkeuring. Dat betekent ook dat de log moet vastleggen wie heeft goedgekeurd, wanneer, en of er aanpassingen zijn gemaakt voor verzending. Dat is geen bureaucratie. Dat is de informatie waarmee u achteraf kunt aantonen dat een mens de eindbeslissing heeft genomen.

Zonder tijdstempel is terugkijken gissen

Het tijdstip klinkt vanzelfsprekend, maar het is precies het onderdeel dat in simpele logging-setups ontbreekt of te grof is. "De agent heeft gisteren een herinnering klaargezet" is niet bruikbaar. U wilt weten: om 09:14 heeft de agent de factuurstatus opgehaald, en op dat moment stond er in Exact of Moneybird nog geen betaling geregistreerd, terwijl de klant om 08:52 heeft betaald.

Dat verschil van 22 minuten is de verklaring. Zonder tijdstempels op het niveau van minuten ziet u die niet. U ziet alleen dat er iets mis is gegaan, niet waardoor. En waardoor is precies de vraag die u moet kunnen beantwoorden als u het wil voorkomen.

Dit geldt ook voor processen zoals orderverwerking automatiseren, waarbij een agent voorraadstanden raadpleegt. Als een order twee minuten na een andere grote order binnenkomt en de agent heeft de voorraad net daarvoor gecheckt, kan hij een bevestiging klaarzetten die niet meer klopt. Zonder timestamp weet u niet eens dat er een volgordekwestie speelt.

Bewaar logs lang genoeg om patronen te zien

Een fout die één keer voorkomt, is een incident. Een fout die drie keer per maand voorkomt onder vergelijkbare omstandigheden, is een patroon. U kunt dat patroon alleen zien als uw logs oud genoeg zijn om terug te kunnen vergelijken.

Hoelang is lang genoeg? Dat hangt af van uw proces. Voor facturatie en debiteurenbeheer is het verstandig om minimaal twaalf maanden terug te kunnen kijken, zodat u seizoensgebonden afwijkingen kunt herkennen. Voor klantenservice-gerelateerde acties kan zes maanden al voldoende zijn om de meest voorkomende uitzonderingen in kaart te brengen.

Dit is ook relevant vanuit de AVG. Als een agent beslissingen neemt die een klant raken, heeft die klant in bepaalde gevallen het recht om uitleg te krijgen. "De agent heeft uw dossier geraadpleegd op datum X en op basis van de op dat moment bekende gegevens de volgende actie klaargezet" is een antwoord dat u alleen kunt geven als de log er nog is.

Logging is ook voor uw medewerkers, niet alleen voor audits

Een veelgemaakte fout is om logging te zien als iets voor de bouwer van de agent, of voor accountants en audits. In de praktijk zijn uw eigen medewerkers de eersten die er gebruik van maken. Zij krijgen de klant aan de lijn, zij merken dat iets niet klopt, en zij moeten binnen een minuut kunnen uitleggen wat er is gebeurd.

Dat betekent dat de logging-interface die uw medewerkers zien niet identiek hoeft te zijn aan de technische logs. Wat zij nodig hebben is een eenvoudig overzicht: welke acties heeft de agent vandaag uitgevoerd voor welke klanten, wat heeft de medewerker goedgekeurd, en is er iets afgeweken van het voorstel? Dat is een werkscherm, geen debugtool.

Wij bouwen dat scherm standaard mee. Niet als optionele feature, maar als onderdeel van de agent zelf. De reden is simpel: als uw medewerker niet kan terugkijken, heeft u geen menselijke controle. En zonder menselijke controle heeft u ook geen goedkeuring, want goedkeuring zonder context is geen goedkeuring.

Waar uw logdata staat en wie er bij kan

Bij agents die wij bouwen worden actieLogs opgeslagen en verwerkt op servers in Frankfurt. De taalmodelcalls lopen via Anthropic in de Verenigde Staten en zijn opgenomen in de sub-verwerkerslijst met een transfer impact assessment. Dat is iets anders dan zeggen dat alle data in de EU blijft. Het is eerlijker om te zeggen hoe het werkt en wat er is geregeld.

Wie toegang heeft tot uw logs, moet u zelf bepalen. Minimaal wilt u dat uw eigen beheerder of office manager eenvoudig kan inloggen en de actielog van de afgelopen dertig dagen kan raadplegen. Wij adviseren ook om in de verwerkersovereenkomst vast te leggen hoe lang logs worden bewaard en wie er op verzoek inzage in heeft. Dat voorkomt discussie op het moment dat u de logs juist hard nodig heeft.

Meer over wat er technisch achter de schermen geregeld moet zijn, leest u in het artikel over logging en monitoring van agents. Het bespreekt ook hoe u alerting instelt zodat u niet zelf hoeft te gaan zoeken als er iets afwijkt.

De eerste stap: beschrijf wat u wilt kunnen terugvinden

Voordat u nadenkt over technische logging-infrastructuur, is er een eenvoudigere stap. Schrijf voor uw eigen proces op: als er iets misgaat, welke drie vragen wil ik dan als eerste kunnen beantwoorden? "Wanneer heeft de agent dit gedaan?" is er meestal één van. "Op basis van welke informatie?" een andere.

Die drie vragen zijn uw logging-vereisten. De rest is implementatie. Als u die vereisten niet kunt formuleren, kunt u ook niet beoordelen of een logging-setup voldoet. En dat is precies de situatie die u wil vermijden op de donderdagmiddag dat een klant belt over een herinnering die hij nooit had mogen ontvangen.

Zet die vragen komende maandag op papier. Bespreek ze met degene die uw proces het beste kent. Dat is de voorbereiding waarmee u, als u een agent laat bouwen, direct kunt aangeven wat de logging moet opleveren. Dan is het geen bijzaak meer, maar onderdeel van de opdracht.