The EU AI Act high-risk deadline moved to December 2027: what it means for where you host and deploy AI infrastructure
The AI Omnibus moved high-risk AI Act obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). The Act does not force EU hosting, but its logging, retention, documentation and authority-access duties decide which hosting setups can prove compliance.
The high-risk deadline was postponed, and it still applies. The AI Omnibus (Regulation (EU) 2026/1744) entered into force on 27 July 2026. Standalone high-risk systems listed in Annex III now have to comply from 2 December 2027, and high-risk AI embedded in products covered by EU product law (Annex I) from 2 August 2028 (European Commission). GPAI, transparency and prohibited-practice rules kept their original dates.
The AI Act does not require you to host in the EU. No article says "keep high-risk AI on EU soil". GDPR transfer rules, sector rules and public procurement policies often do, but the AI Act itself regulates evidence, not geography.
Evidence is where hosting decides compliance. Deployers must keep high-risk system logs for at least six months (Article 26(6)), providers must keep technical documentation for 10 years (Article 18), and market surveillance authorities can demand training, validation and test data through APIs or remote access (Article 74(12)). A setup where a third party holds your logs, swaps your model version or controls the region makes each of those harder.
The practical answer for most teams is "your own cloud account, an EU region, pinned model versions, and logs you control". Self-hosting is not mandatory, but it is the setup where every AI Act evidence request maps to something you can export.
Use the 13 extra months to build the evidence trail. Fines for breaching provider or deployer obligations reach EUR 15 million or 3% of worldwide annual turnover (Article 99(4)), and retrofitting logging into a live AI system in late 2027 is the expensive path.
Two weeks ago a CTO at a European HR-tech company asked me a question I now hear in almost every enterprise call: "The AI Act deadline got pushed. Does that mean we can keep the scoring model on the US API for now and move it later?" Their product ranks job applicants, which is squarely Annex III. Their model runs behind a third-party API in a US region.
My honest answer was "you can, but you are spending the delay on the wrong problem." The AI Omnibus gave high-risk systems more time. It did not change what you will have to prove on 2 December 2027, and most of that proof lives in your infrastructure. Below I cover the new deadline, what the AI Act says (and does not say) about hosting, and how to pick a deployment setup that will survive an audit.
I am not a lawyer, and this is engineering guidance. Check your classification and your dates against the consolidated text on EUR-Lex with counsel before you rely on them.
What is the EU AI Act high-risk deadline now, after the AI Omnibus?
The EU AI Act high-risk deadline is now 2 December 2027 for standalone high-risk AI systems listed in Annex III and 2 August 2028 for high-risk AI built into products already regulated by EU product-safety law listed in Annex I. Both dates come from the AI Omnibus, which was proposed on 19 November 2025, politically agreed on 7 May 2026 and entered into force on 27 July 2026 (European Commission).
The original AI Act (Regulation (EU) 2024/1689) applied most high-risk rules from 2 August 2026. The Commission's November 2025 proposal wanted to tie the start date to the availability of harmonised standards, with a maximum delay of 16 months (European Commission press release). The final text replaced that floating trigger with fixed dates (European Commission). That helps planning, because you can put a date in a roadmap instead of monitoring a condition.
Here is the full timeline as it stands on 14 November 2026:
High-risk obligations for Annex III systems (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice)
Two things did not move, and I see people miss them. GPAI obligations have applied since 2 August 2025, with Commission enforcement from 2 August 2026. Article 50 transparency (telling people they talk to an AI, marking synthetic content) applies from 2 August 2026. If your product uses a foundation model and talks to users, part of your AI Act exposure is already live. We covered the GPAI side in detail in our guide to GPAI enforcement for self-hosted open-weight models.
Does the EU AI Act require you to host high-risk AI systems in the EU?
No. The EU AI Act does not contain a data localisation or EU-hosting requirement for high-risk AI systems. It regulates what a high-risk system must do and what its provider and deployer must be able to prove, wherever the servers sit. A high-risk system running in a US region can be compliant, and one running in Frankfurt can be non-compliant.
What the AI Act does contain are four duties that quietly push hosting decisions:
Authorities need access. Market surveillance authorities get "full access" to documentation and to training, validation and testing data sets, including "through application programming interfaces (API) or other relevant technical means and tools enabling remote access" (Article 74(12)). Source code access is possible when other checks prove insufficient (Article 74(13)).
Non-EU providers need an EU anchor. A provider established outside the EU must appoint an authorised representative in the Union before making a high-risk system available on the EU market (Article 22).
Logs must exist and be retained. High-risk systems must technically allow automatic recording of events over their lifetime (Article 12), and both providers (Article 19) and deployers (Article 26(6)) must keep those logs for at least six months, to the extent the logs are under their control.
Documentation outlives the deployment. Providers keep the technical documentation, quality management records and EU declaration of conformity for 10 years after the system is placed on the market (Article 18). Annex IV even requires "the description of the hardware on which the AI system is intended to run" and "the computational resources used to develop, train, test and validate the AI system" (Annex IV).
Location rules come from other laws that sit right next to the AI Act. High-risk systems almost always process personal data, so GDPR Chapter V transfer rules apply. The EU-US Data Privacy Framework survived its first court challenge when the General Court dismissed the Latombe case (T-553/23) on 3 September 2025, but it remains politically exposed, and the US CLOUD Act and FISA Section 702 questions have not gone away. I wrote about that exposure in our piece on FISA 702 and US cloud providers in Europe. Public buyers add their own rules on top. The Dutch government's July 2026 cloud policy, for example, limits public cloud storage and processing to EEA countries (Kamerstuk 26643, nr. 1541).
The AI Act decides what you must prove, GDPR and procurement decide where you may run it, and your hosting setup decides whether you can produce the proof on demand.
Which high-risk AI Act obligations actually land on your infrastructure?
Six of the high-risk obligations translate directly into infrastructure requirements: logging, log retention, documentation retention, data governance, accuracy and cybersecurity, and post-market monitoring with incident reporting. The rest (risk management, human oversight design, conformity assessment) are mostly process, but they lean on the same evidence.
Here is how each one maps to something your platform team has to build:
Resilience against errors, faults and attacks such as data or model poisoning and adversarial examples
Network isolation, least-privilege access to model artifacts, reproducible deployments, rollback
Post-market monitoring and serious incidents (Art. 72, Art. 73)
Provider, with deployer input
Continuous monitoring; incident reports within 15 days, 10 days for a death, two days for widespread infringement or critical infrastructure disruption
Observability and alerting on model behaviour, and the ability to pull the exact logs for one incident fast
Full access to documentation and datasets, possibly remote via API
A controlled, auditable way to grant read access to a regulator without opening production
The two-day clock in Article 73(3) is the one that worries me most for teams on third-party AI platforms. If the logs you need sit in a vendor's system with 30-day retention and a support ticket queue, you will not reconstruct an incident in 48 hours.
Provider or deployer: whose infrastructure carries the high-risk obligations?
The provider carries most of the high-risk obligations, and the deployer carries a smaller set focused on correct use, monitoring and log retention. Your hosting question depends on which one you are, and many teams are both.
A provider develops a high-risk AI system (or has it developed) and places it on the market or puts it into service under its own name (Article 3(3)). If you sell an applicant-ranking SaaS, you are the provider. A deployer uses a high-risk system under its own authority in a professional context (Article 3(4)). The bank using your credit-scoring model is the deployer.
The trap is Article 25. A deployer, distributor or importer becomes a provider if it puts its name on a high-risk system, makes a substantial modification, or changes the intended purpose so the system becomes high-risk. Fine-tuning a general model and wiring it into a hiring workflow can do exactly that.
What each role means for infrastructure:
Providers need the full evidence chain: versioned training data, reproducible builds, documented hardware, inference logging by design, monitoring, and a way to give authorities remote access. Hosting the model in an account and region you control makes almost every item easier.
Deployers must keep the logs "under their control" for six months, monitor the system and, if they are public bodies or certain private entities, register their use and run a fundamental rights impact assessment (Article 27). If the provider hosts everything as a black-box API, ask in the contract how you get your logs.
Teams that are both (most AI product companies) should design the logging once, in their own infrastructure, and expose a deployer-facing export to customers. That export becomes a sales asset in procurement.
Run high-risk AI on infrastructure you can prove things about.
Qovery deploys your models and apps on Kubernetes in your own AWS, GCP, Azure or Scaleway account, or your existing cluster, with audit logs, RBAC and region choice built in. Talk to us about your AI Act roadmap.
How do hosting options compare for high-risk AI under the AI Act?
Every hosting option can be made compliant on paper. The difference is how much of the evidence you hold yourself versus how much you have to obtain from a vendor under contract. The more of the evidence chain you control, the cheaper the audit.
I scored the five setups I see most in European AI teams against the six things the AI Act and its neighbours test:
Hosting setup
Log control and retention (Art. 12, 19, 26)
Model version pinning (Annex IV, Art. 15)
EU data residency (GDPR, procurement)
Authority access (Art. 74)
Exit and portability
Operational effort
Third-party AI API, US region
Low: vendor logs, vendor retention
Low: provider can deprecate or update models
Depends on DPF or SCCs
Via vendor, under contract
Low
Lowest
Third-party AI API, EU data zone
Medium: EU processing, vendor-held logs
Low to medium
Good
Via vendor, under contract
Low
Low
Hyperscaler managed AI service in your own EU-region account (e.g. Bedrock, Vertex AI, Azure AI Foundry)
Medium to high: logs land in your account if you configure them
Medium: managed model catalog, pinned versions where offered
Good, but US parent company
You grant access to your account
Medium
Low to medium
Self-hosted models on Kubernetes in your own cloud account (EU region)
High: you own every log line and its retention
High: you pin the exact image and weights
Good, region of your choice
You grant scoped, audited access
High (open-weight models, standard containers)
Medium, high without a platform
EU sovereign cloud or on-premise Kubernetes
High
High
Strongest, EU-owned operator
You grant access
High
Highest without a platform
A few honest notes on that table:
Third-party APIs are not disqualified. Plenty of high-risk systems will ship on them. You will carry contractual work: log export rights, retention guarantees, model deprecation notice, sub-processor lists and audit rights. Read the Article 25(4) clause on written agreements between providers and suppliers of AI components before you sign.
Hyperscaler managed services in your own account are a reasonable middle ground when you configure invocation logging to your own storage and pin model versions. The residual question is jurisdiction, which matters more for public sector buyers than for the AI Act itself. Our four levels of EU cloud sovereignty breaks that down.
Self-hosting on Kubernetes gives you the cleanest evidence chain and the most operational work. The CNCF Annual Cloud Native Survey found 66% of organizations hosting generative AI models already use Kubernetes for some or all of their inference, so this is not an exotic path anymore.
My opinion, after a lot of these conversations, is that for an Annex III system the default should be "inference in your own cloud account, in an EU region, on pinned model versions, with logs you own." Start from there and justify every deviation. That is the inverse of how most teams started, which was "call the best API and figure out compliance later."
What should you change in your AI infrastructure before 2 December 2027?
You should use the next 12 months to make your AI system's evidence trail exportable: own the inference logs, pin and record every model version, document the hardware and region, and rehearse an authority request. None of this needs the harmonised standards to be final, and all of it is painful to retrofit.
The standards are still catching up. CEN and CENELEC's JTC 21 is drafting the harmonised standards that will give presumption of conformity (European Commission, AI Act standardisation), and a standard only grants that presumption once it is cited in the Official Journal. Waiting for them before touching infrastructure is how teams end up rushing in Q4 2027.
Here is the plan I would run, by quarter:
Q4 2026: classify and inventory. List every AI system, decide whether it falls under Annex III or Annex I, and record whether you are the provider, the deployer or both. Map where each model runs today, including region, account owner and who holds the logs.
Q1 2027: move inference where you control the evidence. For Annex III systems, bring inference into your own cloud account and an EU region, or renegotiate the vendor contract for log export, retention and model deprecation notice. Pin model images and weights by digest.
Q2 2027: build Article 12 logging by design. Log request ID, timestamp, model version and digest, input reference, output, confidence or score, and the human reviewer where one exists. Ship logs to storage with object lock or equivalent, retention set to at least six months, longer where sector law asks.
Q3 2027: make deployments reproducible. Every production change goes through one reviewed pipeline, with infrastructure as code and a deployment history that answers "which model, which config, which hardware, which region, on which date". That history is your Annex IV hardware and compute section.
Q4 2027: rehearse. Run a mock serious incident with a two-day clock, and a mock Article 74 request where you give a read-only auditor access to documentation and datasets. Fix what breaks before 2 December.
Breaching provider or deployer obligations can cost up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, and supplying incorrect or misleading information to authorities up to EUR 7.5 million or 1% (Article 99). The Omnibus capped penalties for SMEs and small mid-caps at the lower of the two amounts (NicFab analysis of Reg. 2026/1744), which helps, but does not make the logs optional.
Adoption is not slowing down while you wait. Eurostat reported that 20.0% of EU enterprises with 10 or more employees used AI in 2025, up from 13.5% in 2024, and 55.0% of large enterprises. The number of systems you need to classify will be higher in 2027 than it is today.
What does the delay mean for public sector AI and its suppliers?
For public sector AI, the delay changes little. New Annex III systems used by public authorities still have to comply from 2 December 2027, legacy systems used by public authorities must comply by 2 August 2030 (Article 111(2)), and public deployers carry extra duties that private deployers do not.
Public deployers carry three extra duties:
Registration. Public authorities that deploy high-risk systems must register their use in the EU database, and must not use a system that has not been registered (Article 26(8), Article 49).
Fundamental rights impact assessment. Bodies governed by public law and private entities providing public services must assess impact on fundamental rights before first use (Article 27).
Procurement rules stack on top. Public buyers apply their own security baselines. In the Netherlands, for example, the BIO2 baseline became a legal duty for government bodies when the Cyberbeveiligingswet entered into force on 15 August 2026 (NL Digital Government). I unpacked what that means for suppliers in our BIO2 guide for cloud platforms.
If you sell AI to governments, expect the tender to ask for the AI Act evidence and the hosting evidence in the same questionnaire: where inference runs, who operates it, under which jurisdiction, how long logs live and how the buyer gets them. The comparison of European sovereign clouds and hyperscalers for public sector projects covers the hosting half of that questionnaire.
How does Qovery help you deploy high-risk AI infrastructure you can prove things about?
Qovery is an Agentic DevOps platform that deploys and operates your applications and models on Kubernetes in your own AWS, GCP, Azure or Scaleway account, or on an existing Kubernetes cluster, including EU sovereign and on-premise clusters. Qovery's control plane is separate from your data plane: your inference traffic, model weights, logs and data stay in your account and your region.
For the AI Act evidence chain, this split means Qovery handles the operational work that makes self-hosting expensive, without taking custody of the evidence:
Region and account choice per environment. Run Annex III inference in an EU region of your own account, keep non-regulated workloads wherever they are cheapest.
GPU node pools per service on Qovery-managed clusters on any cloud, so self-hosted models do not need a dedicated MLOps team to schedule GPUs.
Reproducible deployments. Git-push deployments, environment cloning and the Qovery Terraform provider give you a deployment history that answers "which image, which config, which region, which date", the raw material for Annex IV.
Audit logs and RBAC. Every deployment and configuration change is attributed to a user or a named API token, and access is scoped per project and environment. AI agents can be restricted further with OPA-based policy tokens.
Observability and cost visibility with Qovery Observe, so post-market monitoring has a home.
Qovery does not make you AI Act compliant, and nobody selling a platform can. Classification, risk management, human oversight and conformity assessment are yours. Qovery removes the excuse that self-hosting in your own account is too much work without a dedicated DevOps or platform team. For the logging design itself, our guide to AI agent governance controls at scale goes deeper on Article 12-style records.
How do I set this up with Qovery from Claude Code or Cursor?
Install the Qovery Agent Skills once, and your coding agent can deploy your inference service and its dependencies to your own cloud account through Qovery, instead of you writing Kubernetes manifests by hand.
curl -fsSL https://skill.qovery.com/install.sh | bash
# 2. Or scoped to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project
# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
# 4. Write access, only when you explicitly want it (also enable write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
Your agent asks you to approve the install script, and the MCP Server opens an OAuth login in your browser, so it acts with your own Qovery permissions. Then ask in plain language, for example: "deploy this inference API to my AWS account in eu-west-3 with Qovery". The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) deploy; the MCP Server operates what already exists. Start with the AI agent quickstart or the Claude Code integration.
Frequently asked questions
What does the EU AI Act high-risk obligations deadline mean for where you host and deploy AI infrastructure?
The high-risk deadline, now 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products, does not require EU hosting. It requires automatic logging, at least six months of log retention, 10 years of technical documentation and remote access for authorities. In practice that favours running inference in a cloud account and region you control, with pinned model versions and logs you own, because every audit request then maps to data you can export.
Was the EU AI Act high-risk deadline postponed?
Yes. The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027, and for high-risk AI in Annex I products to 2 August 2028. GPAI obligations, Article 50 transparency and the prohibited practices kept their original dates.
Does the EU AI Act require AI models to be hosted in the EU?
No. The EU AI Act has no data localisation article. Hosting location is constrained by GDPR transfer rules, sector regulation and public procurement policies, and non-EU providers of high-risk systems must appoint an authorised representative in the EU under Article 22.
How long do I have to keep logs for a high-risk AI system?
Providers under Article 19 and deployers under Article 26(6) must keep automatically generated logs for at least six months, to the extent the logs are under their control, and longer where other EU or national law requires it. Providers must also keep technical documentation, quality management records and the EU declaration of conformity for 10 years under Article 18.
Can I use a US-hosted AI API for a high-risk use case?
Yes, if your GDPR transfer basis and your customers' procurement rules allow it. You then depend on the vendor for logs, retention, model version stability and authority access, so put those rights in the contract, as Article 25(4) expects for suppliers of AI components. Many teams find it simpler to run Annex III inference in their own EU-region cloud account.
Does the AI Omnibus delay change anything for public sector AI?
New high-risk systems used by public authorities follow the same 2 December 2027 date, and legacy systems used by public authorities must comply by 2 August 2030 under Article 111(2). Public deployers must also register their use in the EU database and run a fundamental rights impact assessment under Article 27, and national procurement rules such as the Dutch BIO2 baseline apply on top.
Morgan co-founded Qovery and leads engineering. He writes about Kubernetes architecture, DevOps best practices, and building resilient infrastructure at scale.
Next step
Run high-risk AI on infrastructure you can prove things about.
Qovery deploys your models and apps on Kubernetes in your own AWS, GCP, Azure or Scaleway account, or your existing cluster, with audit logs, RBAC and region choice built in. Talk to us about your AI Act roadmap.
