EU AI Act 2026: The 23-Day Compliance Playbook Before August 2

It is July 10, 2026. In 23 days, on August 2, the next major wave of the EU AI Act switches on. The prohibited-practices list has been enforceable since February 2025 and the governance scaffolding has been quietly assembled for 18 months. What lands on August 2 is the layer that touches almost every product team shipping AI in Europe: the transparency rules, the general-purpose AI (GPAI) obligations, the penalties, and the practical reality that national regulators now have the tools to act.

Most companies outside the EU are still treating this as a Europe-only problem. That is the wrong read. Like GDPR in 2018, the AI Act is becoming a de facto global standard. A vendor in Toronto, a SaaS founder in Singapore, and a US-based model provider are all in scope the moment they have users in the EU. The compliance work is not optional, and the clock has started.

This is the practical guide I wish had existed six months ago: what is actually enforceable on August 2, what the regulator will and will not care about, and what to do in the next 23 days if you are starting from cold start.

What changes on August 2, 2026

The AI Act is a phased regulation. Each phase brings a different set of obligations into force, and most of the public confusion comes from conflating them. Here is the clean picture for 2026.

Phase	Effective	What is enforceable
Prohibitions	February 2, 2025	The eight banned practices: social scoring, untargeted facial-recognition scraping, manipulative AI, real-time biometric ID in public spaces, etc.
GPAI model obligations	August 2, 2025	Provider duties for general-purpose AI models: training-data summary, copyright policy, technical documentation.
Transparency + governance + penalties	August 2, 2026	Article 50 transparency rules, full high-risk regime, EU AI Office enforcement powers, administrative fines.
High-risk system compliance (Annex III)	August 2, 2027	Full high-risk obligations for systems embedded in regulated products (medical devices, machinery, toys, etc.) under Annex I.

The August 2, 2026 date is the one product, legal, and engineering teams need to plan around. It is when three things converge.

First, the Article 50 transparency rules become enforceable. If you put a chatbot in front of a user, the user has to know they are talking to a machine. If you generate images, audio, or video, you have to mark them as AI-generated in a way a reasonable person can detect. Deepfakes need visible disclosure. Text published to inform the public on matters of public interest needs labeling too. This is the rule that will most visibly hit consumer products.

Second, the GPAI regime stops being advisory and starts being enforced. Providers of general-purpose AI models — anyone training or substantially modifying a model with systemic capabilities, including the frontier model labs and an expanding list of mid-tier providers — must publish a sufficiently detailed summary of training data, comply with EU copyright law (with the new opt-out for text-and-data mining), and produce technical documentation for downstream providers. The voluntary GPAI Code of Practice published in 2025 is treated as a sufficient compliance route for most providers, but signing it is not the only way.

Third, the penalty regime is fully armed. Fines for prohibited practices can reach €35 million or 7% of global annual turnover, whichever is higher. Fines for GPAI violations can reach €15 million or 3% of turnover. Member-state authorities can now issue orders, demand information, and trigger market-surveillance action. This is the part the legal teams should be most concerned about, because until now most enforcement has been informal.

Who is actually in scope

The AI Act uses an extraterritorial model similar to GDPR. You are in scope if you are a provider, deployer, importer, or distributor of an AI system, and the system outputs are used in the EU. The nationality of the company does not matter. The location of the user does. If you have a paying customer in Frankfurt, the Act applies.

Three roles matter in practice.

• Provider: develops or has developed an AI system and places it on the market. If you built the model, you are usually the provider. If you fine-tuned and rebranded a foundation model, you are likely the provider of the resulting system.
• Deployer: uses an AI system in a professional context. If you integrated OpenAI or Anthropic into your product and ship it to EU users, you are a deployer of that system. The deployer obligations are lighter than the provider obligations but they are not zero.
• Importer / Distributor: makes non-EU AI systems available on the EU market. If you resell or white-label a non-EU tool, you inherit specific duties.

The most common mistake I see is teams assuming that calling an OpenAI or Anthropic API makes OpenAI or Anthropic the sole responsible party. It does not. If you fine-tuned the model on your data, you are likely a provider of a new system. If you are merely calling the API as a deployer, you still have Article 50 transparency obligations, plus downstream documentation duties, plus the requirement to keep logs of high-risk use cases.

The risk-tier model: where most teams sit

The Act organizes obligations around four risk tiers. Most companies overestimate their risk tier, which leads to expensive over-compliance, and a few underestimate it, which is a much worse mistake.

Unacceptable risk (prohibited since Feb 2025)

You are in this bucket if you do any of the following: social scoring of individuals, untargeted scraping of facial images to build recognition databases, real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), emotion recognition in workplaces or schools, manipulation that distorts decision-making in ways that cause significant harm. If you are doing any of these, you are already non-compliant. Stop.

High risk (full regime from Aug 2, 2026)

You are high-risk if your system is in any of the eight Annex III categories: critical infrastructure, education, employment, essential services (credit scoring, insurance pricing, emergency dispatch), law enforcement, migration and border control, justice and democratic processes, or safety components of regulated products. The full list is in Annex III. The honest take: the Annex III high-risk list is the most misread section of the Act. CV-sorting tools, exam-scoring systems, credit-decisioning models, and tenant-screening services are all in scope. If your startup sells a recruiting product, you are high-risk. If your fintech uses a model to decide who gets a loan, you are high-risk.

Transparency / limited risk (the Aug 2, 2026 layer)

This is the bucket that catches most consumer and B2B SaaS companies. You do not face the full high-risk regime, but Article 50 applies: chatbot disclosure, AI-content labeling, deepfake disclosure, biometric categorization disclosure, emotion recognition disclosure (where allowed). If you deploy a chat assistant, generate any synthetic content shown to users, or run an emotion or biometric system, you are here.

Minimal or no risk

Spam filters, AI in video games, internal RAG systems with no EU user, basic recommendation engines, and most ordinary CRUD-with-AI features live here. The Act does not require you to do anything specific. You can still be asked to keep documentation if a regulator investigates, so keep some.

The Article 50 transparency rules: what they actually require

Article 50 is the single most impactful provision for product teams. Here is what it concretely requires, with the operational interpretation that has crystallized through 2025 guidance documents.

• Chatbot disclosure. Users must know they are interacting with an AI. The disclosure has to be clear and explicit — a tiny “AI” badge hidden in the corner is not sufficient in most member states. The 2025 guidelines from the AI Office clarify that disclosure must be at the start of the interaction and reasonably prominent.
• Synthetic content marking. AI-generated images, audio, and video must be machine-readable as AI-generated. The accepted technical implementation is C2PA content credentials, watermarking, or equivalent metadata. A text caption saying “AI-generated” is necessary but not sufficient. The metadata must travel with the file.
• Deepfake disclosure. If you generate or manipulate an image, audio, or video that resembles a real person, you must disclose that it is artificially generated or manipulated. The disclosure must be clear and visible.
• Public-interest text labeling. Text published to inform the public on matters of public interest must be labeled as AI-generated, unless the output has been reviewed by a natural person and a human or editorial responsibility is held.
• Emotion recognition and biometric categorization. Disclosure to affected individuals, except where used for law enforcement (which is restricted or prohibited depending on context).

The good news: if you use C2PA today, you are largely compliant on the marking side. If you are on the C2PA spec by the end of July 2026, the regulator will treat you as having met the disclosure obligation. The C2PA coalition expanded significantly through 2025 and is now the practical standard.

The GPAI reality for non-frontier providers

The most-discussed part of the AI Act is the GPAI model obligations. Most of the loud commentary is about OpenAI, Anthropic, Google DeepMind, and Meta — all of whom have signed the GPAI Code of Practice published in mid-2025. What is less discussed is the long tail of providers, including fine-tuning shops, hosted model platforms, and companies training domain-specific models in-house.

You are a GPAI provider if your model has significant generality and is integrated into downstream systems. The European AI Office has been explicit that fine-tuned derivatives of foundation models can be GPAI in their own right, especially if the fine-tune substantially changes model behavior. The systemic-risk threshold kicks in at 10^25 FLOPs of training compute, which captures roughly the top 5-10 models by capability as of 2026.

For providers below the systemic-risk threshold, the obligations are: publish a summary of training data (sufficiently detailed to allow downstream providers to understand the data), comply with EU copyright law (which now has a reservation-of-rights opt-out for TDM under the DSM Directive), and produce technical documentation for downstream providers. Signing the GPAI Code of Practice is one way to demonstrate compliance; building your own equivalent program is also acceptable.

For providers at or above the systemic-risk threshold: model evaluations, adversarial testing, serious incident reporting to the AI Office, and cybersecurity protection of the model weights.

The 23-day compliance checklist

If you are starting from a cold start and shipping an AI product with EU users, here is the order of operations for the next 23 days. This is what I would do, in priority order, as a CTO or head of product.

1. Map your systems to the four risk tiers. Spend a day, not a week. For each AI feature you ship, classify it as prohibited, high-risk (Annex III), transparency-only, or minimal. Write the classification down. The classification itself is your first compliance artifact.
2. Fix chatbot disclosure. If you have a chat UI, add a clear, persistent, prominent disclosure that the user is talking to an AI. Top of the conversation, not a footnote. This is the most common Article 50 violation and the easiest to fix.
3. Add C2PA content credentials to generated media. If you generate images, audio, or video, sign them with C2PA manifest credentials. There are now turnkey C2PA libraries for the major generation stacks. The August 2 deadline for marking is concrete; ship this in the next two weeks.
4. Write the Article 50 transparency notice. Publish a one-page disclosure explaining to users when they are interacting with AI and what is generated. Link to it from every AI-touching surface. This is required.
5. Decide on the GPAI Code of Practice path. If you are a GPAI provider, choose: sign the Code, or build an equivalent program. If you are a deployer, document your provider’s compliance. Both are audit-defensible.
6. Document your training data lineage. If you trained or fine-tuned a model, write a one-page summary of what data went in, where it came from, and whether rights-holders opted out. This is the GPAI summary requirement. The first draft does not need to be perfect; the requirement is that it exists and is not misleading.
7. Set up incident reporting. If you are high-risk, you have a duty to report serious incidents to the relevant market surveillance authority. Decide your internal channel now, before you need it. Email to a regulator with a 72-hour SLA is harder to retrofit than a Slack workflow.
8. Update your DPA and contracts. Make sure your customer-facing agreements reflect your role (provider, deployer, both), and that your upstream provider agreements include the AI Act representations you are relying on. The contract trail is what saves you in an enforcement action.
9. Notify your board. A one-line update to the executive team is enough. The Act’s fines are large enough that the board should know what is in scope and what is not.

That list is roughly 80% of the compliance work for a non-high-risk deployer. It is uncomfortable but doable in 23 days.

When the AI Act is a good fit, and when it is not

The Act is not the right frame for every AI product decision. Some honest distinctions.

It is a good fit if: you ship a consumer or B2B AI product with EU users; you are a model provider serving EU customers; you are a company in a regulated industry using AI for high-impact decisions; you operate in a sector where public trust is a competitive lever; you have been wanting to formalize your AI governance anyway.

It is the wrong lens if: you are an internal-only AI tool with no EU users and no path to EU users; you are a research lab that is not shipping a product; you are a hobbyist running models locally for personal use; the marginal cost of the regulation is larger than the marginal value of the EU market to your business, in which case the question is product strategy, not compliance.

There is also a third bucket worth naming: the companies for whom the Act is a forcing function they secretly want. If you have been trying to get engineering and legal to take AI risk seriously, the Act gives you the air cover to do it. The compliance work is good work, regardless of whether the regulator ever reads it.

Common mistakes

After watching a number of teams approach this, the failure modes are remarkably consistent.

• Classifying yourself as minimal risk to avoid the work. This is the most common and most consequential mistake. If your product touches credit decisions, employment, education, law enforcement, justice, or any of the Annex III categories, the Act classifies you as high-risk whether you call it that or not. Wishful thinking is not a defense.
• Treating the GPAI Code of Practice as optional because it is voluntary. The Code is a way to demonstrate compliance, not a regulatory requirement. Not signing it does not exempt you from the underlying obligations. If you skip the Code, you must build an equivalent program, and most teams that take this path build a worse version of the Code.
• Assuming the Act does not apply because you are outside the EU. If you have EU users, you are in. If your model outputs are used in the EU, you are in. The Act is territorial by user location, not by company HQ.
• Reading “AI system” too narrowly. The 2025 guidelines on the AI system definition expanded the scope significantly. If your product uses machine learning to make or substantially influence a decision, you are probably an AI system. If you are a SaaS that just calls an LLM API, the integrated system is usually an AI system even if the API is a thin wrapper.
• Ignoring the C2PA technical detail. The Act requires the marking to be machine-readable. A human-visible watermark is not enough. If you are not using C2PA, IPTC, or an equivalent signed manifest, you are not compliant.
• Forgetting the deployer obligations. Even if you are a deployer (not a provider) you have duties: human oversight, log-keeping for high-risk systems, fundamental rights impact assessments in some cases, and information obligations to the people affected.
• Waiting for national guidance to finalize. Member states are still publishing their national implementation details. That is not a reason to pause. The Act’s text is the legal floor; the national guidance will only raise it.
• Underestimating the cost of internal documentation. Compliance lives in artifacts: risk classifications, training-data summaries, incident reports, FRIA templates, technical documentation. Building the template library is the unglamorous bulk of the work.

Practical tooling and resources

The ecosystem has matured significantly through 2025. The AI Office and member states have published the following, all worth using.

• The AI Act Explorer at artificialintelligenceact.eu for the full consolidated text, with cross-references.
• The Compliance Checker from the same site, which walks through a 10-minute self-assessment for SMEs.
• The Commission’s published guidelines on prohibited practices and on the AI system definition (both released in 2025).
• The C2PA technical specification for content credentials, with reference implementations in most major image and video libraries.
• The GPAI Code of Practice template documentation, which most providers can largely lift and adapt.
• The AI Office’s incident-reporting template for serious incidents, available through the AI Office portal since early 2026.

None of these are substitutes for legal advice, but they reduce the cost of the first draft by a lot.

What is still overhyped vs. what is worth doing now

The Act has been covered like a tech trend, and a lot of the commentary is bad. Three honest opinions.

Overhyped: the idea that the Act will “kill the European AI industry.” It will not. The compliance cost is real but it is a fixed cost, not a per-query tax, and it does not stop model development. The companies complaining the loudest are the ones who would have to clean up their training data practices anyway.

Overhyped: the idea that the Act is “just like GDPR” and can be copy-paste complied with. The Act has a different structure: risk-tier based, with provider/deployer/importer/distributor roles that do not map cleanly to data-controller/processor. Trying to GDPR-it will produce gaps.

Worth doing now: the documentation work. Even if your regulator never asks, the discipline of classifying your systems, summarizing your training data, and keeping an incident log is the kind of hygiene that makes every AI product team more reliable. Most of the value of compliance is internal.

FAQ

I am a US-based startup with no EU customers. Does the AI Act apply to me?

Not yet, by the territorial test. The moment you onboard a customer with EU presence, accept EU payment, or have an EU-based team member using the system professionally, the Act applies. If your roadmap includes the EU at all, the cost of compliance is roughly the same whether you do it now or in 18 months, but the option value of being able to say “we are compliant” is highest now.

What is the difference between a provider and a deployer, and why does it matter?

A provider develops or has the AI system developed and places it on the market under their name or brand. A deployer uses an AI system in a professional context. Provider obligations are heavier (full technical documentation, conformity assessment for high-risk, post-market monitoring). Deployer obligations are lighter (human oversight, log-keeping, transparency notices). The same company can be both for different products. If you fine-tune a model and ship the result, you are usually the provider. If you call an API, you are usually a deployer.

What is the GPAI Code of Practice, and do I have to sign it?

It is a voluntary compliance template published by the AI Office in 2025, with three chapters: transparency, copyright, and safety and security. Signing it is the easiest way to demonstrate GPAI compliance, but it is not the only way. You can build an equivalent program. Most providers are signing because it is faster than building a parallel program from scratch.

How is this different from GDPR?

Three structural differences. First, the Act is risk-tier based, not processing-based. Second, the obligations attach to the AI system as a product, not to personal data as an input. Third, the Act creates product-safety obligations (conformity assessment, CE marking, post-market monitoring) that GDPR does not. The two regulations overlap on personal data, and you have to comply with both, but they are not the same regulation.

What is the practical impact of the August 2 deadline if I do nothing?

If you have EU users and you do nothing, you are out of compliance. The realistic enforcement path is not an immediate fine; it is a market surveillance authority sending a notice, requesting information, and giving you 30 days to respond. But the fines, when they come, are big enough to be material to most companies. The cheap insurance is the 23-day checklist above.

Closing

The AI Act is not a future problem. August 2 is 23 days away. The work is not intellectually hard; it is organizationally hard. Pick a risk-tier classification for every system you ship, fix the chatbot and content-marking pieces first, write down the training-data summary, and tell your board.

The teams that are calm about the deadline are the ones that started in early 2025. The teams that are panicking are the ones that did not. There is still time to move from the second group to the first, but not much.