For AI agents that go live after 9 December 2026, AI liability falls under product liability and whoever develops the agent is the manufacturer; Oase Creative found 6 of 7 automation platforms delete execution logs by default within 60 days.
What changes for AI liability on 9 December?
AI liability gets a new legal basis in December. The European Product Liability Directive (EU) 2024/2853 explicitly names software as a product, and it applies to products placed on the market or put into service after 9 December 2026. An AI agent that emails your customers, drafts quotes or processes orders is then, legally speaking, no longer a service or a tool but a product with a manufacturer. That manufacturer is liable without anyone having to prove fault. The injured person must show the defect, the damage and the causal link, but for technically complex products the court may presume part of that proof (Article 10(4)).
This article is for business owners who are having an AI agent built or already run one. We build and manage these systems, for clients and for our own agency, so we read the directive with a practical question: what needs to be on paper and in the system if something ever goes wrong? This is not legal advice. For your own situation, talk to a lawyer.
Where the Dutch law stands: the lower house passed bill 36 906 on 15 October without debate, and the Senate scheduled it as a formality vote for 10 November. Publication in the Official Gazette and a royal decree setting the start date still have to follow. The Dutch government's business portal Ondernemersplein says that date is not yet known, while the directive sets 9 December as the transposition deadline (Article 22). The Netherlands is not behind the rest of Europe. On the EUR-Lex page for national transposition measures, 5 of the 27 member states had reported something on 9 November: Germany, Slovakia, Croatia, Lithuania and Hungary.
Is my AI agent really a product, even when it runs as a service?
Yes. Article 4 includes software in the definition of "product", and Recital 13 says this applies "irrespective of the means of supply or usage". Software on a device, software in the cloud and software delivered as a service: all product. The same recital says providers of AI systems are to be treated as manufacturers.
In that logic, an AI agent is a composite product. The language model from OpenAI, Anthropic or Google is a component. Connections to your inbox, your CRM or your accounting software are components or related services. The instructions, the permissions the agent gets and the order of its steps make up the design. What we described in our piece on agentic workflows as the building blocks of an agent are, legally, the parts of a product.
Two details in the directive hit agents directly. Article 7(2)(c) says that assessing a defect takes into account the effect on the product of "any ability to continue to learn or acquire new features" after it is placed on the market. If an agent starts behaving differently after delivery, that behaviour counts in deciding whether there is a defect. And Article 2(2) excludes free and open-source software, but only when it is supplied outside a commercial activity. Build an open-source package into an agent you use commercially, and in our reading the whole thing falls under the rules.
What is not a product: information. The directive excludes "the content of digital files" and "the mere source code" of software. The text your agent writes is not a product. But the agent that writes and sends it is.
Who is the manufacturer: you, your builder or the model provider?
The manufacturer is whoever develops the product. Article 4(10) gives three routes: you develop or produce the product, you present yourself as its manufacturer by putting your name or brand on it, or you develop it for your own use. That last route surprises many business owners. If you build an agent in n8n or Make that answers customers on behalf of your company, you are the manufacturer of that agent, even if you never sell anything.
How it plays out depends on who does what. Our reading of the directive, by situation:
| Situation | Who is the manufacturer? | Article |
|---|---|---|
| An agency builds an agent for you and delivers it | The agency, because it develops the agent; possibly you too if you offer it to customers under your own name | Art. 4(10)(a) and (b) |
| You build an agent for your own business | You | Art. 4(10)(c) |
| You buy a standard agent from a software vendor | The vendor | Art. 4(10)(a) |
| You substantially modify a delivered agent without your builder | You, for the modified product | Art. 8(2) |
| The language model behind the agent contains the defect | The model provider as component manufacturer, alongside the agent's manufacturer | Art. 8(1)(b) |
The injured person can choose whom to pursue. Article 12 makes multiple liable parties jointly and severally liable, so you and your builder can each be held liable for the whole amount. You sort out between yourselves who pays afterwards.
Pointing at the model provider usually will not help your builder. Under Article 11(1)(f) the component manufacturer is off the hook if the defect is attributable to "the design" of the final product or to the instructions the final manufacturer gave. In an agent, the system instructions, the tool permissions and the choice of which actions may run without review are exactly that design. If an agent sends emails because it was given that permission, the model provider points back at whoever set the agent up that way.
That the bot is yours was already clear this year, outside product liability. The German Higher Regional Court of Hamm ruled on 12 May 2026 that a clinic had to stop its chatbot from attributing titles to its doctors that they did not hold. That the bot had been fed correct data did not help. According to the court, the bot's answers counted as acts of the company itself.
Why will a claim come down to your logs?
Because the directive shifts the burden of proof towards whoever knows the system. Article 9(1) requires the defendant to disclose "relevant evidence that is at the defendant's disposal" once the claimant has made the claim plausible. Article 10(2)(a) adds that if you fail to do so, the product is presumed defective. And Article 10(4) lets the court presume a defect when the claimant faces "excessive difficulties, in particular due to technical or scientific complexity". A chain of agent, model, connections and tools is a textbook case.
You may rebut those presumptions (Article 10(5)). In practice there is only one way: show what the agent did, with which input, which instructions and which model version. Without execution logs you do not have that story.
That is the problem. On 9 November we checked how long seven common platforms keep execution logs by default. Zapier says it can guarantee a maximum of 60 days of Zap run data. Self-hosted n8n prunes executions after 336 hours by default, so after 14 days. Power Automate keeps runs for 30 days.
| Platform (common plan) | Default retention of execution logs |
|---|---|
| n8n Cloud Starter / Pro | 7 / 30 days |
| n8n self-hosted | 14 days |
| Zapier | 60 days |
| Make Core, Pro and Teams | 30 days |
| Microsoft Power Automate | 30 days |
| OpenAI API (Responses) | 30 days |
| Anthropic API | 0 to 30 days |
| Langfuse Cloud | Access 30 days to 3 years, data is kept |
Six of the seven keep logs for at most 60 days by default, five for at most 30. Against that stand the periods in the directive: a limitation period of three years from the moment the injured person knows of the damage, the defect and the liable party (Article 16), and an expiry period of ten years after the product was placed on the market (Article 17). A claim that arrives in year two concerns a run the platform forgot long ago.
To be fair: the directive itself contains no duty to keep logs. The link between log retention and those evidential presumptions is our reading, not a court ruling. But every platform offers a way out that you have to switch on yourself: exporting, extending retention, or keeping your own log next to the platform. You make that choice when you build, not when the lawyer's letter arrives.
How long do you have to keep delivering updates?
For as long as you have control over the product. Under Article 4(5) you have control as soon as you are "able to supply software updates or upgrades himself or herself or via a third party". Anyone who manages an agent and can push changes to it has control.
That removes a classic defence. Under the old rules a manufacturer could argue that the defect did not exist when the product was delivered. Article 11(2) takes that defence away for software, software updates, a substantial modification and "the lack of software updates or upgrades necessary to maintain safety", each time provided the manufacturer has control. A security update you could have installed but left aside counts against you.
How quickly this matters shows in the components agents run on. The official tool for testing MCP servers, the MCP Inspector, had a vulnerability that came in through a small helper package. Pillar Security described how a malicious server could use it to run code on a developer's Windows machine. The fix shipped on 21 October. We counted through the npm API which versions were downloaded from 1 to 7 November: more than half were still vulnerable. For three components from the same agent chain, 74 to 91 days passed between the fix and the official warning: 74 for the Jira connector mcp-atlassian, 91 for the Claude Agent SDK. Waiting for your scanner to raise the alarm leaves you months behind.
On the other side, Article 7(3) protects you from too strict a reading. A product is not defective "for the sole reason" that a better version or update comes out later. You do not have to improve your agent every week. You do have to install the updates that keep it safe.
What can you settle by contract, and what not?
Towards the injured person, nothing. Article 15 says liability shall not "be limited or excluded by a contractual provision". A cap in your terms, an indemnity or a disclaimer under the chatbot does not work against someone who suffers damage.
Between businesses it is different. Who ultimately pays once the injured person has been compensated is governed by national law, and you can shape that by contract. The directive even gives small software suppliers an extra option: Article 12(2) lets a micro or small enterprise that supplies a software component agree that the buyer will not seek recourse against it.
| Towards the injured person | Between you and your builder | |
|---|---|---|
| Excluding or limiting liability | Not possible (Art. 15) | Possible, through recourse agreements |
| Who can be pursued | Every liable party, jointly and severally (Art. 12(1)) | Follows from your contract and national law |
| Small software supplier | Liable as normal | May agree that no recourse is taken against it (Art. 12(2)) |
| Evidence and logs | You must be able to disclose them (Art. 9) | Agree who keeps them and for how long |
We measured how far the market is in early November. We read the terms and conditions of 14 Dutch builders of software, apps and automations. None of the 14 mentions the new product liability. Four use the word product liability, and all four do so to make the client indemnify the builder. No builder promises updates; for most, maintenance is an optional, separately paid package. For you as the client, that means you stand first in line for a claim, you may have signed that you indemnify your builder, and whether updates arrive depends on a contract you still have to sign.
What should you ask your insurer about an AI agent?
Policies are not clear about it yet. Ondernemersplein advises businesses to check whether their insurance still provides enough cover, because the new rules change the product liability risk. What policies say about it today is little. Broker Aon wrote in June in the Dutch trade journal Balie+ that its Dutch policy terms are "silent" on AI: no explicit inclusion, no exclusion.
Aon draws a distinction in that piece that is useful for you too. AI as a tool, with a person checking the work, is treated as an ordinary professional error. AI that goes to third parties as a standalone product is, in their words, something current policies were not written for. Note that the piece was about the professional liability of lawyers and notaries, seen by one broker. It is a signal, not a picture of the whole market.
Our advice is therefore sober. Ask your insurer two questions in writing: is an AI agent that communicates with customers on behalf of our company covered by our general liability insurance, and is product liability for software included? Keep the answer with the agent's documentation.
And look at where the person sits in your process. An agent that writes a draft for an employee to review is different from an agent that sends on its own. Our article on human in the loop shows how to set up that approval moment without it turning into a rubber stamp. The same human check that protects quality also makes the conversation with your insurer simpler.
What should you settle before 9 December if you have an AI agent built?
Start with the date. The directive applies to products placed on the market or put into service after 9 December 2026. An agent that is already running stays under the old rules until someone substantially modifies it. Under Article 17(1)(b), the expiry period starts again for a substantially modified product. If you are planning a major rebuild, that is the moment to have the points below in place.
These are the questions we would ask if we were having an agent built. The basis in the third column is our reading of the directive:
| Question for your builder | Why | Basis |
|---|---|---|
| Who is the manufacturer, and is that in the contract? | Determines whom the injured person pursues and how recourse works | Art. 4(10), Art. 12 |
| What does the system record per action, and for how long? | Without logs, no defence against the evidential presumptions | Art. 9, 10, 16, 17 |
| Who monitors the components and delivers security updates? | A missing update removes your defence | Art. 11(2) |
| Which model version runs, and is a switch logged? | An automatically updated model is an update you consent to | Art. 4(5) |
| Where must a person approve, and where is the pause button? | Limits damage and keeps the agent close to a tool | design choice |
| What was the intended purpose at delivery? | Reference point for what counts as a substantial modification | Art. 4(18), Art. 8(2) |
| What does the insurance cover, yours and the builder's? | Policies are still unclear about AI | ask in writing |
The questions about logs and updates matter most, because you cannot fix them afterwards. A log that does not exist cannot be disclosed. If you choose a standard platform, also ask what it costs to handle management after the build properly. If you are looking for an agency, our piece on choosing an AI agency has the broader selection questions. These seven now join them.
How does Oase Creative handle AI liability?
Since this spring we have run an agent system that helps run our own agency, and we build the same kind of systems for clients. Two choices from that work now line up with the directive, although we did not make them for legal reasons.
The first is the audit trail. Every risky action of our system is written down in advance: what is about to happen, and afterwards what the outcome was. That log sits apart from the platforms and their retention periods. Since early May that adds up to more than two thousand recorded actions, which we can read back for as long as we keep them. Our managed automation service page lists that log as a fixed part of management, alongside handling model updates.
The second is human approval. Everything our system sends out waits for a person, and that approval is tied to a real message and usable once. On 10 November there were 298 recorded approvals. At Pluis, where we automated the newsletter, every email also passes a person. You can read how that works in the Pluis case.
What that has to do with liability: these are exactly the two things you need after 9 December when someone asks what your agent did and who decided it. That is why managed automation is not an add-on after the build for us, but the part where accountability lives. If you have an agent built through AI automation or custom software, we discuss the questions in the table above at the start, not afterwards. And if you first want to know what AI automation actually is, that is the place to begin.
