Eerste AI-agent: wat misgaat en hoe u dat voorkomt

Een ondernemer belt zijn leverancier. Zijn medewerker weet niet wat er is afgesproken, want die informatie zat in een reeks e-mails die niemand heeft samengevat. Precies dat soort situatie is de aanleiding om een agent te bouwen. Het idee is goed. Maar de uitvoering strandt drie weken na de livegang, en niemand begrijpt goed waarom.

Dat patroon heb ik vaak gezien. Niet omdat de technologie niet werkte, maar omdat een paar fundamentele keuzes vroeg in het traject verkeerd uitvielen. Dit artikel benoemt de meest voorkomende oorzaken, zodat u ze herkent voordat u begint.

Een te groot of te vaag proces is de meest voorkomende fout

De eerste neiging is om het complexe probleem aan te pakken. Het proces dat het meeste tijd kost, de meeste klachten oplevert, de meeste e-mails genereert. Begrijpelijk. Maar dat is bijna nooit het juiste startpunt.

Een goed eerste proces heeft een duidelijk begin en een duidelijk einde. Het is iets dat uw medewerker ook aan een nieuwe collega kan uitleggen in tien regels. Zodra de instructie begint met 'en dan hangt het een beetje af van de situatie', is het proces nog niet klaar voor een agent. Eerst het proces opschrijven, dan pas automatiseren.

In welk proces is geschikt voor een agent staat een kort filter om dit vooraf te toetsen. De drie vragen die u daarin stelt, schelen gemiddeld weken bouwtijd en vermijden teleurstellingen achteraf.

Impliciete regels zijn de onzichtbare blokkade

Een agent volgt regels. Die regels moet iemand hebben opgeschreven. En dat is precies waar het bij veel eerste trajecten vastloopt: de regels zitten niet in een document, maar in het hoofd van één medewerker. Die medewerker maakt elke dag tientallen kleine oordelen zonder dat iemand ze ooit heeft geëxpliciteerd.

Welke klanten krijgen altijd uitstel van betaling? Bij welk bedrag belt u altijd zelf in plaats van een herinneringsmail te sturen? Wanneer wijkt u af van de standaard levertijd? Als u deze vragen niet kunt beantwoorden zonder 'dat weet Marion', is de voorbereiding nog niet af.

Dit is geen kritiek op de organisatie. Het is gewoon hoe MKB-bedrijven werken. Kennis hoopt zich op bij mensen. Een agent dwingt u om die kennis expliciet te maken, en dat is op zichzelf al waardevol. Maar het kost tijd die mensen onderschatten. Reken op minstens evenveel tijd voor het opschrijven van de regels als voor het bouwen van de agent zelf.

“Een agent maakt uw impliciete beleid zichtbaar. Dat is waardevol, maar het kost ook tijd die u vooraf niet inrekent.”

Verwachtingen over autonomie lopen structureel te hoog op

Veel ondernemers starten met het beeld dat de agent straks zelfstandig e-mails verstuurt, facturen verwerkt en klanten informeert. Zonder dat een mens er nog naar kijkt. Dat beeld klopt niet, en het is ook niet wat u wilt.

Elke uitgaande actie van een agent, een antwoord aan een klant, een herinnering, een concept-offerte, gaat langs menselijke goedkeuring voordat hij de deur uit gaat. Niet omdat de technologie dat vereist, maar omdat u de verantwoordelijkheid heeft. Een agent die fout zit in een klantmail kost u een relatie. De medewerker die op verzenden drukt, merkt een fout nog op tijd.

Dit betekent niet dat de tijdwinst wegvalt. De agent doet het denkwerk, het opzoekwerk en het opstellen. De medewerker beoordeelt en verstuurt. Dat is een heel ander takenpakket dan alles zelf doen. Maar het is geen volledig autonome operatie, en trajecten die dat wel beloven vragen om nader onderzoek.

Slechte data levert een onbruikbare agent op

Een agent is zo goed als de informatie waartoe hij toegang heeft. Als uw CRM vol staat met verouderde contactgegevens, dubbele klantrecords en orderhistorie die nooit is bijgehouden, dan merkt u dat meteen bij de eerste echte taken. De agent trekt conclusies op basis van wat er staat, niet op basis van wat u bedoelt.

Dit hoeft geen blokkade te zijn. Perfecte data is geen voorwaarde om te beginnen. Maar u moet weten waar de gaten zitten, en daar eerlijk over zijn bij de inrichting. Bij debiteurenbeheer automatiseren is het betaalgedrag van klanten in het verleden bepalend voor de toon van een herinnering. Als dat gedrag niet goed is vastgelegd, kiest de agent de verkeerde toon.

De praktische aanpak: maak voor u begint een korte inventarisatie van de databron die de agent het meest nodig heeft. Is die bron actueel? Wie is verantwoordelijk voor het bijhouden ervan? Als er geen duidelijk antwoord is, lost u dat eerst op.

Niemand is eigenaar, en dan verwatert het

Een agent die live gaat, heeft iemand nodig die hem bijhoudt. Regels veranderen. Uitzonderingen duiken op die niemand had voorzien. Een klant die altijd snel betaalde, doet dat ineens niet meer. De agent houdt zich aan de oude regel, maar de situatie vraagt om een andere aanpak.

Als er niemand intern is aangewezen die verantwoordelijk is voor de agent, dan komen signalen als deze nergens terecht. Medewerkers gaan eromheen werken. Na een paar maanden gebruikt niemand de output nog, en ligt de agent stil zonder dat iemand precies kan zeggen waarom.

Het hoeft geen fulltime taak te zijn. Een half uur per week om te kijken of de output klopt en of de regels nog actueel zijn is vaak genoeg. Maar die taak moet ergens op iemands lijst staan, met naam en prioriteit. Wie intern welke rol heeft bij een implementatie is uitgewerkt in het artikel over interne rollen voor een AI-agent-implementatie.

Te laat testen met echte taken is een duur experiment

Een veelgemaakte keuze is om de agent pas in productie te zetten als hij 'af' is. Tot die tijd kijken alleen de bouwers naar de output. Het gevolg is dat de eerste keer dat een medewerker ermee werkt, ook de eerste keer is dat echte problemen zichtbaar worden. Dan is de teleurstelling groot en het vertrouwen laag.

Beter is om vroeg te testen met echte taken, maar in een gecontroleerde omgeving. Laat de medewerker die het proces kent de output beoordelen op basis van vijf of tien concrete cases uit het verleden. Klopt de redenering? Mist de agent informatie? Wijkt de uitkomst af van wat de medewerker zelf zou doen, en zo ja: waarom?

Die feedbackronde levert meer op dan weken extra bouwtijd. En het trekt de medewerker eerder in het proces, wat de adoptie later aanzienlijk makkelijker maakt. Hoe u een pilot zo inricht dat hij niet mislukt, staat uitgewerkt in AI-pilot zonder mislukken.

De eerste stap is kleiner dan u verwacht

Al het bovenstaande klinkt misschien als een lange lijst met dingen die fout kunnen gaan. Maar de meeste hiervan zijn te vermijden door één keuze: begin kleiner dan u van plan was. Kies een proces dat saai en voorspelbaar is. Schrijf de regels op voordat u een leverancier belt. Wijs één persoon aan die verantwoordelijk is.

Een eerste agent hoeft niet indrukwekkend te zijn. Hij hoeft te werken. En als hij werkt, bouwt u daar op door. Dat patroon, klein beginnen en stapsgewijs uitbreiden, is consistenter succesvol dan het grote ambitieuze traject dat halverwege vastloopt.

Zet maandag een halfuur opzij om het proces dat u voor ogen heeft te beschrijven in tien regels. Als u er niet in slaagt, is dat waardevolle informatie. Dan weet u waar u eerst aan moet werken, los van de technologie.