What changes on 2 August 2026
From 2 August 2026 the bulk of the Act's substantive obligations begin to apply, including the rules covering high-risk AI systems listed in Annex III. The earlier general-purpose model phase started on 2 August 2025, and the separate Annex I product-safety route is currently scheduled for 2 August 2027, with further delay being actively debated in Brussels.
- Who is in scope: any provider, importer, distributor or deployer placing a covered AI system on the EU market or whose system's output is used in the Union — irrespective of where the company is established. A Bengaluru SaaS firm and a Manchester startup are treated identically with a Berlin one.
- What you must do: technical documentation, a conformity-assessment route, registration in the EU database for high-risk systems, post-market monitoring, and clear instructions for use.
- What it costs to ignore: the headline cap is the higher of EUR 35 million or 7% of global annual turnover — but that ceiling is reserved for prohibited practices. A separate cap of EUR 15 million or 3% applies to most other obligations.
- Watch the calendar: 99 working-ish days. If documentation and a conformity route are not on your roadmap by mid-May, you are already late.
This week, run a short triage. List every AI feature you ship, map each one against the eight Annex III categories, and tag it red, amber or green. Anything red needs a documentation owner named by the end of May. That single document — half a page is fine — is what your auditors, partners and EU customers will keep asking for between now and 2 August.
Who is actually in scope
The Act has explicit extraterritorial reach. If you place an AI system on the EU market, or if the output of your system is used in the Union, you are a provider, deployer, importer or distributor for the purposes of the Act — regardless of your country of establishment. This is the part most Indian and UK builders we speak to under-rate.
For an Indian B2B SaaS firm with EU enterprise customers, the obligations follow the system, not the contract. For a UK startup, the position is the same: post-Brexit, the United Kingdom is a third country for the purposes of EU law, so a UK provider is in scope on identical terms to one in India or the United States.
One practical concession: if you are not established in the EU and your system is high-risk, you typically need to designate an authorised representative in the Union before placing the system on the market. That representative can be a law firm, a compliance services company, or a parent-group entity, but they must be named, contracted and registered.
What "high-risk" actually means under Annex III
The Act's risk taxonomy is the bit that gets misquoted most. There are four buckets — unacceptable (prohibited), high, limited (transparency only) and minimal — and the obligations that bite from 2 August 2026 are largely directed at the high-risk tier.
High-risk splits in turn into two routes:
- Article 6(1) — Annex I: AI systems that are safety components of products already covered by EU product-safety legislation (machinery, medical devices, in-vitro diagnostics, lifts and similar). This track is currently scheduled for 2 August 2027, and there are live proposals to delay it further.
- Article 6(2) — Annex III: stand-alone AI systems used in eight broad domains. This is the route that becomes applicable on 2 August 2026.
The Annex III domains, in plain English, cover biometric identification, critical infrastructure, education (admissions, exam scoring), employment and workforce management (recruitment, performance evaluation, task allocation), access to essential public and private services (credit scoring, benefits eligibility), law enforcement, migration and border management, and the administration of justice.
If you build recruitment-screening AI, credit-scoring models for consumer lending, biometric verification, exam-grading tools or anything that ranks candidates for employment — assume you are in Annex III scope until your counsel tells you otherwise.
A common misconception in product Slack channels is "all AI is high-risk under the Act". That is not true. Article 6(2) only bites where your system fits one of the Annex III categories. A general-purpose chatbot for B2B customer support is not, on those facts alone, a high-risk system. Map carefully before you over-engineer documentation; over-applying the regime is its own kind of compliance debt.
The key dates and articles, side by side
| Article / phase | What it covers | When it applies | Who feels it first |
|---|---|---|---|
| Prohibited practices | Social scoring, untargeted facial-image scraping, emotion inference at work or school, certain real-time biometric uses | Already in force (2 Feb 2025) | Anyone shipping into the EU today |
| General-purpose model rules | Documentation, summary of training data, copyright policy for foundation-model providers | 2 Aug 2025 (Phase 1) | Foundation-model providers and fine-tuners |
| Article 6(2) — Annex III high-risk | Stand-alone high-risk systems: recruitment, credit scoring, biometric ID, education, etc. | 2 Aug 2026 | Most B2B AI builders selling into the EU |
| Article 6(1) — Annex I high-risk | AI components of regulated products (medical devices, machinery, lifts, etc.) | 2 Aug 2027 (subject to active proposals to delay further) | Hardware, medical-device and industrial AI vendors |
The conformity-assessment process, in plain language
For most Annex III systems the Act allows self-assessment against harmonised standards, with notified-body involvement reserved for narrower cases (most prominently, certain biometric uses). The work breaks into five lanes.
- Risk-management system: a documented, iterative process that identifies foreseeable risks, mitigates them, and is reviewed across the lifecycle. It is a living artefact, not a one-off PDF.
- Data and data-governance: training, validation and test datasets must be relevant, sufficiently representative and, to the extent feasible, free of errors. Sourcing, annotation, lineage and bias-testing all sit here.
- Technical documentation: the headline deliverable. It describes the system, intended purpose, training data, performance metrics, monitoring plan and known limitations. Plan for fifty to a hundred pages, written for an auditor, not a marketing reader.
- Logging and human oversight: automatic event logs, plus design choices that allow a competent human to monitor, intervene and override the system. The "human in the loop" requirement is real but flexible — what matters is whether the design supports meaningful oversight in practice.
- Post-market monitoring and incident reporting: a documented programme that captures real-world performance and reports serious incidents to authorities. The reporting clock starts at the moment the provider becomes aware of a serious incident.
Once the assessment is complete the system gets a CE marking, the provider issues an EU declaration of conformity, and the system is registered in the public EU database for high-risk AI before being placed on the market. Expect customers to look you up.
Your next-90-days checklist
If you are reading this in late April 2026, you have roughly thirteen weeks before the rules apply. The realistic roadmap looks like this.
- Week 1 — scope mapping. List every AI-touched feature in production and in the next two release trains. Tag each one against the Annex III categories. Most teams discover one or two surprises here.
- Week 2 — appoint the owners. Name a single accountable person per high-risk system. Get sign-off from the founder, legal and engineering on who that is.
- Week 3-4 — gap analysis. Take the five conformity lanes above and score each high-risk system green, amber, red. Build a Gantt-style remediation plan that finishes in mid-July, not on 1 August.
- Week 5-6 — data governance. Document your training, validation and test sets. Run the bias and representativeness checks the standards expect; do not invent your own metric, follow the harmonised one your sector uses.
- Week 7-8 — technical documentation. Draft. Aim for a structure that mirrors the Act's required contents; do not write it as marketing material. Have an external reviewer read it cold.
- Week 9-10 — post-market monitoring. Stand up logging, alerting, and the incident-reporting workflow with a named on-call rota.
- Week 11-12 — authorised representative + registration. If you are outside the EU, contract your representative now and prepare the database registration package.
- Week 13 — dry run. Walk a friendly customer's procurement team through the documentation, fix the gaps they find, and ship.
"We sell a recruitment-screening tool to mid-market employers. About a fifth of our pipeline is European. We started taking the Act seriously last September and even with a six-month head start the data-governance audit was the longest pole. If you are starting now, do the data-lineage work first; everything else is downstream of it."
— Emma, Rising Builder · Manchester, UKWant to discuss this with other verified Builders?
Every article on AI Tech Connect is written by a Verified Builder. Browse profiles, shortlist who you want to hire or collaborate with.
Browse Builders →Concessions and sandboxes for SMEs
The Act is not blind to the asymmetry between a fifteen-person startup and a multinational. Several concessions sit alongside the core regime.
- Regulatory sandboxes: each member state is required to operate at least one AI regulatory sandbox — a controlled environment to test high-risk systems with regulator engagement, often with relief from certain administrative fees. Spain, the Netherlands and the Nordics are widely regarded as the easiest to join in 2026.
- Fee proportionality: where conformity assessments involve notified-body fees, the Act foresees adjustments for SMEs and start-ups.
- Documentation proportionality: technical documentation requirements for SMEs can be satisfied in a simplified form. Earlier drafts referenced a grace period of around nine months in specific contexts; the final position varies and is one to confirm with counsel.
- Standards-driven compliance: harmonised European standards drafted by CEN-CENELEC give a presumption of conformity, and are in practice the cheapest route for most teams.
What this means for builders in India and the UK
The Indian and British contexts diverge sharply in one respect: domestic AI regulation. India's DPDP Act is in force on the personal-data side, but no horizontal AI statute is in play. The United Kingdom is debating a Frontier AI Bill, with an emphasis on the largest model providers and a sector-led approach below that. Neither materially eases the EU AI Act burden.
For Indian builders, EU obligations are independent of DPDP — the data-governance work for the Act often slots on top of existing DPDP mappings, but the documentation artefacts are different and must be produced separately. The authorised-representative requirement adds a fixed cost, typically in the EUR 6,000 to EUR 25,000 per year band, and the engineering effort is comparable to a SOC 2 Type II in scope but compresses into a tighter time-box.
For UK builders, post-Brexit means a third-country status for EU regulatory purposes, so the Act applies on the same extraterritorial terms as it does to a US or Indian firm. UK GDPR and the EU GDPR remain largely aligned, so the data-protection lift is moderate. Where the UK Frontier AI Bill lands will probably nudge but not displace EU obligations; for sales into the EU, the EU regime is what binds.
The common thread is procurement. EU customers' procurement teams already ask for AI Act readiness statements alongside ISO 27001, SOC 2 and GDPR DPAs. By July, expect a documented readiness pack to be table stakes for any deal worth more than five figures.
Where to read the actual law
The best public reference is the consolidated text on EUR-Lex. Read the recitals first; they are unusually plain-English for an EU instrument and signal regulator intent in a way the operative articles alone do not. Professional summaries from Osborne Clarke and Kennedys Law are useful supplements. The European Commission's own AI Act page is the right source for delegated acts and implementing regulations as they appear.
For specific clause interpretation this article is no substitute for advice from a qualified EU-law practitioner. The framing here is operational; the clause-level work is theirs.