Accountability can shift away from the original provider. If the system is introduced alongside a product under the manufacturer’s name, or if a distributor or importer places it on the market under their own name, trademark, or altered purpose, that party may become responsible for the conformity assessment and related compliance duties.
How conformity assessment responsibility can shift in a resale or rebranding scenario
Under the EU AI Act, responsibility tracks the entity that places the high-risk system on the market under the relevant commercial identity, not just the original developer. If a distributor, importer, or manufacturer rebrands the system, changes its stated purpose, or sells it as part of their own product offering, that party may inherit the conformity assessment burden and the related compliance obligations.
This matters because conformity assessment is tied to the system as actually marketed and used, not only to the codebase as originally produced. A party that changes the name, trademark, packaging, or intended purpose can become the accountable legal actor for demonstrating conformity, maintaining technical documentation, and ensuring the system meets the applicable high-risk requirements before placement on the market.
For the underlying regulatory baseline, the EU AI Act regulatory framework is the canonical reference for high-risk AI system duties and conformity assessment obligations.
Where accountability changes in the supply chain
The accountability shift usually follows the role the party plays in the market chain. A provider that simply supplies the original system is not always the final accountable party if another organisation places the same system on the market under its own name or trademark. Likewise, an importer or distributor can move from a narrow commercial role into a compliance-bearing role when it effectively presents the system as its own.
The practical question is whether the later party is only transacting in the product or is materially changing how it is represented to the market. That distinction affects who must verify the declared purpose, assess conformity against the correct risk class, keep the required records, and ensure the product remains aligned with the obligations that attach to high-risk systems.
That is why third-party and supply-chain governance cannot stop at procurement checks. The issue is not just who built the model or software, but who is now taking legal and operational responsibility for the system as sold.
For adjacent control expectations, EU Digital Operational Resilience Act (DORA) illustrates how third-party and downstream accountability can attach to the party that operationalises a system, not merely the originator.
What practitioners should verify before treating a resale as a simple transfer
Practitioners should verify the commercial representation, the declared purpose, and the exact entity name attached to the product offer. If the same system is being marketed under a different brand, product line, or business unit, assume the compliance question has changed and map the obligations to the current market-facing party rather than to the original supplier by default.
What to verify: confirm who signs the declarations, who owns the technical file, who controls the user instructions and intended purpose statement, and who can evidence the conformity assessment decision. If any of those elements moved with the rebrand or relabeling, the accountability model likely moved as well.
Decision rule: if the system is sold under another party’s name or presented as part of that party’s own offering, treat conformity assessment ownership as reassigned until the contracting and documentation trail proves otherwise.
Practitioner takeaway: in high-risk AI commerce, the name on the market offer is a compliance signal, so teams should align legal ownership, documentation ownership, and assessment ownership before sale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while EU AI Act and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Art. 16 — Obligations of providers of high-risk AI systems | Defines provider duties, including conformity assessment accountability. |
| Art. 25 — Responsibilities along the AI value chain | Covers responsibility shifts for importers, distributors, and other downstream actors. | |
| Art. 52 — High-risk AI system conformity assessment | Directly governs the assessment process that must be completed before market placement. | |
| Recommendation — Map the market-facing provider to Article 16 duties and ensure it owns the conformity assessment file. Reassign compliance ownership when a downstream party places the system on the market under its own name. Complete the required conformity assessment before release under the final commercial identity. | ||
| DORA | Art. 28 — Digital operational resilience and ICT third-party risk management | Highlights downstream accountability when operationalising third-party systems. |
| Recommendation — Assign clear accountability for third-party ICT dependencies and verify control ownership before deployment. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Supports deciding who owns regulatory risk when product identity changes in the supply chain. |
| Recommendation — Assign risk ownership to the entity that markets and governs the system in its final form. | ||
Related resources from NHI Mgmt Group
- Who is accountable when AI-assisted discovery exposes a high-risk legacy system?
- Who is accountable when a high-risk AI system needs reassessment after a substantial modification?
- Who is accountable when runtime AI controls are missing in a high-risk system?
- What are the signs that an AI system is not ready for high-risk deployment under the EU AI Act?
