The search term cloud.ai signals a concrete engineering question, not a product: how should teams running AI workloads on EU cloud infrastructure adapt now that the AI Act’s main application milestones have passed? The short answer is that the transparency rules took effect in August 2026, general-purpose AI model rules have applied since August 2025, and any team embedding third-party models into production systems carries deployer obligations it cannot delegate to the cloud vendor. For background on how AI capability delivery works in practice, see our overview of cloud AI capability delivery and the practical EU delivery view.

What Applies Today

The AI Act entered into force on 1 August 2024 with staggered application dates, so a single “AI Act is live” framing is wrong for engineering planning. Prohibitions and AI literacy duties started on 2 February 2025. Rules on notified bodies, GPAI models, governance, confidentiality and penalties started on 2 August 2025. The remainder of the Act applies from 2 August 2026, except Article 6(1), which applies from 2 August 2027 together with the obligations for high-risk systems under it. The Commission dates each stage precisely, and treating the wrong date as the operative one is the most common planning error teams make. If your system is not high-risk and does not fall under the transparency categories, most of the Act imposes no new direct duties today, but the analysis has to be recorded, not assumed.

Obligations For Model Integrators

Most cloud AI teams are not model providers; they integrate general-purpose AI models accessed through a hosted API. That integration step is exactly where the Act bites. Since August 2025, providers of GPAI models must maintain technical documentation, information for downstream providers integrating the model, and a policy on copyright, while models designated as systemic-risk carry additional evaluation and mitigation duties. When your pipeline consumes such a model, the documentation you receive becomes part of your own compliance trail: you are expected to keep it, verify that your use matches the intended purpose described, and pass required transparency information through to your own deployers and users. Annex XII defines what that downstream documentation must contain, including the model’s intended tasks, acceptable use policy, release and distribution method, architecture and parameter count, input and output modalities, and licence. In practice this means your vendor’s model card is now a legal input to your architecture records, not marketing collateral.

Transparency Duties In Production

The transparency rules applying from August 2026 are the ones most cloud-hosted products actually touch. Chatbots and similar interactive systems must make users aware they are interacting with an AI system. Synthetic audio, image, video or text content must be identifiable as AI-generated, with machine-readable marking where the content is significantly manipulated or deepfake-like. Teams shipping assistants, summarisation features or generated media inside an EU-facing product need disclosure patterns in the interface, not only in a policy document. For deployments structured around EU residency and data controls, the approach described in running AI workloads with EU constraints remains the right starting point, with disclosure added as an explicit acceptance criterion in the release checklist.

Provider Versus Deployer Roles

The Act distinguishes providers, who develop or substantially modify an AI system and bear the heaviest obligations, from deployers, who use an AI system under its intended purpose. A team fine-tuning a hosted base model for its own product can shift into provider territory depending on how substantial the modification is, which changes the documentation burden materially. Role determination is the first compliance decision, because it sets whether you owe conformity documentation or mainly transparency, oversight and logging duties. Cloud infrastructure vendors are generally neither provider nor deployer for your application layer, so contracting with a hyperscaler does not transfer responsibility to the hyperscaler.

Practical Compliance Checklist

1. Classify each AI system in production as minimal, transparency, limited or high risk, and record the decision with its rationale and date.
2. Identify every GPAI model consumed via API, its provider, and the version pinned in each pipeline.
3. Collect and version the downstream technical documentation received from each model provider.
4. Add user-facing disclosure to every interactive or generative feature shipped to EU users.
5. Implement logging sufficient to reconstruct how a specific output was produced, including model version and key prompts.
6. Keep human oversight for any use case affecting employment, credit, education or essential services access.
7. Review fine-tuning work annually to determine whether modifications make you a provider.
8. Track remaining milestone dates, in particular the 2 December 2026 prohibition on AI-generated non-consensual intimate content and the 2 August 2027 full application of Article 6(1).

The overall shape of the regime is now stable enough to build against: risk classification first, documentation second, transparency third. Teams that treat the model card as an architectural artefact and the disclosure pattern as a UI requirement will find the remaining steps mechanical rather than open-ended.

Sources

• Regulation (EU) 2024/1689 (AI Act), EUR-Lex
• European Commission, AI Act policy page
• AI Act implementation timeline, Future of Life Institute

For teams that need a starting inventory, three questions locate the obligations quickly: does the system interact with EU users, does it generate synthetic content, and has the team substantially modified a third-party model. The European Commission states that the AI Act is the first legal framework on artificial intelligence worldwide, which it adopted in 2024; the staggered application dates it publishes are the operative planning calendar for engineering teams. Recording these answers per system, with the model versions pinned, turns a regulatory question into a reviewable engineering artefact and is the cheapest compliance work a team can do this quarter.