AI Act enforcement is now real: an Azure deployer checklist
On Sunday 2 August 2026, the EU AI Act stopped being a compliance deadline on a slide and became an enforcement regime. Exactly one year after the obligations for general-purpose AI (GPAI) model providers took effect, the European Commission's supervision and enforcement powers over those providers activated. The AI Office can now demand technical documentation, run its own evaluations of models, order risk-mitigation measures, restrict or withdraw a model from the EU market, and fine providers up to 3% of annual worldwide turnover or EUR 15 million, whichever is higher. The same date brought two more changes that land directly on enterprises: the Article 50 transparency obligations began to apply, and every member state was required to have at least one operational AI regulatory sandbox.
If your organisation consumes GPAI models through Azure OpenAI or Azure AI Foundry, this date matters twice. First, the companies behind the models you call (OpenAI, Anthropic, Meta, Mistral and others) are now subject to active enforcement, which changes what documentation you can and should demand from them. Second, some obligations under the Act attach to you, not to the model vendor, and 2 August is the date several of them became applicable. This guide separates the two: what to demand from your vendors, and what remains yours as a deployer or downstream provider.
What changed on 2 August 2026
The Commission's GPAI enforcement toolkit is switched on
The GPAI obligations themselves are not new. Articles 53 and 55 have applied since 2 August 2025: providers must maintain technical documentation, supply information to downstream providers, adopt a copyright compliance policy, and publish a summary of training data. What was missing for the past year was the stick. The AI Act deliberately gave providers a twelve-month adjustment period before the Commission could act on non-compliance.
That period is over. From 2 August 2026 the Commission can request documentation and information under Article 91, conduct model evaluations under Article 92, and demand compliance measures, risk mitigation or market restrictions under Article 93, up to and including withdrawal of a model from the EU market. Article 101 backs this with fines of up to 3% of total worldwide annual turnover or EUR 15 million, whichever is higher. Enforcement can be triggered not only by the Commission's own monitoring but also by complaints from downstream providers and alerts from the scientific panel. One nuance for planning: models placed on the market before 2 August 2025 have until 2 August 2027 to reach full compliance, so expect a staggered enforcement picture across the model catalogue you use.
Article 50 transparency now applies to systems you build and run
The second change is broader than GPAI. Article 50 imposes transparency duties on providers and deployers of certain AI systems, and it applies from 2 August 2026. In outline: providers of systems that interact directly with people (chatbots, agents, avatars) must make sure users know they are dealing with AI, unless that is obvious to a reasonably well-informed person. Providers of generative systems must mark synthetic audio, image, video and text output in a machine-readable format so it can be detected as artificially generated. Deployers must disclose the operation of emotion recognition and biometric categorisation systems to the people exposed to them, must label deepfakes clearly, and must label AI-generated text published to inform the public on matters of public interest unless it has gone through human review and editorial control.
Two practical footnotes. There is a narrow grace period: generative AI systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking obligation, and content generated before the deadline does not need retroactive labels. And there is fresh guidance to work from: on 20 July 2026 the Commission published the final version of its Guidelines on Transparency Obligations under Article 50 and confirmed the voluntary Code of Practice on Transparency of AI-generated content as an adequate compliance instrument. Those two documents are what national market surveillance authorities will assess against, so they belong in your compliance file next to the Act itself.
What did not change: the Digital Omnibus deferral
A week before this milestone, on 24 July 2026, Regulation (EU) 2026/1744 (the Digital Omnibus on AI) was published in the Official Journal, entering into force on 27 July. It postponed the high-risk obligations: standalone Annex III high-risk systems now have until 2 December 2027, and AI embedded in products covered by EU product-safety law (Annex I) until 2 August 2028. It is tempting to read that as a general delay of the AI Act. It is not. The Omnibus left the GPAI enforcement date, the Article 50 transparency obligations and the Article 4 AI literacy duty exactly where they were. If your compliance programme paused when the Omnibus headlines landed, 2 August is the date that should have restarted it.
Provider or deployer: where you sit when you consume GPAI via Azure
The Act's obligations attach to roles, and most enterprises hold more than one at once. Getting the mapping right per system is the single most useful compliance exercise you can run this month.
- GPAI model provider: the organisation that developed and placed the model on the market. For GPT-4-class models on Azure OpenAI that is OpenAI; for models in the Foundry catalogue it is Anthropic, Meta, Mistral, xAI or whoever built the model. Chapter V obligations and the new Commission enforcement powers target them, not you.
- Provider of an AI system: whoever develops an AI system and places it on the market or puts it into service under their own name. Build a customer-facing chatbot on Azure OpenAI and run it under your brand, and for Article 50 purposes the provider of that system is most plausibly you. The disclosure duty ("you are talking to AI") and the machine-readable marking duty for generated content then sit with your team, not with Microsoft or OpenAI.
- Deployer: an organisation using an AI system under its own authority. Deployer duties under Article 50 cover deepfake labelling, public-interest text labelling and disclosure of emotion recognition or biometric categorisation. Buy a SaaS product with embedded generative AI and you are typically a deployer of it.
The uncomfortable consequence: consuming a compliant GPAI model does not make your system compliant. Vendor documentation flows down the chain to help you, and Article 53 obliges model providers to give downstream providers the information they need, but the transparency surface your users see is yours to build.
What to demand from your model vendors
Active enforcement changes vendor conversations. A year ago, asking a model provider for AI Act documentation got you a roadmap answer. Now the provider faces information requests, evaluations and fines, which means the documentation exists and you can ask for the parts you are entitled to. Concretely:
- 1. Code of Practice status. The GPAI Code of Practice signatory list published on 1 August 2025 includes Amazon, Anthropic, Google, IBM, Microsoft, OpenAI, Mistral AI and Aleph Alpha. Meta declined to sign, and xAI signed only the Safety and Security chapter. Signatories benefit from a presumption that following the Code meets the corresponding obligations; non-signatories must demonstrate compliance another way. If you consume Llama or Grok through Foundry, ask how the provider demonstrates Article 53 compliance without the Code.
- 2. Downstream documentation under Article 53. Request the model documentation the provider owes downstream providers: capabilities, limitations, intended tasks and integration guidance. File it per model version you run in production.
- 3. Training data summary and copyright policy. Both are mandatory publications for GPAI providers. Record the links and dates in your vendor file; your legal team will want them the first time a copyright question about model output arrives.
- 4. Marking support for generated content. Your Article 50 machine-readable marking duty is far easier if the model or platform emits provenance signals. Ask Microsoft and your model vendors what watermarking and content-provenance support exists today per modality, and what is on the roadmap before the 2 December 2026 marking grace period ends.
- 5. Contractual pass-through. Check that your Azure agreements and any model-specific terms commit the vendor to maintaining AI Act compliance and to notifying you of enforcement actions that affect models you depend on. A model withdrawn from the EU market under Article 93 is now a real, if unlikely, availability risk; it belongs in your exit and fallback planning alongside region failover.
What remains your responsibility
No vendor letter covers these. As of 2 August 2026 the following sit with your organisation for the systems you build or run:
- Interaction disclosure. Every customer-facing chatbot, voice agent or avatar you provide must tell users they are interacting with AI, clearly and at the latest at first interaction, unless it is genuinely obvious. Audit your UX copy, not just your policy documents.
- Machine-readable marking. Generative systems you provide must mark synthetic output so it is detectable as AI-generated. For text this is the hardest modality; the Commission's July guidelines and the Transparency Code of Practice are the reference points for what counts as adequate.
- Deepfake and public-interest text labelling. If your marketing or communications teams publish AI-generated imagery of real people or AI-drafted text informing the public, deployer labelling duties apply. Human editorial review lifts the text-labelling duty, so document your review workflow.
- Emotion recognition and biometric categorisation disclosure. Less common in enterprise Azure estates, but if any HR, retail-analytics or contact-centre tooling does this, the people exposed must be informed.
- AI literacy. Article 4 has applied since February 2025 and survived the Omnibus untouched. Staff who operate AI systems need a sufficient level of AI literacy; keep training records.
- An accurate system inventory. Every duty above is per system and per role. Without an inventory that records what each system does, which model powers it, and whether you are provider or deployer of it, you cannot even scope the work.
The Swedish and EU angle
Enforcement is split, and the split matters. GPAI model enforcement is centralised: the Commission's AI Office supervises the model providers, so Swedish enterprises are not the target of the powers that activated this week. Article 50, by contrast, is enforced by national market surveillance authorities against providers and deployers of AI systems, which includes Swedish organisations directly. Sweden's supervisory structure under the Act is still being stood up, and early national enforcement everywhere tends to start with information requests rather than fines. That is an argument for having your documentation ready, not for waiting.
Sandboxes became an obligation, not an ambition. Article 57 required every member state to have at least one AI regulatory sandbox operational by 2 August 2026, alone or jointly with other member states. For teams building anything that may later fall under the deferred high-risk rules, a sandbox offers supervised development with regulator dialogue and documented evidence of good faith. If you have a borderline Annex III use case on the 2027 horizon, ask now what access looks like in Sweden rather than discovering the queue in a year.
Procurement language should catch up this quarter. Swedish public-sector and regulated buyers already ask suppliers about GDPR and NIS2 posture as standard. AI Act questions now have teeth behind them, so add them: which GPAI models power the offering, the providers' Code of Practice status, how Article 50 marking and disclosure are implemented, and who holds the provider role for each system in the delivery. Suppliers who cannot answer in August 2026 are telling you something useful.
A 30-day plan for Azure teams
- Week 1: Build or refresh the AI system inventory. For each system: purpose, model and version, Azure service, user-facing or not, and your role (provider, deployer or both).
- Week 2: Run the Article 50 gap check. Interaction disclosure in every chatbot UX; marking approach per generative modality; labelling workflow for deepfakes and public-interest text; disclosure for any emotion or biometric systems. Log the 2 December 2026 marking grace date for systems already in market.
- Week 3: Send the vendor documentation requests from the checklist above for every GPAI model in production, and record Code of Practice status per provider. Flag non-signatory models for extra diligence.
- Week 4: Close the governance loop. File the Commission's July transparency guidelines, confirm Article 4 literacy training coverage, brief legal on the Omnibus deferral so nobody assumes Article 50 moved, and put model-withdrawal risk into your Azure fallback planning.
The AI Act's first enforceable date for the models Swedish enterprises actually use has arrived quietly, without dawn raids or headline fines. Treat the quiet as runway. The organisations that spend August building the documentation trail will handle the first information request as routine correspondence rather than a crisis.
Sources
- Future of Life Institute: Enforcement of Chapter V under the EU AI Act
- European Commission: Transparency obligations under Article 50 of the AI Act (FAQ)
- The EU AI Act's Transparency Rules: A Practical Guide to Article 50
- Gibson Dunn: EU AI Act Omnibus Agreement, postponed high-risk deadlines and other key changes
- Faegre Drinker: Commission confirms Transparency Code of Practice as adequate and publishes final Article 50 guidelines
- EU AI Act, Article 57: AI regulatory sandboxes
- General-Purpose AI Code of Practice: signatories and status