The Product Nobody Announced

From 9 December 2026, software — and therefore AI — is a product under Croatian civil law, with strict liability attached. There was no new act and no launch event. It arrived as an amendment to the Civil Obligations Act, filed alongside the right to have your washing machine repaired.

Share

Some legislation arrives with a name everyone learns. The AI Act had summits, delegated acts, a countdown and an entire consulting industry built around its calendar. Other legislation arrives the way most law actually does: as an amendment to something older, published on a Monday at the end of June, in a batch.

On 29 June 2026, Narodne novine (Croatia's Official Gazzete) published amendments to the Zakon o obveznim odnosima (Croatia's Civil Obligations Act), the statute that governs contracts, damages and most of what happens when one party owes another something. The first part of the package implements the EU's right-to-repair rules for consumer contracts. The second part rewrites the Act's section on liability for defective products to transpose Directive (EU) 2024/2853. It applies to products placed on the market or put into service from 9 December 2026.

From that date, under Croatian civil law, software is a product. Article 1072.a says so in a list that runs from electricity and raw materials to "datoteke za digitalnu proizvodnju … i softver". The words "artificial intelligence" appear nowhere in the section, and they do not need to. An AI system is software. Software is now a product. A defective product makes the economic operator liable for the damage it causes bez obzira na krivnju - without regard to fault (Art. 1073(1)).

That is ten weeks from now, and it was filed next to the washing machine.

Why this matters more than it sounds

For most of the last three years, the conversation about who pays when an AI system causes harm ran on two tracks. One was the AI Act: a conformity regime about what providers must do before and after putting a system on the market. It is enforced by regulators and it produces fines. It does not, by itself, put money in the hands of the person who was harmed. The other track was the proposed AI Liability Directive, which would have eased the path for victims bringing fault-based claims. The Commission announced its withdrawal in the 2025 work programme.

What remained was the product liability regime - older, less glamorous, and built on a different premise. It does not ask whether anyone behaved badly. It asks whether the product was defective, whether there was damage, and whether one caused the other. If the answers are yes, someone pays. With the AI Liability Directive gone, this is now the main instrument in EU civil law answering the question the AI Act leaves open: and the person who got hurt?

Croatia has answered it inside the ZOO.

What changed, in the parts that touch AI

Software is in the definition - and so is the service it depends on. Alongside software, Article 1072.a introduces the povezana usluga, a related service: a digital service built into or connected with a product so that its absence would prevent the product from performing one or more of its functions. A cloud inference endpoint that a device cannot work without is the obvious candidate. The definition of manufacturer is correspondingly broad. It covers anyone who develops or produces a product, anyone who puts their name or mark on it, and (a detail worth noticing) anyone who develops or produces it for their own use.

The product is allowed to change after sale, and the liability follows it. The defectiveness test (Art. 1075) still asks whether the product provides the safety a person is entitled to expect, or that the law requires. The list of circumstances the court must weigh now expressly includes the effect of the product's ability to continue learning or acquire new features after it is placed on the market; the reasonably foreseeable effect of other products it will be used with, including through interconnection; cybersecurity requirements relevant to safety; and - crucially - not only the moment the product was placed on the market but, where the manufacturer keeps control after that, the moment it leaves the manufacturer's control. "Control" is defined to include supplying software updates and upgrades, directly or through a third party, and approving someone else's. A system that was safe on the day it shipped and became unsafe after a model update has not escaped the regime by changing. The change is part of the product.

Not updating can cost you your best defence. Article 1078 keeps the traditional defences, including the argument that the defect probably did not exist when the product was placed on the market. But paragraph 2 switches that particular defence off where the product remains under the manufacturer's control and the defect was caused by a related service; by software, including its updates or upgrades; by the absence of software updates or upgrades needed to maintain safety; or by a substantial modification. For anyone selling a connected product with a model inside it, patching has just become a liability decision rather than a matter of good practice. The development-risk defence - that the objective state of scientific and technical knowledge did not allow the defect to be discovered - survives (Art. 1078(1)(5)), and it now expressly covers the whole period during which the product remained under the manufacturer's control, not only the day of first sale.

Damage includes data. Covered damage now includes death, bodily injury and damage to health - including medically recognised harm to psychological health - damage to other property, and the destruction or corruption of data not used for professional purposes (Art. 1073(2)). This is the part agent builders should read twice. This site has written before about agents with file-system access and very little between them and a delete command. From 9 December, an agent that wipes a consumer's personal files is not only an embarrassing incident report. It is a potential strict-liability claim against whoever placed that software on the market.

The black box has a procedural answer. The problem that made AI liability look impossible was always evidence: the claimant cannot see inside the system, and the defendant has no reason to open it. The new rules deal with this directly. A claimant who makes the claim plausible can ask the court to order the defendant to disclose relevant evidence (Art. 1074.a(1)). The court weighs proportionality, cost and trade secrets. It can also order the evidence to be presented u lako dostupnom i razumljivom obliku, in an easily accessible and understandable form (Art. 1074.a(4)). That is, in effect, explainability by court order. A defendant who fails to disclose faces a presumption that the product was defective (Art. 1074(2)(1)). Defectiveness is also presumed where the product breaches mandatory safety requirements, or where the damage came from an obvious malfunction in reasonably foreseeable use. And where technical or scientific complexity makes proof excessively difficult, a claimant who shows that defectiveness or causation is likely gets the benefit of a presumption (Art. 1074(4)). All of these presumptions are rebuttable. The burden has not been reversed. It has been tilted, and the tilt is steepest exactly where AI systems are most opaque.

Who is liable goes well beyond "the developer". The chain of liable operators (Art. 1076) runs from the manufacturer to the manufacturer of a defective component. For manufacturers established outside the EU, it also reaches the importer, the authorised representative and, failing both, the fulfilment service provider. Anyone who substantially modifies a product outside the manufacturer's control and then makes it available is liable as well. Distributors - and, under the conditions of Article 6(3) of the Digital Services Act, online platforms - become liable if they cannot name a responsible operator within a month of being asked. Liability among them is joint and several (Art. 1077).

The two provisions nobody will read until they need them

Substantial modification is defined by your own risk assessment. Where no product-safety rule sets a threshold, a modification is substantial if it changes the product's original characteristics, purpose or type in a way not foreseen by the manufacturer's initial risk assessment, and changes the nature of the hazard, creates a new one or increases the level of risk (Art. 1072.a(19)(b)). For a company that takes a foundation model, fine-tunes it and ships it inside its own product, that sentence decides whether it is a customer of someone else's product or the manufacturer of its own. It also means the upstream provider's risk assessment has quietly become a legal document for everyone downstream.

Recourse against small software suppliers can disappear entirely. Article 1077.a - a provision with no counterpart before this amendment - deals with the manufacturer who integrates someone else's software as a component and then finds that the component caused the damage. Ordinarily that manufacturer pays the injured party and then turns upstream. Here, in the case of a software component made by a micro or small enterprise, that turn upstream can be closed off: the directive behind the provision was written specifically to let small software makers agree with their integrators that no recourse will be sought, and the recital says why: to keep liability exposure from pricing very small firms out of supplying components at all.

Two practical consequences follow, and neither depends on the precise mechanics. For Croatia's software sector, overwhelmingly made up of small companies, this is real protection and worth knowing about before signing anything. For the larger firm that integrates their code, it is risk that stops at its own balance sheet - carried alone unless it is priced, insured or contracted around before December. Anyone on either side of such a contract should read the exact wording of Article 1077.a rather than a description of it, including this one, because the wording is where it gets interesting. The Croatian text lists the two conditions - a micro or small supplier, and a contractual waiver - as separate "cases", with no "and" between them. The directive requires both. Read literally, the Croatian version bars recourse against every small software supplier automatically; read in conformity with the directive, as a Croatian court is bound to attempt, it bars recourse only where a small supplier has also secured a waiver. That gap decides who pays, and it is not a question to discover in a pleading.

Two further provisions close the obvious exits. Liability to the injured party cannot be excluded or limited in advance by contract, and any clause attempting it is void (Art. 1079). The terms-of-service disclaimer that every software product carries is, for this category of harm, decorative. And the new regime does not displace the rest of Croatian liability law: rules on dangerous things and dangerous activities, on contractual liability and on non-contractual liability continue to apply alongside it (Art. 1073(7)). A claimant can plead both.

The time limits are generous to claimants. There are three years from the moment the injured party learned, or should have learned, of the damage, the defect and the operator's identity. The right itself is extinguished ten years after the product was placed on the market - a clock that restarts after a substantial modification - and twenty-five years for bodily injuries that remained latent (Art. 1080).

Why the placement matters

Transposing a directive by amending a general civil code is a perfectly respectable choice. The ZOO is where Croatian lawyers already look for damages, and a separate statute would have created a second place to check. But the choice has a side effect. The most consequential AI liability rule in Croatian law has no name of its own, no dedicated guidance and no countdown. It sits in a bundle whose headline was consumer repairs.

The practical consequence falls on the companies least likely to notice. A large vendor has product counsel who read the Official Gazzete. A Croatian startup that wraps a model in a consumer app has, at best, a compliance checklist written for the AI Act - a regime whose high-risk obligations have been pushed back to December 2027 and beyond. It is entirely possible to be reasonably relaxed about AI Act deadlines this year and exposed to strict civil liability for the same product from December.

What a sensible company does before 9 December

None of this requires waiting for a court to interpret it. The date and the mechanics are already fixed.

  1. Inventory what will be placed on the market or put into service after 9 December. The regime applies by date of placing, not date of development. A major release scheduled for January is covered.
  2. Treat the update policy as a liability document. If a missing safety update removes a core defence, then how long updates are supplied, and how quickly, is no longer only an engineering decision.
  3. Keep the records a court could order you to disclose - in a form a court could read. The choice is between disclosing organised evidence of a reasoned process and disclosing an absence that triggers a presumption.
  4. Decide deliberately whether you are a manufacturer. Fine-tuning, integration and rebranding can amount to substantial modification, measured against someone else's risk assessment. Better settled in a contract with the upstream provider than discovered in a pleading.
  5. Re-read the supply contracts. If you integrate software from a micro or small supplier, recourse may not be there when you need it - establish now whether it is, and price accordingly. If you are that small supplier, check whether a customer has already asked you to waive something, or has quietly assumed you did.
  6. Look at the consumer-facing agents first. Personal data damage is covered, disclaimers are void, and consumers are exactly the claimants the regime was built for.

There is one more thing worth saying about this, and it does not fit the house pessimism. This site keeps a running account of the ways responsibility for what AI systems do fails to land on anyone: tools that find nothing to grip, documents that stand in for controls, registers that record existence and nothing else. From 9 December, in one small jurisdiction, a chunk of it lands. Strict liability, no fault to prove, presumptions that switch on precisely where the system is most opaque, disclaimers that are void, and a court empowered to order the evidence produced in a form a person can read. Whatever else is true of the accountability sink, this is a drain somebody closed - quietly, without a name, in a bundle about washing machines.

The Clause did not announce itself. It rarely does. It arrived as ten articles in the middle of an amending act, and it will be discovered, as these things usually are, by the first claimant's lawyer who reads Article 1072.a more carefully than the defendant did. The AI Act asked the industry what it intended to build. The ZOO, from December, will ask what happened afterwards; and it will not care very much what anyone intended.