Because the duty attaches to the role that places the system on the market or uses it under its own authority. A provider may owe disclosure, labelling, or marking obligations even when a deployer runs the system internally, so ownership has to be assigned before deployment and contract finalisation.
Why the role split changes who owes the obligation
The AI Act does not treat everyone in the supply chain the same way. The legal duty follows the role that brings the system into the market, places it into service, or uses it under its own authority. That means the provider versus deployer split is not a semantic detail, it determines who must produce notices, labels, instructions, or other transparency artefacts.
That matters because the same system can create different obligations depending on whether it is sold, integrated, resold, or operated internally. If the role is unclear at contracting or launch, teams can easily assign the wrong party to disclosure work and discover the gap too late.
For AI governance teams, the practical question is not just “who runs the model?” but “who controls the compliance duty at the moment of deployment?” That is why the role split has to be fixed before the system goes live, not after a complaint, audit, or regulator query.
What transparency duties actually depend on role
Transparency duties can attach to different actors depending on how the system is offered and used. A provider may need to document intended use, issue disclosures, or support labelling and marking requirements, while a deployer may need to present notices or operate the system in a way that preserves those disclosures for affected users.
The key point is that transparency is not only about the model itself, it is about the obligation holder. In practice, that means contracts, product documentation, user interfaces, and operating procedures all need to reflect the same role allocation so the duty does not disappear between development and operations.
This is why the distinction is especially important for packaged AI services, white-label offerings, and internal rollouts of externally supplied systems. The same technical control can sit inside a provider’s product obligation or a deployer’s operating obligation, depending on who is legally responsible for the deployment path.
How teams should assign responsibility before launch
The safest approach is to classify the role at the point the system is marketed, integrated, or commissioned, then align documentation to that classification. If the organisation is the provider, it should verify that transparency artefacts are part of the release package; if it is the deployer, it should verify that notices and operating instructions are actually usable in the intended environment.
That role assignment should be reflected in procurement language, customer terms, internal approvals, and change control. If a third party supplies the model but your organisation decides the use case, interface, or user population, the operational duty may still sit with the party that assumes the relevant legal role, so ownership cannot be left to informal assumptions.
EU AI Act regulatory framework is the right starting point for mapping the provider and deployer obligations to the actual product and deployment model. For governance planning, ISO/IEC 42001:2023 AI Management System Standard helps teams turn that role split into repeatable accountability, documentation, and review steps.
Risk and Threat Considerations
Misclassifying provider and deployer duties creates compliance exposure, but it also creates operational ambiguity. When nobody can show who owns the transparency obligation, disclosures can be delayed, omitted, or inconsistent across interfaces, contracts, and user communications.
Failure mechanism: the organisation treats role allocation as a procurement detail instead of a control decision, so the required notice, label, or instruction is not embedded in the deployment workflow.
Impact: the system can go live with an unowned transparency duty, creating regulatory breach risk, audit findings, customer confusion, and downstream liability if users were not properly informed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF sets the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Provider and deployer obligations | Directly governs transparency duties tied to the actor role. |
| Recommendation — Map the system’s legal role before launch and assign disclosure duties to the correct party. | ||
| ISO/IEC 42001:2023 | AI management system | Supports accountable AI governance and role assignment for deployment duties. |
| Recommendation — Embed provider and deployer accountability into AI governance, documentation, and release controls. | ||
| NIST AI RMF | Govern map measure manage | Aligns role ownership with AI risk governance and transparency controls. |
| Recommendation — Use AI risk governance to assign and verify transparency responsibilities before deployment. | ||
Practitioner Guidance
What to verify: confirm that the provider or deployer designation is fixed in writing before launch, and that the chosen role matches the actual control over market placement, integration, and operational use. If the contract says one thing but the deployment model says another, treat that as a governance defect, not a wording issue.
Decision rule: if your organisation can change the system’s user-facing presentation, intended use, or release timing, do not assume transparency belongs to the vendor by default. Trace the obligation to the party that actually assumes the regulated role, then make that role visible in ownership, approvals, and release criteria.
Practitioner takeaway: transparency duties fail most often at the handoff between vendor and operator, so the critical control is not the label on the AI system, it is the documented handoff of legal responsibility.