sota.io
2026-04-23·14 min read·

EU AI Act Art.41: General Purpose AI Model Provider Obligations — Technical Documentation, Transparency Requirements, and Downstream Information Sharing (2026)

Article 41 of the EU AI Act establishes the foundational layer of obligations that apply to all providers of general purpose AI (GPAI) models — the models that power the AI ecosystem as foundational components integrated into downstream products and services. Unlike the obligations for high-risk AI systems in Chapter III, which focus on the complete AI system placed on the market or put into service, Art.41 targets the model layer itself: the large language models, multimodal foundation models, code generation models, and other general-purpose systems that are deployed at scale and integrated by third parties into applications they control.

The significance of Art.41 lies in its position in the regulatory architecture. GPAI models are upstream infrastructure. Their providers typically do not control how their models are deployed, what use cases they serve, or who interacts with them. Yet the properties of the model — its training data, its capabilities and limitations, its known failure modes, its copyright policy — directly determine the compliance posture of every downstream provider who integrates it. Art.41 creates the information flow that makes this downstream compliance ecosystem function: GPAI providers must document and disclose enough about their models that the providers who integrate them can fulfill their own obligations under the EU AI Act.

For software developers and AI engineers building on top of foundation models — whether through API access, fine-tuning, or on-premises deployment — understanding Art.41 is essential both for assessing your own obligations as a downstream integrator and for evaluating the GPAI providers whose models you depend on.

What Qualifies as a General Purpose AI Model

Before engaging with Art.41 obligations, providers and integrators must assess whether a given model meets the GPAI model definition that triggers the Chapter V framework. The EU AI Act defines a general purpose AI model as an AI model that is trained on large amounts of data at scale, displays significant generality, and is capable of competently performing a wide range of distinct tasks, and that can be integrated into a variety of downstream systems or applications.

The definition has three functional elements that must all be present:

Training at scale on large data volumes: The model has been trained using substantial compute resources on large and diverse datasets. This distinguishes GPAI models from purpose-built models trained on narrow domain-specific datasets for a single task. The precise thresholds for what constitutes "large amounts of data" and "trained at scale" are informed by the implementing acts and guidelines issued by the AI Office, which reference training compute thresholds as a practical proxy.

Significant generality: The model can address many different types of input, produce diverse types of output, and perform across task categories that were not individually specified at training time. A model trained solely on medical imaging data for disease classification, however large its dataset, does not exhibit the cross-domain generality that characterises GPAI models.

Integration capability: The model is designed and made available to be integrated into downstream AI systems rather than deployed exclusively as a standalone consumer-facing product. A closed proprietary system where the model is only ever accessed through a fixed interface that the provider controls and cannot be integrated by third parties falls outside the GPAI framework, though boundary cases require careful analysis.

The practical effect of this definition is that the major large language models, multimodal models, and open-weights foundation models currently available through APIs or for download clearly qualify as GPAI models. Domain-specific models, even large ones, may or may not qualify depending on whether they exhibit cross-domain generality and integration capability.

The Four Core Pillars of Art.41 Documentation

Art.41 organises GPAI provider obligations around four core documentation and disclosure requirements that together constitute the information layer downstream providers need to comply with their own EU AI Act obligations.

Pillar 1: Technical Documentation

Art.41 requires GPAI model providers to draw up, keep up-to-date, and make available to the AI Office upon request a technical documentation package covering the model's architecture, training methodology, and operational characteristics. This documentation serves the AI Office's supervisory function and enables national competent authorities to assess compliance when investigating complaints or conducting market surveillance.

The technical documentation for a GPAI model must cover, at minimum:

Model architecture and design choices: A description of the model architecture including the type of neural network, the number of parameters, the context length (for language models), the modality support (text, image, audio, video, code), and the fundamental design decisions that shape the model's behaviour. The documentation should be sufficiently detailed that a technically competent reviewer can understand how the model processes inputs and generates outputs.

Training process: The training methodology including the training framework, hardware infrastructure, training duration (in terms of both wall-clock time and compute hours), the training stages (pre-training, instruction fine-tuning, RLHF or preference optimisation, safety fine-tuning), and the evaluation protocols used at each stage. Where training involved multiple iterations or curriculum changes, those should be documented.

Training compute: The total floating point operations (FLOPs) used in training, expressed in a standardised format. The EU AI Act uses training compute as a threshold metric for classifying GPAI models with systemic risk under Art.43, so this figure has direct regulatory significance beyond its technical informativeness. Providers should document this figure precisely and maintain records of how it was calculated.

Training data characteristics: A description of the training data used, including the data categories (web text, code, books, scientific papers, images, etc.), the approximate data volumes, the languages represented, the geographic coverage of the data sources, the data collection period, and the filtering and preprocessing steps applied. The documentation must describe these characteristics at a level sufficient to allow assessment of potential biases, quality issues, and representational gaps without necessarily requiring full disclosure of proprietary data pipelines.

Capabilities and limitations: A structured description of the tasks the model performs well, the domains where it has demonstrated competency, the task categories where performance is limited or unreliable, the known failure modes and edge cases, the output types the model can generate, and the languages and modalities in which it performs at different quality levels. This section should be honest about limitations — it is the foundation for downstream providers' own risk assessments.

Safety measures: The safety and reliability measures implemented in the model's training and deployment, including content safety fine-tuning approaches, output filtering, refusal behaviours, and any evaluations conducted against safety benchmarks. Where red-teaming or adversarial testing was conducted, the scope and findings should be summarised.

Energy consumption: An estimate of the energy consumed during training, expressed in kilowatt-hours, along with the geographic location of the training compute used. This environmental data feeds into the Act's sustainability transparency objectives.

Pillar 2: Information for Downstream Providers

Beyond the technical documentation maintained for regulatory purposes, Art.41 requires GPAI model providers to make available to downstream providers who integrate their models the information and documentation necessary for those downstream providers to understand the model's properties and comply with their own obligations.

This downstream information requirement has a different audience and purpose than the technical documentation for the AI Office. It is commercial and operational documentation intended to enable software developers, product companies, and enterprise AI teams to build compliant applications on top of the GPAI model. The downstream information package must cover:

Intended use and deployment contexts: A description of the use cases and deployment contexts for which the GPAI model was designed and evaluated, the contexts where the provider has tested and validated the model's performance, and the contexts that are out-of-scope or for which the model has not been validated.

Capabilities and performance: The tasks and domains where the model performs at a quality level appropriate for production deployment, the evaluation benchmarks and their results, the performance characteristics across languages and modalities, and the confidence calibration of the model's outputs.

Known limitations and failure modes: The domains where performance degrades, the types of queries or inputs that reliably produce poor-quality or problematic outputs, the known biases in the model's outputs, the edge cases where safety measures fail or produce unexpected results, and the conditions under which the model should not be deployed without additional safeguards.

Integration guidance: Technical documentation enabling downstream providers to properly integrate the model into their AI systems, including API specifications, fine-tuning guidance, prompt engineering best practices, output post-processing recommendations, and latency and throughput characteristics relevant to system design.

Safety and responsibility allocation: A clear statement of what safety measures the GPAI provider has implemented, what safety measures remain the responsibility of the downstream integrating provider, and how the provider expects downstream providers to implement their own safety layers. This safety allocation documentation is critical for downstream providers assessing their obligations under Art.16 (provider obligations for high-risk AI systems) and Art.25 (responsibility along AI value chains).

Pillar 3: Copyright Policy and TDM Opt-Out Compliance

Art.41 requires GPAI model providers to make publicly available a sufficiently detailed summary of the copyright policy applied to training data, including whether and how the provider has complied with the text and data mining (TDM) opt-out mechanism established under Article 4(3) of the Copyright in the Digital Single Market (CDSM) Directive (2019/790/EU).

The copyright policy requirement addresses one of the most contested legal aspects of large model training: the use of copyrighted works in training datasets without explicit licensing from rights holders. EU copyright law permits text and data mining under Article 4 of the CDSM Directive, but only where rights holders have not opted out using appropriate machine-readable means (such as the Robots Exclusion Protocol or other standardised opt-out signals).

The Art.41 copyright policy documentation must address:

TDM opt-out compliance: Whether the provider's data collection process respected opt-out signals from rights holders, how those signals were identified and processed, and how systematic compliance was verified. Providers who collected training data before robust TDM opt-out monitoring was technically feasible should document the retrospective analysis conducted and the remediation steps taken.

Data source licensing: Whether training data was collected under specific licenses (such as Creative Commons licenses, open data licenses, or proprietary data licensing agreements) and how those licenses were identified and respected in data collection and processing.

Rights clearance for specific data categories: For training data categories that carry heightened copyright risk (news articles, books, code, academic papers, creative works), what clearance processes were applied and what legal analysis underpins the provider's position.

This copyright policy documentation matters practically because downstream providers integrating GPAI models may face their own liability exposure if they build on models whose training data involved systematic copyright infringement. The Art.41 transparency requirement enables downstream providers to assess this exposure and make informed commercial decisions about which GPAI providers to work with.

Pillar 4: Training Data Summary

Art.41 requires GPAI model providers to make publicly available a summary of the training data used in training the model. The summary is distinct from the full technical documentation — it is a public-facing document intended to provide sufficient transparency to enable external scrutiny without requiring disclosure of proprietary data pipelines or competitive information.

The training data summary must provide meaningful information rather than generic descriptions. A summary that states "we trained on diverse internet data" does not meet Art.41's requirements. A summary that describes the major data categories (Common Crawl web text, open-access books and papers, code repositories, multilingual corpora), the approximate proportions of different data types, the data collection time period, the primary languages represented, and the filtering criteria applied provides the transparency the Act requires.

For providers of open-weights models, the training data summary should be sufficiently detailed to enable the research community to assess potential risks, biases, and capability limitations. For providers of closed-weights models accessed via API, the summary enables downstream providers and users to form informed views about the model's knowledge coverage, potential biases, and copyright exposure.

The Art.41 × Art.11 Interface: GPAI Models in High-Risk AI Systems

One of the most practically important aspects of Art.41 for developers is understanding how GPAI provider obligations interact with the high-risk AI system documentation requirements under Art.11 when a GPAI model is integrated into a high-risk AI system.

Art.25 of the EU AI Act addresses the responsibility allocation when GPAI models are integrated into high-risk AI systems. The downstream provider who places the high-risk AI system on the market or puts it into service bears primary compliance responsibility, including the obligation to prepare the technical documentation required under Art.11 for the complete system. However, Art.25(5) establishes that where a high-risk AI system is built on a GPAI model, the GPAI model provider must cooperate and provide all the information and access necessary for the downstream provider to meet their Art.11 obligations.

This creates a direct Art.41 → Art.11 information flow:

The GPAI provider's Art.41 technical documentation provides the foundational information that the downstream high-risk AI system provider needs to prepare their Art.11 documentation. Without understanding the GPAI model's training data, capabilities, known limitations, and safety measures, the downstream provider cannot accurately complete the Art.11 technical documentation for their system — which must describe the AI system's capabilities and limitations, the data used in development, the training methodology, and the system's expected output quality.

In practical terms, this means:

Before integrating a GPAI model into a high-risk AI system, downstream providers should verify that the GPAI provider has produced Art.41-compliant documentation and that this documentation contains sufficient detail to support their Art.11 technical documentation preparation. If the GPAI provider's documentation is insufficient, the downstream provider should request supplementary information before integration, since gaps in GPAI documentation will create corresponding gaps in their own compliance documentation.

The GPAI provider cannot contractually shift their Art.41 obligations to downstream providers. Terms of service that purport to make the downstream provider solely responsible for all regulatory compliance, without the GPAI provider fulfilling their own Art.41 documentation obligations, do not insulate the GPAI provider from Art.41 enforcement. The provider-integrator split is defined by the Act, not by commercial contracts.

When the downstream provider substantially modifies the GPAI model — through fine-tuning, instruction tuning, or other modification that alters the model's behaviour — the question of who becomes the "provider" of the resulting model for EU AI Act purposes requires careful legal analysis. Art.25 provides guidance on this responsibility allocation, but the practical implication for Art.41 compliance is that the modifying party may take on GPAI provider obligations for the modified model if the modification is substantial enough to constitute making a new model available.

Art.41 and Systemic Risk: The Two-Tier Framework

Art.41 establishes the baseline documentation and transparency obligations for all GPAI model providers. Art.43 then classifies GPAI models with systemic risk and triggers additional obligations under Art.45 that layer on top of the Art.41 baseline.

The systemic risk classification threshold is determined by training compute: GPAI models trained on more than 10^25 FLOPs are presumed to have systemic risk, reflecting the assessment that models at this scale of compute exhibit capabilities and potential risks that require heightened regulatory attention. The Commission may adjust this threshold through delegated acts and may also classify specific GPAI models as having systemic risk based on qualitative capability assessment even below the compute threshold.

For developers and compliance teams, the practical implication is:

All GPAI model providers must fulfill Art.41 obligations: technical documentation for the AI Office, downstream provider information package, copyright policy summary, and training data summary.

GPAI model providers with systemic risk (currently the frontier models like GPT-4 class systems and equivalents) must additionally fulfill Art.45 obligations: adversarial testing and red-teaming, serious incident reporting, cybersecurity obligations, and reporting requirements to the AI Office.

If you are an integrating developer building on a GPAI model, you should check whether the GPAI model you are using is subject to systemic risk obligations, because this affects the quality and depth of information you can expect to receive from the provider and the provider's engagement with the AI Office, which may produce publicly available reports and assessments of the model's risks.

Practical Implementation: Art.41 Documentation Structure for GPAI Providers

For software teams at GPAI model providers working to achieve Art.41 compliance, the documentation work divides into distinct streams that can be pursued in parallel:

Technical documentation (internal, AI Office upon request): This is the most detailed and technically complex component. It requires coordinated input from the ML research team (architecture and training methodology), the data team (training data characteristics and provenance), the safety team (safety measures and evaluations), and the infrastructure team (compute and energy consumption). The documentation should be maintained in version-controlled form and updated when model versions change.

Downstream provider information package (commercial/API documentation): This can be structured as an extension of existing developer documentation, supplemented with the EU AI Act-specific content about limitations, intended uses, and safety allocation. It should be version-controlled alongside the model itself, with clear version mapping between model versions and documentation versions.

Copyright policy (public): This requires input from legal counsel familiar with EU copyright law and the CDSM Directive. The policy should be reviewed by legal before publication and updated when data collection or processing practices change.

Training data summary (public): This requires input from the data team and should be reviewed by communications and legal. It should be factual, specific, and updated when significant training data changes occur (such as adding major new data categories or updating the training data cutoff).

Python Implementation: GPAIDocumentationManager

The following class provides a practical framework for GPAI model providers to structure, validate, and maintain their Art.41 documentation:

from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional
import json


class GPAIRiskTier(Enum):
    STANDARD = "standard"          # Art.41 obligations only
    SYSTEMIC_RISK = "systemic_risk"  # Art.41 + Art.45 obligations


class DocumentationStatus(Enum):
    DRAFT = "draft"
    UNDER_REVIEW = "under_review"
    APPROVED = "approved"
    PUBLISHED = "published"
    NEEDS_UPDATE = "needs_update"


@dataclass
class TrainingDataSummary:
    """Art.41 Pillar 4: Public training data summary"""
    data_categories: list[str]        # e.g. ["web text", "code", "books", "papers"]
    approximate_tokens: Optional[str]  # e.g. "~2T tokens"
    languages_primary: list[str]
    languages_additional: int          # count of additional languages with meaningful coverage
    collection_period_start: date
    collection_period_end: date
    filtering_approach: str            # brief description of quality/safety filtering
    publicly_excluded_sources: list[str]  # data sources explicitly excluded
    last_updated: date = field(default_factory=date.today)


@dataclass
class CopyrightPolicy:
    """Art.41 Pillar 3: TDM opt-out compliance documentation"""
    tdm_opt_out_respected: bool
    opt_out_detection_method: str      # e.g. "robots.txt, meta tags, X-Robots-Tag"
    opt_out_compliance_period: str     # when compliance monitoring began
    licensed_data_categories: list[str]  # data collected under explicit license
    rights_clearance_process: str
    legal_basis_statement: str
    policy_version: str
    policy_date: date
    public_url: Optional[str] = None


@dataclass
class TechnicalDocumentation:
    """Art.41 Pillar 1: Technical documentation for AI Office"""
    model_name: str
    model_version: str
    architecture_type: str             # e.g. "decoder-only transformer"
    parameter_count: Optional[str]     # e.g. "70B"
    context_length: Optional[int]
    modalities: list[str]              # e.g. ["text", "code", "image"]
    training_compute_flops: Optional[float]  # total FLOPs — triggers systemic risk if >1e25
    training_duration_gpu_hours: Optional[float]
    training_stages: list[str]         # e.g. ["pre-training", "SFT", "RLHF"]
    energy_consumption_kwh: Optional[float]
    training_location_regions: list[str]
    safety_evaluations: list[str]      # benchmark names and brief results
    red_teaming_conducted: bool
    known_limitations: list[str]
    capabilities: list[str]
    documentation_date: date = field(default_factory=date.today)
    classification: GPAIRiskTier = GPAIRiskTier.STANDARD


@dataclass
class DownstreamProviderPackage:
    """Art.41 Pillar 2: Information for downstream integrating providers"""
    intended_use_cases: list[str]
    out_of_scope_use_cases: list[str]
    performance_benchmarks: dict[str, str]   # benchmark_name → result
    known_failure_modes: list[str]
    known_biases: list[str]
    safety_measures_by_provider: list[str]   # what the GPAI provider implemented
    safety_measures_by_integrator: list[str]  # what integrators must implement
    fine_tuning_guidance: Optional[str]
    api_documentation_url: Optional[str]
    responsible_use_guide_url: Optional[str]
    version: str
    last_updated: date = field(default_factory=date.today)


class GPAIDocumentationManager:
    """
    Art.41 EU AI Act compliance manager for GPAI model providers.
    Tracks documentation completeness, validates required fields,
    and generates compliance status reports.
    """

    REQUIRED_TECH_DOC_FIELDS = [
        "architecture_type", "training_stages", "known_limitations",
        "capabilities", "safety_evaluations",
    ]

    REQUIRED_DOWNSTREAM_FIELDS = [
        "intended_use_cases", "out_of_scope_use_cases",
        "safety_measures_by_provider", "safety_measures_by_integrator",
        "known_failure_modes",
    ]

    def __init__(
        self,
        tech_doc: TechnicalDocumentation,
        training_data_summary: TrainingDataSummary,
        copyright_policy: CopyrightPolicy,
        downstream_package: DownstreamProviderPackage,
    ):
        self.tech_doc = tech_doc
        self.training_data_summary = training_data_summary
        self.copyright_policy = copyright_policy
        self.downstream_package = downstream_package
        self._classify_risk_tier()

    def _classify_risk_tier(self) -> None:
        """Auto-classify systemic risk based on training compute threshold."""
        SYSTEMIC_RISK_THRESHOLD_FLOPS = 1e25
        if (self.tech_doc.training_compute_flops and
                self.tech_doc.training_compute_flops > SYSTEMIC_RISK_THRESHOLD_FLOPS):
            self.tech_doc.classification = GPAIRiskTier.SYSTEMIC_RISK

    def validate_art41_compliance(self) -> dict:
        """
        Validate Art.41 documentation completeness.
        Returns structured compliance assessment.
        """
        findings = []
        compliant = True

        # Pillar 1: Technical documentation
        for field_name in self.REQUIRED_TECH_DOC_FIELDS:
            val = getattr(self.tech_doc, field_name, None)
            if not val:
                findings.append(f"MISSING tech_doc.{field_name} (Art.41 Pillar 1)")
                compliant = False

        if self.tech_doc.training_compute_flops is None:
            findings.append("WARNING: training_compute_flops unset — needed for Art.43 systemic risk assessment")

        # Pillar 2: Downstream provider package
        for field_name in self.REQUIRED_DOWNSTREAM_FIELDS:
            val = getattr(self.downstream_package, field_name, None)
            if not val:
                findings.append(f"MISSING downstream_package.{field_name} (Art.41 Pillar 2)")
                compliant = False

        # Pillar 3: Copyright policy
        if not self.copyright_policy.tdm_opt_out_respected:
            findings.append(
                "CRITICAL: copyright_policy.tdm_opt_out_respected=False — "
                "document legal basis or remediation plan (Art.41 Pillar 3)"
            )
            compliant = False
        if not self.copyright_policy.public_url:
            findings.append("INFO: copyright_policy.public_url not set — policy must be publicly accessible (Art.41 Pillar 3)")

        # Pillar 4: Training data summary
        if not self.training_data_summary.data_categories:
            findings.append("MISSING training_data_summary.data_categories (Art.41 Pillar 4)")
            compliant = False
        if not self.training_data_summary.languages_primary:
            findings.append("MISSING training_data_summary.languages_primary (Art.41 Pillar 4)")
            compliant = False

        # Systemic risk — additional Art.45 flag
        art45_required = self.tech_doc.classification == GPAIRiskTier.SYSTEMIC_RISK

        return {
            "art41_compliant": compliant,
            "art45_obligations_required": art45_required,
            "findings": findings,
            "pillars_complete": {
                "pillar_1_technical_doc": len([f for f in findings if "Pillar 1" in f]) == 0,
                "pillar_2_downstream_info": len([f for f in findings if "Pillar 2" in f]) == 0,
                "pillar_3_copyright_policy": len([f for f in findings if "Pillar 3" in f]) == 0,
                "pillar_4_training_data_summary": len([f for f in findings if "Pillar 4" in f]) == 0,
            },
            "assessed_at": datetime.now().isoformat(),
        }

    def generate_public_model_card(self) -> dict:
        """Generate public-facing model card satisfying Art.41 Pillars 3 and 4."""
        return {
            "model_name": self.tech_doc.model_name,
            "model_version": self.tech_doc.model_version,
            "modalities": self.tech_doc.modalities,
            "capabilities": self.tech_doc.capabilities,
            "known_limitations": self.tech_doc.known_limitations,
            "intended_uses": self.downstream_package.intended_use_cases,
            "out_of_scope_uses": self.downstream_package.out_of_scope_use_cases,
            "training_data": {
                "categories": self.training_data_summary.data_categories,
                "approximate_size": self.training_data_summary.approximate_tokens,
                "languages_primary": self.training_data_summary.languages_primary,
                "collection_period": f"{self.training_data_summary.collection_period_start} — {self.training_data_summary.collection_period_end}",
                "last_updated": str(self.training_data_summary.last_updated),
            },
            "copyright_policy_url": self.copyright_policy.public_url,
            "responsible_use_guide": self.downstream_package.responsible_use_guide_url,
            "eu_ai_act_risk_tier": self.tech_doc.classification.value,
            "generated_at": datetime.now().isoformat(),
        }

    def check_documentation_currency(self, model_last_updated: date) -> list[str]:
        """Flag documentation components that are stale relative to model updates."""
        stale = []
        if self.tech_doc.documentation_date < model_last_updated:
            stale.append("Technical documentation (Art.41 Pillar 1) predates last model update — review and update required")
        if self.downstream_package.last_updated < model_last_updated:
            stale.append("Downstream provider package (Art.41 Pillar 2) predates last model update — update required")
        return stale

Art.41 in Practice: Integration Checklist for Downstream Providers

If you are a downstream provider integrating a third-party GPAI model into a product or service, Art.41 compliance by the GPAI provider directly affects your own compliance posture. Before integrating a GPAI model, assess the provider's Art.41 compliance by working through this checklist:

Technical documentation assessment:

Downstream provider information:

Copyright and training data:

Systemic risk and Art.45:

Downstream Art.11 readiness:

Key Takeaways

Art.41 creates the information infrastructure that makes the GPAI-to-high-risk-AI compliance chain function. GPAI model providers who treat Art.41 as a documentation exercise rather than a substantive transparency obligation will produce documentation that fails to give downstream integrators what they need to assess model risks, comply with Art.11, and accurately represent the AI systems they place on the market.

For downstream providers, Art.41 compliance by your GPAI model provider is a prerequisite for your own compliance — you cannot accurately complete Art.11 technical documentation for a high-risk AI system built on a GPAI model if the GPAI provider has not fulfilled their Art.41 obligations. Assessing Art.41 compliance during GPAI model procurement is both a legal necessity and a practical risk management measure.

The Art.41 documentation framework will be refined through implementing acts and guidelines from the AI Office, particularly regarding the level of detail required in training data summaries and the precise content standards for downstream provider information packages. Providers and integrators should monitor AI Office guidance developments to ensure their Art.41 documentation stays aligned with evolving regulatory expectations.