Last updated October 1, 2026

Author: Gerben Nerinckx, Commercial Lawyer & Fractional General Counsel

It could happen to anyone: you build the perfect point solution, launch an app or offer software as a SaaS product, with or without an AI model under the hood, and one day things go wrong. Your tool gives bad advice, gets a calculation wrong or makes a batch of data disappear, and your customer, or someone further down the chain, suffers a loss. Should this keep you up at night as a developer? It would do you credit, but don’t overdo it. Belgian liability and contract law puts a few hurdles in the victim’s path before they can come knocking on your door… although those hurdles are about to get a little lower…

Software can’t be sued. You can…

Software, a SaaS instance or an AI model has no legal personality. There is talk of changing that, but today the software itself can’t commit a fault for which IT would be liable, nor can it be dragged into court by the scruff of its proverbial bytes. Whoever suffers a loss from using your software therefore has to come knocking on your door, as the “manufacturer” of that software. And that’s where the real work starts.

Three hurdles, and the claimant has a hard time clearing them…

The road to compensation is littered with three obstacles: proving a fault, proving damage, and proving a link between the two. If the injured party is your contractual counterparty, your fault as the manufacturer will usually consist of breaching an obligation from your contract (think of a spec warranty your software didn’t meet, a promise in your privacy or security policy that was worded just that bit too loosely, or an overenthusiastic marketing claim that promised your customer the moon and ended up becoming part of your contract), or of breaching a legal requirement (think of violating certain AI Act obligations on how you train your AI system). If the injured party sits further down the chain, they will usually find your fault in that same breach of the law, or accuse you of not acting the way a careful software developer would.

So, we already have an idea about the fault, and for the sake of argument, let’s assume there is damage. But the injured party must not just claim the fault and the damage, they must actually prove them. On top of that, they must establish the link between the fault and the damage (again, not just claim it). In the software world, that’s not as easy as it sounds.

The reason is what, in lawyer-geek speak, is called “information asymmetry.” You, as the manufacturer of the software, know, or at least have an idea of, HOW your software was built and trained, which QA procedures were followed, etc. And if you’re lucky (probably less so when it comes down to your AI system), you also know how and why your software ‘decided’ to go off the rails. The victim, on the other hand, has no access to any of that information, and can often only assume or allege… and assumptions are not evidence. So you, as the ‘manufacturer’ of the software, walk away scot-free,… most likely.

The causal link between a fault and the damage is often even harder to prove. With AI systems, you quickly run into the so-called black box problem: often even the manufacturer can’t explain (anymore) how the model got from that one prompt to that one wrong answer. If you, as the manufacturer, can’t, what about the outsider?

Take the following example. Say you develop software that checks labels on packaging for (the absence of) nutritional information. The software ‘looks at’ a label, gives it the green light, and a week later several consumers end up in a hospital bed because your software had its own ideas about gluten intolerance. Or you sell a SaaS network security tool and, despite that tool, all the data of the local amateur soccer club gets wiped by a hacker who surfed right through the holes in your security net. Good luck to the victim in proving (and not merely claiming) that you, as the manufacturer, made a mistake in developing the software THAT CAUSED the damage.

December 9, 2026: the bar gets lower…

By that date, Belgium, like every other EU member state, must have transposed the new EU Product Liability Directive (Directive (EU) 2024/2853) into national law.

Until now, software has fallen outside the product liability rules, because it wasn’t considered a “product.” From that date on however, the tables turn: software, AI systems included, becomes a “product,” regardless of how it is distributed (license or SaaS). And individuals who suffer damage caused by a defective “product” (your software) are entitled to compensation.

On top of that, more types of damage will qualify for compensation: not just personal injury, but also psychological harm, property damage and the loss or corruption of data.

But the biggest change is in the liability itself. In principle, the injured party still has to prove that the product is defective (read: doesn’t provide the safety a person is entitled to expect), that there is damage, and that there is a direct link between that defect and that damage. But… from now on, they get a helping hand. If the claimant makes their claim plausible (a much lower bar than proving it…), the court can order you, as the manufacturer of the software, to provide copies of your documentation, logs, test results, QA procedures, etc. (to help the injured party overcome the information asymmetry we talked about before). If you don’t do it (or can’t, because you were too sloppy in keeping that documentation), … your product is presumed to be defective. And if it is technically too complex to conclusively prove the link between the defect and the damage, the court may settle for “likely.” From then on, it’s enough for the victim to show that it is “likely” that the product is defective and/or that there is a causal link between the defect and the damage.

This gets particularly interesting with AI systems: could it be ‘likely’ that the AI system hallucinated, generated the wrong output, and that this is linked to the damage the victim suffered? Never heard of that happening? The black box that protects you today no longer works in your favor…

And you thought a big disclaimer (‘my software can hallucinate and do crazy things…, so you’d better check everything yourself’) would save you? How about this: “warnings or other information provided with a product cannot be considered sufficient to make an otherwise defective product safe, since defectiveness should be determined by reference to the safety that the public at large is entitled to expect.” With our examples in mind, can’t you expect that software intended to check labels for consistency would have to be safe enough to say ‘stop’ when a label mentions nutritional information incorrectly, or for network security software to actually keep hackers from strolling all too easily into your customers’ systems? Who’s to say? The courts will have to figure that out over the coming years.

Time for some spring cleaning in your contracts and your insurance policy

I wrote earlier about the importance of indemnities (in plain English: your vendor’s promise to cover your losses) in your contracts with AI vendors (I indemnify, You indemnify, He/She indemnifies…and why Your AI vendor should as well). Now there’s a new dimension: as a software manufacturer, you can’t limit your liability toward the injured party under the Product Liability Directive, but the vendor of the AI model baked into your software CAN limit its liability toward you. And… poof… by a sleight of hand, you’re liable toward your customers, but your vendor isn’t liable toward you.

So keep an eye on this before you sign your contracts with your vendor. And maybe don’t outsource the review of those contracts too casually to your AI buddy. Otherwise you risk ending up holding the bag: liable toward your customer, with no recourse against whoever supplied the underlying AI model. Will your insurer step in? You might want to take a quick look at your policy too, while you’re at it…

General information on Directive (EU) 2024/2853 on liability for defective products, not legal advice on your particular situation.