Short answer. Liability today splits across three layers, and no single law draws the line. The bank, as deployer, stays the party a customer can sue under existing consumer credit and civil law, and it carries EU AI Act Article 26 deployer obligations regardless of who built the model. The AI vendor takes on new strict liability exposure once the revised Product Liability Directive, (EU) 2024/2853, applies to products placed on the market from 9 December 2026, treating a defective AI model the same as a defective physical product. The dedicated EU AI Liability Directive that would have unified this picture was withdrawn by the European Commission in 2025, so banks have to build liability into contracts and governance now, not wait for one law to settle it.
Three scenarios show how the split actually plays out. In the first, a credit-scoring model built by a vendor and operated by the bank declines a loan application. Under national consumer-credit law and GDPR, the customer’s claim lands on the bank, not the vendor, because the bank made the decision and holds the customer relationship. Whether the bank later recovers damages from the vendor depends entirely on the indemnification clause in the vendor contract, not on any AI-specific statute.
In the second, an underwriting model systematically mispriced a policy segment because of a data defect in the vendor’s training pipeline. From 9 December 2026, the customer or the bank can pursue the vendor directly under the Product Liability Directive’s strict-liability regime for defective products, which now explicitly covers standalone software and AI systems. The claimant no longer has to prove negligence, only that the output was defective and caused damage, a materially lower bar than today’s contract-law route.
The situations that raise this question most often in a bank or insurer include:
Ableneo shipped 34 production AI projects across financial services and other regulated sectors in 2025, at roughly an 80% pilot-to-production rate. Each carries a documented decision owner and override path, because liability follows the party who can be shown to have controlled the decision, not the party who wrote the model.
For banks and insurers in Slovakia, Czechia, and Austria, credit scoring and life or health insurance risk assessment and pricing sit in Annex III of the EU AI Act as high-risk use cases. The Digital Omnibus deferred the compliance deadline for these standalone Annex III systems from 2 August 2026 to 2 December 2027, but the underlying obligations, human oversight under Article 14, deployer duties under Article 26, and a fundamental rights impact assessment before go-live, are unchanged. A deferred deadline is not a deferred liability question. A bank that puts an AI credit model live in 2026 already carries civil liability exposure under national law even though its AI Act compliance clock has more runway.
DORA adds a second layer. If the AI system counts as a critical ICT function, its failure or wrong output is a reportable incident, and the DORA audit trail becomes the evidence base a court or regulator uses to establish who knew what, and when. A bank that cannot show who approved the model, who could override it, and what the vendor contract says about liability walks into a DORA finding and an open liability question at the same time.
The EU AI Liability Directive was withdrawn by the European Commission in 2025, leaving no single EU civil liability law for AI.
The European Commission proposed the AI Liability Directive in 2022 to make it easier for a harmed party to get compensation from an AI provider or deployer, including a rebuttable presumption of causality in complex cases. The Commission withdrew the proposal in 2025 after member states could not agree on scope, leaving no dedicated EU civil liability regime for AI. This is why the current picture rests on a patchwork of national civil law, the EU AI Act’s regulatory obligations, which are not the same thing as civil liability, and now the Product Liability Directive, rather than one clean instrument.
Directive (EU) 2024/2853 entered into force in December 2024, and EU member states have until 9 December 2026 to transpose it into national law before it applies to products placed on the market after that date. It redefines “product” to explicitly cover software, including AI systems, and it eases the claimant’s burden of proof by letting a court presume defectiveness or causation when technical complexity makes it excessively difficult to prove. For a bank buying an AI credit or underwriting model from a vendor, this means the vendor now carries direct strict-liability exposure to end customers and to the bank itself, exposure that did not exist under the previous product liability regime built for physical goods in 1985.
Both, and the split is contractual, not automatic. As deployer, the bank remains liable for how it uses the system, input data quality, human oversight, and informing the affected individual, under EU AI Act Article 26, and it is the bank the customer sues first because it is the party the customer has a relationship with. Whether the bank then recovers damages from the vendor depends on the liability and indemnification clauses negotiated into the AI vendor contract, plus, from December 2026, the vendor’s own strict-liability exposure if the model itself was defective. A bank that signs an AI vendor contract without a specific liability allocation clause is choosing, by default, to carry the full exposure alone.
GDPR Article 22 gives an individual the right not to be subject to a purely automated decision with legal or similarly significant effects, and the right to a human review of that specific decision. That is a procedural right about how a decision was reached, not a statement of who pays when the decision was wrong. Liability under the EU AI Act, the Product Liability Directive, and national civil law answers a different question: who bears the financial and legal consequence of the error. A bank needs both, a GDPR-compliant review path and a liability allocation that survives a court case.
Three actions do not wait for further legislation. First, put a named, trained human oversight role on every high-risk AI decision, documented under EU AI Act Article 14, so accountability traces to a person rather than a model. Second, renegotiate AI vendor contracts before December 2026 to explicitly allocate liability for model defects, data quality, and output errors, rather than relying on generic software-license limitation-of-liability clauses written before the Product Liability Directive existed. Third, keep the DORA audit trail and the AI Act documentation in the same system of record, because the moment a claim or audit lands, the bank needs to show who approved the model, who could have overridden it, and what the contract with the vendor said about who carries the loss.
Ableneo treats liability allocation as a governance deliverable, not a legal afterthought bolted onto the contract after signature. Across the 34 production AI systems Ableneo shipped in 2025 for financial services and insurance clients, at roughly an 80% pilot-to-production rate, human oversight roles and override paths were defined and documented before go-live, the same documentation a bank now needs to answer a liability question and clear a DORA audit in the same motion. Ableneo’s work on human oversight design for regulated AI systems shows the pattern that holds across FS&I clients: liability clarity comes from designing the accountable human role first, then building the model around it, not the reverse.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.