GPAI Models and the 10²³ FLOP Threshold
What every platform builder must know
If you are building a platform that uses a general-purpose AI model, whether you are integrating a frontier model via API, fine-tuning an open-source model for your product, or wrapping a foundation model in a vertical application, the EU AI Act creates specific obligations that fall on your model provider, not on you. That is the key sentence in the entire GPAI regulatory framework, and it is the one that most platform builders have not read carefully enough.
Understanding who bears which obligations, what your providers are required to disclose, and what systemic risk means for the models you are building on is not optional due diligence. It is the prerequisite for making defensible architecture decisions about how to integrate GPAI into your platform without inheriting obligations that belong to someone else.
This is the fourth article in our ten-part series on AI governance. If you have not yet read The Seven Mandatory Requirements for High-Risk AI Systems, that article covers the full set of obligations that apply to high-risk system providers. This article focuses on a distinct regulatory category : GPAI models; and explains how the obligations attach differently depending on whether you are a model provider, a platform builder, or a deployer.
GPAI Is a Distinct Regulatory Category
The EU AI Act treats GPAI models as a separate regulatory object from GPAI systems. This distinction is deliberate and consequential.
A GPAI model is a foundation model : a machine-trained system that produces outputs from inputs and can be adapted to a wide range of downstream applications. GPT-4, Claude, Gemini, Llama, Mistral, and their equivalents are all GPAI models. The model itself is the regulated object.
A GPAI system is what you get when a GPAI model is integrated into a specific application with a defined intended purpose. The platform you are building, the product you are shipping, the application your customers use : that is a GPAI system.
The regulatory implication is straightforward but important: the provider of the model bears the model-level obligations. The builder of the platform or application bears system-level obligations only if the application is high-risk or if they have substantially modified the underlying model. If you are building an application that calls a frontier model’s API (without retraining, fine-tuning, or otherwise changing the model itself) you are a GPAI system builder, not a GPAI model provider. The obligations under Articles 53 and 55 sit with whoever trained and released the model.
This distinction determines which obligations are yours and which are your upstream provider’s.
Article 53 - Obligations for All GPAI Providers
Article 53 imposes four obligations on all providers of GPAI models, regardless of model size, compute footprint, or market share. These are baseline obligations that apply to every organization training and releasing a GPAI model.
1. Technical Documentation
GPAI model providers must produce and maintain technical documentation that describes the model’s architecture, training approach, capability evaluation, known limitations, and intended use cases. The format is specified by the GPAI Code of Practice’s Model Documentation Form : providers do not need to invent their own template.
The documentation must be kept current and must be available to downstream deployers who need it to assess whether the model is suitable for their intended application. This is the primary mechanism by which downstream builders get the information they need to make informed integration decisions.
Practical implication for platform builders : Before you integrate a GPAI model, ask your provider for their technical documentation package. If the provider cannot produce this, that is a signal about their compliance posture — and about the risk you are assuming by integrating their model without adequate documentation.
2. Copyright Compliance Policy
Providers must document the measures taken to identify and comply with rights reservations from training data. The EU AI Act does not require providers to disclose what training data was used. It requires them to demonstrate that they have a process for respecting copyright reservations.
This is a process documentation obligation, not a disclosure obligation. A provider that has a documented copyright compliance process (one that examines training data sources, respects opt-out requests, and logs the steps taken) satisfies Article 53(1)(b) even if they do not publish the training data itself.
For platform builders : Ask your model provider to describe their copyright compliance policy. The question is not what data they trained on : it is what process they use to respect rights reservations. Providers who cannot answer this question have not built the compliance infrastructure that Article 53 requires.
3. Training Data Summary
Providers must publish a summary of the training data characteristics. This is a factual summary; not a full data dump, not a dataset release. The GPAI Code of Practice provides templates for this summary. The purpose is to give downstream deployers enough information to assess whether the model’s training data is appropriate for their use case.
The summary covers the type, volume, and nature of training data; the geographical and temporal scope; and any known gaps or limitations. It is deliberately high-level; it is not a substitute for a full data sheet, but it is the minimum that downstream users need to evaluate a model.
4. Downstream Information Duties
Providers must supply downstream deployers with information that enables them to : understand the model architecture, comply with acceptable use policies, assess known limitations, and evaluate performance factors relevant to the deployer’s intended use.
This obligation is continuous : it applies as long as the model is in service. If a provider updates the model in a way that materially affects performance or safety characteristics, they must update the information they provide to downstream deployers.
Article 55 - Additional Obligations for Systemic Risk Models
Article 55 adds a second tier of obligations for GPAI models that meet the systemic risk threshold. These obligations are more demanding, and the systemic risk threshold is calibrated to capture essentially all frontier models.
The 10²³ FLOP Threshold
A GPAI model is presumed to have systemic risk if the cumulative compute used for training exceeds 10²³ FLOP (floating-point operations). This is a cumulative threshold : it measures the total compute used across the entire training run, not the compute used for any single training step.
The threshold is set at a level that covers the models that trained above it. As of 2025, every major frontier model (GPT-4 class and above) exceeds 10²³ FLOP. The models that do not exceed it are generally smaller open-source models trained on limited compute budgets.
The threshold is not a size categorization; it is a risk categorization. Models above the threshold are not automatically dangerous. They are presumed to pose systemic risk because of their capability profile, which creates the potential for widespread harm if they are misused or if they fail in consequential domains. The additional Article 55 obligations are the regulatory response to that risk presumption.
Article 55 Obligations
For providers of systemic risk GPAI models, the following additional obligations apply :
Adversarial testing. Providers must conduct testing against state-of-the-art adversarial threats before market placement. This means red-teaming the model for capability misuse, emergent dangerous behaviors, and attack vectors specific to the model’s modality.
Safety and Security Framework. Providers must maintain and report a documented framework to the AI Office. This means describing the model’s safety architecture, testing methodology, incident response process, and governance structure for ongoing safety monitoring.
Safety and Security Model Report. Providers must submit a report to the AI Office before market placement. This means documenting model capabilities, known risks, mitigation measures, and residual risk acceptance decisions.
Serious incident reporting. Providers must report serious incidents to the AI Office. This means defining what constitutes a serious incident for your model and establishing and testing an escalation path to AI Office reporting.
The GPAI Code of Practice
The GPAI Code of Practice was published on 10 July 2025 and endorsed by the Commission on 1 August 2025. It provides the templates, methodologies, and procedural guidance that translate the legal obligations in Articles 53 and 55 into implementable documentation requirements.
Signing the Code of Practice is voluntary. Providers who sign it receive a presumption of compliance; in any enforcement action, their adoption of the Code’s guidance is a mitigation factor. Providers who do not sign must demonstrate compliance through alternative means and must report to the AI Office how they intend to satisfy their obligations without the Code’s template support.
The practical reality : The GPAI Code of Practice is the de facto compliance path for frontier model providers. The templates reduce the documentation burden substantially. Non-signers must build equivalent documentation from scratch. Given that the Code was developed with broad industry input and is the reference point that conformity assessment bodies will use, not signing is a decision that requires an explicit alternative compliance strategy.
What Platform Builders Must Confirm
If you are building a platform or product that integrates a GPAI model, your regulatory exposure as a system builder is determined by two questions :
(1) are you substantially modifying the model, and
(2) if the model is above the systemic risk threshold, is your upstream provider meeting their Article 55 obligations?
Substantial modification (retraining on new data, changing the model’s architecture, altering its capability profile in ways that create new risk vectors) can shift you from system builder to model provider. The threshold for substantial modification is not precisely defined in the regulation, but the principle is clear : if you are changing the model fundamentally, you are responsible for the model-level obligations.
For platforms that integrate unmodified frontier models, the obligation structure is :
What you are responsible for as a platform builder :
High-risk system classification : If your platform’s application falls under Annex III (high-risk categories), you bear the full set of Articles 9–17 obligations as a provider
Fundamental Rights Impact Assessment : For high-risk applications affecting fundamental rights, conducted before first deployment
Human oversight : Article 14 obligations for the application layer (your platform must enable effective human oversight of the application’s outputs)
Post-market monitoring : Article 17 obligations for your application (you must actively monitor how your application performs and update your risk records when new risks emerge)
GPAI system registration : Your application must be registered in the EU AI database before market placement
What your GPAI model provider is responsible for :
Model-level technical documentation (Article 53)
Copyright compliance process (Article 53)
Training data summary (Article 53)
Downstream information provision (Article 53)
For systemic risk models: adversarial testing, Safety and Security Framework, AI Office reporting (Article 55)
The documentation chain : Your conformity declaration for your platform references the model provider’s technical documentation. If the model provider’s documentation is incomplete, your ability to demonstrate conformity at the platform level is compromised. Due diligence on your upstream provider’s compliance infrastructure is not just good practice; it is a component of your own compliance posture.
The Systemic Risk Reality
The 10²³ FLOP threshold is not controversial because it is set too low; it is controversial because it is set at a level that captures nearly every frontier model that organizations are building on. This is intentional. The EU regulatory framework’s designers understood that models at the capability level of GPT-4 and Claude carry systemic risk by virtue of their capability profile, regardless of the intent of the organizations deploying them.
What this means for platform builders is concrete : every time you integrate a frontier model’s API and expose it to your users, you are building on infrastructure that is subject to Article 55 obligations. Your provider (OpenAI, Anthropic, Google, Meta, Mistral, or whoever is training the model) bears those obligations. But your platform’s risk management must account for the possibility that your provider’s compliance infrastructure fails.
The question to ask your GPAI provider is not just “are you compliant?” It is “can you produce your technical documentation, your copyright compliance policy, your training data summary, and (if you are above the systemic risk threshold) your adversarial testing results and Safety and Security Framework report?”
If the answer to any of those questions is “no” or “we are working on it,” your platform’s compliance posture is built on a foundation you cannot rely on.
The Documentation You Should Have
For every GPAI model you integrate, you should have on file :
The provider’s technical documentation (Article 53)
The provider’s copyright compliance policy statement
The provider’s training data summary
Documentation of the provider’s acceptable use policy and your platform’s alignment with it
If the model is above the systemic risk threshold : the provider’s adversarial testing evidence and Safety and Security Framework (or an equivalent alternative)
Your own model integration assessment : what changes you made (if any), what the model’s outputs are used for in your application, and how your application maps to the Article 9–17 requirements if it is high-risk
This documentation does not need to be disclosed publicly. It needs to be retrievable. If a regulator asks to see your evidence of GPAI provider due diligence within 24 hours, and you cannot produce it, the gap is not in the provider’s compliance : it is in your own documentation infrastructure.
Next: The 2 February 2025 Enforcement Cliff — Prohibited Practices and AI Literacy Already Binding
Download our free GPAI Compliance Readiness Checklist for Platform Builders
