The EU’s attempt at a harmonised fault-liability regime for AI is over. The Commission withdrew the AI Liability Directive in 2025 after concluding there was no foreseeable agreement among stakeholders, and the Parliament’s legislative train records it as officially withdrawn in October 2025, with the notice published in the Official Journal. For financial services buyers the consequence is practical: no AI-specific liability statute is coming to fill the gaps in your vendor paper. Claims outside the product-liability route revert to national tort law, and what allocates AI risk now is the revised Product Liability Directive, the AI Act, and, where the supplier is an ICT provider, DORA’s contractual regime.
The most underestimated of these is the revised PLD. Directive (EU) 2024/2853 replaces the 1985 regime and applies to products placed on the market or put into service from 9 December 2026. It expressly includes software and AI systems within “product”, regardless of delivery model: cloud, SaaS, local installation, embedded use. A buyer can no longer assume that AI delivered as software sits outside strict product liability, and a vendor can no longer price a contract as if it did. The 2026 negotiation is about who carries which slice of a materially larger statutory exposure.
Indemnities: separate the buckets
Generic indemnity wording fails for AI services because the loss profiles differ too much to share one clause. Three buckets need drafting on their own terms:
- Model errors and performance failures. A specific indemnity for third-party claims arising from defective output, malfunction, or failure to conform to specification, particularly where the vendor controls training, updates, or deployment. Because the PLD now captures software and AI as products, draft this to sit in parallel with statutory remedies, not in place of them.
- IP infringement. An express indemnity covering claims that the model, training data, prompts, weights, outputs, or vendor-supplied components infringe copyright, database rights, patents, trademarks, or trade secrets. It should survive termination and cover defence costs, settlements, judgments, and replacement or mitigation costs. This matters most where the vendor builds on third-party models or open-source components it did not author.
- Regulatory and compliance claims. A separate liability bucket for AI Act breaches, data protection failures, confidentiality breaches, and security incidents. For mission-critical or customer-facing services, do not leave these inside the general cap; buyers routinely carve them out.
Audit rights you can actually use
Paper audit rights are common. Usable ones are rarer, because a clause drafted for financial audit does nothing when you need to inspect a model. For AI vendor deals, tie the audit right to documented controls: access to model documentation, training-data governance records, and technical documentation or system cards; the right to review security controls, logging, incident records, and change-management evidence; subcontractor and fourth-party transparency; and verification of deletion or return obligations at exit.
Vendors will try to confine audits to annual desktop reviews, business hours, or SOC report delivery. Financial services buyers should push for event-driven audits after incidents, material changes, or serious control failures, and reserve the right to perform or commission independent assessments where the vendor’s certifications are insufficient. Then make the right operable: notice periods, scope definition, confidentiality handling, a remediation timetable, and cost allocation, all agreed in advance. An audit clause you cannot invoke without a quarter of legal wrangling is decoration.
DORA terms for AI-enabled ICT services
Where the supplier is an ICT provider, DORA sets the contractual floor: clear and complete service descriptions, locations of service delivery and data processing, availability, authenticity, integrity and confidentiality requirements, access and audit rights, security and incident reporting, sub-outsourcing controls, business continuity and disaster recovery, assistance on termination, and cooperation with authorities.
For AI-enabled services, that baseline needs extension. The contract should specify who controls model updates and retraining; who owns logs, prompts, outputs, and derived data; how the supplier handles harmful hallucinations or erroneous automated decisions; how quickly it must notify you of model drift, security incidents, or material performance degradation; and whether you can suspend use pending remediation. Add step-in and suspension rights that trigger if the vendor changes the model, data sources, hosting region, or security architecture in a way that increases risk. Map every clause to operational risk and supervisory expectations rather than generic procurement language, because that mapping is what a supervisor will ask to see.
The negotiating table in 2026
The market positions are settled enough to plan around. Buyers push for uncapped or high-cap liability on data protection, confidentiality, security incidents, IP, gross negligence, fraud, and wilful misconduct, a specific AI indemnity for third-party harm caused by vendor defects, workable audit and remediation rights, and no broad disclaimer for AI outputs where the vendor controls the model or the prompt layer. Vendors push for caps tied to twelve months of fees, exclusion of consequential loss, user responsibility for prompts and downstream decisions, and audits limited to questionnaires and third-party reports.
The current legal environment strengthens the buyer’s hand on regulatory access, documentation, and security assurance, because both DORA and the PLD reward demonstrable control over the supplier stack. The drafting hygiene that makes it work is unglamorous: define “AI service”, “model”, “output”, “training data”, and “vendor materials” precisely; keep product-liability risk, service-failure risk, IP risk, and regulatory risk in separate buckets; require disclosure of sub-processors, model providers, and jurisdictional data locations; and align indemnity triggers with the actual use case, since decision support, automated decisioning, customer interaction, and surveillance carry different loss profiles. The era of treating these clauses as boilerplate ended when software became a product. Negotiate them as core commercial terms, because that is what they now are.
FAQ
Does the revised PLD apply to AI systems we already run in production?
The old 1985 regime continues to apply to products placed on the market or put into service before 9 December 2026; the new directive applies from that date onward. The practical consequence for contracting is that any deal signed or renewed now will almost certainly govern deployments that fall under the new regime. Draft against the new baseline rather than assuming the legacy rules will cover the life of the contract.
Our vendor insists on a liability cap of twelve months' fees. Is that market?
It is the standard vendor opening position, alongside exclusion of indirect loss and a disclaimer that outputs are probabilistic. Regulated buyers routinely carve out data protection, confidentiality, security incidents, IP infringement, gross negligence, fraud, and wilful misconduct from the general cap. The real negotiation is rarely about the cap number; it is about which loss categories sit outside it entirely.
The vendor will only offer SOC reports and certifications instead of audit rights. Is that enough?
For a regulated buyer of a material ICT service, usually not. DORA expects contractual access and audit rights, and certifications tell you a control existed at assessment time, not that it worked when your incident happened. Negotiate event-driven audit triggers after incidents, material changes, or serious control failures, plus the right to commission independent assessments where the vendor's own attestations fall short. Treat certifications as the floor, not the ceiling.