EU AI Act Art.111(3) GPAI Transitional Obligations: What Model Providers Must Complete Before August 2, 2027

Post #4 in the sota.io EU AI Act Transitional Compliance Series

If you provide a general-purpose AI model — or build SaaS on top of one — there is a deadline that most EU AI Act coverage barely mentions: August 2, 2027.

Posts one through three in this series covered the main 2026 compliance crunch for high-risk AI systems, the substantial modification trigger, and the Annex X large-scale IT systems that get until 2030. This post covers the fourth and least-discussed transitional track: Article 111(3) of Regulation (EU) 2024/1689, the two-year grace period granted to GPAI model providers whose models were already on the EU market before the GPAI chapter entered into force.

The grace period is real. But it is not passive. Every GPAI provider in scope must be actively building compliance infrastructure now — because August 2, 2027 requires a complete, demonstrable implementation of Art.53 and, where applicable, Art.55 obligations. This guide walks through what that means in practice.

Who Is In Scope: The Art.111(3) Coverage Test

Article 111(3) sets out the scope in one sentence: providers of GPAI models that were placed on the EU market before August 2, 2025 — the date when the GPAI chapter of the EU AI Act entered into force — must comply with the obligations in the GPAI chapter by August 2, 2027.

The operative concepts here are "placed on the market" and "August 2, 2025."

What "Placed on the Market" Means for GPAI Models

For physical products, "placing on the market" has a clear legal meaning: first making the product available in the EU for distribution or use. The EU AI Act applies the same concept to GPAI models, but the practical interpretation differs for software:

• Closed API access: A GPAI model is placed on the EU market when it first becomes accessible to EU-based users or EU-based businesses via API, regardless of where the servers are located. For OpenAI, Anthropic, Google, Mistral, and comparable API-first providers, the placement date is when they first opened their APIs to EU customers — typically the original commercial launch date.
• Open-source release: A GPAI model is placed on the EU market when it is published under an open or open-source licence and made available for download and use, including in EU jurisdictions. Llama models, Mistral open releases, and comparable foundation models placed on platforms like Hugging Face are subject to this interpretation.
• B2B licensing: Enterprise licensing agreements covering EU deployment of a GPAI model constitute placing on the EU market from the date the first EU customer is authorized to use the model under the licence.

The Cut-Off Date: August 2, 2025

Under Art.111(3), models placed on the EU market before August 2, 2025 benefit from the two-year transitional period. Models placed on the EU market on or after August 2, 2025 must comply with the GPAI chapter from the date of placement — there is no grace period for new entrants.

This creates a clear split in the current GPAI landscape:

The practical implication: every major foundation model that SaaS developers currently access via API is within the Art.111(3) window. Their providers have until August 2, 2027 to complete the transition — but the obligations they must complete are the same as the Art.53 and Art.55 requirements that apply to new models from day one.

The Two-Tier GPAI Compliance Structure

Understanding the Art.111(3) deadline requires understanding the underlying structure of GPAI obligations, which operates in two tiers.

Tier 1: Art.53 Obligations — Applicable to All GPAI Models

Article 53 establishes the baseline obligations for every provider of a GPAI model placed on the EU market, regardless of training scale or systemic risk classification. These obligations apply to providers of GPT-4, Claude, Gemini, Llama, and every other foundation model — including smaller GPAI models not near the systemic risk threshold.

The Art.53 obligations are:

1. Technical documentation

Providers must draw up and maintain technical documentation covering the model before placing it on the EU market. This documentation must contain at a minimum the information set out in Annex XI of the Regulation. In practice this means:

• A description of the model architecture and training approach
• The training data used, including source types and any filtering or curation applied
• The model's capabilities, performance benchmarks, and known limitations
• Intended use cases and out-of-scope uses
• Output types and modalities
• Compute resources used in training (relevant for systemic risk threshold assessment)
• Any safety measures, fine-tuning, or RLHF applied

This is more comprehensive than a typical model card. It is a structured technical file that must be made available to the AI Office on request and to downstream providers who build systems on the model.

2. Information for downstream providers

GPAI providers must provide the information necessary for downstream AI system providers — the SaaS teams that build on the model — to understand the model's capabilities and limitations and to comply with their own EU AI Act obligations. This includes:

• The technical documentation or a structured subset of it
• Instructions for use that cover the intended operating parameters
• Information about the training data sources relevant to copyright compliance
• Any restrictions on use cases or deployment contexts

For SaaS teams, this means you are entitled to receive structured disclosure from your API provider under Art.53. If your API provider is not providing this information, they are not in compliance — and as of August 2, 2027, you will need to be able to demonstrate that your GPAI model provider has met their Art.53 obligations.

3. Copyright compliance policy

Providers must implement a policy to comply with Union copyright law, in particular Directive 2019/790 on copyright in the digital single market. This policy must address how the provider handles requests from rights holders who have opted out of their works being used for AI training under the text and data mining opt-out mechanism in the EU Copyright Directive (Directive 2019/790).

In practice, this requires:

• A documented policy governing training data and copyright compliance
• A mechanism for rights holders to notify opt-out requests
• Records of how opt-out requests are processed and honored in training data pipelines

4. Training data summary

Providers must publish a sufficiently detailed summary of the content used to train the GPAI model. The AI Office has developed a template for this purpose as part of the GPAI codes of practice. The summary must be public — it is not a confidential document — and must enable rights holders and researchers to assess copyright exposure and data provenance at a high level.

5. Cooperation with the AI Office

GPAI providers must cooperate with the European AI Office, including:

• Providing access to documentation on request
• Providing access to the model itself for evaluation purposes when the AI Office requests it
• Designating an authorized representative in the EU if the provider is not established in the Union

The authorized representative requirement is significant for US-based providers. OpenAI, Anthropic, and Google have EU entities — but the requirement extends to any GPAI model provider making models available to EU users who lacks an EU establishment. The authorized representative assumes full legal responsibility for the provider's compliance and must be designated in writing before the model is placed on the EU market (or, for Art.111(3) models, before August 2, 2027).

Tier 2: Art.55 Obligations — Additional Requirements for Systemic Risk Models

Article 55 applies a second, more demanding layer of obligations to GPAI models classified as posing systemic risk under the GPAI chapter of the Regulation. The systemic risk threshold is defined by the amount of compute used in training: models trained with more than 10^25 floating-point operations (FLOPs) are presumed to have systemic risk.

As of mid-2026, the models that clearly exceed this threshold include:

• GPT-4 and later OpenAI frontier models
• Claude 3 Opus and the Claude 4 family
• Gemini Ultra and Gemini 1.5 Pro
• Likely several other proprietary frontier models whose training compute has not been publicly disclosed but exceeds the threshold based on publicly known system capabilities

The Art.55 obligations are in addition to Art.53, not instead of them:

1. Perform model evaluations

Providers must carry out model evaluations in accordance with standardised protocols and, where applicable, in accordance with codes of practice. These evaluations must be carried out at least before placing the model on the EU market and after any significant model update or fine-tuning. The evaluations must be documented and made available to the AI Office.

For Art.111(3) models that predate August 2025, providers must conduct these evaluations as part of their transition to compliance before the 2027 deadline. Evaluations cannot be retroactively dated — they must be conducted and documented before the 2027 deadline.

2. Adversarial testing (red-teaming)

Systemic risk GPAI providers must conduct adversarial testing of the model — sometimes called red-teaming — to identify potential harms, bias patterns, misuse vectors, and safety vulnerabilities. The AI Office has published guidance on acceptable methodologies as part of the GPAI codes of practice.

The adversarial testing requirement is ongoing, not a one-time exercise. It must be repeated after significant model updates and periodically during the model's lifecycle.

3. Incident reporting to the AI Office

Providers of systemic risk GPAI models must report serious incidents — defined as incidents that cause or are reasonably likely to cause significant harm — to the AI Office. Reporting must occur within 24 hours of the provider becoming aware that the serious incident has occurred.

This is one of the strictest reporting timelines in the EU AI Act framework. It places a compliance obligation on model providers to have incident detection infrastructure capable of identifying model-related harms at API scale, and an escalation process capable of generating an AI Office notification within 24 hours of discovery.

4. Cybersecurity measures

Systemic risk GPAI providers must implement appropriate cybersecurity protections for the model and its infrastructure. This includes protection against adversarial attacks designed to manipulate the model's outputs, protection of the model weights, and security measures for the training infrastructure.

5. Energy efficiency reporting

Systemic risk providers must document and report the energy consumption of the model, including training and inference. The AI Office has developed reporting templates for this requirement as part of the GPAI codes of practice.

The 2025-to-2027 Transition Timeline

For Art.111(3) GPAI providers, the two-year window from August 2, 2025 to August 2, 2027 should not be treated as two years of low-priority compliance work. The compliance build-out required is substantial. A practical timeline:

August 2025 — Start of the grace period

• Document which model versions are within the Art.111(3) scope (placed before Aug 2, 2025)
• Assess whether any model in scope exceeds the 10^25 FLOPs systemic risk threshold
• Assign internal compliance ownership for GPAI obligations
• Begin gap assessment against Art.53 documentation requirements

Q4 2025 — Documentation foundation

• Complete technical documentation to Annex XI standards for all in-scope models
• Draft and publish the training data summary (public-facing)
• Establish and document the copyright compliance policy and opt-out mechanism
• Designate EU authorized representative (if applicable)

Q1 2026 — AI Office engagement

• Register in the AI Office's GPAI model registry (once operational)
• Establish the information-sharing structure for downstream deployers
• For systemic risk models: begin adversarial testing under the codes of practice framework
• Establish the incident detection and AI Office reporting pipeline

Q2–Q3 2026 — Systemic risk compliance build-out

• For systemic risk models: complete initial model evaluations and document results
• Implement cybersecurity measures and document them against the AI Office framework
• Establish energy efficiency measurement and reporting capability
• Complete first adversarial testing cycle and document findings

Q4 2026 — Gap closure and testing

• Internal audit of Art.53 compliance posture — is documentation complete?
• For systemic risk models: second adversarial testing cycle, review incident reporting test
• Update downstream deployer information packages with any updates from the past year
• Legal review of authorized representative designation and Art.53 completeness

August 2, 2027 — Compliance deadline

• All Art.53 obligations fully implemented and documented
• For systemic risk models: all Art.55 obligations fully implemented
• AI Office cooperation infrastructure in place
• Ongoing monitoring, testing, and reporting cycles operational

What Downstream SaaS Developers Need to Verify

If you build SaaS on GPAI model APIs, Art.111(3) creates an indirect due diligence obligation for you. Your EU AI Act compliance as a deployer depends in part on the GPAI model you deploy being lawfully placed on the EU market and having completed its Art.53 obligations.

After August 2, 2027, you should be able to demonstrate:

1. Your GPAI provider completed the Art.111(3) transition Request updated compliance documentation from your API provider. This should include a statement that Art.53 obligations have been met, a copy or reference to the public training data summary, and confirmation that an EU authorized representative has been designated if applicable.

2. You have received the Art.53 downstream information Under Art.53, your API provider owes you structured disclosure — technical documentation (or a relevant subset), instructions for use, and copyright compliance information. If you have not received this, you are either missing it or your provider has not met their obligations. Either way, it is a compliance gap that needs to be addressed before August 2027.

3. For systemic risk models: you understand the incident reporting chain If your SaaS integrates a systemic risk GPAI model, your API provider has a 24-hour AI Office reporting obligation for serious incidents. Your own incident response plan should account for this — including the scenario where your API provider notifies the AI Office of a serious incident that affects your product, and regulators subsequently inquire about your own use of the model.

Infrastructure Considerations for GPAI Compliance

One of the less-discussed Art.53 requirements is the authorized representative obligation for GPAI providers without an EU establishment. But the infrastructure dimension goes beyond legal presence — it extends to where model inference and training operate.

For GPAI providers and for SaaS teams deploying custom fine-tuned variants:

• Log storage jurisdiction: The technical documentation requirement under Art.53 and the incident reporting requirement under Art.55 both create data that must be available to the AI Office on request. Where that data is stored determines whether it is exposed to third-country data access laws, including the US CLOUD Act. GPAI providers processing EU user data for model evaluation or incident investigation purposes face CLOUD Act exposure if infrastructure is in US-jurisdiction clouds.

• Model serving jurisdiction: There is no explicit "model must be served from the EU" requirement in Art.53 or Art.55. But Art.55's cybersecurity requirement and the AI Office's ability to request model access create practical arguments for EU-infrastructure hosting of the inference layer for EU users, particularly for systemic risk models.

• Fine-tuned variants: If your SaaS team fine-tunes a GPAI model on your own data and deploys that variant to EU users, you may be acting as a GPAI model provider yourself — particularly if your fine-tuned variant is made available to other parties. This creates a separate compliance question beyond simply relying on your upstream provider's Art.111(3) transition.

Summary Checklist for GPAI Providers (Art.111(3))

For each GPAI model placed on the EU market before August 2, 2025:

Art.53 Baseline (All GPAI models):

• Technical documentation complete to Annex XI standard
• Downstream deployer information package prepared and published
• Copyright compliance policy documented and opt-out mechanism operational
• Training data summary published publicly
• EU authorized representative designated (if provider not EU-established)
• AI Office cooperation infrastructure in place

Art.55 Additions (Systemic risk models only — 10^25 FLOPs threshold):

• Model evaluation completed per AI Office protocols and documented
• Adversarial testing cycle completed and documented
• 24-hour serious incident detection and AI Office reporting pipeline operational
• Cybersecurity measures implemented and documented
• Energy efficiency measurement and reporting established

For Downstream SaaS Developers:

• Confirmed API provider's Art.111(3) transition status
• Received Art.53 downstream information from API provider
• Assessed CLOUD Act exposure of inference and log infrastructure
• Mapped own incident response plan to provider's Art.55 reporting chain

Post #5 Preview

The final post in this series — the Transitional Compliance Strategy Checklist Finale — synthesizes all four tracks (Tier 1 large-scale IT systems, Tier 2 high-risk AI, Tier 3 GPAI models, and the substantial modification trigger) into a single decision tree and compliance status dashboard. If you are managing multiple AI systems across multiple compliance tracks with different deadlines, that checklist is designed to give you a single-view status report to bring to your legal and product teams.