EU AI Act GPAI rules go live 2 August 2026: the checklist

What changes on 2 August 2026

Two August 2026 is the day the EU AI Act becomes fully applicable. For builders shipping general-purpose AI models — what the regulation calls GPAI — the practical effect is that a set of obligations that have been theoretical since the law entered into force in 2024 now bite. The European Commission's enforcement powers and fining authority also enter into application on the same date, which means the cost of getting this wrong moves from reputational to financial overnight.

The headline change is straightforward. Every GPAI provider placing a new model on the EU market on or after 2 August 2026 must, from day one, hold technical documentation of the model, publish instructions for use to downstream deployers, comply with the EU Copyright Directive, and publish a summary of the content used to train the model. That last one — the training-data summary required by Article 53 — is the obligation that has caused the most discomfort in builder Slack channels from London to Bengaluru, because it forces a level of transparency the industry has historically resisted.

If your model is open-licence and does not present systemic risk, you get a narrower obligation: copyright compliance plus the training-data summary. The technical-documentation and instructions-for-use obligations fall away. If your model is large enough to be designated as presenting systemic risk, you pick up an entirely separate set of duties under Article 55. We will get to those in a minute.

One important nuance for teams that have been shipping for a while: pre-existing GPAI models — those placed on the market before 2 August 2025 — get a longer runway. They have until 2 August 2027 to come into compliance. The 2026 deadline is the new-model deadline. If you are about to release a fresh checkpoint in the second half of 2026, you do not get the grace period. Plan accordingly.

The checklist for non-systemic-risk GPAI providers

For the majority of teams — anyone who is not running a frontier-scale model — the obligations cluster around four artefacts. None of them are conceptually new; what is new is that they need to be real, current, and defensible the moment a regulator or customer asks for them.

1. Technical documentation of the model. This covers the architecture, training process, evaluation results, intended uses and known limitations. The European AI Office is expected to accept the structure recommended in the GPAI guidelines — see the GPAI guidelines overview — but the substance has to be your own. Generic boilerplate copied from a competitor's model card will not survive scrutiny.
2. Instructions for use to downstream deployers. Anyone integrating your model — a SaaS vendor, an internal team at a customer, a fine-tuning shop — needs enough information to discharge their own AI Act obligations. That means clear statements on intended use, prohibited use, evaluation results that bear on deployment risk, and how to integrate the model safely.
3. Copyright compliance. You must put a policy in place to comply with EU copyright law, including respecting opt-outs expressed by rightsholders. This is where most of the real engineering work has been happening this year — building the tooling to honour robots.txt-style opt-outs and the more granular TDM reservations is non-trivial.
4. Public summary of training content. Article 53 is the obligation everyone is watching. The European AI Office is expected to publish a template; the level of granularity required falls between "we used Common Crawl" and a full dataset listing. Get this drafted early, run it past counsel, and decide what gets redacted before publication, not after.

For open-licence GPAI providers — and this matters especially for the open-weights community in the UK and India that has been driving a lot of the recent open-source momentum — only items 3 and 4 apply. Unless your open-weight model gets designated as presenting systemic risk, in which case all of Article 55 lands on you regardless of how permissive your licence is.

Extra obligations for systemic-risk providers

If your GPAI model is designated as presenting systemic risk, Article 55 stacks four additional duties on top of the baseline. The criteria for designation sit with the European AI Office; if you are unsure whether you are in scope, the practical working assumption is that the largest frontier-scale models — the ones with cumulative training compute at the top end of the industry — are the candidates. Smaller models almost certainly are not.

Obligation	Non-systemic-risk GPAI	Systemic-risk GPAI (Article 55)
Technical documentation	Required (closed-licence only)	Required
Instructions for deployers	Required (closed-licence only)	Required
Copyright compliance	Required	Required
Training-data summary	Required	Required
Model evaluations	Not required	Required
Adversarial testing	Not required	Required
Serious-incident tracking and reporting	Not required	Required
Cybersecurity protections	Not required	Required

The four systemic-risk extras are the ones that genuinely change how you run a frontier programme. Model evaluations and adversarial testing have to be systematic, documented, and recurring — not one-shot pre-launch exercises. Serious-incident tracking means a formal pipeline from "something went wrong in deployment" through to a regulator-facing report. Cybersecurity protections cover both the model weights themselves and the infrastructure they run on, with the bar set by what the AI Office considers state of the art at any given moment.

How the Code of Practice helps you demonstrate compliance

On 10 July 2025, the European AI Office published the final version of the GPAI Code of Practice. It is voluntary. It does not create new obligations. What it does do is give providers a structured way to demonstrate compliance with Articles 53 and 55, and it is the lowest-friction route through the next twelve months.

The Code is organised around the obligation set above: it spells out what a sufficient training-data summary looks like, what counts as an adequate technical documentation set, how systemic-risk providers should structure evaluations and incident reporting, and what a credible cybersecurity posture looks like. Latham & Watkins published a helpful walk-through for in-house teams who need to brief leadership.

You do not have to sign the Code. You can comply with the AI Act through your own internal processes, your own templates, your own evaluation regime. But if you sign, you get two things: a presumption of conformity for the obligations the Code covers, and a much shorter conversation when a regulator or customer asks how you are demonstrating compliance. For most teams, especially those without a large legal function, signing is the pragmatic choice.

Builder reality: what UK and India teams ship before the deadline

The framing question on every founder call I have been on for the past month — and it does not matter whether the team is in Shoreditch or HSR Layout — is the same: how much of this applies to me, really? Three things help cut through the noise.

UK teams

The UK is no longer in the EU, but the AI Act follows your model, not your office. If you are placing a GPAI model on the EU market — selling API access to EU customers, distributing weights into the Union, putting a hosted product into service for European users — you are in scope. The pragmatic UK approach we are seeing across the London AI scene is: write the documentation once, against the EU template, and use it everywhere. The forthcoming UK Frontier AI framework will eventually create a parallel UK compliance track, but until then the EU Act is the binding constraint for any UK team with European revenue.

India teams

For Indian builders, the question of EU scope is genuinely live for the first time. Several Bengaluru and Pune labs are now shipping foundation models or fine-tuned variants directly to EU customers, and the regulation does not care that the training happened in India. If your model is placed on the EU market or put into service in the Union, you have the same Article 53 obligations as a Berlin-based lab. The DPDP Act gives you data-protection muscle memory; the AI Act adds a model-transparency layer on top of it. The work is mostly additive, not duplicative.

The smaller-team move

For teams under, say, fifteen people, the systemic-risk pieces are almost certainly not your problem. Concentrate on the four baseline artefacts. Get one engineer and one legal advisor in a room for two days, draft the technical documentation and training-data summary against the AI Office templates, write a short copyright policy, publish instructions for deployers on your model page, and you are roughly done. The cost of doing this badly later is much higher than the cost of doing it adequately now.

What to do next week

If you are reading this in late April 2026 you have roughly fourteen weeks. That is enough time to do this calmly, and not enough time to put it off any longer. Three concrete actions for next week:

1. Audit your current model documentation against the four-artefact baseline. Tech docs, deployer instructions, copyright policy, training-data summary. Identify which exist, which are stubs, and which are missing entirely.
2. Read the Code of Practice cover to cover. The implementation timeline page on artificialintelligenceact.eu has the latest links. It is shorter than the AI Act itself by an order of magnitude and far more useful as an operational document.
3. Decide on your Code-of-Practice posture by end of May. Sign, do not sign, or sign-with-reservations — but make the decision deliberately, with your legal advisor and engineering leadership in the room together. It will shape how you spend the next ten weeks.

For the broader AI Act picture — including the high-risk system obligations that also land on the same date — see our companion piece on the EU AI Act August 2026 high-risk deadline. If you need a verified Builder with hands-on AI Act experience, browse the AI Tech Connect directory or add your own profile if you are one of those Builders yourself.