Is trustworthy AI the same as trusted AI?

No. Trusted AI has people's confidence; trustworthy AI should deserve justified reliance.

Does it mean zero risk?

No. Evidence has limits, and remaining risks require explicit consideration.

Is a framework a certification?

Following guidance does not by itself establish an independent certification or prove every claim.

AI Glossary / Governance, ethics and safety / Advanced

Trustworthy AI

Definition

Trustworthy AI is AI developed and used in ways that provide justified grounds for reliance in its intended context. The concept combines relevant technical qualities with responsible organizational and human practices. It is an objective to substantiate throughout a system's life, rather than a label earned merely by attracting users' confidence.

What it means

The term applies to the complete use of AI: its purpose, data, model, interface, people, and operating environment. A capable model can form part of an unsuitable service if users receive misleading instructions or cannot address consequential errors.
Different frameworks organize the concept differently. The European Commission's 2019 expert guidelines describe lawful, ethical, and technically and socially robust AI. They address matters such as oversight, data governance, fairness, transparency, wider impacts, and accountability. These historical guidelines should not be mistaken for a statement of every current legal obligation.
NIST emphasizes characteristics relevant to trustworthiness and a continuing risk-management process. Neither approach makes confidence or adoption a substitute for evidence. A meaningful claim identifies the particular use and the basis on which reliance is justified.

How it works

Translate broad principles into requirements for the proposed service. Define who will use it, who may be affected, what decisions it influences, and what failures would matter. Decide what evidence is needed before and during operation.
NIST organizes risk-management work into Govern, Map, Measure, and Manage. These functions interact rather than forming a one-time sequence. Responsibilities, context assessment, evaluation, and responses to risk need to inform one another as the system changes.
In practice, teams connect each important requirement to evidence and an accountable owner. They examine the entire workflow, including how people respond to uncertain outputs. If the evidence does not support a proposed use, options include improving the system, narrowing its use, adding effective safeguards, or choosing another approach.

Three practical examples

A translation assistant is offered for informal internal messages. The company evaluates that purpose and explains its limits. It does not automatically extend the same assurance to specialized documents where a mistranslation could have different consequences.
A document-search service combines useful retrieval with permissions that match the user's access. Its developers test both capabilities because accurate retrieval of information someone should not see would still be a serious failure.
A request-routing system includes a way for staff to correct misrouted items. The organization checks whether corrections reach the right team promptly. A nominal review process would offer little assurance if nobody had time or authority to act.

Think of it this way

Think of a well-run public library. A good collection matters, but so do access arrangements, accurate cataloging, helpful staff, and a way to resolve mistakes. Evaluating only the books would miss much of what makes the service dependable. Trustworthy AI similarly concerns a functioning service in its social setting, not just its central technical component.

Worked example

Consider a pilot for an AI assistant that drafts answers to internal questions. Evaluators examine 100 answers and find 90 supported by the approved reference material. Ten contain unsupported claims.
Staff review the drafts before sending them. They correct eight of the ten unsupported answers but introduce unsupported claims into three of the originally supported answers.
The final number of supported answers is 90 - 3 + 8 = 95, or 95%. The workflow improves the observed result from 90% to 95%, but leaves five unsupported answers: two original errors and three introduced during review.
This calculation shows why evaluating the model alone or simply noting that humans are involved is insufficient. The reviewers' actions affect the delivered result. It also does not establish that the service is trustworthy overall: access, appropriate use, consequences, and other relevant requirements still need assessment.
The numbers describe this constructed test. They are not a forecast of production performance, and the equal counting of errors does not imply equal severity.

Illustrative case study

Fictional company Maple Information pilots a drafting assistant. Its initial report focuses on model performance and states that employees will check every response. The project team then observes actual use and finds that staff sometimes lack access to the reference materials needed for effective checking.
The team revises the workflow so reviewers can inspect supporting material, clarify uncertainty, and route difficult questions to a colleague. It evaluates the resulting answers and records circumstances in which the assistant should not be used.
Managers assign responsibility for responding to reports and assessing later changes. The team describes the pilot's evidence and remaining limitations instead of treating human review as an automatic guarantee.
This fictional case illustrates how technical capability and operational conditions interact. It does not establish that these measures are sufficient for every organization or application.

Common misconceptions and mistakes

“Trustworthy AI is a particular model architecture.” Different technologies can support or undermine the relevant requirements depending on their use.
“A human reviewer guarantees trustworthy outcomes.” Review must be workable and effective, and reviewers can introduce errors.
“A published principles statement proves implementation.” Claims need evidence from the operating service.
“Once trustworthy, always trustworthy.” New conditions can undermine an earlier assessment.
“Every framework uses the same definition.” Their emphases and structures differ, so name the framework when making specific claims.

Business use

Use the concept to connect procurement, development, and operational decisions. Ask what the service is intended to achieve, what evidence supports that use, and who will respond when assumptions fail.
Keep claims specific enough to investigate. For example, distinguish evidence about answer quality from evidence about permissions or correction processes. Involve people who understand the work and those affected by it. Maintain a record of unresolved issues and the reasoning behind deployment boundaries so future teams can assess whether those boundaries still make sense.

Check your understanding

Why are there five unsupported final answers in the example?

Answer: Two original errors remain and reviewers introduce three more.

What is missing from a model-only assessment?

Answer: Evidence about the surrounding workflow and other relevant requirements.

Why identify a framework by name?

Answer: Different frameworks organize trustworthy AI in different ways.

Related terms

Learn next

Map one AI-assisted workflow from input to final action. Identify who can introduce or correct errors, what evidence would support reliance at each stage, and which changes would require reassessment.

Sources

NIST, AI Risk Management Framework 1.0, core functions: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ NIST, AI risks and trustworthiness: https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/ European Commission, High-Level Expert Group, Ethics Guidelines for Trustworthy AI, 2019: https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai

Previous: Trustworthiness Next: Truth