A general-purpose AI model provider must provide information and documentation to downstream providers who intend to integrate the model, so they can understand the model's capabilities and limitations and meet their own obligations. The pack should be tied to the model version, cover the matters in Annex XII in usable form, and be updated when the model changes. Downstream providers should record what they received, test it against their intended purpose, and raise gaps rather than filling them with assumptions.
Why does the downstream flow matter?
A downstream provider builds a system with a specific intended purpose, affected people and deployment context. It cannot assess that system responsibly without knowing what the underlying model can and cannot do, how it was evaluated, what its limitations are, and what conditions apply to its use. The Article 53 information flow is the legal mechanism that connects the model layer to the system layer. Without it, downstream teams are forced to guess, to rely on marketing material, or to duplicate evaluation work they are not equipped to do. With it, they can focus on the system-level questions that are properly theirs: intended purpose, classification, risk management, and deployment controls. The flow therefore protects both sides, provided the information is accurate, current and matched to the version supplied.
What should a downstream pack contain?
The pack should contain the information and documentation set out by reference to Annex XII, presented in a form a downstream provider can actually use. In outline, that includes a description of the model and its intended integration context, its capabilities and limitations, evaluation results and their limits, foreseeable misuse and conditions on use, and information needed for the downstream provider's own documentation and risk work. The pack should state the model version it describes, the date it was issued, and the channel for updates. It should distinguish between facts about the model, evaluation findings, and recommendations, so that a downstream reader does not mistake a recommendation for a guarantee. A contents list and a version history help a reader tell whether the pack in hand is the current one.
For the broader regulatory framework, see General-purpose AI models overview.
How should updates and version changes be handled?
When a model is updated, retrained or otherwise changed in a material way, the downstream pack should be updated and the change communicated to downstream providers who received the earlier version. The update should identify what changed, whether capabilities or limitations changed, whether evaluation results still hold, and whether any downstream assessment needs to be revisited. Downstream providers should have a named contact and a timetable for receiving updates, and should record the version they integrated against. A silent model change, where the hosted model changes but the pack and version label do not, breaks the evidence chain for every downstream system. Providers should therefore treat version discipline as part of the duty, not as a release convenience.
What should a downstream provider ask for?
A downstream provider should ask for the pack before committing to an integration, and should test the pack against its own intended purpose. Useful questions include: what tasks was the model evaluated on, and how do those tasks relate to the downstream use; what are the known failure modes and limitations; what input and output conditions were assumed; what monitoring or oversight does the model provider recommend; and how will changes be communicated. The downstream provider should record the answers, the gaps, and any additional evaluation it carries out itself. Where the pack does not answer a question that matters to the downstream assessment, the gap should be raised with the model provider and recorded as an open item, rather than closed by assumption.
How do confidentiality and completeness fit together?
Model providers may hold commercially sensitive material that is not part of the downstream pack. The duty is to provide the information downstream providers need to understand capabilities and limitations and to meet their own obligations, not to disclose every internal record. The boundary should be drawn by reference to Annex XII and to the downstream purpose, and the pack should state what it contains and where a downstream provider should go for further information. Confidentiality labels should be applied consistently, and the pack should not be so heavily redacted that it ceases to be usable. Where a downstream provider needs material that is held for the authorities, the model provider should explain the route for obtaining it and record the request, rather than leaving the downstream provider without a path.
Continue with Article 53 duties for model providers.
What does this guide not decide?
This guide does not decide whether a particular pack meets Annex XII, whether a downstream provider has enough information for its system, or whether a model change requires a downstream reassessment. It does not set the contents of a commercial agreement or resolve a confidentiality dispute. Those questions depend on the actual pack, the model version, the downstream intended purpose, and the consolidated legal text. Both sides should confirm the flow with a competent authority or legal adviser where the position is contested, keep the pack and the gap log current, and revisit the flow when the model or the downstream use changes.
Frequently asked questions
Is the downstream pack the same as the technical documentation?
No. The technical documentation under Annex XI is drawn up for the authorities, while the downstream information under Annex XII is provided to system providers who intend to integrate the model. The two sets overlap but have different audiences and purposes, and they should be maintained as distinct, version-matched packs.
What if the pack does not answer a downstream question?
Raise the gap with the model provider, record it as an open item, and do not close it by assumption. The downstream provider should also consider what additional evaluation or controls it needs for its own system, and should keep the gap visible until it is answered or mitigated.
Must the pack be updated for every model change?
The pack should be kept up to date and should reflect material changes to the model, its capabilities, its limitations or its evaluation. Minor changes that do not affect downstream assessment should still be versioned, so that readers can tell which pack matches which model version.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk Article 53 ↗European Commission AI Act overview ↗