Civil liability exposure for artificial intelligence deployments in the European Union is no longer a theoretical concern. The combination of the EU AI Liability Directive proposal (COM(2022) 496), the reformed Product Liability Directive (Directive (EU) 2024/2853), and the binding obligations already in force under the EU AI Act creates a layered legal framework that directly affects how regulated organisations in the public sector, finance, healthcare, and legal services must structure their AI infrastructure. The central insight for decision-makers is this: where your AI runs determines what evidence you can produce, and what evidence you can produce determines whether you can defend a civil claim.
How the AI Liability Directive’s Causality Presumption Works in Practice
The causality presumption under COM(2022) 496 is the mechanism that shifts evidentiary burden from claimants to operators of high-risk AI systems. Understanding its precise operation is essential for any CISO or compliance officer.
Under the proposed directive, a national court may presume that a defendant’s non-compliance with an applicable AI Act duty caused the harm alleged, provided the claimant can show a plausible link between that non-compliance and the outcome. This is a rebuttable presumption, not strict liability. The operator can defeat it, but only by producing affirmative evidence that the system operated correctly, that the relevant duty was in fact met, or that the harm had an independent cause. For high-risk AI systems as defined in Annex III of the EU AI Act (credit scoring, employment screening, critical infrastructure management, and several healthcare applications among them), the threshold for triggering the presumption is relatively low. A claimant need not reconstruct the internal logic of the model; they need only point to a breach of a logged obligation and a harm that followed.
For a sovereign on-premises deployer, rebutting this presumption is materially easier than for an organisation running the same model via a public cloud API. The operator that controls its own infrastructure holds every log, every access record, and every inference trace. The operator using an external API depends on a third party to provide those records, on contractual timelines and data retention policies it did not set, and potentially across a jurisdictional boundary.
The PLD Recast and the Manufacturer Reclassification Risk
Directive (EU) 2024/2853 extended product liability to digital products, including AI systems, and introduced the concept of substantial modification as the trigger for reclassifying an operator as a manufacturer or quasi-manufacturer.
An organisation that deploys an off-the-shelf AI model, configuring it through a standard API without altering its weights, training data, or fundamental architecture, generally remains a user or deployer for PLD purposes. However, organisations that fine-tune an open-source model such as Mistral or Llama on their own sovereign infrastructure face a different analysis. If the fine-tuning materially changes the model’s outputs, extends it to a new purpose category, or alters its risk profile in a way the original developer did not anticipate or certify, the organisation may be reclassified as a manufacturer. This carries product liability obligations: conformity assessment, technical documentation, and potentially strict liability for defects in the modified product.
The practical line runs between configuration (adjusting system prompts, setting retrieval parameters, integrating the model with internal data sources via retrieval-augmented generation) and modification (retraining on new corpora, changing model weights, creating a derivative model for a categorically different task). Organisations operating sovereign AI infrastructure should document this distinction explicitly in their technical files, specifying what the original model does, what changes were made, and why those changes do not constitute a substantial modification under Article 7 of Directive (EU) 2024/2853.
Sovereign Infrastructure as a Liability Reduction Strategy
Running a high-risk AI system on sovereign on-premises infrastructure, with full logging, human oversight controls enforced at the infrastructure level, and no data leaving the organisation’s jurisdiction, reduces civil liability exposure across several dimensions simultaneously.
| Liability dimension | Public cloud AI API | Sovereign on-premises deployment |
|---|---|---|
| Access to inference logs for rebuttal | Dependent on vendor retention policy and contract terms; may be limited or delayed | Complete, real-time, operator-controlled; immediately available for legal proceedings |
| Jurisdictional exposure (CLOUD Act, FISA 702) | US-controlled infrastructure creates potential third-country disclosure obligations | Eliminated when infrastructure is under exclusive EU or Swiss jurisdiction |
| Human oversight enforcement (AI Act Article 14) | Override mechanisms may be outside operator control | Operator defines and enforces override logic directly at the system level |
| PLD manufacturer reclassification risk | Lower if using model as-is, but operator bears gap when vendor is non-EU | Controllable through documented fine-tuning policy and technical file |
| GDPR Article 33 breach response speed | Depends on vendor incident notification; 72-hour clock may start before operator is informed | Operator detects and responds directly; 72-hour clock fully under internal control |
According to IBM’s Cost of a Data Breach Report 2024, the average total cost of a data breach reached USD 4.88 million, the highest figure recorded in the report’s history. Organisations with mature incident response capabilities consistently report lower breach costs, and the ability to reconstruct an incident from local logs is a core component of that capability.
Documentation and Audit Trails: Meeting Article 12, Article 14, and the Evidentiary Burden
The EU AI Act’s Article 12 requires that high-risk AI systems automatically generate logs enabling ex post reconstruction of the system’s operation over a period appropriate to the intended purpose, with a minimum retention period specified by implementing acts. Article 14 requires that human oversight measures be designed into the system such that natural persons can understand, intervene in, and override the system’s outputs. Both provisions feed directly into the AI Liability Directive’s evidentiary framework.
A sovereign deployer maintaining compliance with both provisions should structure its documentation around five categories: (1) the technical log record, capturing every inference, input hash, output, confidence score, and the identity of any human reviewer who acted on the output; (2) the risk management file under AI Act Article 9, documenting how risks were identified, assessed, and mitigated throughout the system lifecycle; (3) the conformity record, confirming that the system as deployed matches the version assessed in the technical file; (4) the human oversight protocol, specifying which decisions require human confirmation before acting and how overrides are logged; and (5) the incident register, recording every anomaly, near-miss, and actual adverse outcome together with the corrective action taken.
ENISA’s AI cybersecurity guidelines make clear that logging is not only a compliance obligation but a security control: systems without adequate logging cannot be forensically investigated, which compounds both the security and the legal risk. ENISA’s 2023 AI cybersecurity report found that over 70% of AI security incidents involved systems where the operator lacked sufficient logging to reconstruct the incident chain.
Incident Response and Disclosure When AI-Assisted Decisions Cause Harm
When an AI-assisted decision on sovereign infrastructure causes harm to a data subject, the CISO and DPO face two parallel disclosure tracks that must run simultaneously rather than sequentially.
The GDPR Article 33 track requires notification to the competent supervisory authority within 72 hours of becoming aware of a personal data breach. “Aware” is interpreted strictly by most European data protection authorities: the clock starts when internal staff have sufficient information to recognise that a breach has likely occurred, not when a formal internal investigation concludes. On sovereign infrastructure, the advantage is that the organisation holds all the relevant data and can make this determination quickly from its own logs, without waiting for a vendor notification.
The AI liability track, once COM(2022) 496 enters into force, will require operators to preserve and in some circumstances disclose the logs, model version, risk management records, and human oversight documentation relevant to the adverse outcome. The practical implication is that incident response playbooks for sovereign AI operators must include an automatic log preservation step, triggered at the same moment as the GDPR notification decision, that places a legal hold on all inference records and access logs for the time window in question.
The European Parliament’s Committee on Legal Affairs noted in its commentary on COM(2022) 496 during trilogue discussions that “operators who cannot produce logs will find the presumption very difficult to rebut,” which makes log preservation at the moment of a potential incident the single most consequential operational step available to an organisation.
Sophos reported in its State of Ransomware 2024 survey that 59% of organisations were hit by ransomware in the previous 12 months. For sovereign AI operators, ransomware that encrypts or destroys inference logs before a legal hold can be placed creates a compound liability: the underlying AI incident and the inability to rebut the causality presumption because the evidence was destroyed. Immutable log storage, isolated from the primary AI runtime, is therefore both a security and a liability control.
Legislative Status and the Provisional Compliance Posture for Sovereign Operators
As of mid-2025, the AI Liability Directive (COM(2022) 496) remains a legislative proposal. Trilogue negotiations between the European Parliament, Council, and Commission were ongoing, and the text was subject to further amendment. The Product Liability Directive recast (Directive (EU) 2024/2853) was published in the Official Journal in November 2024 and entered into force; member states have until December 2026 to transpose it into national law. The EU AI Act (Regulation (EU) 2024/1689) entered into force in August 2024, with obligations for high-risk AI systems applying progressively through 2025 and 2026.
The provisional compliance posture for sovereign infrastructure operators should treat the AI Liability Directive’s causality presumption and disclosure obligations as the likely future baseline and build the required documentation infrastructure immediately. The reason is not merely legal prudence: national courts may already apply analogous national fault presumptions in AI cases before the directive is transposed, and the technical files, logs, and oversight records required by the AI Act are in any case mandatory for high-risk systems. Building them now costs less than reconstructing them retroactively under litigation pressure.
Former EDPB Chair Andrea Jelinek has articulated the underlying principle: “Sovereignty is not a marketing term; it is a legal condition. An organisation that cannot demonstrate exclusive control over its AI inference environment will struggle to assert that a third party, rather than itself, caused an adverse outcome.” For regulated organisations in finance, healthcare, and the public sector, where the AI Act’s high-risk categories concentrate most heavily, that legal condition is achievable today through sovereign on-premises deployment with documented governance, not through contractual assurances from a cloud provider operating under foreign jurisdiction.
FAQ
Does deploying AI on-premises automatically exempt an organisation from the EU AI Liability Directive’s causality presumption?
No. The causality presumption under COM(2022) 496 applies to any deployer of a high-risk AI system, regardless of infrastructure. What on-premises deployment changes is the organisation’s ability to rebut that presumption: full local logging, access controls, and human oversight records give operators the concrete evidence needed to demonstrate that the system functioned correctly and that the harm had a different cause.
At what point does fine-tuning an open-source model on sovereign infrastructure make an organisation a ‘manufacturer’ under the PLD recast?
Under Directive (EU) 2024/2853, substantial modification triggers reclassification. Retraining or fine-tuning in a way that materially changes the model’s outputs or extends it to a new risk category can cross that threshold. Standard retrieval-augmented generation or prompt configuration generally does not. The distinction must be documented explicitly in the organisation’s technical file.
What is the current legal status of the EU AI Liability Directive?
As of mid-2025, COM(2022) 496 remains a proposal under trilogue negotiation and has not yet been adopted as binding law. The PLD recast (Directive (EU) 2024/2853) is in force, with a national transposition deadline of December 2026. The EU AI Act is binding, with high-risk AI obligations applying progressively through 2026.
How does GDPR Article 33’s 72-hour notification deadline interact with AI liability log preservation obligations?
Both obligations are triggered by the same event, an AI-assisted decision causing harm that also constitutes a personal data breach. The 72-hour GDPR clock starts from internal awareness. Incident response playbooks must simultaneously initiate GDPR notification procedures and place a legal hold on all relevant inference logs and oversight records. On sovereign infrastructure, both steps are under the organisation’s direct control, without dependency on a cloud vendor’s incident notification process.
Which AI Act articles create the most direct connection to civil liability for on-premises operators?
Article 12 (automatic logging for high-risk systems), Article 14 (human oversight requirements), and Article 9 (risk management system documentation) are the three provisions most directly connected to civil liability exposure. Demonstrating compliance with all three is the primary basis for rebutting the AI Liability Directive’s causality presumption once it enters into force.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.