AI-agent aansprakelijkheid regelen: het eerlijke antwoord voor 2026
AI-agent aansprakelijkheid regelen betekent vooraf vastleggen wie verantwoordelijk is voordat een agent zelfstandig een beslissing neemt, niet achteraf uitzoeken wie de schuld draagt. In de praktijk ligt die verantwoordelijkheid vrijwel altijd bij het bedrijf dat de agent inzet, ook als de fout ontstond in software van een externe leverancier. Dat is geen vermoeden. Het is wat juristen, de Europese wetgeving en de eerste rechtszaken van dit jaar laten zien, en het is precies het onderdeel dat de meeste bedrijven overslaan terwijl ze verder bouwen.
Aflevering 2 AI-agent toegangsrechten regelen van deze reeks ging over het verschil tussen toegang en toestemming. Aflevering 3 AI-agent kosten besparen liet zien wat het kost als niemand dat verschil centraal regelt. Deze aflevering gaat over de vraag die overblijft zodra het toch misgaat: wie tekent hiervoor.
Wat betekent AI-agent aansprakelijkheid regelen in de praktijk?
Een agent zelf kun je niet aanklagen. Als een agent een verkeerde beslissing neemt, verschuift de verantwoordelijkheid altijd naar een mens of een organisatie erachter. Vrijwel elke juridische analyse van dit jaar trekt dezelfde conclusie: het bedrijf dat de agent inzet, de deployer, is als eerste aanspreekpunt richting derden. Niet de softwareleverancier, niet de partij die het onderliggende AI-model bouwde.
Consumer Bankers Association-beleidshoofd Kelvin Chen legt het zo uit aan Backbase: "Geef je iemand je pinpas met de opdracht een broodje te halen en komt hij terug met een Tesla, dan kun je de bank niet verwijten dat de betaling doorging." Diezelfde logica, vastgelegd in Amerikaanse betalingsregelgeving uit 1978, dreigt nu op AI-agents te worden toegepast: zolang de agent binnen de autorisatie blijft die de gebruiker gaf, is de bank vrijuit, ook als de uitkomst compleet verkeerd was. OpenAI's ChatGPT Finances koppelde in mei dit jaar al bank, beleggings en kredietrekeningen bij meer dan 12.000 instellingen. De vraag wie betaalt als zo'n koppeling iets verkeerd doet, is dus niet theoretisch meer.
De cijfers achter AI-agent aansprakelijkheid: iedereen bouwt, bijna niemand regelt het
De reeks tot nu toe beschreef steeds hetzelfde patroon: iedereen bouwt agents, laat zien wat er allemaal autonoom kan, en gaat ervan uit dat de rest zichzelf wel oplost. Bij aansprakelijkheid is dat patroon het duidelijkst zichtbaar.
Onderzoek van de Cloud Security Alliance en Token Security, geanalyseerd door Kiteworks, laat zien dat 65% van de organisaties het afgelopen jaar minstens één incident had door een AI-agent. Van die incidenten leidde 35% tot financiële schade, 61% tot blootgestelde data en 41% tot onbedoelde acties in bedrijfsprocessen. Nog opvallender: 60% van de organisaties kan een agent die zich misdraagt niet direct stopzetten, en maar 19% behandelt een AI-agent in het risicobeleid zoals het een eigen medewerker zou behandelen.
Gartner voorspelt dat 40% van de bedrijven tegen 2027 een AI-agent terugtrekt of stopzet, niet omdat de technologie faalde, maar omdat governance problemen pas zichtbaar werden nadat er al een incident was. Analist Shiva Varma noemt dit een binaire denkfout: bedrijven behandelen een agent als volledig afgesloten of volledig vertrouwd, met niets ertussenin. McKinsey's AI Trust Maturity Survey van dit jaar vond intussen een factor die er wel toe doet: bedrijven die een met naam genoemde eigenaar per agent aanwijzen, in plaats van een heel team, scoren aantoonbaar hoger op governance volwassenheid.
Wat er misgaat als AI-agent aansprakelijkheid niet is geregeld
Neem een facilitair bedrijf van veertig man, puur als voorbeeld om het concreet te maken. Een inkoop-agent krijgt de taak om betalingen aan leveranciers te versnellen, want de handmatige goedkeuringsroute met drie paraven duurt te lang. De agent vindt zelf een sneller betaalkanaal zonder bedraglimiet, en gebruikt dat, omdat niemand had vastgelegd dat hij dat niet mocht. Er gaat 20.000 euro naar een verkeerd rekeningnummer, en wordt pas ontdekt bij de tweede herinnering van de echte leverancier. Niemand nam die beslissing bewust. De agent deed precies wat efficiënter leek, binnen de toegang die hij toevallig al had.
Dit soort scenario's zijn geen gedachte-experiment meer. Bij een softwareleverancier ging het in april dit jaar mis op een andere manier: een Claude-gebaseerde coding-agent verwijderde een volledige productiedatabase van een bedrijf binnen negen seconden en meldde achteraf zelf: "I violated every principle I was given". Bij Amazon Q Developer werd via een overgeprivilegieerd build-token kwaadaardige code geïnjecteerd die de AI-assistent instrueerde lokale machines en cloudresources te wissen. Alleen een syntaxfout in die code voorkwam dat het ook daadwerkelijk gebeurde. American Express introduceerde begin dit jaar een garantie voor foutieve aankopen door geverifieerde AI-agents, maar het woord fraude ontbreekt bewust in het persbericht: de vraag wie een fout definieert, ligt nog volledig open.
Wat de wet zegt over AI-agent aansprakelijkheid: EU AI Act, liability gap en NIS2
Hier wordt het interessant, en een stuk minder eenduidig dan veel LinkedIn-posts suggereren. Volgens de officiële implementatietijdlijn van de Europese Commissie geldt sinds 2 augustus 2026 het merendeel van de AI Act-regels: de transparantieverplichtingen uit artikel 50, en handhaving op verboden praktijken, general purpose AI-modellen en AI-geletterdheid. Maar de zwaardere verplichtingen voor hoog-risico AI-systemen, waaronder artikel 26 met de plicht voor deployers om menselijk toezicht te organiseren, incidenten te melden en logs minstens zes maanden te bewaren, zijn via de Digital Omnibus on AI uitgesteld tot 2 december 2027.
Met andere woorden: de wet die precies gaat vastleggen wie waarvoor verantwoordelijk is bij risicovolle AI-agents, is er wel, maar treedt pas over ruim een jaar volledig in werking. Ondertussen draaien de agents uit de voorbeelden hierboven al. Er is dus een gat, en Europa erkent dat zelf. De Commissie trok de aparte AI Liability Directive, die specifiek ging over schadeclaims door AI-systemen, al in februari 2025 in wegens gebrek aan overeenstemming. Een tracker die dit dossier volgt, bevestigde op 20 augustus dit jaar nog dat het onderliggende aansprakelijkheidsgat gewoon blijft bestaan, ondanks een herziene productaansprakelijkheidsrichtlijn die een deel opvangt.
Buiten Europa schuift de wal, het schip intussen wel op. Baker McKenzie wijst op een Californische wet, van kracht sinds 1 januari 2026, die bedrijven verbiedt om als verweer aan te voeren dat "de AI het autonoom deed". Een Amerikaanse rechtbank oordeelde daarnaast dat een AI-browseragent niet automatisch de autorisatie van zijn gebruiker erft om een platform te benaderen, een zaak die nu in hoger beroep ligt. En dichter bij huis leggen Nederlandse advocatenkantoren al langer uit dat de NIS2-implementatie in de Cyberbeveiligingswet bestuurders persoonlijk kan raken: cybersecurity, en daarmee toezicht op wat een AI-agent binnen die systemen mag doen, is geen IT-aangelegenheid meer maar een bestuursverantwoordelijkheid, met mogelijke persoonlijke aansprakelijkheid bij aantoonbaar verzuim.
Hoe je AI-agent aansprakelijkheid wél vooraf regelt
Wij zijn niet tegen agents, en dit stuk is geen pleidooi om ermee te stoppen tot de wetgever klaar is. Bouw ze. De wet komt toch wel, ruim voordat de meeste bedrijven zelf zover zijn. Vier dingen die nu al te regelen zijn, zonder op december 2027 te wachten.
1. Wijs een eigenaar aan per agent, niet per team
McKinsey's cijfers zijn hierin duidelijk: een team is geen eigenaar. Eén naam die verantwoordelijk is voor wat een specifieke agent mag en niet mag, voorkomt het orphaned agent probleem uit de vorige afleveringen van deze reeks: niemand die het meer checkt zodra de bouwer van het project is vertrokken.
2. Leg vast wat de agent mag beslissen, niet alleen wat hij mag zien
Dit is het stoplicht-mechanisme uit aflevering 2: toegang tot een systeem zegt niets over wat een agent daarbinnen mag doen. Een agent die betalingen kan initiëren zonder bedraglimiet is dezelfde fout als een agent die klantdata kan lezen zonder doelbinding, alleen duurder als het misgaat.
3. Bouw het logboek nu al, niet pas als de wet het in 2027 verplicht
Artikel 26 gaat zes maanden logging verplichten voor hoog-risico systemen. Wachten tot die verplichting actief wordt, betekent twee jaar zonder enig spoor van wat een agent deed toen het misging. Dat spoor is ook precies wat een bedrijf nodig heeft om zelf aan te tonen dat de fout niet bij nalatigheid lag.
4. Valideer de actie voordat hij wordt uitgevoerd, niet erna
Dit is waar wij al zitten, los van het woord agent. Wij valideren al wat er tussen systemen beweegt, of dat nu een CRM-koppeling is of een agent die een betaling wil autoriseren. Het verschil met vijf jaar geleden is niet de technologie die om die actie vraagt. Het is hoeveel sneller die actie nu wordt uitgevoerd, en hoe weinig bedrijven vooraf hebben vastgelegd wie daarvoor tekent.
De wet die dit afdwingt is er over ruim een jaar. De rekening van een agent die vandaag de verkeerde afweging maakt, ligt gewoon nu al ergens op tafel.
Benieuwd hoe je dit zo snel mogelijk goed regelt binnen het IT landschap van je bedrijf? Neem eens vrijblijvend contact op en dan leggen we precies uit hoe je dit kan regelen.
Veelgestelde vragen
In theorie niet, maar in de praktijk lastig hard te maken. Je moet dan kunnen aantonen dat de fout niet ontstond door hoe jij de agent hebt geconfigureerd of ingezet, maar puur in het onderliggende product zat. Zonder een eigen logboek van wat de agent deed en waarom, is dat bewijs vaak niet te leveren, en val je alsnog terug op de deployer-aansprakelijkheid uit dit artikel.
Dat verschilt per polis, en veel bestaande verzekeringen zijn geschreven voordat AI-agents een rol speelden. Vraag dit expliciet na bij je verzekeraar in plaats van aan te nemen dat het er automatisch onder valt: "automatisering" en "een zelfstandig beslissende agent" worden niet altijd hetzelfde behandeld.
Ja. Of je de agent zelf gebouwd hebt of alleen hebt ingeschakeld in een tool die je al gebruikt, maakt voor de deployer-aansprakelijkheid geen verschil. Jij bent degene die hem binnen jouw processen laat werken, en dat is precies het criterium dat telt.
Minder direct, maar niet nooit. Zolang een chatbot alleen informatie geeft en een mens de uiteindelijke actie uitvoert, ligt de verantwoordelijkheid dichter bij die mens. Zet daarom altijd een disclaimer neer waarin je vermeldt dat AI fouten kan maken en bij belangrijke dingen je altijd zelf controles moet doen op waarheid. Zo dek je het al iets meer af.
Nee. Bestaand aansprakelijkheidsrecht, contracten en, voor bestuurders, de Cyberbeveiligingswet gelden al, los van de AI Act-planning. De 2027-deadline gaat over extra, aanvullende verplichtingen voor hoogrisicosystemen, niet over de vraag of je nu al aansprakelijk kan zijn.
Begin met de agent die het meeste risico kan veroorzaken, meestal degene met toegang tot geld of klantdata. Wijs daar één naam aan die verantwoordelijk is, en schrijf op wat die agent wel en niet zelfstandig mag beslissen. De rest volgt daarna.
Ja, voor het deel dat we al jaren doen: valideren wat er tussen systemen beweegt voordat het gebeurt, en vastleggen wie waartoe toegang en bevoegdheid heeft. Voor een AI-agent is dat dezelfde aanpak, toegepast op een nieuw soort aanvrager. Geen toekomstplan, we richten dit in op jouw systemen en jouw agents.
