cd /news/ai-policy/eu-ai-act-august-2-2026-the-develope… · home topics ai-policy article
[ARTICLE · art-33599] src=byteiota.com ↗ pub= topic=ai-policy verified=true sentiment=· neutral

EU AI Act August 2, 2026: The Developer Checklist

The EU AI Act's high-risk AI system requirements become fully enforceable on August 2, 2026, with fines starting at €15 million or 3% of global turnover. Developers must verify if their products fall under Annex III high-risk categories, which include biometric identification, critical infrastructure, hiring tools, credit scoring, and law enforcement systems. The five mandatory technical obligations are risk management, data governance, technical documentation, tamper-evident logging, and human oversight by design, applying to both providers and deployers.

read5 min views1 publishedJun 19, 2026

August 2, 2026 is 44 days away. On that date, the EU AI Act’s high-risk AI system requirements become fully enforceable — and fines start at €15 million, or 3% of global turnover, whichever hurts more. Most developers are still not sure whether their product is in scope. This is the piece that answers that.

Are You Actually Affected? #

Probably not in the way you think — but you need to verify, not assume.

The EU AI Act is not a blanket regulation on all software that touches AI. The August 2 deadline applies specifically to Annex III high-risk AI systems: a narrow set of applications where AI directly shapes high-stakes decisions about people’s lives. Spam filters, recommendation engines, productivity tools, developer copilots, general chatbots — none of these are in scope under Annex III.

What IS in scope:

  • Biometric identification systems (remote surveillance, emotion recognition)
  • AI that manages critical infrastructure (power grids, water, road systems)
  • Student assessment tools sold to EU educational institutions
  • Hiring, promotion, or termination tools where AI output influences HR decisions
  • Credit scoring or insurance underwriting components
  • Law enforcement risk assessment tools
  • Migration and border control AI
- Judicial decision-support systems

If you’re building a hiring platform, a credit API, or a student evaluation tool for EU institutions, stop reading this as general interest and start treating it as a deadline.

The 5 Technical Obligations #

For high-risk systems, these are the requirements taking effect August 2. All five are mandatory. None are optional based on company size.

1. Risk Management System (Article 9)

This is a continuous, iterative process — not a one-time risk audit you tick off in a spreadsheet. You must identify, estimate, evaluate, and mitigate risks throughout the entire system lifecycle. Retrospective documentation is significantly harder than building this in from the start.

2. Data Governance (Article 10)

Training datasets must be relevant, representative, and documented for limitations. Version control records and provenance information — who produced the data, when, under what conditions — are required. Inference-time data protections apply as well.

3. Technical Documentation (Article 11)

Must be produced before the system goes to market, kept current throughout its lifetime, and retained for 10 years. The standard: authorities must be able to assess compliance without reverse-engineering the model. If your architecture is undocumented, that gap doesn’t close with time.

4. Tamper-Evident Logging (Article 12)

Automatic logging of inputs, outputs, decision points, timestamps, and human interventions. Minimum retention: 6 months. The logs must be tamper-evident — a forensic audit trail, not application logs you can edit. If you’re not logging to this standard already, start now; retrofitting compliant logging into a production system is not a weekend job.

5. Human Oversight by Design (Article 14)

Qualified humans must be able to interpret the system’s outputs and intervene when necessary. This is a design requirement, not a policy one. If your current architecture doesn’t support meaningful human intervention — if a decision is fully automated with no override mechanism — you need a redesign before August 2, not a policy document claiming oversight exists.

Providers vs. Deployers: Both of You Are Responsible #

The regulation distinguishes between providers (who build and place AI systems on the market) and deployers (who use AI in business operations). Providers carry the heavier burden. But deployers aren’t off the hook.

There’s no joint liability in the EU AI Act. Provider violations and deployer violations are independent. If you build on a foundation model and ship it as a product, you are the provider for your downstream users. “I’m just calling an API” is not a compliance defense. If you’ve deployed a third-party hiring or credit tool, you need to verify the provider has completed a conformity assessment — if they haven’t, your deployment is non-compliant regardless of the contract language.

The Penalty Structure #

Three tiers, per Article 99: €35M or 7% of global turnover— violations of Article 5 prohibited AI practices (enforceable since February 2025)€15M or 3% of global turnover— non-compliance with high-risk system requirements€7.5M or 1.5% of global turnover— providing false information to authorities

For context: GDPR’s top fine tier is 4% of global turnover. The EU AI Act goes higher. That should settle any debate about whether this regulation has teeth. Enforcement runs through national market surveillance authorities in each EU member state, with the EU AI Office handling cross-border and GPAI cases. Early enforcement will target the most visible violations — but the documentation requirements mean any system can be audited at any time. “Wait and see” is not a strategy. It’s a documented risk you’re voluntarily carrying.

What to Do in the Next 44 Days #

Build an AI inventory. Every AI system you provide or deploy, every third-party API, every embedded component. Classify each against the Annex III categories.Use the official tool. TheEU AI Act Service Desk Guideline Explorerhelps classify systems. Use it, and document the output.Assign ownership. High-risk systems need named owners across Legal, Product, Engineering, and Security. Compliance without ownership is theater.Start logging now. Compliant tamper-evident logging takes time to implement correctly. Every week of delay is a week of missing audit trail.Start conformity assessment for high-risk systems. Most Annex III systems allow self-assessment with documentation. Some categories require third-party assessment. CheckArticle 43 guidance for developersto know which path applies to you.

Forty-four days is enough time to act. It’s not enough time to start a compliance program from zero — but it is enough to complete an inventory, get compliant logging in place, and assign clear ownership while documentation catches up.

The August deadline isn’t the end of anything. It’s the start of enforcement. That distinction matters.

── more in #ai-policy 4 stories · sorted by recency
── more on @eu ai act 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/eu-ai-act-august-2-2…] indexed:0 read:5min 2026-06-19 ·