Everyone Relaxed About the EU AI Act: What Your Product Still Owes by August

What moved and what didn't

The AI Act's phased rollout just got more phased. But the shift isn't uniform—some deadlines moved back by over a year, others didn't move at all. The gap between the two is where most product teams will get caught.

The high-risk delay is real

The Digital Omnibus on AI, agreed on May 7 by the European Parliament and Council, is the first set of amendments to the AI Act since its adoption in 2024. The headline change: compliance deadlines for high-risk AI systems moved back.

• 𐩒Stand-alone high-risk systems under Annex III—employment screening, credit scoring, biometric identification, education, critical infrastructure—now face a December 2, 2027 deadline instead of August 2026.
• 𐩒High-risk systems embedded in regulated products like medical devices and vehicles got pushed to August 2, 2028.

The delay came because the standards, guidance, and compliance infrastructure that companies need weren't ready. Over 110 EU-based businesses lobbied for the pause. The Omnibus is still pending formal adoption—expected by July—but every major law firm and the AI Office itself are treating the new dates as the planning baseline.

Article 50: the deadline that didn't move

Article 50 transparency obligations take effect August 2, 2026, as originally scheduled. These aren't high-risk requirements. They apply to any AI system that interacts with people, generates content, recognises emotions, or categorises users biometrically. If your product does any of these—and most AI-native products do at least one—you have a live deadline. Non-compliance carries fines of up to €15 million or 3% of global annual turnover—the same penalty tier as GPAI violations.

The same date activates enforcement powers for general-purpose AI models. Providers of GPAI models have been subject to transparency and documentation obligations since August 2025, but the Commission couldn't fine them. From August 2, it can—up to €15 million or 3% of global annual turnover. The AI Office enforces GPAI obligations directly. For Article 50 and other provisions, enforcement sits with national market surveillance authorities in each member state.

And the provisions already in force stay in force. AI literacy obligations and prohibited practices have been live since February 2025. The risk-based classification system, the four tiers, the conformity assessment regime—none of that changed.

The Omnibus gave product teams more time on the hardest compliance work. It gave zero extra time on the compliance work that touches the interface.

What Article 50 means for your product

Article 50 creates four transparency obligations. Each one is a product design decision disguised as a legal requirement. And they don't stop at Europe's borders. The AI Act has extraterritorial reach: any organisation whose AI system is used within the EU or produces outputs affecting EU residents must comply, regardless of where the company is headquartered. If you run a SaaS product or an API-based AI service accessible from Europe, Article 50 applies to you.

Chatbot and AI interaction disclosure

If your product includes a chatbot, virtual assistant, copilot, or any conversational AI that interacts with users, you must inform them they're talking to an AI system. The disclosure must happen before or at the start of the first interaction. Not buried in terms of service. Not in a settings page. At the point of contact.

This sounds trivial. It isn't. The European Commission's draft guidelines on Article 50, published May 8, flag that one-time disclosure may not be enough in sensitive contexts—where users experience emotional distress, where there's a risk of emotional attachment, or where the stakes of the interaction are high. Periodic reminders and context-aware disclosures may be necessary. AI companion products are the obvious case, but the principle applies to any system where the user is emotionally invested.

For product teams, this means deciding:

• 𐩒Where in the interface the disclosure lives.
• 𐩒How it adapts to context (routine query versus sensitive interaction).
• 𐩒When it repeats—and what triggers the repetition.

That's an interaction design problem, not a legal one.

AI companion products make this especially clear. Apps like Replika and Character.ai are designed to simulate close relationships—users form emotional attachments, disclose personal information, and interact as if the system were a person. The Commission's draft guidelines single out exactly this scenario: one-time disclosure at the start of a conversation isn't enough when users are emotionally invested. Periodic reminders and context-aware disclosures may be necessary. The Italian Data Protection Authority already sanctioned Replika for insufficient safeguards. Article 50 raises the bar further—and the principle applies beyond companion apps to any system where the user's emotional state is part of the interaction: healthcare chatbots, financial advisors, mental health tools.

AI-generated content marking

If your system generates synthetic text, images, audio, or video, the output must be marked in a machine-readable format as artificially generated. This isn't a visible disclaimer—it's embedded metadata. Think watermarking at the infrastructure level.

The technical standards are still being finalised through the Code of Practice on AI-generated content. But the obligation is live from August 2 for any new system placed on the market. Legacy systems—those already on the market before August 2—get a grace period until December 2, 2026 for the watermarking requirement specifically.

For product teams, this means your content pipeline needs a marking layer. Every piece of AI-generated output that leaves your system must carry metadata identifying it as synthetic. If you're building on top of a GPAI model (GPT, Claude, Gemini), the model provider carries part of this obligation—but you carry the rest. The handoff between provider responsibility and deployer responsibility is where most gaps will appear.

Emotion recognition and biometric categorisation

If your system detects emotions or categorises users biometrically—assessing stress, sentiment, demographic characteristics, or similar attributes—users must be informed before the system operates on them.

This affects more products than most teams realise. Sentiment analysis in customer service tools, facial expression reading in video call platforms, voice tone analysis in sales coaching software—all of these fall under Article 50 if deployed in the EU. The disclosure must be specific: not "we use AI," but "this system is analysing your emotional state" or "this system is categorising you based on biometric data."

Deepfake disclosure

If your system generates or manipulates content that resembles real people—audio, video, or images—deployers must disclose that the content is artificially generated. There's a carve-out for artistic, creative, satirical, or fictional works, but even those require disclosure "in an appropriate manner that does not hamper the display or enjoyment of the work."

For AI-generated text published to inform the public on matters of public interest, disclosure is mandatory regardless.

Why the high-risk delay isn't free time

December 2027 sounds distant. It's 18 months. And the requirements waiting at that deadline are the heaviest in the entire regulation.

What counts as high-risk

High-risk AI systems under Annex III span eight domains: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and administration of justice. If your AI system influences hiring decisions, evaluates creditworthiness, triages patients, or scores applicants for public services, it will almost certainly qualify.

What high-risk compliance demands

The obligations are substantial. Each one touches product architecture, not just documentation:

• 𐩒Risk management systems that identify and mitigate foreseeable risks throughout the system's lifecycle.
• 𐩒Data governance frameworks ensuring training data meets quality, relevance, and representativeness standards.
• 𐩒Technical documentation detailed enough to demonstrate compliance on request—system architecture, algorithms, test results, intended purpose, performance metrics.
• 𐩒Conformity assessments completed before market placement, plus registration in the EU database.
• 𐩒Post-market monitoring and incident reporting with 72-hour and 15-day windows.

None of this is a last-quarter project.

Human oversight: the requirement that reshapes your product

Human oversight is the clearest example of compliance as a design constraint. The AI Act requires that high-risk systems be designed so that humans can effectively oversee their operation, understand their outputs, and intervene or override when necessary. This isn't a toggle switch added before launch. It's a design principle that shapes the product from the ground up—what the system surfaces to the human operator, when it flags uncertainty, how it handles override, what it logs for audit.

We've designed for exactly this kind of constraint across healthcare and fintech. When The Gradient built AMS, an AI-powered healthcare procurement platform, the core design challenge wasn't making the AI faster—it was making AI-assisted decisions transparent, auditable, and overridable.

The system needed to show procurement teams why it recommended a specific supplier, what data it used, and where to intervene. That architectural decision—baking explainability and human control into the product rather than layering it on top—is exactly what the AI Act's high-risk framework demands. Teams that build this way from the start won't need to retrofit. Teams that don't will spend 2027 rebuilding.

Explainability as a product feature

The same principle applies to explainability requirements. High-risk systems must provide outputs that the deployer can interpret and use appropriately. If your AI makes a credit decision, the person reviewing that decision must understand why—not in a general "the model considered these factors" sense, but specifically enough to identify errors and override them.

The regulatory direction isn't slowing down

This isn't happening in isolation. The same week the Omnibus was agreed, the European Commission unveiled its Tech Sovereignty Package—a sweeping set of proposals to reduce reliance on non-European technology providers, including sovereignty requirements for cloud services in banking, energy, and healthcare. The message is clear: the EU is tightening control over how technology operates in Europe, not loosening it. The high-risk delay is a pause, not a reversal.

What to do before August—and before December 2027

The compliance work splits into two tracks: what's urgent now, and what needs to start now but land later.

The August 2 checklist

1. Audit every AI touchpoint. Map where your system interacts directly with users—chatbots, virtual assistants, copilots, recommendation engines with conversational interfaces. If a user can reasonably believe they're interacting with a human when they're not, Article 50 applies.
2. Design your disclosure patterns. The draft Commission guidelines suggest a two-layer approach: a persistent visual indicator (badge or label near the AI interface) and an explicit notification at the start of each interaction. In sensitive contexts—healthcare, finance, emotional support—plan for periodic reminders, not just a one-time notice.
3. Assess your content pipeline. If your product generates text, images, audio, or video using AI, determine whether you're the provider, the deployer, or both. Map the handoff between the model provider's marking obligations and yours. The Code of Practice on AI-generated content is being finalised—track it.
4. Check for emotion recognition and biometric processing. Sentiment analysis, voice tone detection, facial expression reading, and demographic inference all potentially trigger Article 50(3). If your system does any of these in the EU market, users need specific disclosure before the system processes them.

The December 2027 roadmap

1. Classify your AI systems. Use the AI Act Explorer and the Commission's draft high-risk guidelines to determine which systems qualify as high-risk. The classification criteria are in the regulation and won't change—don't wait for final standards.
2. Design human oversight into the architecture. This is the requirement that costs the most to retrofit. What does the operator see? When does the system flag uncertainty? How does override work? What gets logged? These are product decisions that shape your data model, your interface, and your backend infrastructure.
3. Build documentation alongside the product. System architecture, training data governance, risk assessments, test results, performance metrics. Teams that document as they build will have this ready. Teams that reconstruct it retrospectively will discover gaps they can't fill.
4. Assign ownership. Every AI system needs a named accountable owner—typically a product owner—with authority to delay a release if compliance controls aren't met. Cross-functional review involving engineering, legal, privacy, and domain expertise should be a release gate, not an afterthought.

EU AI Act compliance as a product constraint

The EU AI Act is not a legal overlay. It's a set of product constraints. What you disclose, what you log, what you mark, what users can override—these are design decisions that happen in sprint planning, not in legal review.

The teams that treat compliance as a product input—the same way they treat accessibility or performance requirements—will build products that are better for it. Transparency makes AI interactions more trustworthy. Human oversight makes AI decisions more defensible. Explainability makes AI systems more debuggable. These aren't regulatory demands alone. They're product qualities that users and buyers increasingly expect, whether the law requires them or not.

The Omnibus gave you more time on the hardest part. It didn't give you more time on the part that's closest to your users. August 2 is close. Start with the interface.

Key takeaways

1. The EU AI Act's high-risk obligations moved to December 2027 (Annex III) and August 2028 (Annex I products) under the Digital Omnibus. But Article 50 transparency obligations—chatbot disclosure, AI content marking, emotion recognition notification—still take effect August 2, 2026.
2. Article 50 applies to any AI system that interacts with users, generates content, recognises emotions, or categorises people biometrically. Most AI-native products trigger at least one obligation.
3. The Commission's draft guidelines raise the bar beyond simple disclaimers: context-aware disclosure, periodic reminders in sensitive domains, and machine-readable content marking are all in scope.
4. High-risk requirements may be delayed, but they demand architectural decisions—human oversight, explainability, audit logging—that can't be bolted on in the final quarter before the deadline.
5. Compliance is a product constraint, not a legal checkbox. The teams that integrate it into their design process will build better products. The teams that wait for legal to tell them what to do will rebuild.