The NIST AI RMF identifies seven characteristics of trustworthy AI. They are the substantive content of the framework — what the four functions (Govern, Map, Measure, Manage) are designed to achieve in operation. Where the four functions provide the structural backbone, the characteristics provide the working vocabulary for AI risk management: the categories against which AI systems are evaluated, the dimensions impact assessments address, and the goals against which trade-offs are documented.
The seven characteristics are:
- Valid and reliable
- Safe
- Secure and resilient
- Accountable and transparent
- Explainable and interpretable
- Privacy-enhanced
- Fair with harmful bias managed.
“Trustworthy AI systems are valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.” — NIST AI RMF 1.0, Section 3
Key definitions
| Term | Meaning |
|---|---|
| Trustworthy AI | AI that exhibits the seven characteristics across its lifecycle. The framework treats trustworthiness as the substantive goal of AI risk management. |
| Characteristic | A dimension of trustworthy AI — a category of qualities the AI system should exhibit. Seven characteristics in total. |
| Trade-off | A trade-off arises when improvement against one characteristic reduces performance against another. The framework expects trade-offs to be surfaced and documented. |
| Sociotechnical | The framework’s framing of AI: a system whose performance and risk depend on the technical components together with the context of use, user populations, and organisational and societal environment. |
| Measure 2 | The category of the Measure function most directly addressing the characteristics — evaluation of AI systems for trustworthy characteristics. |
How the characteristics fit into the framework
The characteristics appear most directly in the Measure function. Measure 2 explicitly requires evaluation against trustworthy characteristics. But the characteristics also inform the other three functions:
| Function | Role of the characteristics |
|---|---|
| Govern | The characteristics provide the substantive vocabulary for AI policy, objectives, and accountability assignments |
| Map | The characteristics inform risk identification (what could go wrong against each characteristic) and impact characterisation (how each characteristic affects individuals, groups, communities, organisations, society) |
| Measure | The characteristics are the explicit goals of Measure 2 evaluation; methods, metrics, and benchmarks are selected against them |
| Manage | The characteristics inform risk prioritisation, treatment selection, and trade-off documentation |
The framework expects the characteristics to be the working vocabulary across all four functions, not a checklist applied only in Measure activities.
The seven trustworthy AI characteristics
1. Valid and reliable
| Element | Detail |
|---|---|
| What it means | The AI system performs as intended within its defined scope of operation, with confirmed accuracy, robustness, and reliability over time. Validity addresses whether the system produces correct outputs for its intended use; reliability addresses whether it does so consistently. |
| What it requires | Performance metrics appropriate to the task; testing across the conditions the system will encounter in deployment; ongoing reliability monitoring; documentation of the operating envelope within which validity and reliability claims hold. |
| Where it lives in the framework | Measure 2 (evaluation); Map 3 (capability articulation against benchmarks); Manage 4 (treatments to maintain reliability) |
| Common failure mode | Validity established in controlled testing without verification across deployment conditions; reliability monitored at performance dashboards without action on degradation. |
Validity and reliability are the foundational characteristics — without them, claims about the other characteristics are unsupported. A system that does not work cannot be safe, fair, or transparent in any meaningful sense.
2. Safe
| Element | Detail |
|---|---|
| What it means | The AI system does not lead to states that risk human life, health, property, or the environment. Safety encompasses physical, psychological, and social harm avoidance. |
| What it requires | Hazard identification across the deployment context; fail-safe behaviour where applicable; documented operating limits beyond which safety claims do not hold; incident response capability. |
| Where it lives in the framework | Map 5 (impact characterisation including safety); Measure 2 (safety evaluation); Manage 1 (prioritisation of safety risks); Manage 4 (incident response) |
| Common failure mode | Safety analysis limited to physical safety in deployment contexts where psychological or social harm is the more material risk; safety claims undocumented as to operating limits. |
Safety is contextual. What constitutes safe behaviour depends on the deployment setting, user population, and broader context — a system safe for one use may be unsafe for another.
3. Secure and resilient
| Element | Detail |
|---|---|
| What it means | The AI system maintains confidentiality, integrity, and availability under adversarial conditions, and recovers from failures and attacks. Security addresses resistance to attack; resilience addresses recovery and continued operation under degraded conditions. |
| What it requires | Threat modelling specific to AI systems (adversarial inputs, model theft, training data attacks); defensive techniques; monitoring for attack indicators; recovery procedures; ongoing security testing. |
| Where it lives in the framework | Map 4 (component-level risk identification); Measure 2 (security evaluation); Manage 4 (response and recovery) |
| Common failure mode | Generic IT security applied to AI systems without addressing AI-specific attack vectors (adversarial examples, prompt injection, training data poisoning, model extraction). |
AI-specific security is a distinct discipline from general IT security. The threat model differs, the attack vectors differ, and the defensive techniques differ. Resilience extends security to address failures that are not attacks but produce similar operational consequences.
4. Accountable and transparent
| Element | Detail |
|---|---|
| What it means | Decisions about AI system development and deployment can be traced and attributed, and information about the AI system is available to those who interact with it or are affected by it. Accountability addresses who is responsible; transparency addresses what is known and communicated. |
| What it requires | Documented design and development decisions; identified accountable parties at each lifecycle stage; documentation appropriate to the audience (developers, deployers, users, affected parties, regulators); communication mechanisms for the documentation. |
| Where it lives in the framework | Govern 2 (accountability structures); Govern 5 (engagement with AI actors); Map 1 (context including users and affected parties); Measure 2 (transparency evaluation) |
| Common failure mode | Documentation produced for developers and not adapted for downstream audiences; accountability assigned to a committee without a named individual owner. |
Accountability and transparency are paired because they are interdependent — accountability without transparency about who is accountable produces nothing actionable, and transparency without accountability for what is transparent produces information no one is responsible for.
5. Explainable and interpretable
| Element | Detail |
|---|---|
| What it means | The mechanisms of the AI system can be explained to relevant audiences in terms appropriate to those audiences. Explainability addresses how the system works; interpretability addresses how its outputs can be understood. |
| What it requires | Explanation methods appropriate to the AI technology (different for classical machine learning, deep learning, foundation models); interpretation appropriate to the audience (different for developers, end users, affected parties, regulators); documentation of the explanation method and its limits. |
| Where it lives in the framework | Measure 2 (explainability and interpretability evaluation); Govern 5 (engagement with AI actors who need explanations); Manage 2 (strategies including explanation provision) |
| Common failure mode | Single explanation method applied to all audiences regardless of their needs; explanations of model mechanisms substituted for interpretations of specific outputs that affected parties actually need. |
Explainability and interpretability are method-dependent and audience-dependent. The framework expects organisations to match the explanation method to the AI technology and the audience — generic explainability claims are not sufficient.
6. Privacy-enhanced
| Element | Detail |
|---|---|
| What it means | The AI system protects individual autonomy, identity, and dignity through privacy-preserving design, data minimisation, and privacy impact management. Privacy in the AI RMF is broader than data protection — it addresses informational privacy, decisional privacy, and the privacy implications of AI inferences. |
| What it requires | Privacy-preserving design choices (data minimisation, anonymisation, differential privacy where applicable); privacy impact analysis appropriate to AI systems including inference risks; ongoing privacy monitoring through the system lifecycle. |
| Where it lives in the framework | Map 5 (impact characterisation including privacy impacts); Measure 2 (privacy evaluation); Manage 2 (privacy-enhancing strategies) |
| Common failure mode | Privacy treated as data protection compliance (GDPR, CCPA) without addressing AI-specific privacy issues — training data memorisation, inference attacks, privacy implications of AI-generated content. |
Privacy in AI systems extends beyond traditional data protection. AI systems can produce inferences that constitute privacy violations even when the underlying data was lawfully obtained, and the framework expects privacy analysis to address these AI-specific dimensions.
7. Fair with harmful bias managed
| Element | Detail |
|---|---|
| What it means | The AI system does not produce harmful bias against individuals or groups, and fairness is addressed across the lifecycle. The framework recognises that bias takes multiple forms — systemic, computational, statistical, human cognitive — and that fairness is context-dependent rather than a single objective. |
| What it requires | Bias identification across lifecycle stages (training data, model architecture, deployment context, downstream use); fairness measurement appropriate to the system and the relevant groups; mitigation methods where harmful bias is identified; ongoing monitoring for emerging bias. |
| Where it lives in the framework | Map 5 (impact characterisation including fairness impacts); Measure 2 (bias and fairness evaluation); Manage 1 (prioritisation of fairness risks); Manage 4 (treatments for harmful bias) |
| Common failure mode | Fairness measured at aggregate population level only, masking group-level disparities; bias addressed at training data without addressing deployment-context bias or downstream-use bias. |
The framework is explicit that not all bias is harmful — some statistical bias is intentional and desirable (a fraud detection model should detect fraud disproportionately against fraudulent transactions). Harmful bias is bias that produces unjust or discriminatory outcomes; the framework’s expectation is management of harmful bias, not elimination of all statistical bias.
How the trustworthy AI characteristics interact
The characteristics are not independent. They interact in ways that affect every AI system design and deployment decision. Three relationships recur.
Trade-offs
Improvement against one characteristic frequently reduces performance against another. The framework expects trade-offs to be surfaced and documented, not hidden or denied.
| Trade-off | How it arises |
|---|---|
| Privacy vs. explainability | Privacy-preserving techniques (differential privacy, federated learning) reduce the granularity of explanations available |
| Accuracy vs. fairness | Optimising for accuracy across the full population may produce worse outcomes for some groups; optimising for group-level fairness may reduce overall accuracy |
| Transparency vs. security | Detailed documentation of model mechanisms can support adversarial attacks; opacity supports security but reduces transparency |
| Explainability vs. performance | Inherently interpretable models often have lower predictive performance than black-box models in many domains |
| Privacy vs. accuracy | Data minimisation reduces the data available for training, which can reduce accuracy |
The framework does not prescribe how trade-offs should be resolved. It expects organisations to make the trade-offs consciously, document the decisions, and communicate them to affected parties. Resolution depends on the deployment context, the affected populations, and the organisational risk tolerance.
Reinforcement
Some characteristics reinforce each other. Improvement against one supports improvement against others.
| Reinforcement | How it arises |
|---|---|
| Accountability and transparency | Transparency about who is accountable and what they are accountable for makes accountability operative |
| Valid and reliable, safe | Reliable performance is a precondition for safe operation in most contexts |
| Secure and resilient | Security against attack and resilience against failure address adjacent threat models with overlapping defences |
| Explainable and accountable | Explanations of system behaviour support accountability for specific decisions |
Organisations sometimes find that work on one characteristic produces gains across reinforcing characteristics. The framework does not formally identify reinforcement relationships but expects organisations to recognise them in implementation.
Context dependence
The relative importance of the characteristics depends on the AI system and its deployment context. A clinical diagnostic system weights safety, reliability, and explainability heavily. A content recommendation system may weight fairness and privacy more heavily. A financial trading system may weight reliability and security most heavily. The framework expects relevance to be determined per system based on intended use, deployment context, and identified risks — not applied as a uniform checklist.
How the NIST AI RMF framework expects characteristics to be balanced
The framework provides three structural expectations for how characteristics are balanced in design and deployment decisions.
Explicit prioritisation
The relative weighting of characteristics for a given AI system should be explicit, documented, and connected to the system’s purpose and context. Implicit prioritisation — where the characteristics important to the development team are addressed and others quietly receive less attention — produces systems whose actual values are not the organisation’s stated values.
Map 1 (context) and Map 5 (impact characterisation) are the natural locations for characteristic prioritisation. The deployment context and affected populations identified in Map inform which characteristics carry most weight; the prioritisation is then carried through into Measure activities and Manage decisions.
Trade-off documentation
Where characteristics conflict, the trade-off decisions must be documented. This includes the trade-off being made, the rationale, the affected parties, and the residual risk accepted. Trade-off documentation is part of the evidence base for both internal governance and external attestation.
Manage 1 (risk prioritisation) and Manage 2 (benefit-impact balancing) are the natural locations for trade-off documentation. The framework treats trade-off decisions as part of risk management — not as separate ethical judgements made outside the management framework.
Engagement with affected parties
Where characteristics matter most heavily — fairness, privacy, safety, transparency — the affected parties should be engaged in the prioritisation and trade-off decisions. The framework expects this engagement to be substantive rather than formal: not consultation that confirms decisions already made, but engagement that informs the decisions themselves.
Govern 5 (engagement with AI actors) is the structural mechanism. Engagement processes documented under Govern 5 should produce inputs to Map 5 impact characterisation and to Manage 1 prioritisation decisions.
How the trustworthy AI characteristics relate to other frameworks
The seven characteristics align with substantive content in other AI governance instruments, but the alignment is not exact.
| Framework | Treatment of trustworthy AI characteristics |
|---|---|
| ISO/IEC 42001 | Annex C lists organisational objectives including fairness, transparency, robustness, safety, security, privacy — overlapping with but not identical to the seven characteristics |
| EU AI Act | Specific requirements address accuracy and robustness (Article 15), human oversight (Article 14), data quality (Article 10), transparency (Articles 13 and 50) — substantively related but legally framed |
| OECD AI Principles | Five values-based principles overlap substantially with the seven characteristics |
| ISO/IEC 23894 | Provides risk management methodology applicable across the characteristics |
Crosswalks between the AI RMF and these instruments identify where the characteristics correspond to other frameworks’ substantive content. For organisations using the AI RMF as methodology source within an ISO/IEC 42001 management system, the seven characteristics typically become the working vocabulary for both — adopted as AI objectives under Clause 6.2 and as the framework for trustworthy AI evaluation under Measure 2.
NIST AI RMF resource references
The primary references for the seven characteristics:
| Resource | Source |
|---|---|
| NIST AI RMF 1.0 | https://www.nist.gov/itl/airc — Section 3 introduces the seven characteristics |
| AI RMF Playbook | https://airc.nist.gov/airmf-resources/playbook/ — Measure 2 subcategories include suggested actions for each characteristic |
| NIST AI 600-1: Generative AI Profile | https://www.nist.gov/itl/airc — characteristics adapted to generative AI contexts |
| NIST AI 100-1 | https://www.nist.gov/itl/airc — the AI RMF document itself, defining the characteristics |
| NIST publications on specific characteristics | https://www.nist.gov/itl/airc — additional NIST publications on bias (NIST SP 1270), explainability, and other characteristics |
NIST publishes additional technical documents on specific characteristics — bias, explainability, secure AI — that extend the AI RMF’s substantive content. These publications are useful methodology references for organisations operationalising specific characteristics.
FAQ
Are the seven trustworthy AI characteristics requirements?
The AI RMF is voluntary, so the characteristics are not requirements in a regulatory sense. They are the substantive goals the framework treats as defining trustworthy AI. Organisations adopting the framework are expected to address the characteristics relevant to their AI systems, document trade-offs, and engage with affected parties — but failure to address them produces no legal sanction.
Can the trustworthy AI characteristics be applied in priority order?
There is no fixed priority. The relative importance of the characteristics depends on the AI system and its deployment context. A clinical AI weights safety and reliability most heavily; a content moderation AI weights fairness and transparency; a security AI weights reliability and resilience. The framework expects the prioritisation to be explicit and documented for each system.
Are all trustworthy AI characteristics always applicable?
The framework expects relevance to be determined per system. All seven characteristics are conceptually applicable to any AI system, but their operational weight varies. A system processing no personal data may treat privacy-enhanced as less material; a system with no group-disparate effects may treat fairness measurement at lighter weight. The framework expects relevance decisions to be documented rather than assumed.
How do the trustworthy AI characteristics interact with the EU AI Act?
The Act addresses substantively similar territory through specific legal obligations — accuracy, robustness, cybersecurity (Article 15); human oversight (Article 14); transparency (Articles 13, 50); data quality (Article 10). The seven characteristics align with these obligations substantively but are not legally framed. Organisations preparing for both treat the characteristics as substantive content and the Act provisions as legal requirements that consume the substantive analysis.
How do the characteristics interact with ISO/IEC 42001?
The ISO 42001 Annex C lists organisational objectives that overlap with the seven characteristics. Organisations using both frameworks typically adopt the seven characteristics as their working vocabulary because the AI RMF specifies them in more operational detail than Annex C. The characteristics become AI objectives under ISO 42001 Clause 6.2 and the framework for evaluation under Annex A.6.2.4.
Is “fair with harmful bias managed” the same as “fair”?
No. The framework is deliberate in this language. Fairness in the AI RMF is not the elimination of all bias but the management of harmful bias — bias that produces unjust or discriminatory outcomes. Some statistical bias is intentional and desirable (a model designed to detect fraud should detect fraud disproportionately against fraudulent cases). The framework’s expectation is identification of harmful bias and management of it, not elimination of all statistical bias.
What does “explainable” require in practice?
The requirement is that mechanisms can be explained to relevant audiences in terms appropriate to those audiences. The method depends on the AI technology — what counts as explanation for a logistic regression differs from a deep learning model differs from a foundation model. The audience depends on the use case — what counts as explanation for a developer differs from an end user differs from an affected party. The framework expects organisations to match method to audience, not to apply a generic explainability technique.
How does “privacy-enhanced” differ from GDPR compliance?
GDPR compliance addresses data protection — lawful basis, data subject rights, transfer restrictions, accountability. Privacy-enhanced in the AI RMF includes those concerns but extends to AI-specific privacy issues: training data memorisation, inference attacks producing privacy violations from non-personal inputs, the privacy implications of AI-generated content. Privacy-enhanced is broader than GDPR compliance but does not substitute for it.
Where are trade-offs between characteristics resolved?
The framework does not resolve trade-offs centrally. Resolution depends on the deployment context, the affected populations, the organisational risk tolerance, and the engagement processes documented under Govern 5. The framework’s expectation is that resolution is explicit, documented, and informed by affected parties — not that any particular resolution is correct.
Are trade-offs always real or sometimes apparent?
Both. Real trade-offs — privacy versus explainability, accuracy versus fairness — reflect substantive tensions in current AI methodology. Apparent trade-offs sometimes dissolve under analysis: a system claimed to require sacrificing fairness for accuracy may be examined and found to allow improvement on both dimensions through better methodology. The framework expects organisations to test claimed trade-offs rather than accept them as given.
Will the characteristics change in future versions of the AI RMF?
The AI RMF Roadmap indicates continued development of the framework, including in characteristic-specific areas. The seven characteristics themselves are likely to remain stable, but the methodology guidance for each — particularly bias measurement, explainability methods, and generative-AI-specific characteristics — continues to develop through NIST publications and external work.
