AI liability and sovereign infrastructure are converging concerns for European regulated organisations: civil liability exposure from AI systems is increasingly determined not just by what an AI does, but by whether the deployer can prove, through auditable evidence under its own control, that it met its duty of care. For compliance officers, CISOs and data protection officers in public administration, finance, healthcare and legal services, the infrastructure decision is therefore also a litigation-readiness decision.
The Proposed AI Liability Directive and the Causality Presumption
Proposed AI Liability Directive COM(2022) 496 introduced a rebuttable presumption of causality in Article 4: where a claimant establishes that a defendant failed a duty of care under Union law, and where that failure is plausibly linked to the AI output that caused harm, a court may presume that the breach caused the damage. The defendant must then disprove the causal link.
For regulated organisations running high-risk AI systems, this presumption is not abstract. High-risk categories under the AI Act include systems used in employment decisions, credit scoring, benefits administration, biometric identification and medical diagnosis. Public-sector bodies and financial institutions deploying such systems are squarely within scope.
The relevant duty-of-care obligations under Union law that activate Article 4 include the AI Act’s Article 9 risk-management system requirements and Article 17 quality-management system requirements. Failure to implement either, or failure to document implementation adequately, creates the preconditions for a court to apply the presumption without the claimant needing to explain the technical mechanism of harm.
Dragoș Tudorache, the European Parliament’s rapporteur for the AI Act, stated clearly: “The AI Liability Directive was designed to address the fundamental information asymmetry between AI deployers and those harmed by AI decisions. Withdrawing the proposal does not remove that asymmetry from national courts.”
Sovereign On-Premises Infrastructure vs. Public Cloud: The Evidentiary Gap
The practical difference between sovereign on-premises and public cloud deployment becomes most visible when litigation-relevant evidence must be produced quickly.
| Evidence category | Sovereign on-premises deployment | Public cloud deployment (US-controlled) |
|---|---|---|
| Model access logs | Held directly by deployer; immediately retrievable | Held by provider; subject to contract terms and provider cooperation |
| Infrastructure audit trails | Full stack visibility including hypervisor layer | Shared responsibility model limits deployer visibility |
| Training data provenance | Deployer maintains complete registry | Provider may not disclose proprietary model lineage |
| Incident records | Internally generated and stored; no dependency on provider SLA | Provider incident reports may be redacted or delayed |
| Cross-border disclosure risk | Governed by local law; Swiss FADP or EU GDPR controls apply | Subject to US CLOUD Act, FISA 702 and Patriot Act requests |
The European Parliament’s JURI Committee noted in its 2025 opinion that over 70 percent of AI-related complaints examined in the impact assessment involved situations where claimants could not access evidence held by the AI deployer. That figure exposes the structural problem: when evidence is held in a public cloud environment, the deployer itself may lack the access rights needed to respond to discovery, not just the claimant.
AI Act Conformity Assessment and the On-Premises Advantage
The AI Act establishes that high-risk AI systems must undergo conformity assessment before deployment. For systems listed in Annex III, including those used in public administration, credit decisions and healthcare, the deployer is responsible for demonstrating compliance with Articles 9 and 17 at the point of deployment and on an ongoing basis.
Article 9 requires a continuous risk-management system that identifies and mitigates risks across the system lifecycle. Article 17 requires a quality-management system covering data governance, technical documentation, logging, human oversight and post-market monitoring. Both articles produce documentation that doubles as litigation evidence.
On sovereign on-premises infrastructure, every layer of that documentation is generated and stored by the deployer. Model version changes, retraining events, human-oversight interventions and anomaly detections are all recorded in systems the organisation controls. When a regulator or court requests evidence of conformity, the deployer can produce it without negotiating with a third-party provider or waiting on contractual data-access procedures.
Andrea Jelinek, former Chair of the European Data Protection Board, observed that “organisations that can demonstrate end-to-end control over their AI systems, including training data provenance, access logs and output auditing, are in a fundamentally stronger position in any liability dispute than those relying on a third-party cloud provider’s compliance representations.”
Specific Controls Required to Rebut the Causality Presumption
Rebutting the Article 4 presumption requires the defendant to show that a duty-of-care breach, even if it occurred, did not cause the alleged harm. This is a factual question, and courts will look for contemporaneous documentary evidence, not retrospective reconstruction.
A sovereign deployer should maintain the following controls as a minimum operational baseline:
Immutable, timestamped access logs: Every query to a high-risk AI model, every output generated, and every human-oversight action taken must be recorded in a log that cannot be altered after the fact. Log integrity should be verifiable through cryptographic hashing, and logs should be retained for a period aligned with national limitation periods for tort claims (typically three to ten years across EU member states).
Model register and change governance: A register recording model identity, version, training data sources, known limitations and approval history for each deployment change. This directly evidences compliance with AI Act Article 9 and supports the argument that any identified risk was already assessed and mitigated before the incident.
Incident documentation with root-cause analysis: For every adverse outcome attributable to an AI system, a structured incident report should be created within a defined timeframe (for example, 72 hours for significant events under NIS-2 analogies). Root-cause analysis should distinguish between model failure, data-quality failure and user-error, because each has different liability implications.
Human-oversight records: High-risk AI systems under the AI Act must include meaningful human oversight. Documentation of when human review was triggered, what decision was made by the human reviewer, and on what basis, is essential evidence that the system was not operating autonomously without accountability.
The Withdrawal of COM(2022) 496 and Residual Liability Risk
In early 2025 the European Commission signalled that COM(2022) 496, the proposed AI Liability Directive, would be withdrawn from the legislative process following its stalled progress through the JURI Committee and the IMCO Committee. This withdrawal removes the prospect of a harmonised Article 4 causality presumption across all member states. It does not, however, remove civil liability risk for AI deployers.
Three residual liability channels remain fully operative. First, national tort law in each member state continues to apply to AI-caused harm under general negligence principles. Courts in Germany, France, the Netherlands and Belgium have each developed case law on software liability that can be applied to AI systems without a specific directive. Second, the revised Product Liability Directive (EU) 2024/2853, which entered into force in late 2024, explicitly extends product liability to AI-enabled products and software, including digital manufacturing files and AI components embedded in physical products. Third, sector-specific obligations under GDPR Article 22 (automated decision-making), DORA’s ICT risk-management requirements, and NIS-2 incident-reporting duties all create independently enforceable compliance obligations whose breach can ground civil claims.
IBM’s Cost of a Data Breach Report 2024 recorded that the global average cost of a data breach reached USD 4.88 million, the highest figure in the report’s history, reflecting both direct costs and regulatory penalties. For regulated organisations, an AI-related incident that triggers both liability claims and regulatory investigation under the AI Act or GDPR compounds that exposure significantly.
The ENISA Threat Landscape 2023 identified ransomware and data-related threats as the top two threat categories targeting EU public administration and healthcare, the same sectors that operate the largest volumes of high-risk AI systems under the AI Act. A breach that also exposes AI decision records creates simultaneous GDPR, AI Act and civil liability exposure.
Practical Architecture for Liability-Aware Sovereign AI Deployment
Organisations that have already moved to sovereign workspace infrastructure, such as a self-hosted Nextcloud environment replacing Microsoft 365, are well positioned to extend the same governance logic to AI. Open-source models such as Mistral and Llama, deployed on on-premises GPU infrastructure, allow the organisation to run private AI without routing data to public cloud endpoints. The model weights, inference logs and training-data registries all remain within the organisation’s jurisdiction and under its direct custody.
This architecture directly addresses the evidentiary requirements for AI Act Article 9 and Article 17 compliance. The risk-management system and quality-management system documentation can be generated automatically from the organisation’s own infrastructure logs, rather than assembled from provider-supplied compliance reports that may not be granular enough for litigation purposes.
For regulated organisations subject to both GDPR and the AI Act, maintaining AI inference data and model-governance records within a jurisdiction whose data-protection law prohibits foreign-government compelled disclosure (such as Switzerland under the revised Federal Act on Data Protection, or within EU member states) also prevents the scenario where US CLOUD Act or FISA 702 requests compel the disclosure of AI decision records to foreign authorities, which would itself constitute a GDPR violation and a breach of duty toward data subjects.
FAQ
Does the withdrawal of the AI Liability Directive proposal mean regulated organisations no longer face AI-related civil liability risk?
No. Withdrawal from the JURI/IMCO legislative track removes the harmonised EU framework, but national tort law in member states continues to apply. In Germany, France, the Netherlands and other jurisdictions, existing negligence and product liability rules can reach AI-caused harm. The revised Product Liability Directive (EU) 2024/2853 also now covers AI-enabled products and software explicitly.
What makes sovereign on-premises infrastructure easier to defend in a causality-presumption dispute?
Under Article 4 of COM(2022) 496, the presumption is rebutted by demonstrating that the duty-of-care breach did not cause the harm. Sovereign infrastructure gives the deployer direct custody of all logs, access records, model version histories and incident reports, without depending on a cloud provider’s cooperation or contractual access clauses. That evidence is retrievable immediately and in a format the deployer controls.
Which AI Act articles are most directly linked to civil liability exposure for high-risk AI deployers?
Article 9, which requires a documented risk-management system, and Article 17, which requires a quality-management system, are the primary articles because failures in either create documented duty-of-care breaches. Article 4 of the proposed AI Liability Directive ties the causality presumption directly to non-compliance with such obligations under Union law.
Can a public cloud deployment satisfy AI Act conformity-assessment requirements for high-risk systems?
Technically yes, but evidence production becomes harder. The deployer must demonstrate that risk-management and quality-management systems meet AI Act Articles 9 and 17, yet much of the underlying infrastructure evidence including hardware logs, hypervisor access records and co-tenancy data is held by the cloud provider and may be inaccessible under their terms of service, especially where US providers are subject to the CLOUD Act.
What is the minimum documentation a sovereign AI deployer should maintain to be litigation-ready?
At minimum: immutable, timestamped access logs for every model interaction; a model register recording version, training data provenance and change approvals; documented risk assessments per AI Act Article 9; quality-management records per Article 17; incident reports with root-cause analysis for any AI-related adverse outcome; and records of human-oversight interventions. These should be stored in a jurisdiction whose law permits domestic discovery controls.
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.