Als een AI-agent een fout maakt: wie is er verantwoordelijk?

Voor wie? Cross-functionele teams met een PO, tech lead en manager die samen een AI-agent in productie brengen — of al hebben gebracht — en willen weten hoe ze verantwoordelijkheid helder verdelen voordat het misgaat.

Kort: Een agent faalt niet zoals een klassieke bug. Hij handelt, beslist, en pas achteraf zie je wat er mis was. De vraag “wie is verantwoordelijk?” heeft geen standaardantwoord — maar ze heeft wel een structuur. Dat is wat we in de teamworkshop concreet maken: van taakomschrijving tot audit trail.

Stel: een agent beheert klantcommunicatie. Op een dag stuurt hij een annuleringsbevestiging naar een klant die helemaal niet had geannuleerd. De klant belt kwaad. Iedereen kijkt naar iedereen.

De developer zegt: “De agent deed wat hij moest doen op basis van de data die hij zag.”

De PO zegt: “Ik had hem niet gevraagd om zelfstandig e-mails te sturen.”

De manager zegt: “Ik had begrepen dat dit getest was.”

Niemand liegt. En toch is het fout gegaan.

Dit is het fundamentele probleem met agents: klassieke software faalt voorspelbaar. Een bug geeft een foutmelding. Een crash heeft een stack trace. Je kunt aanwijzen waar het fout ging.

Een agent faalt anders. Hij nam een beslissing op basis van informatie die hij had. Hij voerde een actie uit die technisch correct was. En pas later — soms veel later — zie je dat de uitkomst niet klopte. Er is geen rode foutmelding, geen crashrapport. Er is alleen een klant die kwaad belt.

De vraag is dus niet alleen “wat ging er mis?” maar ook “wie had dit moeten voorkomen, en hoe?”

Drie lagen van verantwoordelijkheid

Verantwoordelijkheid voor een agent is niet één ding. Ze zit op drie lagen, en elke laag heeft een andere eigenaar.

Technisch — de developer. De developer die de agent bouwde, is verantwoordelijk voor de correcte werking van het systeem. Dat betekent: stopcriteria bouwen zodat de agent niet eindeloos doorgaat, fallbacks voor als een externe dienst uitvalt, en logging zodat elke beslissing traceerbaar is. Een agent zonder audit trail is een agent waarvoor niemand achteraf verantwoording kan afleggen — ook de developer niet.

Functioneel — de PO of business owner. De PO is verantwoordelijk voor de taakomschrijving. In het voorbeeld hierboven: als de agent letterlijk deed wat hij moest doen maar de verkeerde intent uitvoerde, zit het probleem bij de opdrachtgever. Een taakomschrijving die te breed is — “beheer klantcommunicatie” zonder grenzen aan wat hij zelfstandig mag versturen — is een functioneel risico, geen technisch probleem.

Organisatorisch — het bedrijf. De organisatie nam het besluit om een agent in te zetten voor deze specifieke taak. Dat besluit omvat een risicoafweging: wat zijn de mogelijke gevolgen als het fout gaat, en hebben we die geaccepteerd? Als er geen goedkeuringsregel was voor uitgaande communicatie, is dat een organisatorisch gat, geen individuele fout.

Deze drie lagen bestaan altijd. Het probleem is dat teams ze zelden expliciet maken vóór een agent live gaat.

Wat jullie vastleggen vóór go-live

De vier vragen die je moeten kunnen beantwoorden voordat een agent in productie gaat:

Audit trail. Elke beslissing van de agent is gelogd. Wat zag hij? Wat besliste hij? Welke actie voerde hij uit? Zonder dit kun je na een incident niets reconstrueren — en kun je ook niet verbeteren.

Human-in-the-loop punten. Voor welke beslissingen is menselijke goedkeuring vereist? Een bruikbare richtlijn: alles met externe effecten. Uitgaande communicatie, financiële transacties, toegangswijzigingen — dat zijn beslissingen waarbij een fout onmiddellijk zichtbaar is voor iemand buiten jullie systeem. Die laat je niet aan de agent alleen.

Escalatieprotocol. Wat doet de agent als hij er niet uitkomt? Het antwoord is altijd: hij blokkeert en informeert een mens. Nooit: hij escaleert zelfstandig naar een hogere actie. Een agent die bij twijfel harder handelt in plaats van stopt, is een agent die jullie vroeg of laat voor een verrassing plaatst.

Rollback-mogelijkheid. Kunnen jullie de gevolgen van een fout terugdraaien? Als het antwoord nee is — als de actie van de agent onomkeerbaar is — dan is de vraag of een agent hier überhaupt de juiste oplossing is. Niet elke taak is geschikt voor automatisering.

De rolverdelingsvraag

In teams met een agent in productie ontbreken vaak antwoorden op drie simpele vragen:

• Wie monitort de agent dagelijks?
• Wie beslist of een edge case door de agent of door een mens wordt afgehandeld?
• Wie is aanspreekpunt als de agent een fout maakt?

Deze vragen hoeven niet juridisch perfect te zijn. Ze moeten gewoon beantwoord zijn — en iedereen in het team moet weten wie wat bezit.

Als de enige eerlijke versie van het antwoord “dat weten we nog niet” is, dan is dat het signaal. Niet dat jullie te langzaam zijn. Maar dat er iets mist dat je vóór productie had moeten regelen.

EU AI Act: de tijdlijn die al geldt

Voor teams die met gevoeliger toepassingen werken is er een praktische reden om dit snel te formaliseren. De EU AI Act is van kracht, en de transparantieplicht voor hoog-risico AI-systemen gaat in op 2 augustus 2026.

Hoog-risico toepassingen — HR-beslissingen, toegang tot essentiële diensten, biometrische identificatie — vallen onder wettelijke eisen voor menselijk toezicht en traceerbaarheid. Maar ook voor de meeste interne automatisering met externe effecten geldt: logging en human-in-the-loop zijn best practice, geen optie.

De praktische implicatie is simpel: bouw dit vóór uitrol, niet erna. Een audit trail toevoegen aan een agent die al drie maanden draait, is technisch mogelijk maar politiek moeilijk — want je geeft daarmee toe dat je het daarvoor niet had.

Wat je niet doet

Drie patronen die teams regelmatig kiezen en die later problemen geven:

“We evalueren het als het fout gaat.” Dat is te laat. De fout is op dat moment al zichtbaar voor een klant, een collega of een systeem buiten jullie controle.

Verantwoordelijkheid diffuus houden zodat niemand het écht bezit. Dat lijkt comfortabel tot het moment dat er iemand gebeld moet worden. Dan is de vraag wie er opneemt opeens urgent.

Dezelfde human-in-the-loop drempel hanteren voor elke agent. Een agent die interne samenvattingen maakt heeft een andere risicoprofiel dan een agent die externe systemen beheert. Behandel ze niet hetzelfde.

Wil je met jullie team de accountability-structuur uitwerken voor een concrete agent — van taakomschrijving tot escalatieprotocol? Dat is een van de centrale oefeningen in de workshop voor teams.