What should organisations do when an AI system may fall under both Article 50 and Article 13?

How to separate Article 50 and Article 13 without creating ownership gaps

Article 50 and Article 13 solve different compliance problems, so organisations should not collapse them into a single generic “AI transparency” task. Article 50 is about what the user sees at the point of interaction or output, while Article 13 is about the information deployed to the organisation operating the system. A shared control map helps keep those obligations distinct while still linking them to one lifecycle view.

The practical move is to define one control family, then split it into two evidence tracks. One track governs customer-facing notices, disclosures, or labels. The other governs internal or downstream artefacts such as instructions, limitations, intended purpose, performance assumptions, and operational documentation. That separation prevents teams from assuming that a document for deployers also satisfies user disclosure, or that a user notice is enough for internal accountability.

For AI programmes that already span development, deployment, and operations, this is also a governance issue, not just a drafting exercise. The control map should name the accountable owner for each obligation, the approval point, and the evidence that proves the obligation was met. NHIMG’s Agentic AI Compliance Guide is useful here because it frames AI transparency, record keeping, and audit evidence as lifecycle controls rather than one-off policy statements.

What the control map should contain

A useful control map starts with a simple rule: one obligation, one primary evidence set, one owner. For Article 50, the evidence set is whatever proves the user-facing disclosure is present, accurate, and aligned to the actual system behaviour. For Article 13, the evidence set is whatever shows deployers received the required information before use, including the limitations and operational context they need to deploy responsibly.

That map should also record where the obligations diverge. Article 50 content often needs to be concise, accessible, and visible in real time. Article 13 content is usually more detailed and operational, because deployers need enough information to configure, supervise, and use the system correctly. If the same text is used for both, teams should verify that it actually works for both audiences instead of assuming that regulatory overlap means textual reuse is safe.

In practice, the strongest control maps include versioning, distribution evidence, and change triggers. If the model, interface, intended purpose, or limitations change, both the user-facing disclosure and the deployer documentation may need review. That is especially important where a single AI product is distributed through multiple channels, because the same system can have different disclosure paths and documentation owners.

Why overlap becomes a governance problem, not just a drafting one

The main failure mode is responsibility drift. When teams treat Article 50 and Article 13 as one combined obligation, one group often assumes the other owns the evidence. The result is familiar: user disclosures are written, but deployer documentation is stale, or the deployer pack is complete while the live interface no longer matches it. Either gap can create regulatory exposure because the obligations are assessed at different points in the lifecycle.

A second failure mode is inconsistent change control. If product, legal, and deployment teams maintain separate artefacts without a shared map, the organisation can satisfy one obligation and quietly break the other during release cycles. That is why the control needs a single inventory of artefacts, owners, review dates, and dependency links between what is shown to users and what is handed to deployers.

For broader AI governance, this is where authoritative sources help anchor the programme. The EU AI Act regulatory framework and the NIST AI Risk Management Framework both support the idea that transparency, documentation, and accountability need to be managed as operating controls, not merely as legal text.

Practitioner Guidance

What to prioritise: Build the control map before the next release, not after a regulatory review finds a gap. Start by inventorying every user-facing disclosure and every deployer-facing document, then assign a named owner and a review trigger for each.

What to verify: Check that the live product experience matches the Article 50 wording, and that the deployer pack contains the Article 13 material before deployment. If one artefact is current and the other is stale, treat it as a control failure rather than a documentation issue.

Decision rule: If a single sentence, policy, or help page is being used to cover both obligations, split it unless you can prove it satisfies both audiences without ambiguity. If it cannot serve both clearly, it should not be treated as a shared control.

Practitioner takeaway: The objective is not to minimise the number of documents, it is to make disclosure, deployment information, and accountability traceable through the AI lifecycle without assuming that one satisfies the other.

Related resources from NHI Mgmt Group

• How is Article 50 different from Article 13 for AI governance teams?
• Who is accountable when a customer-facing AI system fails Article 50 transparency requirements?
• What should organisations do when AI systems may fall under Annex III high-risk rules?
• What makes agentic AI an NHI governance issue?