Who is liable when the software is the product

The question usually arrives as a worry from whoever built or bought something with AI inside it: does the new product liability regime make us answerable for what the system does. For anyone who bought a tool and uses it, the answer is no. Liability sits with whoever manufactured the product, and merely using someone else's software does not make you a manufacturer. And the words artificial intelligence do not appear in the provisions that carry that liability. They say software.

That is not the whole picture, though, and the line does not run where most people look for it. It runs neither between internal and external use nor at whether the software is called AI. It runs between using someone else's product and having built your own, and after that at two things: whether the product is still within the manufacturer's control, and whether anyone has substantially modified it.

The directive is settled, the Swedish implementation is not

Directive (EU) 2024/2853 on liability for defective products replaces the 1985 regime. Article 2(1) is short and decides the timing: "This Directive shall apply to products placed on the market or put into service after 9 December 2026." Article 22(1) required Member States to have the implementing provisions in force by the same day, and Article 21 keeps the old directive applicable to anything placed on the market before it.

Sweden is one of the Member States still finishing that work, and its draft is a useful worked example because it is recent and specific. The government decided the bill En ny produktansvarslag on 13 August 2026 and published it a week later. It is a lagrådsremiss, a draft referred to the Council on Legislation for scrutiny, so there is no adopted Swedish act yet, and the proposed entry into force is 9 December 2026, the day the 1992 act would be repealed. Quotations below are from the directive unless the Swedish bill is named.

The software is the product

Article 4(1) defines a product as "all movables, even if integrated into, or inter-connected with, another movable or an immovable; it includes electricity, digital manufacturing files, raw materials and software".

Standalone software is therefore a product. No machine is needed around it, no physical delivery, no hardware. An application is a product in the same way a drill is.

The words artificial intelligence are absent from the provisions quoted here, and AI is reached in two other ways. The first is that single word software in the definition. The second is a line in the defectiveness test. Among the circumstances Article 7(2) requires to be taken into account, point (c) is "the effect on the product of any ability to continue to learn or acquire new features after it is placed on the market or put into service".

The provisions never need to say AI, because they write in instead that the product goes on learning.

Recital 13 is blunter than any of the articles, and it is the passage to read if you think the delivery model saves anyone. Software is a product "irrespective of whether the software is stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model", and "a developer or producer of software, including AI system providers within the meaning of Regulation (EU) 2024/1689 of the European Parliament and of the Council, should be treated as a manufacturer". The same recital draws a line the other way: information is not a product, so the rules do not reach the content of digital files or the mere source code of software.

That point does something unusual. Product liability has always assumed the product is the same after delivery as it was at delivery, and that a defect therefore either existed or did not exist at a fixed moment. Point (c) accepts instead that the product changes itself, and puts that change among the things the assessment has to weigh.

A manufacturer is also whoever builds for their own use

Liability attaches to roles. First among them is the manufacturer of the defective product, and the Swedish bill spells out who that is: whoever manufactures, produces or develops a product, whoever has a product manufactured or designed, and whoever holds themselves out as the manufacturer by putting their name, trade mark or other distinguishing feature on it.

The verb develops carries more than it looks like it does. Nothing in the definition requires the product to be sold, licensed, or even to leave the organisation. Whoever builds software has developed a product.

The next step closes a door that would otherwise stand open. The exemption for a manufacturer or importer runs only where they show they did not place the product on the market or put it into service. Putting into service is defined as "the first use of a product in the Union in the course of a commercial activity, whether in return for payment or free of charge, in circumstances in which that product has not been placed on the market prior to its first use". The free of charge limb matters here: nothing has to be sold. Putting your own software into production in your own business is therefore itself a triggering act, and the exemption does not apply.

The list of liable roles does not stop at the manufacturer either. The manufacturer of a component is liable where the component was integrated or inter-connected within that component maker's control and the defect in the finished product is due to a defect in the component. Whoever sells a model, a library or an interface that is built into someone else's product stands in that position, which is neither the user's nor the finished product's manufacturer's. Importers, authorised representatives and, in the last resort, fulfilment service providers carry liability where the manufacturer is established outside the Union.

The difference between buying and building is therefore larger than the difference between using internally and selling. A company that buys a model and runs it in its own operations is using someone else's product. A company that develops the same function itself and puts it into service is the manufacturer of its own.

Who can claim, and for what

The role is one thing and the exposure another, and the second is narrower than the first. Article 5(1) requires Member States to ensure that "any natural person who suffers damage caused by a defective product (the 'injured person') is entitled to compensation". The injured person is a human being, and a company recovers nothing for its own loss. That does not mean the party across the table is always an individual. Article 5(2) lets a claim also be brought by "a person that succeeded, or was subrogated, to the right of the injured person", which is how an insurer normally arrives.

Article 6(1) then lists what counts. Death or personal injury, "including medically recognised damage to psychological health". Damage to or destruction of property, but excluding the defective product itself, a product damaged by a defective component the manufacturer integrated, and "property used exclusively for professional purposes". And "destruction or corruption of data that are not used for professional purposes".

That gives the manufacturer role a very definite shape for anyone who has built something for their own use. An internal system whose failure can only destroy the company's own working equipment and its own professional data carries no liability under this regime at all, however badly it goes. A system whose failure can hurt a person does. And people are present in more systems than one first assumes: the operator at the machine, the patient, the passenger, the visitor.

The Swedish bill draws the same two lines with different words. Its property head reaches damage to property that was not used exclusively for professional purposes, which leaves purely professional equipment outside, and its data head is framed as pure economic loss from the loss or corruption of data used exclusively for personal purposes. The directive asks whether the data are used professionally; the bill asks whether they were used exclusively personally. Two ways of bounding the same item.

Control does not end at delivery

The next question is when the clock stops. The Swedish bill defines a manufacturer's control as the control the manufacturer is taken to have by integrating, inter-connecting or supplying a component, by making changes to the product or consenting to someone else doing so, or by having the ability, alone or through another, to supply updates or upgrades to software.

The ability is enough. Not that updates are actually shipped, but that they can be. A cloud service that could be patched tomorrow is within the manufacturer's control today, and a product still within control has not passed the moment that would otherwise cap liability.

It shows most clearly in the exemptions. Article 11(2) removes the escape route for a defect that arose after release where the defect is due to any of four things within the manufacturer's control: "a related service", "software, including software updates or upgrades", "a lack of software updates or upgrades necessary to maintain safety", and "a substantial modification of the product".

Point (c) is the one worth reading twice. Not supplying a safety update is itself a route to liability, provided the ability to supply it was within the manufacturer's control. The Swedish bill reaches the same place by a different arrangement: its corresponding provision has two points rather than four, and the missing update does not appear as a point of its own. That it is caught anyway, because control under the bill persists for as long as the ability to supply updates exists, is a reading rather than something the wording states. Anyone building an argument on the directive's four points should know the Swedish wording counts differently.

Whoever modifies changes places with the manufacturer

The provision that moves liability between companies is Article 8(2): "Any natural or legal person that substantially modifies a product outside the manufacturer's control and thereafter makes it available on the market or puts it into service shall be considered to be a manufacturer of that product for the purposes of paragraph 1."

Two conditions have to be met at once, and the second is easily forgotten. The modification must be made outside the manufacturer's control, and the product must then be made available on the market or put into service. Both expressions are defined. Putting into service presupposes that the product had not been placed on the market beforehand, so modifying something you bought and keeping it inside the building does not meet that limb. Software you developed yourself and first put into production does.

What counts as substantial is decided in two steps. Where Union or national product safety rules treat a modification as substantial, that settles it. Where those rules set no threshold, Article 4(18) requires two things together: that the change "changes the product's original performance, purpose or type, without that change having been foreseen in the manufacturer's initial risk assessment", and that it "changes the nature of the hazard, creates a new hazard or increases the level of risk".

Whoever modifies substantially and then passes the product on stands in the manufacturer's place.

The second limb therefore hangs on a risk assessment somebody else wrote at the time of manufacture. If that assessment is broad and documented, a great deal falls inside what was foreseen. If it is narrow or absent, the threshold drops for everyone who touches the product afterwards. There is relief for whoever ends up in the role, and it is in the directive rather than in any national addition. Article 11(1)(g) exempts a person that modifies a product where "the defectiveness that caused the damage is related to a part of the product not affected by the modification". The Swedish bill carries it over unchanged.

The objection that carries weight

There is a countervailing case for doing nothing at all, and it should be put plainly.

Article 2(1) reaches only products placed on the market or put into service after 9 December 2026, and Article 21 leaves everything older under the 1985 regime. An existing portfolio does not move across. In Sweden the implementing act is still a draft: the Council on Legislation has to give its opinion, a government bill has to be written, and parliament has to decide. A reader with a shipped portfolio can fairly ask what the hurry is, and for anyone planning neither to place anything new on the market nor to put anything new into service, the answer is that there is none.

Three things argue against postponing it for those it does concern. The load-bearing date sits in the directive rather than in any national calendar, so it does not move when a parliament runs short of time. The substantial modification test rests on the breadth of the original risk assessment, which means the quality of an assessment written today decides how much room you and your customers have to change the product later. And the question that governs all the others, which of your software you built and which you bought, is an inventory question rather than a legal one.

The two questions that decide whether this is your problem

Before those two lies one that decides whether either matters: can this system's failure hurt a person, or only your own working equipment and your own professional data. If it is the latter, there is no liability under this regime to carry.

The first question is whether you built the software or bought it. If you are using someone else's product you are not its manufacturer, and liability follows whoever is. If you developed it yourself you are the manufacturer even if it is never sold, and the first time it goes into production in your business is the act that closes the exemption. If you build on someone else's software and pass the result on, Article 8(2) governs, not your own view of how large the change was.

The second question is how broadly the original risk assessment was written. It sets the threshold in both directions. If you are the manufacturer, a broad and documented assessment protects you against a customer's adaptations counting as unforeseen. If you are the one adapting, the same document decides whether your change falls inside what was foreseen or lifts you into the manufacturer's role. Two companies making exactly the same technical change can therefore get different answers, depending on what the supplier wrote down before the product left the building.

There is a third question that is not about the law but about your own list: which of your systems you built, which you bought, which you have modified and by how much. Without that list neither of the first two can be answered. How it is built and who owns it afterwards is set out under AI governance and compliance. Who makes the decisions about those systems once they are listed is covered in our analysis of who owns AI decisions, and the calendar for the AI Act, a separate and already adopted rulebook, is on our EU AI Act page.