The EU AI Act, formally Regulation (EU) 2024/1689, establishes a risk-based framework that places some of the most demanding compliance obligations ever enacted on organisations deploying AI in public administration, finance, healthcare and the legal sector. For compliance officers, CISOs and data protection officers in those sectors, the central question is not whether the regulation applies to them, but how they can deploy AI systems in a way that keeps sensitive data under sovereign control while satisfying the Act’s requirements for technical documentation, conformity assessment and human oversight. On-premises deployment using open-source models is increasingly the answer, but it brings its own regulatory obligations that must be understood precisely.
How Article 6 and Annex III Determine High-Risk Classification
An AI system is classified as high-risk if it falls within one of the two pathways defined in Article 6 of Regulation (EU) 2024/1689. The first pathway covers AI systems that are safety components of products already regulated under specific EU harmonisation legislation (such as medical devices or machinery). The second, and more immediately relevant to public and regulated sectors, is the list in Annex III.
Annex III enumerates eight domains where AI use carries sufficient potential harm to warrant the full high-risk compliance burden. These include biometric identification (point 1), critical infrastructure management (point 2), education and vocational training (point 3), employment and worker management (point 4), access to essential private and public services including financial services and healthcare (point 5), law enforcement (point 6), migration and border control (point 7), and the administration of justice and democratic processes (point 8).
For a government body deploying an AI model to support benefit eligibility assessments, or a hospital using AI-assisted triage, the classification as high-risk under Annex III point 5 is almost certain. A financial institution running AI-driven credit scoring or fraud detection falls squarely into point 5 as well. The classification is not optional or subject to internal risk appetite: it is determined by the use case, the deploying sector and whether the system influences a consequential decision about an individual or group.
Obligations Under Articles 9 to 17: What Sovereign Deployers Actually Owe
Articles 9 through 17 of the AI Act establish the substantive obligations that apply to high-risk AI systems. Taken together, they constitute a compliance programme that must be documented, maintained and auditable. On-premises deployment directly affects who bears these obligations and how they can be discharged.
Risk management and data governance (Articles 9 and 10)
Article 9 requires a continuous risk management system covering the full lifecycle of the high-risk AI system. Article 10 imposes strict data governance obligations on training, validation and testing datasets: data must be relevant, representative, free of errors and complete as far as reasonably achievable. For organisations that fine-tune an open-source model such as Mistral on proprietary datasets, Article 10 obligations apply to those datasets in full. On-premises infrastructure allows an organisation to enforce data lineage, versioning and access controls on training data in ways that are technically verifiable and auditable, without exposing that data to a cloud provider’s processing environment.
Technical documentation and conformity assessment (Articles 11 and 43)
Article 11 requires providers to draw up technical documentation before a high-risk AI system is placed on the market or put into service. For organisations that are classified as deployers rather than providers, Article 26 assigns a set of deployer-specific obligations, including implementing appropriate human-oversight measures and informing the provider of any serious incidents. However, where an organisation fine-tunes an open-source model substantially, it may be reclassified as a provider for the purposes of the resulting system, bringing Article 11 documentation obligations with it. Maintaining this documentation on-premises, within a controlled repository with audit trails, satisfies both the AI Act’s requirements and GDPR data minimisation principles simultaneously.
Transparency, logging and post-market monitoring (Articles 13, 14 and 17)
Article 13 requires high-risk AI systems to be transparent to deployers. Article 14 mandates human oversight, including the technical capacity for a natural person to understand, monitor and override the system’s outputs. Article 17 requires a post-market monitoring plan collecting real-world performance data. On-premises sovereign infrastructure, by keeping all inference logs, override records and performance telemetry within the organisation’s own environment, makes compliance with these three articles structurally more straightforward than cloud deployments where log access depends on contractual arrangements with a foreign vendor.
“Deployers of high-risk AI systems cannot hide behind their vendors. The regulation places direct obligations on those who put the system into use in a specific context.” (EU AI Office, enforcement authority for the AI Act from August 2026)
The AI Omnibus Simplification Amendments: What Changed in 2025 and 2026
The AI Omnibus simplification proposal, adopted by the European Commission in November 2025 and reaching political agreement in May 2026, adjusted the transition timeline architecture rather than eliminating the substantive compliance obligations. For high-risk AI systems embedded in regulated products (the Article 6 first pathway), it extended the transition period and introduced a simplified conformity assessment track for SMEs and public bodies that deploy AI systems developed by third parties. The obligations under Articles 9 through 17 remain intact; what changed is when they must be demonstrably in place and how the conformity assessment can be structured for smaller deployers.
For regulated-sector organisations running sovereign AI, the practical implication is additional runway to build audit-ready documentation infrastructure. Organisations that begin implementing technical documentation and post-market monitoring systems now, on their own infrastructure, will be well positioned before the extended deadlines arrive.
GPAI Code of Practice and the Open-Source Model Question
The GPAI Code of Practice, submitted to the Commission by the EU AI Office in July 2025, addresses general-purpose AI models, including open-source releases such as Mistral AI’s models and Meta Llama variants. For organisations running these models locally, the Code’s relevance depends on whether the organisation is acting as a downstream deployer or has taken on provider-level responsibility through significant fine-tuning.
A local deployment that simply serves inferences from an unmodified open-source model for internal use does not constitute “placing on the market” under the AI Act. The Act defines placing on the market as making a system available for the first time on the EU market, which implies some form of distribution or third-party access. Internal deployment, even at scale across a government ministry or hospital network, remains a deployer activity. If the organisation fine-tunes the model, publishes the adapted version for use by affiliated bodies, or makes it available to external contractors, the analysis changes and provider obligations may attach.
On-Premises Infrastructure as a Unified Compliance Architecture
A recurring challenge for compliance officers is that the AI Act, GDPR and sector-specific frameworks such as DORA each impose overlapping record-keeping and oversight requirements. On-premises private AI infrastructure addresses all three simultaneously through a single technical layer.
Under GDPR Article 22, individuals have the right not to be subject to solely automated decisions with significant legal effects. The AI Act’s Article 14 human-oversight requirement maps directly onto this: a system that cannot be meaningfully reviewed and overridden by a natural person violates both instruments at once. On-premises deployment allows an organisation to instrument the AI system with override logging, decision rationale capture and reviewer audit trails, all stored in a jurisdiction under the organisation’s direct legal control, satisfying both Article 22 and Article 14 with the same technical mechanism.
“The AI Act is not just another compliance checkbox. It fundamentally changes who is responsible for what when an automated system makes or influences a consequential decision about a person.” (Andrea Jelinek, former Chair of the European Data Protection Board)
Regulatory Tensions in Financial Services: AI Act, GDPR Article 22 and DORA
Financial institutions face a particularly dense overlay of obligations when deploying AI-driven risk or fraud detection systems. The AI Act classifies such systems as high-risk under Annex III point 5. GDPR Article 22 applies because credit and fraud decisions produce significant legal effects. DORA (Regulation (EU) 2022/2554), fully applicable from January 2025, requires ICT risk management, incident reporting and resilience testing for all digital tools that support critical functions, including AI-based fraud detection.
| Regulatory Instrument | Primary Obligation for AI Fraud Detection | How On-Premises Sovereign Deployment Helps |
|---|---|---|
| EU AI Act, Articles 9–17 | Technical documentation, risk management, human oversight, post-market monitoring | All logs, documentation and override records stay in-house and under direct legal control |
| GDPR Article 22 | Lawful basis for automated processing, right to human review on request | Decision rationale and reviewer logs stored locally, accessible without third-party data-sharing agreements |
| DORA (Regulation (EU) 2022/2554) | ICT risk management, resilience testing, incident reporting within 4 hours for major incidents | No dependency on foreign cloud availability; incident telemetry remains within the organisation’s infrastructure |
The tension between these instruments is real but manageable. DORA’s resilience requirements push towards redundancy and continuity planning, which can appear to conflict with the AI Act’s requirement for human-override capacity if the override mechanism itself is part of a system that must stay available. The resolution is architectural: human-oversight functions must be designed as independently resilient components, not as features of the AI inference layer itself.
Enforcement of the AI Act becomes the EU AI Office’s direct responsibility from August 2026. For financial institutions already under EBA, ESMA and national supervisory scrutiny, adding EU AI Office oversight creates a multi-authority environment where gaps in documentation or human-oversight mechanisms can surface from several directions simultaneously.
62% of surveyed European companies reported they were not yet prepared to meet EU AI Act requirements as of early 2024 (PwC EU AI Act Readiness Survey, 2024). Against a backdrop where GDPR fines across the EU and EEA exceeded EUR 1.78 billion in 2023 (DLA Piper GDPR Fines and Data Breach Survey, January 2024), the cost of deferring compliance architecture decisions is measurable. Building on-premises sovereign AI infrastructure now, with documentation and oversight mechanisms designed to satisfy Articles 9 through 17 from the outset, is both the most defensible regulatory posture and the most operationally resilient one.
Frequently Asked Questions
Does running an open-source model such as Mistral or Llama on-premises make my organisation a provider under the AI Act?
Not automatically. If your organisation deploys the model solely for internal use without placing it on the market or making it available to third parties, you are typically classified as a deployer. If you fine-tune the model substantially and make the resulting system available to others, even within a group of public bodies, provider obligations under Articles 9 through 17 may attach to your organisation.
Which Annex III categories most commonly apply to public-sector AI deployments?
The most frequently encountered categories are: AI used in the administration of justice and democratic processes (point 8), AI used by public authorities for benefit or service eligibility decisions (point 5), and biometric identification systems (point 1). Healthcare providers should examine point 5 carefully when AI informs clinical triage or resource allocation decisions.
What changed with the AI Omnibus political agreement of May 2026?
The AI Omnibus simplification proposal, adopted by the Commission in November 2025 and subject to political agreement in May 2026, extended transition periods for certain high-risk AI systems embedded in regulated products and simplified the conformity assessment path for SMEs and public bodies. It did not remove the substantive obligations under Articles 9 through 17 but gave deployers more time to build audit-ready documentation structures.
How does GDPR Article 22 interact with the AI Act when a bank uses AI for fraud detection?
GDPR Article 22 grants individuals the right not to be subject to solely automated decisions that produce significant legal or similarly significant effects. The AI Act classifies many financial AI systems as high-risk under Annex III point 5. A bank must satisfy both regimes simultaneously: the AI Act requires human-oversight mechanisms, logging and conformity assessment, while GDPR Article 22 requires a documented lawful basis and the ability to provide meaningful human review on request. Neither regulation supersedes the other.
Can on-premises sovereign deployment satisfy post-market monitoring requirements under Article 17?
Yes. Article 17 requires a post-market monitoring system collecting and analysing data on system performance. On-premises infrastructure keeps all monitoring telemetry, logs and incident records within the organisation’s own jurisdiction and under its direct control, making it straightforward to produce these records for national market surveillance authorities or for the EU AI Office, which assumes its enforcement role from August 2026.