Voor AI-agents die na 9 december 2026 live gaan, valt AI aansprakelijkheid onder productaansprakelijkheid en is wie de agent ontwikkelt fabrikant; Oase Creative mat dat 6 van 7 automatiseringsplatforms uitvoeringslogs standaard binnen 60 dagen weggooien.
Wat verandert er op 9 december aan AI aansprakelijkheid?
AI aansprakelijkheid krijgt in december een nieuwe basis. De Europese richtlijn productaansprakelijkheid (EU) 2024/2853 noemt software uitdrukkelijk een product, en geldt voor producten die na 9 december 2026 in de handel komen of in gebruik worden gesteld. Een AI-agent die je klanten mailt, offertes opstelt of bestellingen verwerkt, is dan juridisch gezien geen dienst of hulpmiddel meer, maar een product met een fabrikant. Die fabrikant is aansprakelijk zonder dat iemand schuld hoeft te bewijzen. De benadeelde moet het gebrek, de schade en het verband ertussen aantonen, maar bij technisch complexe producten mag de rechter dat bewijs deels vermoeden (artikel 10 lid 4).
Dit artikel is voor de ondernemer die een AI-agent laat bouwen of er al een gebruikt. Wij bouwen en beheren zulke systemen, voor klanten en voor ons eigen bureau, en lezen de richtlijn dus met een praktische vraag: wat moet er op papier en in het systeem staan als er ooit iets misgaat? Juridisch advies is dit niet. Voor je eigen situatie neem je een jurist.
De stand van de wet in Nederland: de Tweede Kamer nam het wetsvoorstel 36 906 op 15 oktober zonder debat aan, en de Eerste Kamer zette het voor 10 november als hamerstuk op de agenda. Daarna volgen nog publicatie in het Staatsblad en een koninklijk besluit voor de ingangsdatum. Ondernemersplein schrijft dat die datum nog niet bekend is, terwijl de richtlijn 9 december als omzettingsdatum voorschrijft (artikel 22). Europees gezien loopt Nederland niet achter. Op de EUR-Lex-pagina met nationale omzettingsmaatregelen hadden op 9 november 5 van de 27 lidstaten iets gemeld: Duitsland, Slowakije, Kroatië, Litouwen en Hongarije.
Is mijn AI-agent echt een product, ook als hij als dienst draait?
Ja. Artikel 4 noemt software in de definitie van "product", en overweging 13 zegt dat dit geldt "ongeacht de wijze van levering of gebruik". Software op een apparaat, software in de cloud en software via een software-als-service-model: allemaal product. In dezelfde overweging staat dat aanbieders van AI-systemen als fabrikant moeten worden behandeld.
Een AI-agent is in die logica een samengesteld product. Het taalmodel van OpenAI, Anthropic of Google is een component. De koppelingen met je mailbox, je CRM of je boekhouding zijn componenten of bijbehorende diensten. De instructies, de rechten die de agent krijgt en de volgorde van de stappen vormen het ontwerp. Wat we in ons stuk over agentic workflows beschreven als de bouwstenen van een agent, zijn juridisch de onderdelen van een product.
Twee details uit de richtlijn raken agents direct. Artikel 7 lid 2 sub c zegt dat bij de beoordeling van een gebrek meetelt welk effect "het vermogen om te blijven leren of nieuwe functies te verwerven" op het product heeft. Gaat een agent na de oplevering ander gedrag vertonen, dan telt dat gedrag mee in de vraag of er een gebrek is. En artikel 2 lid 2 sluit gratis opensourcesoftware uit, maar alleen zolang die buiten een handelsactiviteit wordt geleverd. Bouw je een open-sourcepakket in een agent die je commercieel inzet, dan valt het geheel er naar onze lezing onder.
Wat geen product is: informatie. De richtlijn sluit "de inhoud van digitale bestanden" en "de loutere broncode" uit. De tekst die je agent schrijft, is geen product. Maar de agent die hem schrijft en verstuurt, is dat wel.
Wie is de fabrikant: jij, je bouwer of de leverancier van het model?
De fabrikant is wie het product ontwikkelt. Artikel 4 punt 10 geeft drie routes: je ontwikkelt of produceert het product, je presenteert je als fabrikant door je naam of merk erop te zetten, of je ontwikkelt het voor eigen gebruik. Die laatste route verrast veel ondernemers. Wie zelf in n8n of Make een agent bouwt die namens het bedrijf klanten antwoordt, is daarmee fabrikant van die agent, ook als hij nooit iets verkoopt.
Hoe het in de praktijk uitvalt, hangt af van wie wat doet. Onze lezing van de richtlijn, per situatie:
| Situatie | Wie is fabrikant? | Artikel |
|---|---|---|
| Een bureau bouwt een agent voor jou en levert hem op | Het bureau, omdat het de agent ontwikkelt; jij mogelijk ook als je hem onder eigen naam aan klanten aanbiedt | art. 4 punt 10 a en b |
| Je bouwt zelf een agent voor je eigen bedrijf | Jij | art. 4 punt 10 c |
| Je neemt een standaard-agent af van een softwareleverancier | De leverancier | art. 4 punt 10 a |
| Je past een opgeleverde agent ingrijpend aan zonder je bouwer | Jij, voor het gewijzigde product | art. 8 lid 2 |
| Het taalmodel achter de agent bevat het gebrek | De modelleverancier als componentfabrikant, naast de fabrikant van de agent | art. 8 lid 1 b |
De benadeelde mag kiezen wie hij aanspreekt. Artikel 12 maakt meerdere aansprakelijke partijen hoofdelijk aansprakelijk, dus jij en je bouwer kunnen elk voor het geheel worden aangesproken. Daarna zoeken jullie onderling uit wie het betaalt.
Wijzen naar de modelleverancier helpt je bouwer meestal niet. Artikel 11 lid 1 sub f laat de componentfabrikant vrijuit gaan als het gebrek komt door "het ontwerp" van het eindproduct of door de instructies die de fabrikant van dat eindproduct gaf. Bij een agent zijn de systeeminstructies, de tool-rechten en de keuze welke acties zonder controle mogen precies dat ontwerp. Gaat een agent mailen omdat hij die rechten kreeg, dan wijst de modelleverancier terug naar wie de agent zo heeft ingericht.
Dat de bot van jou is, bleek dit jaar al buiten de productaansprakelijkheid om. Het Duitse Oberlandesgericht Hamm legde op 12 mei 2026 een kliniek een verbod op voor titels die haar chatbot aan de artsen toedichtte. Dat de bot met correcte gegevens was gevoed, hielp niet. De antwoorden van de bot golden volgens de rechter als handelingen van het bedrijf zelf.
Waarom draait een claim straks om je logboek?
Omdat de richtlijn de bewijslast verschuift naar wie het systeem kent. Artikel 9 lid 1 verplicht de verweerder om "relevant bewijsmateriaal waarover hij of zij beschikt" openbaar te maken als de eiser zijn vordering aannemelijk maakt. Artikel 10 lid 2 sub a voegt eraan toe: verzuim je dat, dan wordt het product vermoed gebrekkig te zijn. En artikel 10 lid 4 laat de rechter ook een gebrek vermoeden als de eiser "buitensporige moeilijkheden" heeft door "technische of wetenschappelijke complexiteit". Een keten van agent, model, koppelingen en tools is daar een schoolvoorbeeld van.
Tegen die vermoedens mag je je verweren (artikel 10 lid 5). Dat kan in de praktijk maar op één manier: laten zien wat de agent deed, met welke invoer, met welke instructies en met welke modelversie. Zonder uitvoeringslog heb je dat verhaal niet.
Daar zit het probleem. Wij hebben op 9 november nagelezen hoe lang zeven gangbare platforms hun uitvoeringslogs standaard bewaren. Zapier schrijft dat het maximaal 60 dagen aan rungegevens kan garanderen. Zelf gehoste n8n ruimt uitvoeringen standaard na 336 uur op, dus na 14 dagen. Power Automate houdt runs 30 dagen vast.
| Platform (gangbaar plan) | Standaard bewaartermijn uitvoeringslogs |
|---|---|
| n8n Cloud Starter / Pro | 7 / 30 dagen |
| n8n zelf gehost | 14 dagen |
| Zapier | 60 dagen |
| Make Core, Pro en Teams | 30 dagen |
| Microsoft Power Automate | 30 dagen |
| OpenAI API (Responses) | 30 dagen |
| Anthropic API | 0 tot 30 dagen |
| Langfuse Cloud | Inzage 30 dagen tot 3 jaar, data blijft bewaard |
Zes van de zeven bewaren standaard hooguit 60 dagen, vijf hooguit 30. Daartegenover staan de termijnen uit de richtlijn: een verjaringstermijn van drie jaar vanaf het moment dat de benadeelde schade, gebrek en aansprakelijke partij kent (artikel 16), en een vervaltermijn van tien jaar na het in de handel brengen (artikel 17). Een claim die in jaar twee binnenkomt, gaat over een run waarvan het platform al lang niets meer weet.
Eerlijk is eerlijk: de richtlijn bevat zelf geen bewaarplicht voor logs. Het verband tussen logretentie en die bewijsvermoedens is onze lezing, geen oordeel van een rechter. Maar alle platforms bieden een uitweg die je zelf moet aanzetten: exporteren, de bewaartermijn verlengen of een eigen logboek naast het platform. Die keuze maak je bij de bouw, niet als de brief van de advocaat er ligt.
Hoe lang moet je updates blijven leveren?
Zolang je zeggenschap over het product hebt. Volgens artikel 4 punt 5 heb je zeggenschap zodra je "zelf of via een derde software-updates of -upgrades kan leveren". Wie een agent beheert en er wijzigingen in kan doorvoeren, heeft dus zeggenschap.
Dat raakt een klassiek verweer. Onder het oude recht kon een fabrikant zeggen: het gebrek bestond nog niet toen ik het product leverde. Artikel 11 lid 2 haalt dat verweer weg voor software, voor software-updates, voor een ingrijpende wijziging en voor "een ontbreken van software-updates of -upgrades die nodig zijn om de veiligheid te handhaven", telkens op voorwaarde dat de fabrikant er zeggenschap over heeft. Een beveiligingsupdate die je had kunnen doorvoeren maar liet liggen, telt dus tegen je.
Hoe snel dat speelt, zie je aan de componenten waar agents op draaien. Het officiële hulpmiddel om MCP-servers te testen, de MCP Inspector, had een lek dat via een klein hulppakket binnenkwam. Pillar Security beschreef hoe een kwaadwillende server zo op Windows code kon uitvoeren op de machine van de ontwikkelaar. De fix verscheen op 21 oktober. Wij telden via de npm-API welke versies er van 1 tot en met 7 november werden gedownload: nog ruim de helft was een kwetsbare. Bij drie componenten uit diezelfde agentketen zaten 74 tot 91 dagen tussen de reparatie en de officiële waarschuwing: 74 bij de Jira-koppeling mcp-atlassian, 91 bij de Claude Agent SDK. Wie wacht tot zijn scanner alarm slaat, loopt dus maanden achter.
Daar staat tegenover dat artikel 7 lid 3 je beschermt tegen een te strenge lezing. Een product is niet gebrekkig "om de enkele reden" dat er later een betere versie of update uitkomt. Je hoeft je agent niet elke week te verbeteren. Je moet wel de updates doorvoeren die de veiligheid op peil houden.
Wat kun je contractueel regelen, en wat niet?
Tegenover de benadeelde niets. Artikel 15 zegt dat de aansprakelijkheid "niet wordt beperkt of uitgesloten door een contractuele bepaling". Een plafond in je algemene voorwaarden, een vrijwaring of een disclaimer onder de chatbot werkt niet tegenover iemand die schade lijdt.
Tussen bedrijven ligt dat anders. Wie uiteindelijk betaalt nadat de benadeelde is vergoed, regelt het nationale recht, en dat mag je contractueel invullen. De richtlijn geeft kleine softwareleveranciers zelfs een extra mogelijkheid: artikel 12 lid 2 laat een micro- of kleine onderneming die een softwarecomponent levert afspreken dat de afnemer geen regres op haar neemt.
| Tegenover de benadeelde | Tussen jou en je bouwer | |
|---|---|---|
| Aansprakelijkheid uitsluiten of beperken | Kan niet (art. 15) | Kan, via regresafspraken |
| Wie wordt aangesproken | Elke aansprakelijke partij, hoofdelijk (art. 12 lid 1) | Volgt uit jullie contract en het nationale recht |
| Kleine softwareleverancier | Gewoon aansprakelijk | Mag afspreken dat er geen regres op haar komt (art. 12 lid 2) |
| Bewijs en logboek | Moet je kunnen overleggen (art. 9) | Spreek af wie het bewaart en hoe lang |
Hoe ver de markt daarmee is, hebben we begin november gemeten. We lazen de algemene voorwaarden van 14 Nederlandse bouwers van software, apps en automatiseringen. Geen van de 14 noemt de nieuwe productaansprakelijkheid. Vier gebruiken het woord productaansprakelijkheid, en alle vier om de klant de bouwer te laten vrijwaren. Geen enkele bouwer belooft updates; bij de meesten is onderhoud een optioneel, apart betaald pakket. Voor jou als opdrachtgever betekent dat: je staat vooraan bij een claim, je hebt misschien getekend dat je je bouwer vrijwaart, en of er updates komen hangt af van een contract dat je nog moet afsluiten.
Welke vragen stel je je verzekeraar over een AI-agent?
De polissen zijn er nog niet duidelijk over. Ondernemersplein raadt ondernemers aan om te controleren of hun verzekering nog voldoende dekking biedt, omdat de nieuwe regels het risico op productaansprakelijkheid veranderen. Wat polissen er nu over zeggen, is weinig. Makelaar Aon schreef in juni in vakblad Balie+ dat zijn Nederlandse voorwaarden over AI "silent" zijn: geen uitdrukkelijke insluiting, geen uitsluiting.
Aon maakt in dat stuk een onderscheid dat ook voor jou bruikbaar is. AI als hulpmiddel, met een mens die het werk controleert, behandelen ze als een gewone beroepsfout. AI die als zelfstandig product naar derden gaat, is volgens hen iets waarvoor de huidige verzekeringen niet geschreven zijn. Let wel: dat stuk ging over de beroepsaansprakelijkheid van advocaten en notarissen, gezien door één makelaar. Het is een signaal, geen marktbreed beeld.
Ons advies is daarom nuchter. Stel je verzekeraar schriftelijk twee vragen: valt een AI-agent die namens ons bedrijf met klanten communiceert onder de bedrijfsaansprakelijkheidsverzekering, en is productaansprakelijkheid voor software meeverzekerd? Bewaar het antwoord bij de documentatie van de agent.
En kijk naar de plek van de mens in je proces. Een agent die een concept maakt dat een medewerker beoordeelt, is iets anders dan een agent die zelfstandig verstuurt. In ons artikel over human in the loop staat hoe je dat akkoordmoment inricht zonder dat het een stempelmachine wordt. Diezelfde menselijke controle die de kwaliteit bewaakt, maakt het verhaal richting je verzekeraar ook eenvoudiger.
Wat regel je vóór 9 december als je een AI-agent laat bouwen?
Begin met de datum. De richtlijn geldt voor producten die na 9 december 2026 in de handel komen of in gebruik worden gesteld. Een agent die nu al draait, valt nog onder het oude recht, tot iemand hem ingrijpend wijzigt. Volgens artikel 17 lid 1 sub b begint de vervaltermijn bij een ingrijpend gewijzigd product opnieuw te lopen. Plan je een grote ombouw, dan is dat het moment om het hieronder geregeld te hebben.
Dit zijn de vragen die we zelf zouden stellen als we een agent lieten bouwen. De grondslag in de derde kolom is onze lezing van de richtlijn:
| Vraag aan je bouwer | Waarom | Grondslag |
|---|---|---|
| Wie is de fabrikant, en staat dat in het contract? | Bepaalt wie de benadeelde aanspreekt en hoe regres loopt | art. 4 punt 10, art. 12 |
| Wat legt het systeem vast per actie, en hoe lang? | Zonder log geen verweer tegen de bewijsvermoedens | art. 9, 10, 16, 17 |
| Wie bewaakt de componenten en levert beveiligingsupdates? | Een ontbrekende update haalt je verweer weg | art. 11 lid 2 |
| Welke modelversie draait er, en wordt een wissel gelogd? | Een automatisch bijgewerkt model is een update waarmee je instemt | art. 4 punt 5 |
| Waar moet een mens akkoord geven, en waar zit de pauzeknop? | Beperkt de schade en houdt de inzet dicht bij hulpmiddel | ontwerpkeuze |
| Wat was het beoogde doel bij oplevering? | Referentiepunt voor wat een ingrijpende wijziging is | art. 4 punt 18, art. 8 lid 2 |
| Wat dekt de verzekering, van jou en van de bouwer? | Polissen zijn over AI nog onduidelijk | schriftelijk navragen |
De vragen over het log en de updates zijn de belangrijkste, omdat je ze achteraf niet meer kunt repareren. Een log dat niet bestaat, kun je niet overleggen. Kies je voor een standaardplatform, vraag dan ook wat het kost om het beheer na de bouw goed te doen. Wie een bureau zoekt, vindt in ons stuk over een AI-bureau kiezen de bredere selectievragen. Deze zeven komen daar nu bij.
Hoe pakken wij AI aansprakelijkheid aan bij Oase Creative?
Wij draaien sinds dit voorjaar een agentsysteem dat ons eigen bureau helpt runnen, en bouwen dezelfde soort systemen voor klanten. Twee keuzes uit dat werk sluiten nu aan op de richtlijn, al hebben we ze niet om juridische redenen gemaakt.
De eerste is het audit-spoor. Elke risicovolle actie van ons systeem wordt vooraf weggeschreven: wat er gaat gebeuren, en daarna wat de uitkomst was. Dat logboek staat los van de platforms en hun bewaartermijnen. Sinds begin mei zijn dat ruim tweeduizend vastgelegde acties, die we kunnen teruglezen zolang we ze bewaren. Op de dienstpagina managed automation staat dat logboek als vast onderdeel van het beheer, naast het opvangen van model-updates.
De tweede is het menselijke akkoord. Alles wat ons systeem naar buiten stuurt, wacht op een mens, en dat akkoord is gekoppeld aan een echt bericht en één keer bruikbaar. Op 10 november stonden er 298 vastgelegde akkoorden. Bij Pluis, waar we de nieuwsbrief automatiseerden, gaat ook elke mail langs een mens. Hoe dat werkt, lees je in de case van Pluis.
Wat dat met aansprakelijkheid te maken heeft: het zijn precies de twee dingen die je na 9 december nodig hebt als iemand vraagt wat je agent deed en wie dat besliste. Daarom is managed automation voor ons geen extraatje na de bouw, maar het deel waar de verantwoording zit. Laat je een agent bouwen via AI-automatisering of maatwerk software, dan bespreken we de vragen uit de tabel hierboven bij de start, niet achteraf. En wil je eerst weten wat AI-automatisering eigenlijk is, dan is dat de plek om te beginnen.
