The AI Act, formally Regulation (EU) 2024/1689, is the world’s first comprehensive binding legal framework for artificial intelligence systems. For European organisations operating in regulated sectors, the regulation creates enforceable obligations not only for the companies that build AI systems but also for the bodies that deploy and operate them. The Omnibus VII legislative package, based on a Commission proposal of 19 November 2025 and reaching political agreement on 7 May 2026, materially adjusts the timeline for some of the heaviest obligations, making the period between now and 2 December 2027 the decisive window for compliance planning on sovereign on-premises infrastructure.
What becomes enforceable on 2 August 2026
The general application date of the AI Act, two years after its entry into force on 1 August 2024, brings a broad set of obligations into effect. The prohibited-practices chapter was already enforceable from 2 February 2025. From 2 August 2026, the obligations covering general-purpose AI models, transparency requirements and the governance architecture of the regulation become fully operative.
For deployers specifically, Article 26 of Regulation (EU) 2024/1689 creates a separate and direct compliance burden that is distinct from the provider’s burden. Deployers must follow the provider’s instructions for use, implement the human oversight measures described in Article 14, monitor the system’s performance in its operational environment, and maintain the logging records required by Article 12. Where a deployer identifies that a system is producing unexpected outputs or has malfunctioned, there is a duty to notify either the provider or the national competent authority designated under Article 73, depending on the severity of the incident.
The IBM Cost of a Data Breach Report 2023 recorded a global average breach cost of USD 4.45 million, the highest in 18 years of the report’s history. For regulated organisations, non-compliance penalties under the AI Act can reach 30 million euros or 6 percent of global annual turnover for the most serious violations, meaning the financial exposure from AI governance failures now sits in the same tier as data breach liability.
Omnibus VII and the revised timeline for high-risk systems
The Omnibus VII political agreement of 7 May 2026 consolidates the applicability dates for Annex III high-risk AI categories into a single date of 2 December 2027. This affects systems used in biometrics, critical infrastructure management, employment screening, educational assessment, and access to essential services.
| High-risk category (Annex III) | Pre-Omnibus VII applicability | Post-Omnibus VII applicability |
|---|---|---|
| Biometric identification and categorisation | 2 August 2026 | 2 December 2027 |
| Critical infrastructure management | 2 August 2026 | 2 December 2027 |
| Employment and worker management | 2 August 2026 | 2 December 2027 |
| Education and vocational training | 2 August 2026 | 2 December 2027 |
For sovereign deployers building on-premises AI environments, this single consolidated deadline removes an earlier source of confusion about which system types triggered obligations first. A hospital deploying a patient-triage AI, a financial institution running an automated credit-scoring model, or a public authority using AI in recruitment screening can now design a single compliance project targeted at December 2027, rather than managing overlapping waves.
The consolidated timeline does not, however, eliminate the August 2026 obligations for general-purpose AI model governance or for transparency requirements that apply to any AI system interacting with natural persons.
Technical documentation and conformity obligations for sovereign on-premises deployments
A regulated organisation running a high-risk AI system on sovereign on-premises infrastructure must, by the applicable deadline, have the following in place: a fully documented Article 9 risk-management system covering the identified risks of the specific use case, technical documentation demonstrating the system’s design choices and performance characteristics, a conformity assessment (either self-assessment or third-party, depending on the category), registration in the EU database established under Article 71, and operational logging under Article 12 covering relevant inputs, outputs and human-override events.
On-premises deployment simplifies one dimension of this evidence-gathering exercise significantly. In a public cloud environment, the deployer depends on the cloud provider to supply audit logs, infrastructure attestations, and evidence of data residency. That evidence chain typically involves service-level agreements, third-party audit reports (such as ISO 27001 or SOC 2) and contractual representations that regulators may not accept as equivalent to direct technical evidence. On sovereign on-premises infrastructure, the organisation controls the entire evidence chain: log files, access controls, model weights, inference hardware, and network perimeters. This makes it materially easier to demonstrate to a national competent authority under Article 73 that the system operates as documented.
The European Data Protection Board has stated: “Deployers of high-risk AI systems bear direct legal obligations under the AI Act, including the duty to implement human oversight measures and to monitor system performance in production.” This makes it legally untenable for a DPO or CISO to treat AI compliance as solely a procurement matter managed through vendor contracts.
GPAI models on sovereign infrastructure: interaction with AI Office oversight
Open-weight general-purpose AI models such as Llama and Mistral occupy a distinctive position under the AI Act. The European AI Office, established as the central supervisory body for GPAI models, holds oversight authority over these models regardless of where inference is executed. The AI Office has stated: “The AI Office will act as the central supervisor for general-purpose AI models, and national competent authorities will remain the primary point of contact for high-risk system deployers at the operational level.”
For a deployer running Mistral or Llama entirely within a sovereign on-premises environment, the practical implication is a split responsibility model. The model provider (or the open-weight release maintainer) is responsible for the GPAI Code of Practice obligations: technical documentation of training data, energy consumption disclosures, and systemic-risk evaluations for models above the 10^25 FLOP threshold. The deployer is responsible for how the model is integrated into a specific application, whether that application qualifies as high-risk under Annex III, and whether the Article 9 risk-management system adequately covers the GPAI component.
Critically, on-premises deployment of open-weight models means that inference data never reaches the model provider’s infrastructure. This removes one category of data-sovereignty risk entirely, and it means the deployer cannot be caught by the CLOUD Act, FISA 702 or similar foreign-jurisdiction access mechanisms that apply when a US-headquartered provider hosts the inference endpoint. ENISA’s Threat Landscape 2023 report identified public-sector and healthcare organisations as the targets of the largest share of high-impact incidents in the EU, reinforcing why eliminating external access vectors matters for these sectors specifically.
National AI regulatory sandboxes and the August 2027 deadline
Article 57 of Regulation (EU) 2024/1689 requires Member States to establish at least one operational AI regulatory sandbox by 2 August 2027. These sandboxes provide a supervised testing environment in which deployers can validate high-risk AI systems against regulatory requirements before full deployment, with explicit legal coverage from the national competent authority under Article 73.
For sovereign deployers in healthcare, finance or the public sector, sandbox participation offers three concrete advantages. First, it produces structured compliance evidence, including documented risk assessments and authority feedback, that feeds directly into the technical documentation required for conformity assessment. Second, it creates a dialogue channel with the regulator before enforcement begins, allowing the deployer to address gaps without facing penalty exposure. Third, it provides a mechanism for testing on-premises AI configurations, including local GPAI inference setups, under authority supervision, which reduces legal uncertainty about novel deployment architectures.
Organisations that anticipate deploying high-risk AI systems by December 2027 should contact their designated Article 73 national competent authority now, given that sandbox capacity will be finite and application processes typically require lead time.
Mapping Article 9 and Article 12 onto NIS-2 and DORA governance
For compliance officers and DPOs managing simultaneous obligations under NIS-2, DORA and the AI Act, the most practical approach is integration rather than parallelism. The three frameworks share overlapping concepts: risk identification, documentation, incident reporting, and periodic review. Building three separate audit trails for the same underlying operational events is both resource-intensive and likely to produce inconsistencies that regulators can exploit during inspections.
Article 9 of the AI Act requires a risk-management system that identifies, analyses and addresses the risks posed by the specific high-risk AI system throughout its lifecycle. NIS-2 already mandates a documented information-security risk-management process covering the same infrastructure. The practical solution is to extend the existing NIS-2 risk register with AI-specific entries, mapping each identified AI risk to the corresponding NIS-2 control and adding the AI Act-specific mitigations as additional columns. This produces a single reviewable document that satisfies both frameworks simultaneously.
Article 12 requires that high-risk AI systems have logging capabilities enabling reconstruction of the circumstances of incidents. DORA requires financial entities to maintain ICT incident logs with specific retention requirements. These obligations are architecturally identical: both require a tamper-evident, time-stamped log of system events accessible to supervisors. A single SIEM implementation feeding both the AI Act’s Article 12 logs and the DORA incident-reporting pipeline eliminates duplication and ensures consistency between what the AI Act record shows and what the DORA incident report states, which matters when a single event triggers obligations under both regimes simultaneously.
The governance committee responsible for NIS-2 and DORA reporting is the natural home for AI Act review cycles. Assigning a separate AI governance committee creates structural fragmentation and risks the two bodies reaching contradictory conclusions about the same system’s risk profile.
FAQ
Which AI Act obligations actually apply to deployers, rather than to AI providers or developers, from 2 August 2026 onwards?
Article 26 of Regulation (EU) 2024/1689 assigns deployers a distinct set of duties: implementing the provider’s instructions for use, ensuring human oversight in line with Article 14, monitoring system performance in production, logging relevant inputs and outputs under Article 12, and notifying the provider or the national competent authority when the system malfunctions or produces unexpected outputs. Providers bear the conformity assessment and CE-marking burden; deployers bear the operational governance burden.
What does the Omnibus VII political agreement of 7 May 2026 actually change for high-risk AI timelines?
The Omnibus VII legislative package, built on the Commission proposal of 19 November 2025, introduces a consolidated applicability date of 2 December 2027 for the AI Act’s Annex III high-risk categories covering biometrics, critical infrastructure, employment screening and educational assessment. This replaces the earlier staggered schedule and gives deployers rolling out sovereign on-premises systems in those sectors a clearer single deadline to target, provided the system was not already placed on the market before the cutoff.
Does running an open-weight GPAI model such as Llama or Mistral entirely on sovereign on-premises infrastructure exempt an organisation from AI Act obligations?
Not entirely. The European AI Office holds centralised oversight over GPAI models regardless of where inference runs. If a deployer uses an open-weight model to build or operate a high-risk application, the deployer’s Article 26 obligations still apply. On-premises deployment means no data leaves the organisation’s control and the organisation can demonstrate full audit trails without relying on a cloud provider’s attestations. The deployer must still document how it has integrated the model into its risk-management system under Article 9.
When must EU Member States have established national AI regulatory sandboxes, and how can sovereign deployers use them?
Under Article 57 of the AI Act, Member States are required to have at least one operational AI regulatory sandbox in place by 2 August 2027. Sovereign deployers in healthcare, finance or the public sector can apply to test high-risk AI systems under the supervision of the national competent authority designated under Article 73 before full deployment. Sandbox participation produces documented evidence of compliance testing that can feed directly into the technical documentation required for conformity assessment.
How can a CISO or DPO avoid creating separate, duplicated audit trails for the AI Act, NIS-2 and DORA?
The key is to treat Article 9’s risk-management system as a layer on top of the existing information-security risk framework rather than a parallel process. Article 12 logging obligations can be satisfied using the same SIEM or log-management infrastructure that feeds NIS-2 and DORA incident reports. The practical recommendation is to extend the existing risk register to include AI-specific entries, map Article 12 log categories to the organisation’s existing retention schedules, and assign the AI Act review cycle to the same governance committee that handles NIS-2 and DORA reporting.