Essay

Put your name on software and from December you are its manufacturer

On 15 October the Dutch House of Representatives passed, without debate, the law that makes software and AI a product. From 9 December, the app or assistant bearing your name makes you its manufacturer, even if someone else built it.

October 19, 2026 · Levy van Bremen · Lees in het Nederlands

On 15 October the Dutch House of Representatives passed a bill as a hamerstuk, the procedure for proposals it does not consider controversial: no debate and no vote. The bill implements a 2024 European directive on liability for defective products. The Senate still has to approve it, but the date is already fixed in European law: the new rules apply to products placed on the market or put into use from 9 December 2026.

The change comes down to one word. Software now counts as a product. The explanatory memorandum to the bill explicitly names applications and AI systems, as well as software you use over the internet as a service. Products carry strict liability: someone who suffers damage does not have to prove that the maker did anything wrong. A defect, damage and a causal link between them are enough.

Most companies will read this as a rule for software houses. I read it differently. The law ties liability to two things: whose name is on the software, and who can still update it. Anyone who offers an app, customer portal or AI assistant to customers under their own name therefore becomes a manufacturer, even if someone else built it. That role only ends when you can no longer update the software. For every software project, the key question becomes who keeps control of the updates.

Your name makes you the manufacturer

Under the bill, a manufacturer is not only whoever develops a product. It is also whoever presents themselves as the manufacturer by putting their name or brand on the product, and whoever develops a product for their own use. If you have an app built for your customers and your logo is on it, the law treats you as a manufacturer, alongside the party that built it.

That has three consequences. The injured party may choose whom to pursue, because you are jointly and severally liable: each of you can be held liable for the full damage. You cannot exclude that liability towards the injured party in your terms and conditions; the law explicitly forbids it. What you can arrange is what happens afterwards between you and your developer. Lawyers call this recourse: recovering costs from another party that is also liable.

There is a second route to becoming a manufacturer. Anyone who substantially modifies a product without the original manufacturer having control over that change, and then puts it into use, counts as a manufacturer. According to the memorandum, a change is substantial when it alters the risk. With AI this is not theoretical. If you take over a supplier's assistant and give it your own instructions, your own data or a different language model (the system that writes the answers), you need to ask whether you have changed the risk.

What you can update, you keep carrying

The second point is subtler, and in my view more important. Under the old rules, a product was judged at the moment it was put on the market. If a defect only arose later, it was generally not the manufacturer's problem. The new rules look at the moment the product leaves the manufacturer's control, as lawyers at Freshfields put it. For software you can update remotely, that moment never comes.

The memorandum is blunt about it. If the manufacturer controls the software or the updates, it cannot escape liability by arguing that the defect arose later. A lack of updates needed to maintain safety counts as a cause in itself. For AI, the fact that a system can keep learning or gain new features after delivery is also taken into account. A claim remains possible for up to ten years after the product came onto the market.

That strips the delivery date, the anchor of almost every software contract, of its meaning towards anyone who suffers damage.

I see in my own work how ordinary that updating is. In the first half of October I released two fixes for my learning app LerenLand: an animation that froze when the iPhone setting 'Reduce Motion' was on, and text that turned blurry on the iPhone. The first was in the App Store one day after I submitted it, the second two hours after Apple started reviewing it. For another app I switched on a technical change that Google Play requires before February 2027. None of the three added a feature. That is what software in use looks like. Under the new law, that very ability to update is why the responsibility carries on.

If you cannot show it, you are exposed

The third point is about evidence. A court can order the defendant to disclose relevant evidence. If that does not happen, the product is presumed defective. The same presumption applies when the product obviously malfunctions. In technically complex cases, and AI is the textbook example, the court can assume a defect and a causal link if the claimant shows that both are likely. Formally that is not a reversal of the burden of proof, the memorandum stresses. In practice it comes close, Freshfields writes.

For a company, this means your records are your defence. Which version was running on the day of the damage? What changed in the update before that? Which language model sat underneath, with which instructions? If you can still show that two years from now, you are in a strong position. If you have to reconstruct it from old emails with a developer who has since moved on, you are exposed.

The strongest counterargument

The strongest objection is that little changes for most companies. That is partly true. The law only protects natural persons. Property used exclusively for business and data used for professional purposes fall outside it. So does pure financial loss: an AI assistant that sends the wrong quote falls under your ordinary contract, not under this law. Information itself is not a product either. If you only supply other businesses and can only cost them money, you will see little legal difference.

But the line is closer than many companies think. Injury always counts, including to an employee of your business customer, and medically recognised psychological harm counts too. A phone or laptop that is also used privately is covered. So is data belonging to private individuals that is lost or corrupted. The 500 euro threshold for damage to property disappears, so small claims become possible as well. An app that controls a heating system, a lock or an alarm, or an AI assistant that cleans up customers' files, sits right in the middle of it.

Then there is insurance. The Dutch government advises companies to check whether their policy still provides enough cover. That advice deserves attention. In the United States there has been a standard clause since January that lets insurers keep injury and damage caused by AI out of the ordinary liability policy, according to the Cloud Security Alliance. If you become a manufacturer without knowing it, you only discover clauses like that with the first claim.

What to decide before 9 December

Go through every app, every customer portal and every AI assistant that reaches people under your name. Are you the manufacturer, because your name is on it, because you built it yourself or because you substantially changed someone else's system? Who can deliver updates, and for how long? What happens if that party stops? Does the contract with your developer say who reimburses whom? Can you show, day by day, which version was running? And what does your insurer say, in writing?

Underneath all this lies one choice. If you keep control of the updates yourself, you also keep the risk, and maintenance belongs in your budget as part of the product. If you leave that control with your developer, your name still makes you liable. In that case, put in writing that they will keep delivering updates, are insured and will reimburse you if the defect was theirs. What no longer works is having software built, putting your name on it and leaving maintenance to chance.

Sources

Is there work in your business that comes back every week? That is what I build software for.

Book a call →