The EU's general-purpose AI obligations are now in an enforcement phase. Providers and downstream users need model evidence that remains attributable, versioned and usable across release, integration and regulatory review.
Observed facts: general-purpose AI has entered an enforcement phase
The European Commission states that the obligations for providers of general-purpose AI models became applicable on 2 August 2025 and that its enforcement powers, including the ability to impose fines, apply from 2 August 2026 [1][2]. Providers of models placed on the market before 2 August 2025 have a later compliance date of 2 August 2027 [2][4]. That transition matters because a model's release date, provider identity and later modification history can affect which obligations and deadlines are relevant. The operating question is therefore no longer only whether a policy exists. It is whether the organisation can identify the governed model, establish when and how it entered the EU market, and produce the associated evidence when requested.
The Commission's guidance also distinguishes providers that place a general-purpose AI model on the EU market from downstream actors that integrate or build on it [1]. Roles may change when a downstream actor substantially modifies a model or presents it under its own name. Public guidance cannot determine every fact-specific classification, but it makes attribution evidence important: model names, versions, release records, distribution channels, responsible entities and modification logs are inputs to the compliance analysis rather than administrative detail.
Observed facts: the required evidence extends beyond a model card
Article 53 of the AI Act requires a general-purpose AI model provider to maintain technical documentation, provide information and documentation to downstream AI-system providers, establish a copyright-compliance policy, publish a sufficiently detailed summary of training content and, where relevant, appoint an authorised representative [1][4]. The technical material is intended both for the AI Office and national competent authorities and for downstream providers that need to understand capabilities, limitations and integration conditions. The obligations therefore create more than a publication exercise: they require evidence that can move between technical, legal, product and supervisory contexts.
The Regulation's annexes make the evidence boundary concrete. Annex XI covers matters including model tasks, architecture, training and testing processes, data type and provenance, curation methods, computational resources, energy consumption and evaluation results [4]. Annex XII addresses information for downstream providers, including input and output modalities, intended tasks, acceptable-use conditions, architecture, training-data characteristics, evaluation metrics and known limitations [4]. Not every record must be public, and confidentiality protections remain relevant, but the provider must be able to assemble and maintain the required information in a form that supports the statutory purpose.
Observed facts: enforcement can test whether evidence is complete and usable
The AI Office may request documentation or additional information from a general-purpose AI provider, including where needed to assess compliance or investigate a substantiated downstream complaint [4]. The Regulation also permits requests for access to a model through APIs or other appropriate technical means after a structured dialogue where documentation alone is insufficient [4]. If the Commission finds non-compliance, it can require corrective measures and can impose fines of up to EUR15 million or 3% of the provider's total worldwide annual turnover for the preceding financial year, whichever is higher [2][4].
A Commission complaint channel published on 31 July 2026 gives downstream providers a route to allege infringement of the AI Act by an upstream general-purpose AI model provider [3]. The form asks the complainant to identify the model and provider, explain the alleged infringement, provide supporting evidence and address confidentiality. The existence of that route does not establish that any complaint will succeed. It does show that missing, stale or unusable downstream information can become part of a documented supervisory record rather than remaining a private integration problem.
Oakhampton inference: model evidence should be managed as a release control
Oakhampton's inference is that the practical control is an evidence package tied to each governed model release, not a static compliance folder. The package can connect the model identifier and provider role to the placement date, technical dossier, training-data provenance records, evaluation results, known limitations, copyright policy, public training-content summary and the information supplied to downstream users. It can also record who approved each component, which version was distributed, when recipients received it and what changed in later releases. This does not determine legal compliance by itself. It reduces the risk that technically related evidence becomes impossible to reconcile when a regulator or downstream provider asks a precise question.
A release gate can test completeness before distribution: required documents exist; claims trace to dated test outputs; provenance fields identify source categories and curation steps; public and confidential versions remain consistent; limitations reach the downstream integration pack; and ownership is assigned for post-release updates. The value is evidential continuity. A polished model card without links to underlying records may communicate well but still leave the organisation unable to explain which model, data process, evaluation or limitation it described at a particular time.
Oakhampton inference: downstream information needs receipt, change and escalation controls
Downstream providers also need a controlled way to receive and use upstream information. A practical register can map the integrated model version to the provider's documentation, permitted-use conditions, interface assumptions, evaluation limits and change notices. Teams can then identify which product or workflow depends on the model, whether an upstream update changes an existing assessment, and who owns clarification or escalation. The Commission's complaint process makes supporting evidence relevant [3]; an internal record of requests, responses, unresolved gaps and technical impact can distinguish a genuine information failure from a misunderstanding about a different version or use case.
This approach is proportionate when it follows the actual release and integration chain. It does not require every team to duplicate the provider's complete technical file. It requires enough controlled linkage to show what information was relied on, when it was current, where limitations were carried into the downstream system and how later changes were assessed. That turns documentation from an end-stage artefact into an operational interface between provider, deployer and supervisor.
Remaining uncertainty: sufficiency remains fact-specific
The public sources do not resolve how the AI Office will judge every documentation package, provenance record, training-content summary or downstream disclosure. Confidentiality, intellectual-property protection, model access, systemic-risk classification and the treatment of modified or legacy models can require fact-specific analysis [1][2][4]. Guidance, templates, standards and enforcement practice may also continue to evolve. A record can be complete in form yet weak in substance if it cannot be tied to the released model or reproduced from underlying evidence.
The bounded conclusion is that enforcement has made model evidence operational. The strongest control is not a forecast about regulatory outcomes and not a claim that one template is universally sufficient. It is a traceable chain from model identity and provenance through evaluation, release, downstream information and change management, with uncertainty and confidentiality recorded rather than hidden. Specific legal classification and sufficiency questions still require review against the current facts and applicable official materials.
Sources
- Guidelines for general-purpose AI modelsEuropean Commission
- When does enforcement start?European Commission AI Act Service Desk
- Complaints channel for downstream providers using general-purpose AI modelsEuropean Commission · 31 July 2026
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligenceOfficial Journal of the European Union · 12 July 2024