The high-risk obligations that applied from 2 August 2026 dominated the conference circuit, the compliance webinars, and a great many anxious internal emails. For organisations placing high-risk AI systems on the EU market, that date was a genuine cliff edge, and rightly treated as one. But for everyone who spent the spring scrambling toward it, the most important thing to understand now is this: the deadline was not the end of the work. It was a waypoint on a regulatory journey that runs well into 2027 and arguably beyond.
The EU AI Act is now in force as a single, staggered regulation, but its individual obligations switch on at different moments. Several of the duties that matter most to organisations building AI products did not land on 2 August 2026 at all. The general-purpose AI (GPAI) model provider regime began earlier, in August 2025, and continues to mature through codes of practice and enforcement that are only now finding their feet. The systemic-risk tier sits on top of that. And the political conversation around a possible “Digital Omnibus” simplification package introduces a layer of genuine uncertainty about how some of this will be sequenced.
This article is the forward-looking companion to our day-one coverage. If you have already worked through your high-risk readiness, the question becomes: what next? The answer is to stop reacting deadline by deadline and start building a regulatory roadmap. Below, we set out the GPAI obligations, the systemic-risk requirements, the role of the codes of practice, the milestones still ahead, and how the cascade of duties reaches organisations that merely build on top of foundation models.
The GPAI obligations that did not arrive on 2 August
General-purpose AI models — the foundation models underpinning chat assistants, code copilots, document-understanding pipelines, and most of the AI features being shipped today — are governed by their own dedicated chapter of the Act, with its own timeline. The core GPAI model provider obligations began applying from 2 August 2025, a full year before the high-risk rules. That sequencing was deliberate: the EU wanted the upstream model layer documented and transparent before the downstream high-risk obligations bit.
For a provider of a general-purpose AI model, the baseline EU AI Act GPAI obligations centre on four things:
- Technical documentation. Providers must draw up and maintain documentation describing the model, its design, training and testing process, and evaluation results, kept up to date and available to the AI Office and national authorities on request.
- Information for downstream providers. Providers must make available documentation and information to organisations that intend to integrate the model into their own AI systems — enough for those downstream parties to understand the model’s capabilities and limitations and to meet their own obligations under the Act.
- A copyright policy. Providers must put in place a policy to comply with EU copyright law, including respecting rights reservations expressed through machine-readable means (the text-and-data-mining opt-out).
- A training-data summary. Providers must publish a sufficiently detailed summary of the content used to train the model, following a template provided by the AI Office.
These are not high-risk obligations and they do not depend on the 2 August 2026 date. They have been live for the better part of a year. What changes over time is the depth of enforcement and the supporting machinery — templates, codes of practice, and the AI Office’s growing supervisory capacity — rather than the existence of the duties themselves. A practical consequence: if your organisation trained or fine-tuned a model in a way that could make you a GPAI model provider, these duties may already apply to you, and the relevant test is not whether the high-risk regime touches your product.
The systemic-risk tier: what frontier models trigger
Sitting above the baseline GPAI regime is a more demanding tier for general-purpose AI models that present systemic risk. This is the category aimed squarely at the largest, most capable frontier models — the ones whose capabilities or reach could have significant effects across the EU market, on public health, safety, fundamental rights, or society.
The Act sets out a presumption mechanism based on the model’s capabilities, including a threshold expressed in terms of the cumulative compute used for training (measured in floating-point operations). Models above that threshold are presumed to carry systemic risk, and the Commission can also designate models on other grounds. Providers crossing the threshold are required to notify the Commission. The compute threshold is a moving target by design — it can be adjusted as the technology and the methodologies evolve — so the specific figure matters less than understanding that the classification exists and that it can change.
Providers of GPAI models with systemic risk carry the baseline obligations plus a substantial additional set:
- Model evaluation, including standardised testing and state-of-the-art adversarial testing (red-teaming) to identify and mitigate systemic risks.
- Systemic-risk assessment and mitigation across the model lifecycle, including risks arising from development, market placement, and use.
- Serious-incident tracking and reporting to the AI Office and, where relevant, national authorities, along with possible corrective measures.
- Cybersecurity protection for the model and its physical infrastructure.
For most organisations, the immediate point is not that you will be training a systemic-risk model. Very few will. The point is that you are almost certainly using one. If your product is built on a leading commercial foundation model, you are consuming the output of a provider that is — or may become — subject to the systemic-risk tier. That shapes what you can reasonably expect from your vendor in terms of documentation, evaluation evidence, and incident communication, and it shapes the questions you should be asking in procurement and contract renewals.
How GPAI duties cascade to organisations that build on foundation models
This is the part that catches organisations off guard, and it is the heart of why the post-August roadmap matters even if you do not consider yourself an “AI company”. The GPAI regime is not a self-contained set of obligations for a handful of frontier labs. It is the upstream layer of a chain, and responsibilities flow down that chain.
If you take a foundation model and integrate it into a system you place on the market or put into service, you are a downstream provider. Two distinct things follow.
First, you become a consumer of upstream documentation, and the Act explicitly contemplates this. The information GPAI model providers must supply to downstream providers exists precisely so that you can discharge your own obligations. If your integrated system turns out to be high-risk, you will need that upstream documentation to build your technical file, run your risk assessment, and demonstrate conformity. Relying on it is legitimate — but you must actually obtain it, evaluate whether it is sufficient, and retain it. “The vendor handles compliance” is not a defensible position when your name is on the system that reaches the user.
Second, and more subtly, fine-tuning or substantially modifying a general-purpose model can make you a GPAI model provider in your own right for the modified model, with the corresponding documentation, transparency, and copyright duties attaching to your changes. Where you sit on the spectrum from “light prompt engineering” to “substantial retraining” determines how much of the upstream regime you inherit. Many teams assume they are pure consumers when, in regulatory terms, their modifications have moved them upstream.
The practical mechanism that makes all of this manageable is contractual flow-down. Your agreements with model providers, API vendors, and integration partners should explicitly allocate who provides what documentation, who reports incidents and on what timeline, what copyright and training-data assurances are given, and what happens when the upstream model is reclassified or updated. We increasingly advise clients to treat AI-vendor contracts the way mature engineering organisations treat security and data-processing addenda: as a place where regulatory obligations are mapped, not assumed.
The codes of practice and the role of the AI Office
Because the GPAI obligations are drafted at the level of principle, the Act relies on codes of practice to translate them into concrete, day-to-day expectations. The General-Purpose AI Code of Practice is the central instrument here. Developed through a multi-stakeholder process facilitated by the AI Office, it gives providers a practical way to demonstrate compliance with their GPAI obligations until harmonised standards are available.
A few points are worth being precise about, because there is a lot of loose commentary. The code is a voluntary instrument in the sense that signing it is not the only route to compliance — a provider can demonstrate compliance by other adequate means. But adhering to the code gives providers a structured, AI-Office-recognised path and a degree of legal predictability, which is why the major model providers have engaged with it. The code addresses areas such as transparency, copyright, and — for the systemic-risk tier — safety and security practices. Treating the code as the de facto baseline for what “good” looks like is sensible, even for organisations that are not themselves signatories.
The AI Office is the body that supervises GPAI model providers at EU level, facilitates the codes, maintains templates (including the training-data summary template), and will play the central enforcement role for the GPAI regime. For downstream organisations, the AI Office is relevant in two ways: it sets the expectations your upstream vendors are being held to, and it is the channel through which serious incidents involving systemic-risk models are reported. Watching what the AI Office publishes — templates, guidance, and clarifications — is one of the highest-value monitoring activities you can build into your roadmap, because it tells you where the goalposts actually are when the legislative text is silent or ambiguous.
On the talk of EU AI Act codes of practice 2027: expect the codes and accompanying guidance to continue evolving as harmonised standards are developed and as the AI Office gains operational experience. The codes are living instruments. The version that informs your compliance posture today is unlikely to be the last word, and building for that change is more durable than optimising for a single snapshot.
The roadmap and remaining milestones toward 2027
Stepping back, the staggered structure of the Act looks like this in practice:
- February 2025 — the prohibitions on unacceptable-risk practices and the AI literacy obligations began to apply.
- August 2025 — the GPAI model provider obligations and the governance provisions (including the AI Office’s role) began to apply.
- August 2026 — the bulk of the high-risk obligations and the transparency obligations for certain systems applied. This is the date most organisations organised around.
- August 2027 — the extended deadline for high-risk AI systems that are components of, or are themselves, products already regulated under existing EU product-safety legislation. This later milestone gives those products additional time to align.
That August 2027 milestone is the one most often forgotten now that the headline date has passed. If your AI is embedded in a regulated product — medical devices, machinery, certain vehicles and their components, and similar — your clock may run on the longer timeline, and your conformity work intersects with sectoral regimes you already know. Mapping which of your systems fall under which date is itself a useful exercise, because organisations frequently assume a single deadline applies uniformly when in fact different parts of their portfolio are governed by different timelines.
Alongside these legislative dates sits the slower, continuous track: harmonised standards being finalised, codes of practice being refined, AI Office guidance being published, and national authorities being designated and resourced. The roadmap to 2027 is therefore not a series of cliffs but a combination of hard legislative dates and a rolling stream of soft-law clarification.
The Digital Omnibus uncertainty
Any honest roadmap has to acknowledge that some of the sequencing above is, at the time of writing, contested. There has been active discussion at EU level about a “Digital Omnibus” — a simplification package intended to ease and streamline aspects of the EU’s digital rulebook, the AI Act among them. Proposals and commentary have floated the possibility of adjusting certain timelines, easing some administrative burdens, and clarifying obligations, partly in response to concerns about competitiveness and the readiness of supporting standards.
We want to be careful here, and we will speak as practitioners rather than lawyers. As of August 2026, the precise scope, content, and fate of any such package is not settled, and you should treat specific claims about postponed deadlines or relaxed duties with caution until they are confirmed in the Official Journal. It is entirely possible that some timelines shift; it is equally possible that the core obligations remain as enacted. What would be a mistake is to pause your compliance work on the assumption that relief is coming. Regulatory simplification, if it arrives, tends to change the packaging more than the substance — the underlying expectations around documentation, transparency, risk management, and accountability are unlikely to vanish.
The pragmatic stance: build your roadmap on the law as it currently stands, design your controls so they are robust to reasonable changes in sequencing, and assign someone to track the Digital Omnibus process so that you can adjust deliberately rather than react to a headline. Flexibility is a feature you design in, not a hope you hold.
Building a regulatory roadmap rather than reacting deadline by deadline
The organisations that handle this well share a common trait: they stop treating the AI Act as a series of fire drills and start treating it as a programme. A workable roadmap usually includes the following.
An AI inventory and classification. You cannot manage obligations you cannot see. Catalogue every AI system and model in use — built, bought, embedded, and experimental — and classify each by risk category and by which provider role you occupy (provider, downstream provider, deployer). This single artefact answers most “does this apply to us?” questions.
A model-supply-chain map. For each system, record which foundation models sit underneath, who provides them, what documentation you have obtained, and whether your fine-tuning has pushed you upstream into provider territory.
Contractual flow-down review. Audit AI-vendor agreements for documentation provision, incident reporting, copyright and training-data assurances, and reclassification handling. Close the gaps at renewal.
A monitoring function. Assign ownership for tracking AI Office publications, code-of-practice updates, harmonised standards, and the Digital Omnibus process. Translate changes into roadmap adjustments quarterly.
Milestone mapping. Plot your systems against the February 2025, August 2025, August 2026, and August 2027 dates so that nothing governed by the longer product-safety timeline is mistaken for “done”.
Done properly, this turns compliance from a recurring panic into a predictable operating rhythm — and, not incidentally, into a procurement and trust advantage when your customers ask how you handle AI governance.
How McKenna Consultants can help
We build and integrate AI into real products — document-processing pipelines, Microsoft 365 and SharePoint Embedded integrations, Office Add-Ins, and bespoke AI features — which means we look at the EU AI Act from an engineering and architecture perspective, not only a legal one. We help organisations inventory and classify their AI systems, map their model supply chains, understand where GPAI duties cascade down to them as downstream providers, and design documentation and monitoring that holds up as the codes of practice and the timeline evolve toward 2027.
If you have cleared the August high-risk hurdle and are now asking “what next?”, we would be glad to help you turn that question into a concrete, prioritised roadmap. Get in touch to arrange an initial conversation.
This article reflects our practitioner perspective on the EU AI Act as at August 2026 and is intended for general information. It is not legal advice. The GPAI regime, the codes of practice, and the surrounding timeline — including any Digital Omnibus simplification measures — continue to develop, and specific obligations should be confirmed against the current legal text and assessed with qualified legal counsel for your particular circumstances.
