ISO/IEC 12792 vs EU AI Act Articles 13 and 50: Transparency Requirements Mapped

Two documents that differ in kind

ISO/IEC 12792:2025, "Information technology — Artificial intelligence (AI) — Transparency taxonomy of AI systems", is published within ISO/IEC JTC 1/SC 42, the committee for artificial intelligence. By its title it is a taxonomy. Its job is to name and structure the kinds of transparency information about an AI system, so that different parties describe transparency in the same terms. It is not addressed to a regulator and does not create duties.

The EU AI Act is Regulation (EU) 2024/1689 of 13 June 2024. A regulation is binding law, and it applies to providers placing AI systems on the market or putting them into service in the Union, whether or not they are established in the Union. As of November 2026 we are not aware of any amendment to Articles 13 and 50 that changes the analysis here, but teams should confirm the current consolidated text before finalising any mapping.

That difference in kind drives everything else. A taxonomy answers "what can be said about a system, and how is it categorised?" The Act answers "who must tell whom what, and when?" A crosswalk is useful only if it keeps those two questions apart.

What Articles 13 and 50 each require, and of whom

Article 13 is headed "Transparency and provision of information to deployers". It states that an appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3. Recital 72 explains the purpose: addressing the opacity and complexity of certain AI systems and helping deployers fulfil their obligations. Recital 66 lists transparency and information to deployers alongside risk management, data quality, technical documentation and record-keeping, human oversight, and robustness, accuracy and cybersecurity. The recipient is the deployer, and the artefact is information and instructions for use that let the deployer interpret high-risk system output.

Article 50 sits in a separate chapter, "Transparency obligations for providers and deployers of certain AI systems". It covers disclosure that a person is interacting with an AI system, marking of synthetic content, and notices for deepfakes and emotion recognition. Its recipients are the people exposed to the system or its output, not the deployer's compliance team. It states that it does not affect the requirements and obligations in Chapter III and is without prejudice to other transparency obligations in Union or national law for deployers. It is therefore not the only transparency duty an organisation carries.

Keep the two artefacts separate in any crosswalk. Deployer-facing instructions and end-user-facing disclosures have different audiences, different timing and different evidence.

Obligation-by-obligation mapping frame

The rows below show how to classify each obligation. The classification is a working judgement to be recorded and reviewed against the standard's text and the operative wording of each article. It is not a statement of legal conclusion.

• Article 13: information and instructions for use: Role: provider supplies, deployer receives. Recipient: deployer. Standard's role: a taxonomy is a natural structure for organising this information, so treat as aligned or partial. Evidence: versioned documentation, delivery records to deployers.
• Article 50: disclosure of AI interaction: Role: provider and deployer, depending on the paragraph. Recipient: the person interacting. Standard's role: can name the information, but cannot perform the disclosure, so treat as partial at most. Evidence: per-interaction records that the disclosure was presented.
• Article 50: marking of synthetic content: Role: primarily the provider of the generating system. Recipient: downstream users and recipients of the output. Standard's role: vocabulary only. Evidence: output-level records showing marking applied, plus configuration and test records.
• Article 50: deepfake notices: Role: deployer of the system generating the content. Recipient: audience of the content. Standard's role: vocabulary only. Evidence: records of notices attached to or presented with specific outputs.
• Article 50: emotion recognition notices: Role: deployer of the system. Recipient: the people exposed to it. Standard's role: vocabulary only. Evidence: records of notices shown at the point of exposure.
• Chapter III and other transparency law: Article 50 does not displace these. Treat as a separate row so that Article 50 evidence is not mistaken for the whole transparency picture.

Alignment is not compliance

Use three classifications per row: aligned, partial, or not addressed. Aligned means the standard's elements describe the same kind of information the obligation concerns. Partial means they describe it but do not specify timing, recipient or delivery. Not addressed means the standard has no counterpart. Add a separate field for runtime dependence, because a row can be aligned in vocabulary and still depend entirely on what the system does when it is running.

Expect the pattern to be uneven. Information-oriented duties such as Article 13 map comfortably onto a taxonomy because both concern what is said about a system. Action-oriented duties such as telling someone they are interacting with AI, or marking an output, are performed by the system, and a taxonomy cannot perform them. The standard can help you describe a disclosure consistently. It cannot show that the disclosure was made.

Write the limit into the mapping itself. A statement such as "vocabulary aligned to the taxonomy; legal obligation assessed separately against the article text" prevents the crosswalk being read as a compliance claim by auditors, customers or internal sponsors.

Which obligations depend on runtime behaviour

Article 13 is largely satisfied by artefacts that exist before and alongside deployment: instructions, descriptions, and the record that they reached the deployer. An auditor will reasonably look for the current version, its version history, and evidence of delivery. These can be shown with static documentation, although they must be kept current as the system changes.

The Article 50 duties described above are different. Disclosure of AI interaction, marking of generated output and notices attached to content happen at the moment of interaction or output. A policy document saying the disclosure will be shown does not show that it was shown. An auditor or regulator would reasonably expect records tied to individual interactions or outputs: what was presented, to which interaction, under which configuration, and when. They would also expect evidence that the control behaves consistently, for example through test records and change history for the configuration that drives it.

Two practical consequences follow. First, the control has to sit where the interaction happens, since a review after the fact cannot create a disclosure that was never made. Second, evidence should be retained per interaction or per output so that it can be tied to a specific obligation and to the provider or deployer responsible for it.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact and block decisions made at the level of individual interactions and tool calls. Enforcement generates continuous, audit-ready evidence mapped to the EU AI Act, among other frameworks. For obligations that are met at runtime, this is the kind of per-interaction record described above.

The scope is specific. Trussed does not claim to deliver compliance with Articles 13 or 50, and it does not address model or dataset provenance. Article 13 information content, role determination and legal interpretation remain with the provider and deployer.