For engineering teams running cloud AI workloads in the EU, two clocks matter more than any vendor roadmap: the AI Act’s transparency rules took effect in August 2026 while the full high-risk regime applies from 2 December 2027, and the data-residency defaults baked into your cloud provider decide whether the pipeline behind your model is defensible long before anyone writes a compliance document. This guide maps the deadlines that actually change engineering work, the Azure settings that quietly route prompts across borders, and a deploy-time checklist for cloud AI compliance reviews. If you are still scoping what counts as cloud AI for your stack, start with our practical cloud AI guide for Portugal before layering compliance obligations on top of it.
What the AI Act changes
The AI Act, formally Regulation (EU) 2024/1689, is the first comprehensive legal framework on AI anywhere, and it sorts systems into four risk tiers: unacceptable, high, limited and minimal. The unacceptable tier is already live: eight prohibited practices, from social scoring to untargeted scraping of images for facial-recognition databases, have applied since February 2025, and a ninth prohibition covering non-consensual synthetic intimate imagery follows in December 2026. For most product teams the immediate exposure sits one tier down.
At the model layer, rules for general-purpose AI models started applying on 2 August 2025, imposing transparency, copyright and, for models flagged as systemic-risk, safety obligations on providers. If you fine-tune or materially modify a general-purpose model and place it on the EU market, those duties flow down to you. If you only deploy third-party models, the binding model-level duties sit mostly with the provider, but your system documentation still has to name the models, their versions and their provenance, which is a configuration-management problem before it is a legal one.
The high-risk tier is where cloud AI projects get expensive. Use cases explicitly listed include CV-sorting software for recruitment, credit scoring that gates access to loans, exam scoring in education, AI safety components in critical infrastructure and biometric identification systems. From the December 2027 application date, such systems need risk assessment and mitigation, high-quality training datasets, activity logging for traceability, detailed technical documentation, human oversight measures and demonstrated robustness, accuracy and cybersecurity. None of that is retrofittable at the last minute: logging schemas, evaluation harnesses and documentation pipelines have to exist inside the architecture, which is why the window between now and the application date is when the engineering work has to happen rather than the paperwork.
The timeline that matters
Dates, not intentions, drive this programme. The table below is the compressed version engineering leads should keep pinned next to the release calendar.
| Date | What applies | Who is affected |
|---|---|---|
| 2 February 2025 | Prohibitions on the listed unacceptable practices | Any provider or deployer in the EU market |
| 2 August 2025 | GPAI model rules: transparency, copyright, systemic-risk duties | Providers of general-purpose AI models |
| August 2026 | Transparency and labelling rules, including chatbot disclosure | Most deployers of AI systems |
| 2 December 2027 | Full obligations for high-risk AI systems | Providers and deployers of listed use cases |
| 2 August 2030 | Compliance deadline for high-risk systems used by public authorities | Public-sector providers and deployers |
Azure settings that move data
Residency in Azure is defined by the Geography you select, not the single region. Microsoft’s published commitment is blunt:
Microsoft will not store or process customer data outside the customer-specified Geo without your authorization.
The exceptions list is where AI teams get caught, because AI services carry the widest carve-outs. The decisive setting for anyone calling hosted models through Azure AI Foundry is the deployment type. A model deployment labelled Global may process prompts and completions in any Microsoft Foundry region globally, for inference and for fine-tuning, while a deployment labelled DataZone keeps that processing inside the specified data zone. The same model with the same endpoint contract produces materially different data flows, so prefer DataZone deployments for any workload with EU residency commitments and record the deployment type explicitly in your architecture decision records rather than trusting whatever the portal defaulted to.
Metadata services are the second trap. Azure Databricks stores identity information in the United States to support its global account platform, meaning usernames, first names, last names and email addresses land outside the EU Geography regardless of where your clusters run. Azure Machine Learning adds another: freeform asset names such as workspace, resource group, experiment and file names, plus experiment execution parameters, may be stored in the United States for debugging. Neither exception necessarily breaks your model-data residency position, but both belong in a data-protection impact assessment whenever personal data is in scope. Treat them as known transfers you document up front instead of findings you discover in an audit.
For teams designing the surrounding platform, the residency question is inseparable from region topology: our Azure enterprise architecture guide covers how AKS clusters and a multi-cloud strategy interact with these constraints in practice.
A deploy-time compliance checklist
Run this checklist when a new AI workload reaches staging, not when legal asks for it:
- Classify the use case against the high-risk list: recruitment filtering, credit scoring, education scoring, critical-infrastructure safety components, biometrics. A match means budgeting for conformity assessment now, not in the release review.
- Pin the deployment type: DataZone or regional for anything under EU residency commitments, and verify the setting in infrastructure code so a redeploy cannot silently revert it.
- Map every cross-border flow, including the US-stored identity metadata from Databricks and the experiment metadata from Azure Machine Learning, and record the lawful basis for each.
- Turn on activity logging with a defined retention window and tamper-evidence; the traceability obligation is written against logs, not intentions.
- Version the technical documentation with the system itself: purpose, datasets, evaluation results, known limitations and the model versions in each environment.
- Design the human oversight path for any listed system: who can override the output, through which interface, and what the override writes to the audit trail.
- Label AI-generated content and disclose machine interaction for chatbots and assistants, as the transparency rules already require.
- Establish the incident route: who reports a serious incident to the market surveillance authority, using which template, inside which deadline.