GPAI and Transparency Duties (Articles 50–56)

Chapter V obligations applied from 2 August 2025 for GPAI models first placed on the market after that date; for models placed before, compliance was required by 2 August 2027 (Article 111(3)). The specialist working on a foundation-model-backed portfolio therefore classifies by market-placement date as well as by capability.

Three categories, three regimes

The specialist must hold three distinct categories in view simultaneously:

1. General-purpose AI model — Article 3(63). A model that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of how it is placed on the market. Obligations attach to the provider of the model (Articles 53, 54, 55 for those with systemic risk).
2. General-purpose AI system — Article 3(66). An AI system based on a GPAI model that can serve a variety of purposes. Obligations attach depending on downstream integration: where the GPAI system is itself a high-risk system or is integrated into one, Chapter III obligations apply.
3. System subject to Article 50 transparency duty — specific system classes (chatbots; emotion-recognition; biometric-categorisation; synthetic content and deepfakes; AI-generated text informing the public on matters of public interest) regardless of whether they are high-risk.

The three regimes can stack. A foundation-model provider placing a model on the EU market that is also offered as a chatbot product owes Chapter V provider duties and Article 50 transparency duties and — if the chatbot falls within Annex III (e.g., customer-service chatbot for an essential service under point 5) — Chapter III high-risk duties.

Article 51 — systemic-risk designation

Article 51 designates a GPAI model as presenting systemic risk when it has high-impact capabilities evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks. The Article fixes an initial presumption threshold: a GPAI model is presumed to have high-impact capabilities when the cumulative amount of computation used for its training, measured in floating-point operations (FLOPs), is greater than 10^25. The Commission may adjust this threshold by delegated act.

The 10^25 FLOP threshold was selected to capture frontier models without sweeping in the open-weight and smaller-scale ecosystem. As of the Act’s entry into force, public disclosures indicate that a small number of closed-weight models — including GPT-4-class and frontier Claude, Gemini, Llama, and Mistral large variants — approach or exceed the threshold in training compute. The specialist should not treat the threshold as static: the Commission will re-evaluate, and individual designations can occur independent of the threshold under Article 51(1)(b).

Systemic-risk additional duties — Article 55

Providers of GPAI models with systemic risk owe additional duties under Article 55 on top of the Article 53 baseline: model evaluation including adversarial testing, assessment and mitigation of possible systemic risks at Union level, tracking and reporting of serious incidents, and ensuring an adequate level of cybersecurity. The Article 55 evaluation obligation is where the technical rigor of the model-provider specialist actually bites. Acceptable evaluation includes state-of-the-art tools and red-teaming, proportionate to the capabilities and to the identified systemic risks.

Article 53 — baseline provider duties

Every GPAI model provider — systemic-risk or not — owes the Article 53 baseline: draw up and keep up-to-date technical documentation of the model, including training and testing process and results of evaluation; draw up and keep up-to-date information and documentation to provide to downstream AI system providers intending to integrate the model; put in place a policy to respect Union copyright law including identifying reservations of rights under Article 4(3) of the Copyright in the Digital Single Market Directive (EU) 2019/790; and draw up and make publicly available a sufficiently detailed summary of the content used for training the GPAI model, according to a template provided by the AI Office.

The summary-of-training-content obligation is the one the specialist will spend most time on. Foundation-model providers through 2024–2025 published model cards, system cards, and technical reports — Anthropic’s Claude model family documentation, OpenAI’s GPT-4 system card, Meta’s Llama model cards, Mistral’s model release notes — each of which surfaces some elements of what Article 53 requires while differing in completeness and granularity. The specialist’s job in evaluating an upstream provider’s Article 53 disclosure is not to write it; it is to verify that the disclosure the provider has made is sufficient for the specialist’s organisation, as a downstream deployer, to meet its own Article 26 and Article 14 duties.

The AI Pact and the GPAI Code of Practice

The European Commission’s AI Pact (launched September 2024) and the GPAI Code of Practice (published July 2025) created a voluntary pre-enforcement track for major foundation-model providers. Signatories committed to early application of Article 53 / 55 elements and to cooperation with the AI Office. The Pact’s participant list and the Code’s signatory list are public, giving the specialist a starting point for assessing which upstream providers have structured disclosure programmes already in place.

The specialist uses the Pact/Code signatory status as a leading indicator, not a compliance substitute. A provider that has signed the Code has a demonstrated intent to meet the Article 53 / 55 requirements but has not necessarily met them for the specific version, capability, or systemic-risk posture the specialist’s organisation is integrating. Source: EU AI Pact, https://digital-strategy.ec.europa.eu/en/policies/ai-pact .

Article 54 — authorized representatives for non-EU GPAI providers

GPAI-model providers established outside the EU must appoint an authorized representative in the Union before placing the model on the EU market (Article 54). This parallels the Article 22 authorized-representative duty for high-risk systems. The representative verifies the technical documentation, maintains a copy, cooperates with the AI Office and national authorities, and acts as the EU contact point.

Meta’s public pause of certain Llama 3 multimodal features in the EU in summer 2024, cited in Article 1 of this credential, is the most prominent documented case of a non-EU provider actively managing its EU product availability in response to regulatory duties including Article 54. The specialist draws from the Meta case the generalisable lesson that non-EU provider market-entry timing is itself a compliance lever — not a workaround, but a structured sequencing of the authorized-representative appointment, the Article 53 disclosure, and the market launch. Source: Meta Responsible AI Deployment Principles update, https://about.fb.com/news/2024/07/meta-responsible-ai-deployment-principles/ .

Article 50 — transparency duties on specific system classes

Article 50 applies to providers and, in some cases, deployers of AI systems in five specific classes, regardless of whether the system is high-risk:

The chatbot duty (Article 50(1)) is the highest-volume trigger for most enterprises. Any customer-service, sales-support, or help-desk chatbot built with a large language model must include a disclosure — “You are interacting with an AI assistant” or equivalent — unless the context makes the AI nature obvious. Best practice is to default to explicit disclosure regardless of context, avoiding litigation around the “obvious from context” carve-out.

Deepfake and synthetic-content duties

The deepfake disclosure duty falls on deployers who make synthetic content public. Content watermarking and provenance-signalling under Content Authenticity Initiative / C2PA standards is the technical mechanism supervisors will expect — though the Act does not mandate a specific standard. The specialist verifying an organisation’s Article 50 posture checks for three elements: the technical marking mechanism, the disclosure surface (on-content labelling, caption disclosure, platform disclosure), and the internal workflow that ensures no synthetic content is published without going through the disclosure gate.

The role-assignment rerun for GPAI

Because fine-tuning or substantial modification can move an organisation from deployer to provider (Article 25, covered in Article 1 of this credential), the specialist reruns role assignment at every fine-tuning event for a GPAI-backed system. The triggers to flag:

• Fine-tuning that changes the model’s intended purpose from the upstream provider’s declared purpose.
• Fine-tuning with a dataset large enough or specific enough that the resulting derivative model behaves materially differently.
• Distribution under own name or trademark of a fine-tuned model.
• Wrapping the model in a system where the specialist’s organisation, not the upstream provider, is the face of the system to end users.

Any of these can move the specialist’s organisation into the provider role for the derivative system, activating the Article 53 (or Article 55 for systemic-risk derivatives) obligation stack.

Cross-provider comparison — the vendor-neutral caveat

The specialist working with GPAI disclosures encounters a disclosure landscape that varies substantially by provider. Anthropic publishes detailed Claude model-family documentation. OpenAI publishes GPT-4 and successor system cards. Meta publishes Llama model cards and responsible-use guides. Mistral publishes per-release notes and model weights with documentation. Google publishes Gemini technical reports. Each approach covers different elements of what Article 53 will formally require; no single provider’s 2024 disclosure style is a complete template for post-2025 Article 53 compliance.

The specialist does not select a favoured provider on the strength of disclosure quality. The specialist documents the specific Article 53 elements each upstream provider has covered, the gaps, and the mitigations — most commonly, the specialist’s own organisational documentation supplementing the upstream disclosure. Sources: Anthropic Claude 3 family documentation, https://www.anthropic.com/news/claude-3-family ; OpenAI GPT-4 system card, https://openai.com/index/gpt-4-system-card/ ; Meta Llama documentation, https://ai.meta.com/llama/ ; Mistral release notes, https://mistral.ai/news/ .

Mapping an Article 53 gap analysis

The specialist runs an Article 53 gap analysis per upstream GPAI provider in scope. The analysis is a table with one row per Article 53 element and one column per provider-version combination. For each cell, the specialist records one of four states: covered (upstream disclosure materially meets the Article 53 element); partially covered (upstream disclosure covers some aspects, organisation will need to supplement); not covered (upstream silent; organisation must supplement from its own assessment); and not applicable (element does not apply to the version in scope).

The Article 53 elements that typically require supplementation by the downstream organisation are the downstream-integrator information pack (because the upstream provider cannot know the specific integration context), the foreseeable-misuse assessment for the specific deployment (upstream generic; downstream specific), and the copyright-policy statement for any fine-tuning data the organisation has added on top of the upstream model.

Open-weight and self-hosted deployments

A common misreading of Chapter V is that it applies only to closed-weight managed-API providers. Article 3(63) defines a general-purpose AI model by generality of capability, not by distribution model. An organisation that runs Llama 3, Mistral Large, Qwen, or DeepSeek on its own infrastructure is not a GPAI provider of those models (the originating organisation is), but it is a downstream deployer or, where it fine-tunes substantially, a provider of the derivative model under Article 25.

The open-weight and self-hosted pathway does not reduce the Article 50 transparency duties. A chatbot built on a self-hosted open-weight model owes the same Article 50(1) disclosure to users as a chatbot built on a closed-weight API. The deployment-infrastructure choice is architecturally and economically meaningful but regulatorily neutral on the user-facing transparency duties.

Interaction with Article 27 fundamental-rights impact assessments

Deployers of GPAI-backed systems that fall under Annex III and that are public-sector bodies, or that provide public services, owe an Article 27 fundamental-rights impact assessment before first use. The FRIA must describe the deployer’s processes, the period and frequency of use, the categories of natural persons likely affected, the specific risks of harm to those persons, the description of human-oversight measures, and the measures to be taken if risks materialise.

For the specialist, the FRIA is the deployer-side document most likely to surface the interaction between upstream GPAI provider disclosures and downstream deployer obligations. A FRIA that cites the upstream Article 53 disclosure as input — and that describes what the deployer has done to supplement where the disclosure is thin — is the template to follow.

Diagram — Bridge primitive

This article uses a Bridge primitive diagram. Left abutment: GPAI provider obligations under Articles 53–55 (technical documentation, training-content summary, copyright policy, systemic-risk evaluation). Right abutment: downstream deployer obligations under Article 26 (use per instructions, Article 27 fundamental-rights impact assessment, Article 50 deployer-side transparency). Bridge beams: the four information flows between the two — upstream technical documentation, capability and limitation disclosures, training-content summary, copyright reservation information. The figure frames the Article 53 provider duty as a flow-down discipline that makes downstream compliance possible.

Cross-references

• EATF-Level-1/M1.4-Art04-Generative-AI-and-Large-Language-Models.md — generative-AI foundation that precedes the GPAI classification discussion.
• EATL-Level-4/M4.3-Art13-EU-AI-Act-Board-Reporting-and-Fiduciary-Duty.md — board-level framing of GPAI and systemic-risk exposure.
• EATL-Level-4/M4.3-Art14-EU-AI-Act-Strategic-Portfolio-Impact-Assessment.md — portfolio-level strategic assessment that consumes the specialist’s GPAI classification work.
• Existing regulatory article regulatory-compliance-articles.ts Article ID 253, “EU AI Act Risk Classification: A Practitioner’s Guide” — four-tier foundation.

Learning outcomes — confirm

A specialist who completes this article should be able to:

• Explain the distinction between a general-purpose AI model, a general-purpose AI system, and a high-risk AI system, with the Article 3 definition anchors.
• Classify four described model-and-application stacks by which entity is the GPAI provider at each layer.
• Evaluate a GPAI provider’s Article 53 summary of training content for sufficiency, naming specific gaps.
• Design an Article 50 transparency notice for a customer-facing chatbot and a deepfake-generation feature.

Quality rubric — self-assessment

Publish threshold per design doc §16.5 is 85. This article meets the threshold.