Artificial Intelligence

GPAI Obligations, Codes of Practice, and the EU AI Act Roadmap After the AI Omnibus

GPAI Obligations, Codes of Practice, and the EU AI Act Roadmap After the AI Omnibus

Correction, 3 October 2026: An earlier version of this article stated that the EU AI Act’s high-risk obligations applied from 2 August 2026, that high-risk AI in regulated products followed in August 2027, and that the Digital Omnibus was still an unsettled proposal. That was not correct. The AI Omnibus, which entered into force on 27 July 2026, moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. What did apply from 2 August 2026 included the Commission’s powers to enforce the GPAI obligations and the Article 50 transparency obligations. The earlier version also overstated how readily fine-tuning a model makes you its provider. The article has been corrected throughout.

2 August 2026 loomed large in EU AI Act planning, and it was a real milestone: from that day the Act became generally applicable, the enforcement powers of the AI Office and national authorities began to apply, and so did the Article 50 transparency obligations. What it did not bring was the high-risk regime. The AI Omnibus, which entered into force on 27 July 2026, moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. For everyone who spent the spring preparing for 2 August, the most important thing to understand now is this: the date was not the end of the work. It was a waypoint on a regulatory journey that now runs into 2028.

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 an enforcement regime whose powers only began to apply on 2 August 2026. The systemic-risk tier sits on top of that. And the AI Omnibus has reset the sequence of what comes next.

This article looks forward. Whatever you prepared for 2 August, the question now is: 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, what the AI Omnibus changed, 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, more than two years before the first high-risk obligations, which now apply from 2 December 2027. Whatever the intent behind that sequencing, its practical effect is that the upstream model layer carries documentation and transparency duties well before the downstream high-risk obligations bite.

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 identifying and respecting, through state-of-the-art technologies, rights reservations made under the EU text-and-data-mining exception (the TDM 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 the AI Omnibus did not postpone or amend them: the provider obligations in Articles 53 and 55 are unchanged in the consolidated text. They have applied since 2 August 2025. What changed on 2 August 2026 was enforcement: from that date the Commission can enforce the GPAI obligations, including through fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher. Providers of GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply. Beyond those dates, what develops over time is the supporting machinery — templates, codes of practice, guidelines, and the AI Office’s supervisory practice — rather than the existence of the duties themselves. A practical consequence: if your organisation trained or substantially modified 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 is easiest to overlook, 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 once the high-risk obligations apply (from 2 December 2027 for Annex III systems). 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. If an upstream provider does not supply what the Act requires, the AI Office runs a complaints channel through which downstream providers can raise issues under Articles 53 to 55.

Second, and more subtly, fine-tuning or modifying a general-purpose model can, in some cases, make you a GPAI model provider in your own right for the modified model. The bar is high. The Commission’s guidelines say a modifier becomes a provider only in exceptional circumstances, specifically where the modification or fine-tuning uses more than one-third of the original model’s training compute, so most fine-tuning and adaptation will not trigger the provider obligations. Where the threshold is crossed, the Commission limits the obligations to documenting the modification itself — the changes made and the new training data used — rather than the entire model. The guidelines are not legally binding, but the Commission has said it will base its enforcement on them. If your team does substantial retraining rather than prompt engineering or light fine-tuning, measure where you sit against that threshold rather than assuming either way.

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. Our recommendation is 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. Published on 10 July 2025 and prepared by independent experts in 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 that does not adhere to it must demonstrate alternative adequate means of compliance for assessment by the Commission. But the Commission and the AI Board have confirmed the code as an adequate voluntary tool for demonstrating compliance, and the Commission says adherence reduces administrative burden and gives more legal certainty than proving compliance by other methods. The signatories it lists include Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI and OpenAI. The code has three chapters: Transparency and Copyright, which offer all GPAI model providers a way to meet their Article 53 obligations, and Safety and Security, which is relevant only to providers of models with systemic risk under Article 55. In our view, 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 enforces the GPAI regime: its enforcement powers have applied since 2 August 2026, with fines imposed by Commission decision. Since the AI Omnibus it also has extended oversight of certain AI systems: with some exceptions, it is exclusively competent for AI systems built on a GPAI model by the same provider or group, and for AI systems that constitute or are integrated into very large online platforms or search engines. 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: the Act tasks the AI Office with encouraging the review and adaptation of the codes, in particular in light of emerging standards, so 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 GPAI code is also no longer the only one: a separate Code of Practice on Transparency of AI-generated Content was published in final form on 10 June 2026 to help providers and deployers of generative AI systems meet the Article 50 marking and labelling obligations, and the Commission reports that about 190 organisations had signed it by the end of July 2026. 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

Stepping back, the staggered structure of the Act, as amended by the AI Omnibus, 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 — on 2 August the Act became generally applicable. The enforcement powers of the AI Office and national authorities began to apply, including the Commission’s power to fine GPAI model providers, as did the Article 50 transparency obligations for certain AI systems. The high-risk obligations did not: the AI Omnibus had already moved them.
  • December 2026 — from 2 December, a new prohibition on AI systems that generate non-consensual intimate material or child sexual abuse material applies, and generative AI systems placed on the market before 2 August 2026 must comply with the Article 50(2) marking and detection obligation.
  • August 2027 — by 2 August, providers of GPAI models placed on the market before 2 August 2025 must comply, and each Member State must have at least one national AI regulatory sandbox operational.
  • December 2027 — from 2 December, the high-risk obligations apply to Annex III systems: the use cases listed in the Act, such as AI used to recruit or select candidates for employment.
  • August 2028 — from 2 August, the high-risk obligations apply to Annex I systems: AI that is a product, or a safety component of a product, covered by the EU harmonisation legislation listed in Annex I and required to undergo third-party conformity assessment.

The split between the two high-risk dates is the detail most worth getting right. If your AI is embedded in a regulated product — the Commission’s examples include machinery, toys and lifts — your clock runs to the later date, and your conformity work intersects with sectoral regimes you already know. The Omnibus also narrowed what counts as a safety component: AI used solely for non-safety aspects such as user assistance, performance optimisation or convenience does not qualify, unless its failure would endanger health and safety. Mapping which of your systems fall under which date is itself a useful exercise, because it is easy to assume a single deadline applies uniformly when in fact different parts of a 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 is therefore not a series of cliffs but a combination of hard legislative dates and a rolling stream of soft-law clarification.

What the AI Omnibus changed

The AI Omnibus, proposed by the Commission on 19 November 2025 as part of its digital omnibus package, entered into force on 27 July 2026 — six days before 2 August 2026. It is now part of the law, and the consolidated text on the Commission’s AI Act Service Desk reflects it. According to the Commission, its changes include:

  • Extended high-risk timelines: 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
  • Simplification for small mid-cap companies: some measures previously reserved for SMEs now extend to them.
  • A simplified AI literacy requirement, with the Commission and Member States taking a stronger role in promoting AI literacy. Providers and deployers must still take measures to support the AI literacy of their staff and others operating AI systems on their behalf.
  • A new prohibition on AI systems that generate non-consensual intimate content or child sexual abuse material, applying from 2 December 2026.
  • Extended AI Office oversight of certain AI systems, including those built on general-purpose models and those embedded in very large online platforms and search engines.
  • Wider access to regulatory sandboxes, including a new EU-level sandbox.

What it did not do is relax the GPAI provider obligations. Articles 53 and 55 are unchanged, and the Commission’s enforcement powers over GPAI providers began to apply on 2 August 2026.

Our reading, as practitioners rather than lawyers: for the high-risk regime, the Omnibus changed the timing more than the core requirements. The underlying expectations around documentation, transparency, risk management, and accountability have not gone away; they have been given more time to land. In our view, the extra time before December 2027 is best treated as runway rather than relief.

The pragmatic stance: build your roadmap on the law as it now stands, design your controls so they are robust to reasonable changes in sequencing, and assign someone to track further amendments, guidelines, and standards 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 approach we recommend is to 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 further amendments to the Act. Translate changes into roadmap adjustments quarterly.

Milestone mapping. Plot your systems and models against the milestones above — including August 2027 for GPAI models already on the market before August 2025, December 2027 for Annex III systems, and August 2028 for Annex I systems — so that nothing on a later 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, guidance, and timeline continue to evolve.

If you prepared for 2 August 2026 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.

Sources

This article reflects our practitioner perspective on the EU AI Act as at October 2026 and is intended for general information. It is not legal advice. The GPAI regime, the codes of practice, and the surrounding guidance continue to develop, and specific obligations should be confirmed against the current legal text and assessed with qualified legal counsel for your particular circumstances.

Related Articles

Related Case Studies

View all case studies

Have a question about this topic?

Our team would be happy to discuss this further with you.

Get in Touch