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 blijkt wat er mis was. De vraag “wie is verantwoordelijk?” heeft geen standaardantwoord, maar wel een structuur. Dat maken jullie concreet in de teamworkshop: 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. Later — soms veel later — blijkt 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. Dit 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 (zoals “beheer klantcommunicatie” zonder grenzen) 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. Dit 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 jullie 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 kunnen jullie na een incident niets reconstrueren — en kunnen jullie 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 — dit zijn beslissingen met zichtbare gevolgen. Die laten jullie niet aan de agent alleen.

Escalatieprotocol. Wat doet de agent als hij er niet uitkomt? Het uitgangspunt is simpel: hij blokkeert en informeert een mens (met deterministische fallbacks voor lage-risicotaken waar dat verantwoord is). Niet: hij escaleert zelfstandig naar risicovoller acties. Een agent die bij twijfel harder handelt in plaats van stopt, zal jullie vroeg of laat voor een verrassing plaatsen.

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 jullie vóór productie hadden moeten regelen.

EU AI Act: wat al geldt, en wat nog komt

Voor teams die met gevoeliger toepassingen werken is er een praktische reden om dit snel te formaliseren. Sinds 2 augustus 2026 geldt de transparantieplicht voor AI-gegenereerde content (artikel 50); de volledige nalevingsvereisten voor hoog-risico AI-systemen volgen later — uitgesteld tot 2 december 2027 onder de Digital Omnibus.

Hoog-risico toepassingen — HR-beslissingen, toegang tot essentiële diensten, biometrische identificatie — vallen straks onder wettelijke eisen voor menselijk toezicht en traceerbaarheid. Maar ook nu al, 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 daarmee geven jullie toe dat jullie het daarvoor niet hadden.

Wat jullie niet doen

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

“We evalueren het als het fout gaat.” Dit 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. Dit lijkt comfortabel tot het moment dat er iemand gebeld moet worden. Dan wordt 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 ander risicoprofiel dan een agent die externe systemen beheert. Behandel ze niet hetzelfde.

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