What changed on Sunday
- Enforcement started, not the rules. Per the European Commission's press release of 2 August 2026 — "Commission starts enforcing AI Act rules and new transparency requirements on 2 August", IP/26/1714 — the AI Office and national authorities began enforcing the Act on that date.
- The obligations are a year older than the powers. Duties on providers of general-purpose AI models took effect on 2 August 2025. The Commission's ability to enforce those duties took effect on 2 August 2026, after a one-year adjustment period.
- The toolkit is broader than fines. From that date the Commission can request documentation, run technical evaluations of models, demand compliance and risk-mitigation measures, restrict or withdraw a model from the EU market, and issue penalties.
- The numbers. Up to €15 million or 3% of global annual turnover, whichever is higher, for general-purpose AI providers under Article 101. The €35 million or 7% tier under Article 99 is reserved for breaches of the Article 5 ban on prohibited AI practices; most other breaches, including the transparency duties, cap at €15 million or 3%.
- Transparency duties landed the same day. Certain AI systems must tell users they are interacting with AI; AI-generated or altered content must be disclosed; deepfakes must be labelled; and such content must carry machine-readable marks so it can be detected. These reach deployers, not only model builders.
- Nothing has been enforced yet. No enforcement action has been reported as of publication. Powers existing and powers being used are separate events.
Most coverage of this date has collapsed two things that are worth keeping apart. The EU AI Act did not "come into force" on Sunday, and general-purpose AI providers did not suddenly acquire obligations they did not have on Saturday. What closed on 2 August 2026 is the gap between an obligation existing on paper and an authority being able to do something about it. For a year, a provider could have been non-compliant with the GPAI rules and faced nothing worse than reputational awkwardness. That is the part that ended.
Obligations since 2025, powers since 2026
The staggered design is deliberate and it is the spine of this story. The Act's general-purpose AI chapter began applying on 2 August 2025. The Commission then had a one-year adjustment period before it could enforce those provisions, which is precisely the window that expired on Sunday.
The practical consequence is that the compliance question has changed shape. Twelve months ago the question was "do we have a technical documentation set, a copyright policy and a training-data summary?" Today the question is "can we produce them, in a form that survives inspection, inside whatever window a regulator gives us?" Those are not the same problem. Plenty of teams have the artefacts scattered across Notion pages, model cards, an internal wiki and one engineer's memory. That was survivable in the adjustment period. It is less survivable now.
| Date | What it means | Who it lands on |
|---|---|---|
| 2 August 2025 | GPAI provider obligations begin applying. Models placed on the EU market on or after this date are subject to the full obligations from day one, with no grace period. | Providers of general-purpose AI models |
| 2 August 2026 | Commission enforcement powers over those obligations take effect. Transparency rules apply: AI interaction disclosure, AI-content disclosure, deepfake labelling, machine-readable marking. | GPAI providers, plus deployers of AI systems |
| 2 August 2027 | Deadline by which providers of GPAI models placed on the EU market before 2 August 2025 must be compliant. | Providers of legacy and pre-existing models |
That third row is the most under-reported line in the whole schedule, and it is genuine breathing space for a specific group: anyone shipping derivatives of open-weight models that were on the EU market before August 2025. If that describes your stack, you have another year. You should still not spend it doing nothing, because the documentation burden does not shrink with delay, but you are not in the same position as a team that put a new model out last month.
The 2027 date applies to models placed on the market before 2 August 2025 — not to your company, and not to a product you launched this year using an older base model. If you took an open-weight model from 2024 and released a fine-tuned derivative in 2026, the sensible working assumption is that you have placed a new model on the market, and the 2025 rules apply to it with no grace period. Get that classification decided by someone who will put their name on it, before a regulator decides it for you.
Who is exposed on day one
The scope question that matters for readers in Bengaluru, Pune, London and Manchester is extraterritorial reach, and the answer is unhelpfully simple. The Act follows the market. If you place a general-purpose AI model or an AI system on the EU market, or the output of your system is used in the EU, you are in scope regardless of where you are incorporated, where your engineers sit or where your GPUs are rented.
Within that, two populations are exposed very differently.
Providers of general-purpose AI models are the group the enforcement powers were written for. This is a smaller set than the discourse suggests. It means you trained or substantially modified a general-purpose model and made it available on the EU market. Most Indian and UK product teams are not in this group, and it is worth establishing that clearly rather than assuming the worst — we walked through the classification tests in more detail when the high-risk systems deadline came round.
Deployers of AI systems are the group that was caught off guard, because the transparency obligations that started on the same day reach them directly. If you run a customer-facing chatbot for a bank in Frankfurt, generate marketing imagery for an EU retailer, or build a synthetic-voice feature used by European customers, the transparency duties apply to you even though you trained nothing and your entire model layer is somebody else's API.
| Situation | In scope from 2 Aug 2026? | What bites first |
|---|---|---|
| Indian lab shipping a general-purpose model available in the EU | Yes, as a provider | Documentation requests, technical evaluation |
| UK startup fine-tuning an open-weight model, sold to EU customers | Likely, depending on modification scale | Provider classification, then documentation |
| Indian or UK SaaS product with EU users, third-party models only | Yes, as a deployer | Transparency duties, machine-readable marking |
| Agency generating AI imagery or video for EU brands | Yes, as a deployer | Content disclosure, deepfake labelling |
| Purely domestic Indian or UK product, no EU users or output | No | Nothing under this regime |
The transparency duty most teams have not built
Of the four transparency requirements, three are largely a copy-and-interface exercise. Telling a user they are talking to an AI is a string. Disclosing that content was AI-generated is a label. Labelling deepfakes is a label with a stricter trigger. None of them are trivial to get right across every surface, but none of them require anything you do not already have.
The fourth is different. AI-generated or altered content must carry machine-readable marks so that it can be detected. That is not a badge in your user interface. It is a property of the artefact that has to travel with the file after it leaves your product, survive a download, and be detectable by a system that has never heard of you. Very few product teams have shipped this, and it is not something you can retrofit in an afternoon across an existing content pipeline — the practical implementation route, including where provenance metadata gets stripped in real workflows, is set out in our guide to machine-readable AI content marking with C2PA.
Audit where your generated artefacts lose their metadata before you audit anything else. Most pipelines strip provenance information at exactly the points nobody looks: an image resize step, a CDN transformation, a re-encode on upload, a social share. A marking implementation that works in your test suite and dies at the CDN is worse than none, because it produces a compliance claim you cannot support. The wider interface work — disclosure copy, interaction notices, labelling triggers — is covered in our walkthrough of shipping transparency as code.
What enforcement realistically looks like first
The headline number is €15 million or 3% of global turnover under Article 101, and it is doing a lot of work in the coverage. It is worth reading the sequence of powers rather than the last item in the list.
The Commission can request documentation. It can carry out technical evaluations of models. It can require compliance measures and risk-mitigation measures. It can restrict or withdraw a model from the EU market. And it can fine. Those are not five parallel options a regulator picks between at random; they read as an escalation ladder, and the first rung is paperwork.
That reframes the near-term risk considerably. For the overwhelming majority of teams reading this, the plausible bad day in the next twelve months is not a nine-figure penalty. It is a documentation request with a deadline attached that you cannot meet, because the training-data summary lives in a deprecated notebook and the person who wrote the evaluation protocol left in March. The penalty exposure comes later, and it comes as a consequence of the first failure rather than instead of it.
"Every compliance regime I have worked under has the same first move, whether it is financial services or data protection. Someone asks you to show your work with a clock running. Teams do not fail that because they were negligent. They fail it because the evidence was never in one place, and thirty days is not long enough to assemble it retrospectively."
— Rishi Kora, Verified Builder · Bengaluru, IndiaEvery article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →The UK is in a genuinely different position
This matters for British readers and it is frequently got wrong. The United Kingdom has not passed an AI-specific statute. UK AI regulation continues to operate through existing sectoral law and the regulators who already hold the relevant powers — the ICO on data protection, the FCA in financial services, the MHRA in medical devices, and so on. An AI Bill may appear in a future parliamentary session, but as of mid-2026 it is not law, and anyone telling you the UK has a frontier AI statute in force is describing something that has not happened.
The consequence is asymmetric in a way that is easy to misread. A UK team is not subject to a domestic equivalent of the AI Act. A UK team selling into the EU is subject to the AI Act in full, on identical terms to an Indian or American one, because the trigger is the EU market and not the seller's jurisdiction. Leaving the EU changed the UK's obligations as a rule-maker; it changed nothing about a UK company's obligations as an EU market participant.
For Indian builders the picture is structurally the same but the domestic backdrop differs again, with DPDP obligations running on their own timetable and no overlap in scope. The mistake in both markets is the same: treating "we are not in the EU" as an exemption, when the operative question is whether your model or your system reaches an EU user.
Write down, in one sentence each, which role you occupy for each product surface: provider of a GPAI model, deployer of an AI system, or neither. Most compliance confusion in Indian and UK teams comes from not having made that determination explicitly, so every regulatory headline feels like it might apply to everything you build. It usually applies to one surface, and knowing which one collapses the work by an order of magnitude.
One more piece is still coming
Separately from Sunday's enforcement date, the Commission presented the EU Action Plan on Cybersecurity and Artificial Intelligence on 7 July 2026. Among other things it establishes dedicated evaluation capacity for cybersecurity threats arising from advanced AI models.
That capacity is expected to become operational in 2027. It is not live now. This is worth holding in view when reading forecasts about aggressive early enforcement: the specialist technical evaluation function that would underpin the most demanding assessments is still being built. That does not weaken the powers that took effect on Sunday, and it should not be read as a reason to defer work. It is simply a reason to expect the first year of enforcement to lean on documentation and process rather than on deep adversarial model evaluation.
What to do this week
Nothing here justifies a fire drill. It justifies about a day of unglamorous work, done now rather than under a deadline set by someone else.
First, settle your classification. Provider, deployer, or out of scope, per product surface, in writing, with a named owner. Second, if you are a provider, assemble the documentation set into one location that a person who does not work on your team could navigate: technical documentation, training-data summary, copyright policy, evaluation results. The test is not whether the artefacts exist; it is whether they can be handed over coherently in a fortnight. Third, if you are a deployer, walk your generated-content surfaces and check what disclosure and what marking actually reaches production, not what the design document says. Fourth, if your models predate August 2025, confirm that in writing and diarise the 2027 date rather than trusting anyone's memory of it.
And then stop. Enforcement powers existing is not the same as enforcement actions happening, and as of publication none has been reported. The teams that will handle this badly are the ones treating Sunday as either irrelevant or as an emergency. It is neither. It is the day the paperwork started to matter, in a regime where the paperwork was always the point. More of our regulatory coverage sits in the policy section.