EU AI Act GPAI Obligations: What Enterprises Using Foundation Models Must Do Now

The GPAI Blind Spot Most Enterprise Compliance Teams Are Missing

Most enterprise AI compliance programmes are built around a single mental model: classify your AI system by risk level, apply the corresponding obligations, and document accordingly. That framework works reasonably well for bespoke or internally-developed systems. It breaks down almost immediately when your AI stack runs on a foundation model — which, in 2025, describes the majority of enterprise AI deployments.

General Purpose AI, or GPAI, is defined under the EU AI Act as any AI model trained on broad data at scale that demonstrates significant generality and can competently perform a wide range of distinct tasks. OpenAI's GPT-4o, Google's Gemini, Anthropic's Claude, Meta's Llama series, and Mistral's commercial models all meet this definition. If your enterprise is using any of these — through an API, a vendor-packaged product, or a fine-tuned derivative — the GPAI provisions of the Act affect you, whether you are the provider of a model or the organisation deploying one built on top of it.

Articles 51 through 55 of the EU AI Act establish a tiered obligations framework for GPAI. The distinction that matters most for enterprises is between GPAI models generally and GPAI models of systemic risk — the latter being models trained on compute exceeding 10^25 FLOPs, or those designated by the European AI Office on capability grounds. GPT-4 class models almost certainly fall into the systemic risk tier. That designation carries substantially heavier obligations for the model provider, but it also changes the risk surface that deployer enterprises must manage and document.

The compliance gap this creates is not theoretical. Enterprises that have correctly mapped their deployer obligations under Articles 26 and 27 may still be completely unprepared for the questions that GPAI introduces: What technical documentation has your model provider made available? What are your obligations when you fine-tune or adapt a GPAI model? What does adequate post-market monitoring look like when the underlying model is not yours to inspect? These questions require answers before your organisation can claim a defensible compliance posture.

How GPAI Obligations Are Structured: Providers, Deployers, and the Chain Between Them

The EU AI Act's GPAI framework introduces a supply chain logic that enterprise compliance teams need to internalise. Article 51 draws the foundational distinction: GPAI providers are entities that develop and make available GPAI models, while downstream deployers build AI systems or products on top of those models. An enterprise using the OpenAI API to power an internal HR chatbot is simultaneously a deployer relative to OpenAI and, if that chatbot is distributed to other businesses, potentially a provider relative to its own customers.

For model providers, Article 53 sets out core obligations that apply to all GPAI models: they must prepare and maintain technical documentation, make available information and documentation to downstream providers building on their models, comply with copyright law and publish a summary of training data, and implement a policy to comply with Union copyright rules. These are baseline obligations. Providers of systemic-risk GPAI models carry an additional layer under Article 55: they must perform adversarial testing and red-teaming, report serious incidents to the European AI Office, implement cybersecurity protections, and ensure an adequate level of energy efficiency documentation.

For enterprises that are purely deployers — consuming a GPAI-based product without redistribution or modification — the direct GPAI obligations are lighter, but they are not zero. The obligations that flow from Articles 26 and 27 (deployer obligations for high-risk AI systems) interact with GPAI in a critical way: if you are using a GPAI model integrated into a high-risk AI system, your human oversight requirements, incident reporting duties, and fundamental rights impact assessment obligations all apply with full force. The fact that the intelligence sitting beneath your system is a third-party foundation model does not create a compliance exemption.

The practical challenge for most enterprises is information asymmetry. You are expected to conduct oversight and maintain documentation for a model you cannot inspect, audit, or retrain. This is precisely where the transparency requirements in Articles 53(1)(b) and 53(2) become operationally significant: GPAI providers are required to furnish downstream operators with enough technical information to enable them to meet their own obligations. If your foundation model vendor cannot or will not provide this, that is a governance red flag you should be documenting.

Systemic Risk Models: What Changes When You Build on GPT-4 Class Infrastructure

The systemic risk designation is where GPAI compliance gets genuinely demanding. The Act's threshold — training compute exceeding 10^25 FLOPs — is not a fixed ceiling. The European AI Office retains the authority under Article 51(2) to designate additional models as presenting systemic risk based on capability evaluations, multiplier effects, or the number of users affected across the Union. In practical terms, any frontier model from a major AI lab should be treated as falling within or near this tier unless you have specific documentation to the contrary.

For enterprises building on systemic-risk GPAI models, the compliance implications cluster around three obligations that your provider must fulfil — and that you have an indirect interest in verifying. First, under Article 55(1)(a), providers must perform adversarial testing before release and on an ongoing basis. You should be requesting evidence of this testing as part of your vendor due diligence, just as you would request penetration testing reports from a security vendor. Second, under Article 55(1)(b), providers must report serious incidents and corrective measures to the European AI Office without undue delay. If your deployment is affected by such an incident, your own incident response procedures need to account for the upstream notification timeline. Third, providers must maintain model documentation that is technically sufficient to enable downstream compliance — and if that documentation is absent, inadequate, or behind a commercial paywall, you have a governance exposure that regulators could attribute to the deploying enterprise.

For enterprises that fine-tune systemic-risk GPAI models on proprietary data — a common pattern in enterprise RAG architectures and domain-specific deployment — the picture becomes more complex. Fine-tuning does not transfer the provider's compliance obligations to the enterprise, but it does create a hybrid system where the enterprise takes on meaningful responsibility for the modified system's behaviour. Fronterio's deployer obligations tracker is designed specifically to surface these hybrid scenarios, mapping the obligations that shift when a GPAI model is customised versus consumed as-is, and generating an evidence chain that can be presented to a conformity assessment body or a national competent authority.

The Technical Documentation Gap: What You Should Be Demanding From Your AI Vendors

One of the most underappreciated operational requirements of the GPAI framework is the documentation obligation that runs between providers and downstream deployers. Article 53(1)(b) requires GPAI providers to make available to entities building on their models the information and documentation they need to comply with their own EU AI Act obligations. This is not optional. It is a legal requirement on the provider, and it creates a corresponding right — and due diligence obligation — for the enterprise deploying their technology.

In practical terms, this means your AI vendor contracts should now include explicit provisions requiring the provider to supply: training data composition summaries including data sources and filtering methodologies; model capability and limitation documentation covering known failure modes, performance boundaries across domains, and recognised biases; incident reporting commitments aligned with Article 73 timelines for serious incidents; and evidence of adversarial testing or red-teaming if the model is in the systemic risk tier. If your current contract with OpenAI, Anthropic, Google, or another foundation model vendor does not include these provisions, your legal and procurement teams have work to do.

The European AI Office is establishing codes of practice for GPAI providers under Article 56, and participation in those codes creates a presumption of conformity. As those codes are finalised through 2025, enterprises should track which of their vendors are participating and to what standard, since non-participation or non-conformity will affect the robustness of the documentation you can obtain and present.

Beyond contracts, the practical governance challenge is managing documentation across a multi-vendor AI stack. Most enterprises are not running a single foundation model; they are running several, through direct API access and through SaaS products that embed foundation models under the hood. Mapping each of these to its corresponding GPAI tier, its available technical documentation, and its incident reporting capabilities is a structured data problem. It requires an inventory process and a continuous update mechanism — precisely because model versions change, capability thresholds shift, and vendor policies evolve.

Incident Reporting Under Article 73: How GPAI Escalates the Stakes

Article 73 of the EU AI Act establishes the incident reporting obligation for providers and deployers of high-risk AI systems. Serious incidents — defined as incidents or malfunctions that directly or indirectly result in death, serious harm to health, serious infringement of fundamental rights, or significant disruption to critical infrastructure — must be reported to national market surveillance authorities without undue delay, and in any case within 72 hours of becoming aware of the incident for life-threatening situations.

Where GPAI intersects with Article 73 is in the systemic amplification risk. A critical vulnerability or capability failure in a foundation model used by thousands of enterprises simultaneously creates the conditions for coordinated, large-scale harm that no single deployer's monitoring would catch first. The European AI Office receives notifications from systemic-risk model providers directly under Article 55(1)(b), but deploying enterprises have their own parallel reporting duties when their specific deployment is implicated in a serious incident.

This creates a sequencing and communication problem that most enterprise incident response plans do not currently address. If OpenAI identifies a serious incident in GPT-4o that affects a class of deployments including yours, how does that notification reach your security operations centre? What is your protocol for assessing whether your specific deployment was implicated? What is the timeline for your own Article 73 notification to your national authority, relative to the upstream provider's notification to the AI Office?

Fronterio's Article 73 workflow is built around exactly this cascade: it monitors for upstream provider incident disclosures, maps them to affected deployments in your AI inventory, triggers an internal impact assessment process, and maintains the timestamped evidence chain that regulators expect to see in a post-incident audit. Without a structured workflow, enterprises are left managing this under time pressure with improvised tooling — a posture that is defensible in court only until it is not.

Post-Market Monitoring for GPAI-Powered Systems: What Continuous Oversight Requires

The EU AI Act does not treat deployment as a compliance endpoint. For high-risk AI systems, Articles 72 and 26(5) establish that deployers must implement post-market monitoring plans and report serious incidents. When the system in question is built on a GPAI foundation model, post-market monitoring is materially more complex because the model you are monitoring is not static. Foundation model providers update, retrain, and deprecate model versions continuously. A deployment that was compliant and well-characterised at launch may drift in its behaviour following an upstream model update you had no direct role in and may not have been adequately notified about.

Effective post-market monitoring for GPAI-powered systems therefore requires two parallel tracks. The first is internal: tracking the performance, error rates, user complaints, and downstream decision outcomes of your specific deployment against the baselines established at launch. This is standard post-market monitoring work, and the Act's expectations for documentation frequency and incident categorisation are set out clearly enough to design processes around. The second track is external: monitoring upstream provider communications for model version changes, deprecation notices, capability updates, and incident disclosures that could affect your deployment's compliance status even without any change on your side.

Fronterio's post-market monitoring synthesiser is designed for this dual-track model. It ingests both your internal deployment telemetry and publicly available or contractually provided upstream model change notices, flags divergences from your established compliance baseline, and generates the monitoring reports that Article 72 and its implementing acts will require deployers to maintain. The practical value is not just regulatory coverage — it is the ability to detect model drift before it manifests as a user-visible failure or a reportable incident.

Enterprises that have invested in GPAI-powered products should be building monitoring into the architecture of those products, not layering it on top after deployment. Instrumentation that captures decision rationale, output confidence signals, and user outcome data is not technically trivial, but it is the only foundation on which a credible post-market monitoring programme can be built.

Building a GPAI Compliance Posture: The Practical Checklist for Enterprise AI Leaders

Translating the GPAI obligations framework into a practical action list requires cutting through the regulatory abstraction and focusing on the specific decisions and documentation artefacts your organisation needs to produce. There are five areas that should be on every enterprise AI leader's immediate agenda.

First, inventory every foundation model in your stack — not just the ones you directly contract with, but the ones embedded in SaaS products, co-pilot tools, and third-party integrations. Many enterprise AI deployments involve GPAI models at layers the compliance team never directly evaluated. Fronterio's AI inventory and categorisation capabilities are built to surface this full stack, including the GPAI tier classification for each model.

Second, classify each model against the GPAI tiers. Models above the 10^25 FLOP training threshold or designated by the European AI Office as systemically risky trigger the heavier obligations under Article 55. Your classification should be documented and reviewed at least annually, or whenever a model version change is announced by your provider.

Third, audit your vendor contracts for documentation obligations. Under Article 53(1)(b), providers are legally required to furnish downstream operators with compliance-enabling information. If your current agreements do not reflect this, open procurement and legal conversations now — the compliance burden of incomplete upstream documentation falls on the deployer in a market surveillance investigation.

Fourth, integrate GPAI incident reporting into your existing security and incident response protocols. The Article 73 timeline is tight. Enterprises that are waiting for an incident to design their response process are accepting a regulatory risk that is entirely avoidable with structured preparation.

Fifth, establish a post-market monitoring baseline for every high-risk deployment built on GPAI. This means defining the performance indicators, the monitoring frequency, the escalation triggers, and the responsible owner before deployment — not after the first anomaly is reported. The Act's implementing acts will specify monitoring plan requirements in greater detail, but the structural investment in instrumentation cannot wait for that guidance to arrive.

What Regulators Will Actually Look For When They Audit GPAI Deployments

Enforcement of the EU AI Act will be conducted by national market surveillance authorities, with the European AI Office taking primary jurisdiction over GPAI providers of systemic-risk models. For deploying enterprises, the audit questions that will matter most are not abstract compliance assessments — they are documentation requests.

Regulators will ask to see your AI system inventory and want evidence that each GPAI-powered system has been correctly classified. They will ask for the technical documentation you received from your model provider under Article 53 and will want to verify that it was adequate for you to understand the model's capabilities, limitations, and known failure modes. They will ask for your post-market monitoring records and specifically for evidence that monitoring was active before any incident you are being investigated for. They will ask for your incident response records with timestamps demonstrating that Article 73 timelines were met. And if your deployment involves a high-risk AI system, they will ask for the Fundamental Rights Impact Assessment that Article 27 requires deployers in certain contexts to conduct.

What regulators will not accept is a general assurance that you take AI governance seriously, unsupported by structured evidence. The EU AI Act is a documentation-heavy regulation by design. The compliance posture that survives an audit is one built on artefacts, audit trails, and automated evidence collection — not on policy documents that no one has acted on.

For enterprises using Fronterio, the auto-evidence ladder capability is the practical mechanism for maintaining this artefact record continuously, not in preparation for an audit that may never come. The posture shift that GPAI compliance requires is from periodic compliance reviews to continuous compliance operations — maintaining the evidence chain as a byproduct of normal governance activity, rather than reconstructing it under regulatory pressure.