EU AI Act Art.71: GPAI Model Registration — Art.51, Art.52 & Annex VIII Part II Requirements 2026

Post #1659 in the sota.io EU AI Act Compliance Series — EU-AI-ACT-ART71-DATABASE-REGISTRATION-2026 #3/5

In our previous post we covered Annex VIII Part I — the twelve fields every provider of a high-risk AI system under Annex III must submit to the EU database. But Art.71 creates a second, parallel registration regime that most SaaS developers are unaware of: the mandatory registration of General Purpose AI (GPAI) models with systemic risk under Art.71(2).

This matters to you even if you are not a foundation model provider. If your SaaS product is built on top of a GPAI API — GPT-4, Claude, Gemini, Mistral, or any other large model — then the registration status of that upstream provider is now part of your own compliance picture. Understanding the GPAI registration regime tells you exactly what to demand from your AI API providers and how to verify that your supply chain is compliant.

Two Registration Regimes, One Database

Art.71(1) establishes the EU database for high-risk AI systems listed in Annex III — that is the regime covered in posts #1657 and #1658 of this series. The registrant is the provider of the system, and the information submitted is drawn from Annex VIII Part I.

Art.71(2) adds a second layer: GPAI models with systemic risk must also be registered in the EU database by their providers. The information submitted for these models follows a separate template — Annex VIII Part II. The registrar is the European AI Office (part of the Commission), not the national competent authority.

This distinction matters in practice:

Art.51: Which GPAI Models Must Register?

The registration obligation under Art.71(2) only applies to GPAI models that are classified as having systemic risk under Art.51.

Art.51 establishes two routes to systemic risk classification.

Route 1: The Training Compute Threshold

A GPAI model is presumed to have systemic risk if the cumulative amount of compute used for training, measured in floating point operations (FLOPs), exceeds 10^25 FLOPs.

This threshold is not chosen arbitrarily. At the time of the regulation's adoption, models trained at or above this level — GPT-4 class and above — represent the frontier of capability and the highest potential for cross-sectoral societal impact. The 10^25 FLOPs boundary is a hard line: once crossed, the systemic risk classification and all accompanying obligations apply automatically, without the need for a Commission decision.

For downstream developers: you cannot calculate this value yourself. You must rely on disclosure from your GPAI provider. Art.53(1)(a) obliges all GPAI model providers — regardless of whether they have systemic risk — to prepare and maintain technical documentation that includes training methodology, compute used, and data sources. This documentation forms the evidentiary basis for the systemic risk determination.

Route 2: High-Impact Capabilities Designated by the Commission

Even if a model's training compute falls below 10^25 FLOPs, the Commission may designate it as having systemic risk based on demonstrated or reasonably foreseeable high-impact capabilities. This is a forward-looking power designed to catch future model architectures that may achieve frontier capabilities through greater efficiency rather than raw compute.

Art.52 establishes the procedure for this designation:

1. The European AI Office monitors the market for models that may have high-impact capabilities
2. The AI Office may request technical documentation and additional information from providers
3. Providers may also voluntarily notify the AI Office if they believe their model may have systemic risk based on high-impact capabilities
4. Following assessment, the Commission may issue a decision designating the model as having systemic risk

Practical implication: If you are building a product on a model that the AI Office begins to investigate under Art.52, you may receive requests for information about your downstream deployment through your contract with the GPAI provider. This is part of the Art.53 cooperation obligation that flows through the supply chain.

Art.53: Obligations for All GPAI Providers (Not Just Systemic Risk)

Before examining what GPAI providers with systemic risk must register (Annex VIII Part II), it is important to understand the baseline obligations that apply to all GPAI model providers under Art.53. These are separate from the registration requirement but directly relevant to what you, as a downstream operator, can legally demand.

Every GPAI model provider available in the EU must:

Technical Documentation

Prepare and keep up to date technical documentation that includes:

• The training methodology and training data used (types and sources)
• The computational resources used for training
• The model's capabilities, limitations, and known biases
• The intended purposes and reasonably foreseeable misuses
• Evaluation procedures and results, including red-teaming

This documentation is submitted to the AI Office on request, or as part of the registration for systemic risk models.

Information for Downstream Operators

Provide downstream operators (i.e., you, the SaaS developer) with information sufficient to enable them to understand the model's capabilities and limitations, comply with their own AI Act obligations, and implement appropriate safeguards.

This obligation creates a contractual information right. When you sign up for a GPAI API, you are entitled to receive — and should actively request — a transparency document that covers these points. "It works great, here are the API docs" is not sufficient under Art.53.

Copyright Compliance and Training Data Summary

Maintain a policy on compliance with EU copyright law, in particular Regulation (EU) 2019/790 (the Digital Single Market Directive). Publish a publicly available summary of the content used for training.

For SaaS developers, this matters when clients in regulated sectors (media, publishing, legal) ask about the provenance of the AI outputs your product generates.

Annex VIII Part II: What GPAI Providers Must Register

For GPAI models that have been classified as having systemic risk — either through the 10^25 FLOPs threshold or a Commission designation — the provider must register in the EU database using the Annex VIII Part II template.

The Annex VIII Part II registration fields for GPAI models with systemic risk cover the following categories of information:

Provider Identity

Name, address, and contact details of the provider. If the provider is established outside the EU, the details of their EU authorised representative designated under Art.54 are also required.

This authorised representative requirement is critical for non-EU GPAI providers. A US or UK foundation model company serving EU customers must designate an EU-based legal entity to act as their authorised representative for AI Act purposes — this entity can be held accountable by EU regulators.

Model Identity and Description

The name of the GPAI model (including version information) and a general description of its capabilities, architecture type, and intended general purposes. Providers must distinguish between different versions if they have different capability profiles.

Training Compute

The cumulative compute used for training, measured in FLOPs. This is the figure that substantiates the Art.51 systemic risk classification. The AI Office can request supporting evidence for this figure.

Training Data Summary

A description of the types and sources of training data used, including whether the training data included web-crawled data, licensed content, synthetic data, or proprietary datasets. The level of detail required is sufficient to allow the AI Office to assess potential copyright issues and bias risks at population scale.

Date of Market Placement

The date on which the GPAI model was first made available in the EU market, whether via direct deployment, API access, or integration into products. For models already on the market when the GPAI obligations entered into force (12 months after the AI Act entered into force — i.e., by August 2025 for GPAI models), providers had a transitional period to bring their documentation into compliance.

Downstream Deployment Information

Where known, information about the categories of providers and downstream operators using the model, and the primary use cases in which the model is deployed. GPAI providers with broad API access (millions of downstream integrations) will provide aggregate category descriptions rather than individual customer lists.

Ongoing Obligations Covered in Registration

The registration also references compliance with the Art.55 additional obligations (adversarial testing, serious incident reporting, cybersecurity). These are not submitted as evidence at registration time but are referenced as ongoing obligations the provider confirms they are undertaking.

Art.55: Additional Obligations That Accompany Registration

Registration under Art.71(2) does not discharge the systemic risk obligations — it is one step in a larger compliance package. The registered GPAI provider must also comply with Art.55:

For SaaS developers: the adversarial testing and incident reporting obligations create a feedback loop between your product's incidents and the upstream model provider's compliance status. If your product causes a serious incident that traces to the GPAI model's behaviour, the AI Office may investigate the upstream provider's Art.55 compliance.

The EU AI Office as Registrar: Implications for Developers

Unlike high-risk AI system registration (Art.71(1)), which is supervised by national competent authorities, the GPAI registration regime is administered centrally by the European AI Office — a cross-border body embedded in the Commission.

This has several practical implications for SaaS developers:

Single point of inquiry: If you want to verify that a GPAI provider is registered, you check the EU database maintained by the AI Office, not seventeen different NCA registers. This simplifies supplier due diligence.

Cross-border enforcement: Enforcement against GPAI providers with systemic risk is coordinated EU-wide, not country-by-country. A UK-based GPAI provider serving EU customers via an Irish subsidiary does not escape systemic risk obligations by choosing a favourable jurisdiction.

AI Office guidance authority: The AI Office publishes guidance, requests documentation, and can issue non-binding opinions on model classification. Its guidance on what constitutes "high-impact capabilities" under Art.51(2) will shape which mid-tier models eventually fall under systemic risk classification — and therefore under the Art.71(2) registration requirement.

What SaaS Developers Must Verify

If you build your product on top of a GPAI API, here is what Art.71(2) compliance requires from your side:

Confirm Your Provider's Registration Status

Once the EU database is operational, you should verify that your primary GPAI API provider appears in it with an active registration. A provider that has crossed the 10^25 FLOPs threshold and is actively serving EU customers but is not registered is in breach of the AI Act — and using their API for EU market deployments exposes your product to market surveillance scrutiny.

Practical step: Request a written confirmation from your GPAI API provider (via their legal/compliance team or their published compliance documentation) that they have registered under Art.71(2) and their registration ID.

Obtain the Art.53 Information Package

Even if your provider's model is below the systemic risk threshold (and therefore not subject to Art.71(2) registration), you are entitled under Art.53(1)(b) to receive information about the model's capabilities and limitations sufficient to comply with your own AI Act obligations.

Ask your GPAI provider for:

1. Technical documentation summary (capability profile, known limitations, bias assessments)
2. Training data categories and sources (to assess copyright and bias exposure)
3. Intended purposes and documented misuse cases (to validate your use-case risk assessment)
4. Any Art.56 codes of practice the provider has signed

Contract Clauses to Include

When contracting with GPAI providers for EU market products, include:

• A representation and warranty that the provider is compliant with applicable EU AI Act obligations including Art.71(2) where applicable
• An obligation to notify you of any Art.55 incident reports submitted to the AI Office
• A right to receive updated Art.53 technical documentation when the model is significantly updated

GPAI Registration vs. High-Risk AI System Registration: The Intersection

The two Art.71 registration regimes are not mutually exclusive. A product that uses a GPAI model as its foundation and is itself classified as a high-risk AI system under Annex III must satisfy both registration obligations:

1. You, as the provider of the high-risk AI system, register the system under Art.71(1) using Annex VIII Part I
2. Your GPAI API provider registers the foundation model under Art.71(2) using Annex VIII Part II

In practice this means your Annex VIII Part I registration (Field 6: Technical documentation, and Field 8: Notified body certificate) will reference your use of a specific GPAI model. The AI Office cross-references the high-risk AI system registrations against the GPAI model registrations to build a picture of deployment patterns and systemic risk exposure.

If your GPAI provider is not registered, your own registration may be flagged by the EU database system during submission review.

Timeline: When Does GPAI Registration Apply?

Key point: The GPAI registration deadline has already passed (August 2025). GPAI model providers with systemic risk who have not registered are in breach of the AI Act today. From a downstream developer perspective: any GPAI API provider serving the EU market that cannot demonstrate Art.71(2) compliance is already behind schedule.

For foundation model providers that reached the 10^25 FLOPs threshold after August 2025, they must register before making their model available in the EU.

The Infrastructure Angle: Why GPAI Provenance Matters for EU Hosting

The Art.71(2) registration creates an audit trail that connects GPAI model versions to downstream deployments. For SaaS developers using EU infrastructure:

Data residency and GPAI inference: If your product calls a GPAI API, the inference happens on the provider's infrastructure. For EU-deployed SaaS products, this creates an asymmetry: your data is stored in the EU, but inference (including the specific model weights used) happens on US infrastructure. The GPAI registration database does not resolve this, but it makes the relationship visible.

EU-hosted GPAI providers: GPAI providers that are either EU-incorporated or operate EU-based inference infrastructure can provide:

• Contractual data processing agreements under GDPR that cover inference data
• Confirmation of Art.71(2) registration with a specific EU registration ID
• Cooperation with EU-based NCA requests without requiring cross-border legal processes

When selecting GPAI providers for EU-market products, registration status and EU infrastructure availability are now formal compliance criteria, not just commercial preferences.

Action Checklist: GPAI Registration Due Diligence

Before your August 2026 compliance review, confirm the following for each GPAI API you use in production:

• Provider registration status: Is the provider registered under Art.71(2) if applicable? Request their EU database registration ID
• Art.53 documentation: Have you received and reviewed the provider's technical documentation package?
• Systemic risk classification: Is the model you are using classified as having systemic risk (10^25 FLOPs or Commission designation)? If yes, are Art.55 obligations documented?
• Contract provisions: Do your API terms include AI Act compliance representations and incident notification obligations?
• Version tracking: Do you know which specific model version(s) your product uses, and are these the versions covered by the provider's registration?
• EU authorised representative: For non-EU providers, have you identified their EU authorised representative under Art.54?
• Incident notification path: If your product causes a serious incident, do you know how to notify both your NCA (Art.73) and ensure the upstream GPAI provider is informed for Art.55 purposes?

What's Next in This Series

This post covered the GPAI-specific registration regime under Art.71(2). In post #4 we will look at how national competent authorities and the EU AI Office use the database for market surveillance — specifically, what happens when an NCA queries the database during an enforcement investigation, what data is available to them, and how registration records become evidence in compliance proceedings.

Next post: EU AI Act Art.71 — NCA Database Access, Market Surveillance & Developer Obligations →

sota.io runs on European infrastructure, committed to EU data sovereignty. For EU-compliant AI deployment that aligns with your Art.71 registration obligations, learn more about sota.io.