ISO/IEC 12792 and the AI transparency taxonomy: what the standard defines and how regulated enterprises can apply it

What ISO/IEC 12792 is

ISO/IEC 12792:2025, Information technology, Artificial intelligence (AI), Transparency taxonomy of AI systems, is listed in the catalogue of ISO/IEC JTC 1/SC 42, the subcommittee responsible for artificial intelligence standards. It sits under the information technology vocabularies classification, which fits its purpose. A taxonomy does not prescribe controls. It names and organises categories so that different teams describe the same thing in the same terms.

That matters because transparency is used loosely. One team means a model card, another means an explanation shown to a user, and a third means an audit trail. A shared classification lets governance leaders ask which kind of transparency a request is actually about.

This page does not reproduce the standard's clause text. Category definitions and stakeholder roles should be taken from the published standard when a formal mapping is built. Treat ISO/IEC 12792 as a voluntary vocabulary for internal use. It is not a regulatory mandate, and an organisation that applies it should describe that as use of the taxonomy, not as certification or conformance.

The problem a transparency taxonomy addresses

Regulators, auditors, customers and internal risk functions all ask enterprises to explain what their AI systems do. Their questions differ. A customer may need to know that AI is involved in an interaction. An auditor may need evidence that a stated policy was applied. A risk function may need to know how a system was designed and what data and models sit behind it.

Without a shared vocabulary, teams answer each request with a one-off document. The result is duplicated effort and gaps that surface during an audit. A taxonomy gives governance leaders a way to turn those requests into a standing requirements set.

In practice, each transparency requirement can be described along three questions. What information is it? Who needs it? At what point in the AI lifecycle is it created or needed? Once each requirement answers all three, the organisation can assign an owner and an evidence source to it. That last step is where documentation and runtime evidence diverge.

How it relates to ISO/IEC 42001, ISO/IEC 22989, the EU AI Act and the NIST AI RMF

ISO/IEC 22989 covers AI concepts and terminology and comes from the same subcommittee. ISO/IEC 12792 is best read as a companion vocabulary focused on transparency, so the terms used in transparency requirements should be consistent with the base AI terminology.

ISO/IEC 42001 is a management system standard. It addresses how an organisation governs AI through policies, processes and records. A transparency taxonomy can supply the vocabulary for the transparency information that such a management system needs to produce and keep. The two serve different purposes, and neither replaces the other.

The EU AI Act, Regulation (EU) 2024/1689, is binding law, and a voluntary taxonomy does not substitute for reading its obligations directly. Application dates for high-risk rules may also move. The Commission's Digital Omnibus on AI, proposed on 19 November 2025, would set fixed dates of 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products. As of November 2026, these should be tracked as proposed dates and kept separate from enacted ones.

On the NIST side, a NIST-hosted explainability document distinguishes process-based explanations, which describe the governance of an AI system across design and deployment, from other kinds of explanation. The distinction is a useful reminder that transparency covers how a system was governed as well as what it did.

Runtime evidence and design-time artifacts

Transparency information comes from two kinds of source. Design-time artifacts describe what a system is and how it was built. Runtime evidence shows what the system was allowed to do and what it did in a specific interaction. A static document cannot show the second, because it describes intent and not behaviour.

The split below is a working hypothesis for planning. Each row should be checked against the taxonomy element it is meant to satisfy before it is relied on in an audit response.

• Policy decisions: Runtime. Whether an interaction was allowed, redacted or blocked, and under which policy.
• Interaction-level actions: Runtime. What was sent to and returned from a model or tool in a given interaction.
• Tool calls: Runtime. Which tools an AI system invoked, and whether the call was permitted.
• Model documentation: Design time. Purpose, capabilities and limitations, maintained by the model owner.
• Data records: Design time. Provenance and characteristics of the data used, held in data management records.
• System documentation: Design time. Intended use, architecture and oversight arrangements, held in system records.

Where runtime enforcement evidence fits

Trussed is relevant to one part of this mapping: the runtime part. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact, with decisions such as allow, redact, block, rate limit and escalation for human approval. The scope is individual interactions and tool calls. That enforcement generates continuous audit-ready evidence, mapped to frameworks including the EU AI Act and NIST, and it can be deployed self-managed in the customer cloud with configurable retention and data residency.

In the terms of the table above, that covers policy decisions, interaction-level actions and tool calls. It does not replace model documentation, data records or system documentation. Those remain separate artifacts with their own owners.

Trussed does not implement or certify conformance to ISO/IEC 12792. The standard is a vocabulary, and any mapping of enforcement evidence to its elements is the enterprise's own work.