"The AI wrote that."
I have said it. You have probably said it. It sounds like an explanation, and for about three years it worked as one.
Since January it does not work in a California courtroom.
The sentence that stopped working
California AB 316 was signed on 13 October 2025 and took effect on 1 January 2026. It says that in an action against a defendant alleged to have caused harm through the development, modification or use of an AI system, the defendant may not assert as a defence that the AI acted autonomously.
Read that with a developer's eyes and find yourself in it. "Use" is in the list, next to development and modification. Importing a model, accepting its output and shipping it is enough to put you inside that sentence.
Whether the thing you used acted on its own is no longer an answer you can offer.
The honest limits: AB 316 does not create strict liability. A plaintiff still has to prove the AI caused the harm and that the harm was foreseeable, and every other affirmative defence stays available to you. One door closed out of many.
It happens to be the specific door the whole industry has been leaning on.
This is not the review argument
I have argued that you should never ship code you cannot explain to a colleague. That rule governs one moment: the minute before the merge, when the question is whether you understand what you are about to accept.
This post is about every moment after it.
Understanding the code is the cheap half of ownership. The expensive half is that you are the one who answers for it afterwards, in the postmortem, under the contract, and now in front of a judge.
Europe made software a product
The EU Product Liability Directive (2024/2853) has been in force since December 2024, and member states have to have it in national law by 9 December 2026. It applies to products placed on the market after that date.
Four things in it matter to anyone shipping code:
- Software is a product. Firmware, applications, AI systems, however they reach the user: on a device, from the cloud, as SaaS.
- Not patching can make a product defective. If a vulnerability needs an update that is within your control and you do not supply it, that omission counts towards a finding that the product is defective.
- You cannot contract your way out. Liability under the PLD cannot be excluded or limited by agreement. The all-caps AS IS block at the bottom of your licence does not survive contact with it.
- The burden of proof tilts. Where technical complexity makes defectiveness or causation excessively difficult for a claimant to prove, a court may presume it, and can order you to disclose evidence in an accessible form.
The third one deserves a minute of your attention, because disclaiming liability in the licence file is the oldest reflex in commercial software.
Now the scope, honestly, because this gets overstated. The PLD is about safety-related defects that harm people: death, personal injury, property damage, and destruction or corruption of data that is not used professionally. It is not a new route for a client whose invoice totals came out 3% wrong.
If you build medical devices, vehicles, industrial control or consumer hardware, this is your regime from December. If you build internal dashboards, it is background reading.
For Dutch readers the date is the same, 9 December 2026, though business.gov.nl still notes that entry into force depends on the bill passing both chambers.
No vendor is indemnifying you for the code being wrong
Vendors do offer indemnities, and they are worth having. Microsoft's Customer Copyright Commitment will defend you against third-party intellectual property claims about output content.
Look carefully at what that covers. Copyright. Somebody asserting that the generated code was theirs.
There is no clause, from any vendor, that covers the code being broken.
The copyright cover is also conditional. For Azure OpenAI you have to run the protected-material model in annotate or filter mode, keep the jailbreak filter in filter mode, include a metaprompt directing the model against infringement, and retain a testing and red-teaming report that you hand to Microsoft if you ever claim. Their wording is unambiguous: a customer who tenders a claim for defence "will be required to demonstrate compliance with all relevant requirements".
The indemnity is a reward for having done the work. If you skipped the work, you have a licence rather than a shield. GitHub's burden did get lighter. As of 3 April 2026 GitHub offerings carry no additional required mitigations, and Duplicate Detection has become optional instead of a condition of coverage.
The sharper problem is one the lawyer Kate Downing flagged back in 2023, and it has not aged away. The exclusion applies to "code that differs from a suggestion provided by Copilot", with no "materially" or "significantly" sitting in front of "differs". Every real codebase differs. You took the suggestion, renamed a variable, pulled it into a class, and three refactors later nobody can reconstruct what the model originally proposed against a model version that no longer exists.
The 24-hour question
GitLab's 2026 AI Accountability Report, run by the Harris Poll across 1,528 developers and technology buyers in six countries, contains the number that ought to bother you.
87% are confident their team could determine within 24 hours whether AI-generated code contributed to a production incident.
Of the organisations that actually had an incident in the past year, 34% could not make that determination.
Confidence and capability got measured separately for once, and they came back different.
The rest of the report reads like a description of borrowed time. 43% cannot reliably tell AI-generated code from human-written code. 84% say the hardest part of AI-generated code is governing what happens to it after it is created.
80% adopted the tools faster than they wrote policies to govern them, and 82% expect all of it to become a form of technical debt they are not equipped to manage.
When an agent wiped a production database on a box I owned, recovery took minutes because a backup had run the night before. Working out what had actually happened took an hour, and that hour is why I wrote the runbook for the hour after an agent breaks something.
I was in the 34%. I would have told you, confidently, that I was in the 87%.
Ownership is a capability, so go and test it
Accountability is a set of capabilities you either have or you do not, and you find out which on your worst day unless you check on an ordinary one.
Four questions. Answer them this week, on real code, not hypothetically.
- Pick a pull request merged last month. Can you say which parts came out of an agent? If not, you are in the 43%, and provenance is the input to everything else on this list.
- Pick a file in production and name its owner. One person, who would be called, who has read it.
- Open your vendor terms and find what the indemnity actually covers. Then check whether you are meeting its conditions today. An indemnity you have voided by skipping the mitigations is worse than none, because you planned around it.
- Run the 24-hour drill. Take last quarter's incident and try to establish whether generated code contributed. Time yourself. However long that took is your real answer.
The agent will apologise when it goes wrong. Mine did, gracefully, quoting the weak line in its own instructions back at me and accepting the blame.
It cannot accept blame. Accountability means there is something you stand to lose, and it has nothing at stake: no licence, no reputation, no job, no name on the commit. Every one of those is yours.
You merged it. You own it.