AI-agent bouwen: van één taak naar een veilig werkproces

Definieer precies één taak

Een goede agentspecificatie bevat een begin, een eindresultaat en duidelijke uitsluitingen.

Te breed:

Ondersteun ons verkoopteam.

Beter:

Lees nieuwe aanvragen uit één goedgekeurde bron, controleer of vijf verplichte gegevens aanwezig zijn, maak een samenvatting en zet een concepttaak klaar voor beoordeling door een medewerker.

De tweede omschrijving maakt duidelijk:

• wanneer de agent start;
• welke bron is toegestaan;
• welke controle plaatsvindt;
• welke uitvoer wordt verwacht;
• dat een mens de volgende stap goedkeurt.

Leg ook vast wat de agent niet doet. Bijvoorbeeld geen prijs toezeggen, geen klantgegevens wijzigen, geen e-mail verzenden en geen informatie uit andere dossiers gebruiken.

Kies een taak met voldoende volume om te testen, maar met beheersbare gevolgen wanneer iets fout gaat. Een agent die eerst voorstellen maakt, levert sneller betrouwbare leerdata op dan een agent die meteen onomkeerbare acties uitvoert.

Welke tools en data zijn toegestaan?

Iedere tool is een bevoegdheid. Een zoekfunctie, mailbox, CRM, agenda of betaalomgeving geeft de agent mogelijkheden die technisch en organisatorisch moeten worden begrensd.

Documenteer per tool:

• voor welk deel van de taak zij nodig is;
• welke gegevens gelezen mogen worden;
• welke gegevens gewijzigd mogen worden;
• onder welk technisch account de toegang loopt;
• welke limieten en foutmeldingen bestaan;
• welke handelingen worden gelogd;
• hoe toegang direct kan worden ingetrokken.

Geef minimale rechten. Wanneer een agent alleen beschikbaarheid hoeft te lezen, hoeft hij geen afspraken te kunnen verwijderen. Wanneer hij een concept schrijft, hoeft hij het niet zelfstandig te verzenden.

Beperk ook de zoekruimte. “Gebruik alle bedrijfsdocumenten” klinkt handig, maar maakt bronconflicten en ongewenste informatie waarschijnlijker. Wijs goedgekeurde bronnen toe en leg vast welke bron leidend is wanneer informatie verschilt.

Gevoelige data verdient een aparte beoordeling. Bepaal welke gegevens noodzakelijk zijn, welke gemaskeerd kunnen worden en welke nooit aan het agentproces mogen worden aangeboden.

Actielimieten en menselijke goedkeuring

Autonomie is geen aan-uitknop. Deel acties in risiconiveaus in.

Lezen en voorbereiden

De agent verzamelt informatie, classificeert, vat samen of maakt een concept. Dit is vaak geschikt voor een eerste pilot, zolang toegang en brongebruik goed zijn begrensd.

Omkeerbare interne acties

De agent maakt een concepttaak, label of interne notitie die een medewerker kan controleren en verwijderen. Gebruik limieten en duidelijke logging.

Externe of gevoelige acties

De agent verstuurt berichten, wijzigt klantgegevens, boekt iets, zet geldstromen in gang of neemt een beslissing met gevolgen. Hiervoor is meestal expliciete goedkeuring nodig, zeker tijdens de eerste versies.

Bepaal per actie:

• is menselijke goedkeuring verplicht;
• welke informatie ziet de beoordelaar;
• hoe lang blijft de goedkeuring geldig;
• wat gebeurt er wanneer de context daarna verandert;
• kan de actie worden teruggedraaid;
• welke hoeveelheids- of tijdslimiet geldt?

Een goedkeuringsscherm moet de reden en relevante bronnen tonen. Alleen “agent wil actie uitvoeren — akkoord?” is onvoldoende voor een inhoudelijke controle.

Gebruik harde limieten voor aantallen, bedragen, ontvangers of tijdvakken waar dat past. Grenzen in de interface en systeemlogica zijn sterker dan alleen een instructie in de prompt.

Testset, grondwaarheid en evaluatie

Test een agent niet alleen met voorbeelden die door het bouwteam zijn bedacht. Gebruik een representatieve set uit de echte workflow, inclusief uitzonderingen.

Voor ieder testgeval leg je een verwachte uitkomst vast:

• welke informatie relevant is;
• welke bron gebruikt moet worden;
• welke actie wel of niet is toegestaan;
• wanneer de agent moet stoppen;
• wat een medewerker als correct beschouwt.

Deze verwachte uitkomst is de grondwaarheid voor evaluatie. Niet ieder taalverschil is een fout. Beoordeel de onderdelen die zakelijk belangrijk zijn: juiste classificatie, volledig gebruik van verplichte gegevens, geen verboden actie en een correcte overdracht bij onzekerheid.

Neem ook negatieve tests op:

• ontbrekende of tegenstrijdige informatie;
• verouderde bronbestanden;
• dubbele aanvragen;
• ongeldige tooluitvoer;
• een gebruiker die om een verboden actie vraagt;
• instructies in documenten die de agent proberen af te leiden;
• verlopen toegang;
• gedeeltelijk uitgevoerde stappen.

Evalueer per versie met dezelfde kernset. Anders kan een nieuwe wijziging beter lijken omdat toevallig andere voorbeelden zijn gebruikt.

Fouten, herstel en operationeel toezicht

Een agent zal situaties tegenkomen die niet volledig zijn voorspeld. Ontwerp daarom foutgedrag vóór livegang.

De agent moet kunnen:

• stoppen zonder half afgewerkte externe actie;
• aangeven welke stap is mislukt;
• relevante invoer en toolresultaten vastleggen;
• een taak aan een mens overdragen;
• een veilige retry uitvoeren wanneer dat verantwoord is;
• dubbele uitvoering herkennen;
• na herstel verdergaan of gecontroleerd opnieuw starten.

Maak onderscheid tussen een fout in de tool, ongeldige data, onduidelijke instructie en een inhoudelijk onbekende situatie. Ze vragen verschillende herstelacties.

Operationeel toezicht betekent dat iemand kan zien:

• hoeveel taken zijn gestart en voltooid;
• waar agents stoppen;
• welke acties wachten op goedkeuring;
• welke bronnen of tools fouten geven;
• welke resultaten vaak door medewerkers worden aangepast;
• of gedrag na een wijziging verslechtert.

Wijs een eigenaar aan die bevoegd is om toegang te beperken, een workflow uit te schakelen en wijzigingen te beoordelen. Een agent zonder operationele eigenaar is geen beheerd proces.

Bouwen versus kopen en blijvend eigenaarschap

Een bestaande tool kan voldoende zijn wanneer de workflow standaard is, integraties beschikbaar zijn en de grenzen van het product passen. Maatwerk wordt relevanter wanneer de taak sterk samenhangt met eigen processen, rollen, gegevens of controles.

Vergelijk niet alleen functies. Beoordeel:

• welke data de leverancier verwerkt;
• welke modellen of externe diensten worden gebruikt;
• of prompts, logs en evaluaties beheersbaar zijn;
• hoe rechten en goedkeuring worden ingericht;
• hoe wijzigingen worden getest;
• hoe data en configuratie kunnen worden geëxporteerd;
• wat er gebeurt wanneer de leverancier of prijs verandert.

Ook bij maatwerk blijft eigenaarschap nodig. Wie onderhoudt bronnen? Wie controleert evaluaties? Wie reageert op fouten? Wie beslist dat een nieuwe actie veilig genoeg is?

Compacte agentspecificatie

Taak
Welke ene taak voert de agent uit?

Startsignaal
Welke gebeurtenis of menselijke opdracht start het proces?

Toegestane bronnen
Welke informatie mag worden gebruikt en welke bron is leidend?

Tools
Welke systemen mogen worden gelezen of gewijzigd?

Verboden acties
Wat mag nooit automatisch gebeuren?

Goedkeuring
Welke acties vragen menselijke toestemming en welke context wordt getoond?

Succes
Wat is een correcte afgeronde taak?

Stopvoorwaarden
Wanneer moet de agent weigeren, pauzeren of overdragen?

Herstel
Hoe worden fouten, retries en dubbele acties behandeld?

Eigenaar
Wie beheert bronnen, toegang, evaluatie en incidenten?

Bouw een agent als proces, niet als persoonlijkheid

Een betrouwbare AI-agent begint niet met een slimme naam of brede opdracht. Hij begint met één taak, minimale bevoegdheden, testbare uitkomsten en menselijk eigenaarschap. Breid pas uit wanneer iedere extra actie aantoonbaar beheerst kan worden.

Lees meer over maatwerksoftware, bekijk het experiment rond een persoonlijke AI-assistent en zie hoe we keuzes afbakenen in onze werkwijze.