Wanneer mag een AI-agent iets wijzigen of versturen?

Waarom is een actie anders dan een antwoord?

Een verkeerd antwoord kun je corrigeren voordat iemand het gebruikt. Een verstuurde e-mail, aangepaste CRM-status of geannuleerde afspraak heeft direct effect op anderen. Daarom mag een agent die informatie verzamelt niet automatisch dezelfde rechten krijgen als een medewerker die wijzigingen uitvoert. Teken de drie stappen afzonderlijk: lezen, concept of voorstel maken, en uitvoeren. Wijs voor iedere stap een eigenaar en een acceptatiecriterium aan.

OWASP beschrijft het risico van te veel handelingsruimte bij taalmodeltoepassingen. Een prompt met ‘vraag altijd toestemming’ is geen vervanging voor beperkte API-rechten. De applicatie moet technisch verhinderen dat een model via een andere tool toch verstuurt of wijzigt. Begin daarom met alleen-lezen toegang en open pas een nieuwe handeling wanneer je de noodzaak en het foutpad kunt uitleggen.

Wat moet een mens precies goedkeuren?

Laat de agent eerst een concept maken. De medewerker ziet de bedoelde actie, ontvanger of record, de exacte inhoud, het gebruikte bronmateriaal en de mogelijke gevolgen. Een algemene knop ‘agent toestaan’ is te grof. De bevestiging hoort bij deze ene handeling en vervalt wanneer het concept of de context verandert. OpenAI beschrijft menselijke review als een expliciete pauze in de uitvoering; Google ADK documenteert een vergelijkbaar controlemoment.

Neem een fictief serviceproces. De agent leest de status van een ticket en stelt een antwoord voor. De medewerker controleert de klantidentiteit, de geciteerde procedure en de ontvanger, en klikt pas dan op verzenden. Als de wachttijd te lang is, blijft het concept staan of vervalt het; de agent mag niet zelf besluiten dat stilzwijgen toestemming betekent. Gebruik voor geldstromen, contractwijzigingen en personeelsbesluiten aanvullende interne controles.

Welke controles horen achter de knop?

Voer vóór de actie opnieuw autorisatie uit bij de achterliggende dienst. Controleer het record, de gebruikersrol, de gevraagde wijziging, de ontvanger en de geldigheid van het akkoord. Leg vast welk concept is goedgekeurd met een herkenbaar uitvoeringsnummer. Maak de actie zo mogelijk idempotent: een netwerkherhaling mag dezelfde e-mail niet tweemaal sturen. Als dat technisch niet kan, moet de applicatie na een onzekere fout de daadwerkelijke status ophalen voordat zij opnieuw probeert.

Beperk de uitvoertool tot de benodigde velden en handelingen. `werk_ticketstatus_bij` is duidelijker dan een generieke beheer-API. Houd het leestoken gescheiden van het schrijftoken. Laat het model nooit zelfstandig het token of de API-scope kiezen. Log wie goedkeurde, welke handeling gebeurde en het resultaat, maar bewaar geen onnodige volledige klantinhoud in een extra logbestand.

Hoe test en herstel je ongewenste acties?

Test met fictieve records: correcte goedkeuring, afgewezen goedkeuring, verlopen toestemming, gewijzigd concept, onbereikbare API en een dubbel verzoek. Controleer telkens zowel de gebruikersmelding als de feitelijke status van het doelsysteem. Een scherm dat ‘niet verzonden’ meldt terwijl de mail al weg is, is een ernstiger fout dan een duidelijk mislukte actie. Leg stopregels en een meldroute vast voor onzekere gevallen.

Bepaal vooraf wat herstel betekent. Een CRM-veld kan wellicht worden teruggezet; een externe e-mail doorgaans niet. In dat geval is voorkomen belangrijker dan terugdraaien. Laat een medewerker het incident onderzoeken, beperk zo nodig de agentrechten en voer de testset opnieuw uit voordat de actie terugkomt. De gids over koppelingen helpt de volledige gegevensroute te tekenen.

Maak van de goedkeuringsstap een concreet acceptatiecriterium in de pilot: een tweede medewerker moet uit het log kunnen reconstrueren wie welk concept zag, welke inhoud uiteindelijk is verzonden en waarom een actie is geweigerd. Lukt die reconstructie niet, dan is het proces nog niet klaar voor zelfstandig gebruik.