- The trust and transparency dimension covers three sub-dimensions: explainability of outputs, human oversight capability, and transparency to users and affected parties. Each is scored separately; the composite score forms the dimension result.
- Explainability assessment distinguishes between post-hoc explainability (the system can be queried for an explanation after the fact), inherent interpretability (transparent architecture), and operator-provided explanation (documented process). The highest scores require at least post-hoc explainability supplemented by override procedures.
- Human oversight scoring maps directly to Article 14 of Regulation (EU) 2024/1689, assessing technical monitoring capacity, intervention authority, scope of autonomous action, and feedback loop quality. An agentic system executing consequential actions without a prior human review step will score low regardless of its other attributes.
- Output transparency assessment covers compliance with Article 50 of Regulation (EU) 2024/1689, including disclosure of AI interaction, synthetic content labelling, and the right of affected parties to know they are receiving AI-generated outputs.
- The trust and transparency dimension score is one of the two most consequential dimensions for insurance eligibility. Insurers treating this as a primary underwriting signal include the AIUC-1 certification programme (ElevenLabs February 2026 policy) and Munich Re aiSure.
Why trust and transparency form a single dimension
The grouping of explainability, human oversight, and output transparency into a single dimension reflects a structural relationship between the three attributes, not an administrative convenience. Explainability is the prerequisite for meaningful human oversight. A human reviewer who can observe that a system produced an output, but cannot obtain any account of why, is in a position to react to failures after they occur but cannot exercise oversight in the substantive sense that Article 14 of Regulation (EU) 2024/1689 requires. The Article 14 obligation is not simply to have a stop button. It is to have oversight measures that allow the responsible person to understand the system well enough to detect, anticipate, and correct problems. Understanding requires some degree of explainability. An oversight arrangement that cannot draw on explainability is procedural: a documented role with formally assigned authority and no practical capacity to exercise it.
Output transparency to users and affected parties is the external expression of the same underlying capability. An organization that has invested in explainability because it values meaningful internal oversight will typically have the informational resources needed to satisfy Article 50 transparency obligations. The reverse also tends to hold: organizations that treat output transparency as a low-priority disclosure checkbox frequently have not invested in explainability either, and their internal oversight arrangements are correspondingly weak. The three attributes reinforce each other architecturally. Assessing them as a single dimension produces a coherent picture of an organization's actual capacity to operate AI agents responsibly, rather than a disaggregated checklist of disconnected requirements.
For the relationship between this dimension and the governance infrastructure that enables it, see the governance dimension certification requirements. For the full picture of how this dimension fits within the broader assessment, see the seven dimensions of AI agent certification.
Sub-dimension 1: explainability
Explainability, as assessed in the trust and transparency dimension, means the capacity of the system or its operator to produce an account of why a specific output was generated, in terms appropriate to the audience receiving that account. The definition has two critical components. First, it is output-specific: the capacity to describe how the system works in general is not explainability in the certification sense. What the dimension requires is the capacity to account for the basis of this output, in this instance, for this affected party. Second, it is audience-calibrated: the account must be comprehensible to the relevant recipient, not just to the engineers who built the system.
Certification scoring for this sub-dimension distinguishes three levels of explainability. Post-hoc explainability means the system can be queried for an account of a specific output after that output has been generated. This may involve logging the reasoning steps that contributed to the output, providing a feature-importance summary, or generating a natural-language explanation in response to a query. The key requirement is that the explanation is derivable from the system's actual processing of the specific case, not from a generic description of how the system behaves on average. Inherent interpretability means the system's architecture produces outputs that are transparent by design: a rules-based system, a decision tree with documented branches, or a system whose outputs are directly derived from explicitly stated criteria that can be reviewed. Operator-provided explanation means the deployer has documented an explanation of how the system makes decisions that is sufficient for affected parties to understand and challenge outputs, independently of any capacity to query the system itself.
The scoring rubric assigns the highest scores to post-hoc explainability or inherent interpretability supplemented by documented override procedures. Operator-provided explanation scores moderately: it satisfies the transparency obligation to affected parties but does not provide the basis for genuine internal oversight, because it describes the system rather than interrogating it. Systems for which no meaningful explanation can be produced, where the operator can only state that the system produced an output without being able to account for why, score at the lower end of this sub-dimension regardless of how well-governed the deployment is in other respects.
The practical implications differ by deployment context. For an employment screening agent, explainability means a deployer must be able to explain to a candidate why their application was assessed as it was, in terms specific to their case and sufficient for them to understand and contest the basis for the decision. This is not merely a good practice requirement: it connects directly to the right to an explanation of automated decisions under Article 22 of Regulation (EU) 2016/679 (the General Data Protection Regulation) and to the transparency obligations Article 13 of the EU AI Act imposes on high-risk system providers. For a financial advisory agent, explainability means the system must be able to articulate the basis for a specific recommendation in terms an ordinary investor can evaluate, connecting to the suitability and disclosure requirements applicable to regulated financial services. For a customer service agent operating under Article 50 of the EU AI Act, explainability means that when a user queries why they received a particular response, the operator can provide a meaningful account. The threshold for what constitutes a meaningful account scales with the consequences of the output. Low-stakes conversational outputs require a lower standard of explainability than outputs that trigger enforceable decisions.
Sub-dimension 2: human oversight
Human oversight is assessed against four elements derived directly from Article 14 of Regulation (EU) 2024/1689. The Article requires that high-risk AI systems be designed and developed to allow the persons assigned to oversight to effectively monitor the system's operation, intervene or interrupt the system when necessary, and interpret the system's outputs. The four elements in the certification assessment operationalize this requirement into assessable organizational and technical conditions.
Element 1: technical capacity for human monitoring. This element assesses whether appropriate interfaces, logs, and alert mechanisms exist to allow oversight staff to observe the system's behaviour. A system that operates without producing an auditable log of its actions does not satisfy this element. A system that produces logs but stores them in a format that oversight staff cannot access or interpret without specialist technical assistance scores lower than a system with a monitoring interface designed for the oversight role. The requirement is not that oversight staff have continuous real-time visibility into every system operation, but that the technical infrastructure supports monitoring at a level appropriate to the system's risk profile and the frequency with which material decisions are taken.
Element 2: operational capacity for human intervention. This element assesses whether staff have defined roles, authority, and documented procedures to pause or override the system. The role definition question asks who is designated as responsible for oversight and what authority that role carries. A designated oversight role with no actual authority to pause or modify the system's operation is not an oversight role in the Article 14 sense. The procedure question asks whether the process for intervention is documented and known to the person responsible. A well-intentioned oversight officer who has never been told how to pause the system is not an effective control.
Element 3: scope of autonomous action. This element assesses what consequential decisions the system takes without a prior human review step. Agentic AI systems, by their nature, take actions in the world rather than simply producing outputs for human review. The oversight dimension must therefore assess whether the actions the system takes autonomously are appropriately bounded relative to their potential consequences. A system that autonomously drafts and sends communications on behalf of an individual without any human review before sending carries a different oversight risk profile than a system that produces draft communications for human approval before any external delivery. The certification assessment applies a proportionality standard: the threshold at which a human review step is required before execution should be set relative to the reversibility and consequence of the action. Actions that are difficult to reverse and consequential for third parties require human review before execution to score well on this element.
Element 4: review and feedback loop. This element assesses whether human oversight findings are documented and fed back into the risk management process. Oversight that identifies problems but does not produce any documented record, and does not result in any adjustment to system behaviour or deployment conditions, is passive monitoring rather than governance-grade oversight. The feedback loop requirement connects the oversight function to the improvement cycle: findings from monitoring should inform updates to the risk assessment, trigger reviews of the explainability documentation, and feed into the incident response process when they indicate a potential failure. An organization that can demonstrate that an oversight finding produced a documented response, whether a system adjustment, a governance update, or a formal risk reassessment, satisfies this element at the level the dimension requires.
For a detailed analysis of the Article 14 framework and what it requires from deployers specifically, see the Article 14 human oversight requirements under the EU AI Act.
Sub-dimension 3: output transparency and Article 50
Article 50 of Regulation (EU) 2024/1689 imposes transparency obligations that apply to a broader category of AI systems than the high-risk classification under Article 6(2). The Article 50 obligations apply from 2 August 2026 and cover three categories of deployment.
The first category covers AI systems that interact directly with natural persons in the course of providing a service to those persons. Deployers operating AI agents in customer-facing roles must ensure that users are informed they are interacting with an AI system, unless this is obvious from context. The disclosure must be made at the outset of the interaction, not buried in terms of service documentation that the user is not expected to read before the interaction begins. Certification assessment of this obligation examines whether the disclosure exists, whether its timing and placement are consistent with the regulation's requirement that it be provided before or at the start of the interaction, and whether it is comprehensible to ordinary users rather than expressed in technical or legal language.
The second category covers AI systems that generate synthetic audio, image, video, or text content. Where such content is intended for distribution, Article 50(2) requires that it be marked in a machine-readable format indicating its AI-generated nature. This obligation applies to the provider of the system generating the content. Deployers using such systems have a related but distinct obligation: they must not remove or alter the machine-readable markings when the content is distributed. Certification assessment of this obligation examines whether the marking obligation is known to the deployer, whether technical controls prevent the removal of markings in the distribution workflow, and whether the deployer has a procedure for handling third-party AI-generated content that arrives without the required markings.
The third category covers AI systems deployed by public authorities or in the context of employment, education, and essential services that produce outputs affecting individuals in those contexts. For such systems, Article 50(3) and (4) impose additional notification requirements for the affected individuals. Certification assessment of this category focuses on whether the deployer has identified all contexts in which their AI agent outputs are subject to these extended requirements, and whether the notification procedures are in place and documented.
The common failure pattern across all three Article 50 categories is a disclosure practice designed to satisfy the letter of the requirement at minimum cost to the user experience. A disclosure embedded in a footer, delivered after the interaction has already begun, or expressed in a format that most users will not encounter constitutes a transparency gap in the certification assessment, even if a legal team has assessed it as technically compliant. The certification standard applies a genuine transparency test, not a minimum legal threshold, because insurers and enterprise procurement teams making decisions based on certification scores need confidence that the organization's transparency practices would withstand scrutiny in an enforcement context, not merely pass a technical reading of the regulation.
How the dimension maps to the EU AI Act
The three sub-dimensions map with precision to specific EU AI Act articles, which is what makes the trust and transparency dimension directly actionable for compliance purposes rather than an interpretive framework imposed over the regulatory text.
Article 13 of Regulation (EU) 2024/1689 requires that high-risk AI systems be designed and developed in a way that ensures their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. The Article specifically requires that high-risk AI systems be accompanied by instructions for use that include the level of accuracy, robustness, and cybersecurity of the system, and information about the intended purpose, conditions of use, and limitations. This article is the regulatory basis for the explainability sub-dimension as it applies to high-risk systems. A deployer of a high-risk system that cannot interpret the system's outputs, and has not been provided instructions for use that would enable interpretation, is in breach of Article 13's transparency requirement regardless of whether the system works well in practice.
Article 14 requires deployers of high-risk systems to implement human oversight measures. The four elements of the oversight sub-dimension described above are derived from Article 14(4), which specifies that oversight measures shall enable designated persons to fully understand the system's capacities and limitations, monitor the system's operation, detect and address automation bias, correctly interpret the system's outputs, and decide not to use the system or otherwise override its output. The Article 14 mapping is the most direct in the dimension: each element of the oversight sub-dimension has a corresponding obligation in Article 14(4).
Article 50 obligations apply to a broader set of AI systems, as described in the previous section. For systems that fall under both Article 6(2) and Article 50, the transparency sub-dimension captures obligations from both articles. For systems that are not high-risk under Article 6(2) but that interact with persons, generate synthetic content, or operate in regulated employment or service contexts, Article 50 remains fully applicable and the transparency sub-dimension remains the primary certification assessment vehicle.
For deployers of systems falling under both Article 6(2) and Annex III's high-risk classifications, the trust and transparency dimension's requirements under Articles 13 and 14 are mandatory legal obligations. For deployers of other systems, Articles 13 and 14 are not directly applicable, but the explainability and oversight attributes they require represent best practice that the certification dimension still assesses, because they remain relevant to insurance eligibility regardless of regulatory classification.
Trust and transparency in underwriting decisions
Insurance underwriters pricing AI liability coverage evaluate the trust and transparency dimension through two lenses: the investigability lens and the loss prevention lens.
The investigability lens asks whether, if a claim arises, the insurer can reconstruct what happened. A system that cannot explain its outputs is, from the insurer's perspective, a system whose failures cannot be investigated. Loss adjustment for AI liability claims requires establishing what the system did, why it did it, and whether the outcome falls within the covered scope of the policy. A system with no explainability capability produces claims that cannot be investigated with any confidence, which translates into claims that must be settled under significant factual uncertainty. Insurers price that uncertainty as additional risk, which either increases premiums substantially or results in policy terms that exclude the scenarios the deployer most needs covered.
The loss prevention lens asks whether the oversight arrangements in place are adequate to prevent failures from propagating unchecked. An AI agent operating without effective human oversight is more likely to produce a large claim than an identical system with robust oversight, because the oversight function is the mechanism by which emerging failures are detected and contained before they produce material harm. Insurers underwriting policies with unlimited or high-limit AI liability exposure treat the oversight sub-dimension as a direct predictor of expected claim severity, not just claim frequency.
AIUC-1 certification, which backed the ElevenLabs February 2026 AI agent policy, requires evidence of both an oversight process and output transparency as conditions of coverage. This requirement is not merely procedural: it reflects the AIUC-1 framework's assessment that systems without adequate oversight and transparency are not insurable at commercially viable premiums, because the informational basis for pricing is absent. Munich Re aiSure's parametric structure requires pre-agreed performance metrics that trigger payouts when a system's error rate or latency exceeds defined thresholds. Those metrics are only measurable if the system's behaviour is sufficiently transparent to be monitored. An organization whose AI agent operates as a black box that cannot be queried about its performance cannot satisfy the monitoring requirement that aiSure's parametric structure depends on.
For a deployer seeking AI agent coverage, the practical implication is that investing in explainability and oversight infrastructure is not merely a compliance expenditure. It is a precondition for accessing insurance at all, and the quality of that investment directly determines the terms on which coverage is available. Organizations that reach scores of 7 or above across the trust and transparency sub-dimensions consistently find the underwriting process more productive, receive more favourable premium and excess terms, and face fewer exclusions related to investigability limitations. For a detailed treatment of how certification scores feed into the underwriting submission, see how certification feeds insurance underwriting.
Preparing for the trust and transparency assessment
Five practical steps constitute the preparation process for a trust and transparency assessment.
Step 1: document your explainability procedures. For each AI agent in scope, document what account of its outputs can be produced, to whom, and in what form. Specify whether explainability is provided through the system itself (post-hoc querying or inherent interpretability) or through operator-maintained documentation. If the answer is the latter, review whether the documentation is sufficiently specific to account for individual outputs rather than general system behaviour. The gap between describing how the system works in general and accounting for why it produced this specific output is the most common explainability weakness in first assessments.
Step 2: map oversight roles and escalation paths. For each AI agent, document who is designated as responsible for oversight, what authority that role carries, and what the procedure is for intervention. Verify that the designated person knows the procedure and has tested it at least once. Confirm that the monitoring infrastructure provides the information that person would need to exercise their oversight role effectively. If the oversight infrastructure exists at a system level but the designated person has never used it, conduct a supervised walkthrough and document it.
Step 3: audit output transparency disclosures. Review all user-facing contexts in which your AI agents produce outputs or conduct interactions. For each context, assess whether the required Article 50 disclosures are in place, whether they are timed correctly (before or at the start of the interaction, not retrospectively), and whether they are expressed in terms that ordinary users will understand. Pay particular attention to agent contexts where the AI nature of the interaction may not be immediately apparent from the interface design.
Step 4: review AI disclosure in user-facing interfaces. Separately from the Article 50 audit, review the user interface design of all AI agent-powered products and services. Consider whether a user who had not read the disclosure would nonetheless encounter obvious signals that they are interacting with an AI system. Systems designed to minimize the perceived AI nature of the interaction, even when a disclosure technically exists, score lower on the transparency sub-dimension than systems designed to make the AI nature of the interaction evident from the interaction experience itself.
Step 5: assemble the evidence bundle for submission. The trust and transparency assessment is an evidence-based process. Before requesting an assessment, assemble the documentation that demonstrates each sub-dimension: explainability logs or architecture documentation, oversight role charters and procedure documents, monitoring interface screenshots or access arrangements, output transparency disclosure copies, and any records of oversight events or explainability queries that have been made in practice. First assessments without a prepared evidence bundle consistently produce lower scores, not because the capability is absent, but because the assessment cannot verify capability that has not been documented. The evidence bundle is the artefact that converts operational capability into a certifiable score.
Frequently asked questions
What does the trust and transparency dimension of AI agent certification assess?
The trust and transparency dimension assesses three distinct attributes of an AI agent deployment. First, explainability: whether the system can generate a meaningful account of how it produced a specific output, calibrated to the audience affected. Second, human oversight: whether human reviewers can monitor, intervene in, and override the system's decisions in ways that satisfy the requirements of Article 14 of Regulation (EU) 2024/1689. Third, output transparency: whether users and affected parties are informed that they are interacting with or receiving outputs from an AI system, in compliance with Article 50 of the Regulation. Each sub-dimension is scored separately, with the composite score forming the trust and transparency dimension result.
How does the trust dimension map to EU AI Act requirements?
The trust and transparency dimension maps directly to three EU AI Act provisions. Article 13 requires that high-risk AI systems be designed with transparency sufficient to allow deployers to interpret and document outputs. Article 14 requires human oversight measures that allow operators to monitor, understand, correct, and stop the system. Article 50 imposes transparency obligations for AI systems that generate synthetic content, interact with persons, or produce outputs that could be mistaken for human-generated work. A system that scores strongly on the trust and transparency dimension has satisfied the evidentiary requirements these articles impose on both providers and deployers.
What does explainability mean for an AI agent, and how is it scored?
Explainability for an AI agent means the capacity to produce an account of why a specific output was generated, comprehensible to the relevant audience. Certification scoring distinguishes between post-hoc explainability (the system can be queried for an explanation after the fact), inherent interpretability (the system's architecture produces outputs that are inherently transparent), and operator-provided explanation (the operator documents the basis for outputs independently of the system). The highest scores require post-hoc explainability or inherent interpretability, supplemented by documented override procedures. A generic description of how the system works in general does not satisfy the explainability requirement; the system must be able to account for a specific output in a specific case.
How does human oversight scoring work in the trust dimension?
Human oversight scoring assesses four elements derived from Article 14 of Regulation (EU) 2024/1689: the technical capacity for human monitoring, the operational capacity for human intervention, the scope of autonomous action, and the review and feedback loop. An agentic system that takes consequential actions without a human review step before execution will score low on the oversight sub-dimension regardless of its other attributes. The feedback loop element requires that oversight findings are documented and fed back into the risk management process, not simply observed and forgotten.
Why does the trust and transparency dimension affect insurance eligibility?
Insurers writing AI liability coverage treat explainability and oversight as primary risk signals. A system that cannot explain its outputs cannot be investigated when a claim arises, making loss adjustment significantly more uncertain. A system without adequate human oversight carries higher probability of unchecked failure propagating before correction. AIUC-1 certification requires evidence of an oversight process and output transparency as conditions of coverage. Munich Re aiSure's parametric structure requires pre-agreed performance metrics, which are only measurable if the system's behaviour is sufficiently transparent to be monitored. The trust and transparency dimension score is, in practice, one of the two most consequential dimensions for insurance eligibility, alongside governance.