"Die heeft de AI geschreven."
Ik heb het gezegd. Jij waarschijnlijk ook. Het klinkt als een verklaring, en ongeveer drie jaar lang werkte het ook zo.
In een Californische rechtszaal gaat die vlieger sinds januari niet meer op.
De zin die het niet meer doet
De Californische wet AB 316 is op 13 oktober 2025 ondertekend en op 1 januari 2026 in werking getreden. De wet bepaalt dat een gedaagde die schade zou hebben veroorzaakt door het ontwikkelen, aanpassen of gebruiken van een AI-systeem, niet als verweer mag aanvoeren dat de AI zelfstandig handelde.
Lees dat nog eens met de ogen van een developer en kijk waar jij daarin voorkomt. "Gebruiken" staat in dat rijtje. Je hebt niets getraind en niets gefinetuned. Je hebt een model gebruikt, de output geaccepteerd en geshipt.
Of dat model op eigen houtje handelde, doet juridisch niet meer ter zake.
Meteen de nuance erbij: AB 316 voert geen risicoaansprakelijkheid in. Een eiser moet nog steeds aantonen dat de AI de schade veroorzaakte en dat die schade voorzienbaar was, en al je andere verweren kun je nog gewoon voeren. Er gaat één deur dicht, de rest blijft open.
Het is wel precies de deur waardoor de hele branche tot nu toe naar buiten liep.
Dit gaat niet over reviewen
Ik heb eerder betoogd dat je nooit code moet shippen die je niet aan een collega kunt uitleggen. Die regel gaat over één moment: de minuut vóór de merge, als de vraag is of je begrijpt wat je op het punt staat te accepteren.
Dit stuk gaat over alle momenten daarna.
Begrijpen wat er staat is de goedkope helft van eigenaarschap. De dure helft is dat jij degene bent die er later verantwoording over aflegt, in de postmortem, onder het contract, en nu ook voor de rechter.
Europa maakt software een product
De nieuwe richtlijn productaansprakelijkheid (EU 2024/2853) is sinds december 2024 in werking en moet uiterlijk 9 december 2026 in nationale wetgeving zijn omgezet. De richtlijn geldt voor producten die ná die datum op de markt komen.
Vier punten daaruit raken iedereen die code shipt:
- Software is een product. Firmware, applicaties en AI-systemen, hoe ze de gebruiker ook bereiken: op een apparaat, uit de cloud, als SaaS.
- Niet patchen kan een product gebrekkig maken. Als een kwetsbaarheid een update nodig heeft die binnen jouw macht ligt en je die niet levert, dan kan het product alleen daarom al als gebrekkig gelden.
- Je kunt het niet wegcontracteren. Aansprakelijkheid onder deze richtlijn kun je niet uitsluiten of beperken in je voorwaarden. De AS IS-disclaimer onderaan je licentie houdt hier geen stand.
- De bewijslast verschuift. Als de technische complexiteit het voor een eiser te moeilijk maakt om het gebrek of het causale verband aan te tonen, mag de rechter dat vermoeden, en kan hij jou verplichten bewijs in begrijpelijke vorm over te leggen.
Dat derde punt verdient even je aandacht, want aansprakelijkheid uitsluiten in het licentiebestand is de oudste reflex in commerciële software.
En dan de omvang, want die wordt vaak groter gemaakt dan hij is. Deze richtlijn gaat over gebreken die de veiligheid raken en mensen schade toebrengen: overlijden, lichamelijk letsel, materiële schade en het vernietigen of beschadigen van data die niet zakelijk wordt gebruikt. Het is geen nieuwe route voor een klant bij wie de factuurtotalen er 3% naast zaten.
Bouw je medische apparatuur, voertuigen, industriële besturing of consumentenhardware, dan geldt dit vanaf december voor jou. Bouw je interne dashboards, dan is het achtergrondkennis.
Voor Nederland is de datum dezelfde, 9 december 2026, al meldt business.gov.nl dat de inwerkingtreding nog afhangt van behandeling in de Tweede en Eerste Kamer.
Geen enkele leverancier dekt je als de code niet werkt
Leveranciers bieden wel vrijwaringen aan, en die zijn de moeite waard. Microsofts Customer Copyright Commitment verdedigt je tegen claims van derden over intellectuele-eigendomsrechten op de output.
Kijk goed naar wat daar staat. Auteursrecht. Iemand die beweert dat de gegenereerde code van hem was.
Geen enkele leverancier heeft een clausule die je dekt als de code niet werkt.
Die auteursrechtdekking is ook voorwaardelijk. Voor Azure OpenAI moet je de protected-material-detectie aan hebben staan in annotate- of filtermodus, het jailbreakfilter in filtermodus houden, een metaprompt meegeven die het model opdraagt geen inbreuk te maken, en een test- en red-teamingrapport bewaren dat je overhandigt als je ooit een beroep op de vrijwaring doet. Hun eigen formulering laat weinig ruimte: wie een claim indient, moet aantonen dat aan alle relevante eisen is voldaan.
De vrijwaring is een beloning voor werk dat je gedaan hebt. Heb je dat werk overgeslagen, dan heb je een licentie in handen en geen schild. Bij GitHub zijn de eisen wel lichter geworden: sinds 3 april 2026 gelden er voor GitHub-diensten geen aanvullende verplichte maatregelen meer, en is Duplicate Detection optioneel in plaats van een voorwaarde voor dekking.
Het scherpere probleem zag advocaat Kate Downing al in 2023, en het is niet overgewaaid. De uitsluiting geldt voor "code that differs from a suggestion provided by Copilot", zonder dat er "materially" of "significantly" vóór dat "differs" staat. Elke echte codebase wijkt af.
Je nam de suggestie over, hernoemde een variabele, verhuisde hem naar een class, en drie refactors later kan niemand nog reconstrueren wat het model oorspronkelijk voorstelde. Die modelversie bestaat inmiddels niet eens meer.
De 24-uursvraag
In het AI Accountability Report 2026 van GitLab, uitgevoerd door Harris Poll onder 1.528 developers en technologie-inkopers in zes landen, staat het cijfer waar je wakker van zou moeten liggen.
87% is ervan overtuigd dat het eigen team binnen 24 uur kan vaststellen of AI-code heeft bijgedragen aan een incident in productie.
Van de organisaties die het afgelopen jaar echt een incident hadden, kon 34% dat niet vaststellen.
Hier zijn overtuiging en vermogen eens apart gemeten, en er kwamen twee verschillende antwoorden uit.
De rest van het rapport leest als een sector die op krediet leeft. 43% kan AI-code niet betrouwbaar onderscheiden van code die een mens schreef. 84% zegt dat het moeilijkste aan AI-code is wat er ná het genereren mee gebeurt.
80% nam de tools sneller in gebruik dan er beleid voor was, en 82% verwacht dat er technische schuld van overblijft waar de organisatie niet op is ingericht.
Toen een agent een productiedatabase wiste op een machine die ik zelf beheer, kostte het herstel een paar minuten, want de nacht ervoor was er een backup gelopen. Uitzoeken wat er precies was gebeurd kostte een uur, en dat uur is de reden dat ik het draaiboek voor het uur nadat een agent iets breekt schreef.
Ik zat in die 34%. En ik zou je vol overtuiging hebben verteld dat ik in die 87% zat.
Eigenaarschap is een vermogen, dus test het
Verantwoordelijkheid is een verzameling dingen die je kunt of niet kunt. Wat jij kunt, merk je op je slechtste dag, tenzij je het op een gewone dag controleert.
Vier vragen. Beantwoord ze deze week, op echte code, niet in gedachten.
- Pak een pull request die vorige maand is gemerged. Kun je zeggen welke delen uit een agent kwamen? Zo niet, dan zit je in die 43%, en die herkomst is de basis voor elk ander antwoord hieronder.
- Pak een bestand in productie en noem de eigenaar. Eén persoon, die gebeld wordt en die het bestand gelezen heeft.
- Zoek in je leveranciersvoorwaarden op wat de vrijwaring werkelijk dekt. Kijk daarna of je vandaag aan de eisen voldoet. Een vrijwaring die je zelf ongeldig hebt gemaakt door de maatregelen over te slaan is erger dan geen vrijwaring, want je hebt erop gerekend.
- Doe de 24-uursoefening. Neem het incident van vorig kwartaal en probeer vast te stellen of er gegenereerde code aan te pas kwam. Klok hoe lang je erover doet. Die tijd is je echte antwoord.
De agent biedt zijn excuses aan als het misgaat. De mijne deed dat netjes, hield me de zwakke regel uit zijn eigen instructies voor, en nam de schuld op zich.
Schuld op zich nemen kan hij niet. Verantwoordelijkheid betekent dat er iets te verliezen valt, en hij heeft niets op het spel staan: geen licentie, geen reputatie, geen baan, geen naam onder de commit. Die zijn allemaal van jou.
Jij hebt de code gemerged. Dus is die van jou.