A customer asks your assistant whether a fee applies. The assistant answers confidently, and the answer is wrong. Eleven months later a lawyer asks what that answer was checked against before it was sent.
Your company can produce the transcript. It can produce the model card, the risk assessment, the deployment approval and the monitoring dashboard. None of those answers the question that was asked.
That is the shape of AI liability in practice. The argument is rarely about whether the company owns the words, and a tribunal has already held a company to what its chatbot said. It is about what the company can show it did before the words went out. That artifact is not something the enterprise AI stack is ordinarily built to produce.
From December 9, 2026, in Europe, not producing it carries a named consequence. It lands first on whoever placed the software on the market, and reaches the company that deployed it through the contract and through the older route a tribunal has already used.
What AI Liability Means, and What Changes on December 9, 2026
AI liability is the legal exposure an organization carries for what its AI systems say and do. That includes statements made to customers that no person reviewed first. It runs through ordinary routes: contract, negligence, misrepresentation, consumer protection, and now product liability.
What changes on December 9, 2026 is evidentiary rather than doctrinal. On that date Member States must have transposed Directive (EU) 2024/2853, the recast product liability regime. Its Article 4 defines a product to include software, and Article 9 requires a defendant to disclose relevant evidence at its disposal, once a claimant in proceedings has shown the claim is plausible and asked for it. Article 10 then presumes the product defective where that disclosure does not come.
So the question stops being whether the company is at fault for the answer. It becomes whether the company can produce the evidence, and what the absence of that evidence is taken to mean.
The Directive Writes an Inference into Statute
Directive (EU) 2024/2853 was adopted on October 23, 2024 and entered into force on December 8, 2024. Article 22 requires Member States to bring the necessary laws into force by December 9, 2026. It applies to products placed on the market or put into service after that date.
Three provisions matter here, and they matter in sequence.
Article 4 settles what counts as a product. A product means "all movables." The definition "includes electricity, digital manufacturing files, raw materials and software." Software is named, not inferred.
Article 9 creates the obligation. A claimant in proceedings presents facts and evidence sufficient to support the plausibility of the claim, and asks for disclosure. The defendant is then required to disclose relevant evidence at its disposal, bounded by what is necessary and proportionate.
Article 10 supplies the consequence. The defectiveness of the product is presumed where "the defendant fails to disclose relevant evidence pursuant to Article 9(1)." A national court shall also presume defectiveness or the causal link where, despite disclosure under Article 9, the claimant faces excessive difficulties, in particular due to technical or scientific complexity. The claimant must still show the product is likely defective, and the defendant has the right to rebut these presumptions.
Read those three together and a practical rule falls out. Evidence you hold and will not produce counts against you. Evidence you never created cannot be produced. On our reading, Article 10(2)(a) draws no distinction between the two.
What Air Canada Could Not Point To
The pattern is older than the directive. In Moffatt v. Air Canada, 2024 BCCRT 149, decided on February 14, 2024, a British Columbia tribunal held an airline responsible for what its chatbot told a customer. It rejected the argument that the chatbot answered for itself. The tribunal found the airline did not take reasonable care to ensure its chatbot was accurate, as reported by the American Bar Association's Business Law Today and by McCarthy Tétrault.
It is a provincial tribunal decision, not binding precedent. The headline version, that a company answers for what its chatbot says, is the part already widely known. What the tribunal actually found in the Air Canada case is the part that bears on evidence, and it is taken up in the next section.
The Record the Governance File Does Not Contain
A well-run program produces a substantial file. Our own account of what an AI governance framework has to cover describes its parts: the system documented, validated, monitored and owned. Article 9 reaches that file, where the evidence is relevant and the disclosure is necessary and proportionate.
Every item in it describes the system. On our reading, none of it records what one customer-facing statement was measured against in the moment before it was released. That is not a gap better documentation would close. The statement did not exist when the file was compiled, so no entry in it could have been about this answer.
The conversation log has the same shape from the other direction. It holds what was said and when. It does not hold what the sentence was checked against, or what the check returned, or which version of the standard was then in force. The Directive asks only whether relevant evidence was disclosed, not who produced it. Neither of these records can be re-run, and on this article's reading reproducibility rather than provenance is what makes a record worth holding up.
The Strongest Objection
The best argument against all of this is that the directive does not reach the deploying organization at all.
It applies to economic operators in relation to products placed on the market or put into service. A bank running its own customer-service assistant for its own customers is most likely not the defendant under that regime. Its vendor is. The bank's own exposure runs through agency and misrepresentation, which is the route Moffatt took, and the product liability regime never enters.
That objection is substantially correct, and the scope question is unsettled. "Put into service" is the broader limb. Whether an organization putting its own assistant into service for its own customers falls inside it is a question for a lawyer, not a writer.
Our reading is that the two routes converge on one question. Moffatt turned on an airline that had taken no reasonable care to ensure its chatbot was accurate, and could point at nothing that had checked the answer. Article 10 writes that same inference into statute as a presumption. One is a tribunal reasoning from an absence, the other a legislature deciding in advance what an absence means.
And the deployer is reached either way. Where the vendor is the defendant, Article 9 runs to evidence at the vendor's disposal, which does not include the deploying company's own standard or the version of it in force that day. That record sits with the deployer, and the contract is how it gets asked for. Where the directive does not reach at all, the older route does, and it asks for the same thing.
Where the Record Has to Be Made
LuxeDetect™ is AI Brand Integrity Infrastructure: the independent, deterministic brand-integrity release gate across the enterprise AI stack. It evaluates AI-generated language against a benchmark the brand owns. It enforces tiered actions at the release gate, and logs the result with reason codes and the benchmark version.
The record is the point, and it has to be made by something other than the producer of the sentence. A producer grading its own sentence returns a judgment; an independent check against a named benchmark returns a rule that can be re-run. Governance that grades its own work has no outside reading to report. A standard applied later is applied after the customer has read the answer.
LuxeDetect™ does not provide legal advice, does not guarantee immunity from liability, and does not by itself establish regulatory or legal compliance.
The enterprise stack still lacks a consistent, independent control layer that verifies AI-generated language against the brand's own standard before release.
Three Questions to Ask of Your Own Evidence
Take one customer-facing AI statement from last month and ask three questions of it, in order. Each has a disclosable answer and a non-disclosable one, and the difference is the whole of what this article argues.
- What was this statement measured against? Disclosable: a named standard and the version in force that day. Not disclosable: the model's own training, which no one outside the company can inspect.
- What did the measurement return, and where is it written? A conclusion held in a reviewer's memory is not disclosable, and neither is a pass inferred from the absence of a complaint. A result logged with the benchmark version and the time is.
- Could the same check run today and return the same result? Disclosable: a rule that can be re-applied to the same output and the same benchmark. Not disclosable: a judgment that cannot be reproduced, which is an opinion with a timestamp.
Count the disclosable answers. Three of them is a record you can hand over. Fewer is the gap this article is about, and closing it is work you can start before any of this is tested.
Frequently Asked Questions
Who Is Liable for AI Mistakes?
The organization that deployed it answers for what it said. Moffatt v. Air Canada held an airline to what its chatbot told a customer, and rejected the argument that the chatbot answered for itself. That is one provincial tribunal decision rather than a general rule, and which review should have caught it is the harder question, still open.
What Is AI Liability?
AI liability is the exposure an organization carries for statements and decisions produced by its AI systems. It runs through contract, negligence, misrepresentation and consumer protection. From December 9, 2026 in the European Union it runs through the recast product liability regime as well. The novel part is evidentiary rather than doctrinal.
Does AI Liability Apply to Internal AI Tools, or Only Customer-Facing Ones?
Both, though the exposure differs in kind. An internal tool that misstates something creates a problem the organization can correct before anyone outside sees it. A customer-facing statement is irreversible at send. That is why the record of what it was measured against carries the weight.
What Evidence Would a Court Ask For?
Article 9 requires disclosure of relevant evidence at the defendant's disposal, limited to what is necessary and proportionate. On our reading that reaches the artifacts describing the system, and anything recording the decision at issue. A record of the second kind names the standard, the version in force, the result and the time, and it can be re-run against the same output.
Where to Start
Start with the gap rather than the regime. Run the three questions above against one statement your AI sent last month, and count the disclosable answers. Whether the directive reaches your organization directly is a question for counsel. Whether you could produce that record is a question for this quarter, and the work is the same either way.
Request early access to LuxeDetect™ for a record of what each output was measured against.
AI content risk is not solved after publication; it has to be controlled before release.
We are building AI Brand Integrity Infrastructure for luxury, and global enterprise brands. LuxeDetect™ evaluates every AI-generated output before it goes live. We measure alignment with brand tone, style, and standards, then enforce tiered actions at the release gate so off-brand content never reaches the public.
As AI spreads across CRM, CX, and marketing, manual review and generic safety filters cannot protect brand voice at scale. Our focus is to safeguard brand equity from AI generated content risks. We’ve been accepted into the Vector Institute Fastlane Build Phase. Stay tuned for launch updates.
