NIST AI RMF trustworthy AI characteristics explained

What are the NIST AI RMF trustworthy AI characteristics?

When a customer, contract or regulator asks how your AI system meets the NIST AI RMF, the answer is organized around the seven characteristics of trustworthy AI in NIST AI 100-1: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. The framework has no certificate, so an assessment against these characteristics is a voluntary evidence review. Nobody issues a pass mark for them, and the organization must show how each characteristic was considered, measured and managed for its own system.

The right answer differs by system. NIST says tradeoffs are usually involved, that rarely do all characteristics apply in every setting, and that trustworthiness is only as strong as its weakest characteristic. A fraud model, a clinical triage tool and an internal document search assistant will need different metrics, different threshold values and different resolutions of the tension between, for example, interpretability and privacy. AI 100-1 says human judgment should set those metrics and thresholds. Your team should record who made each decision, why the chosen tradeoff is justifiable, and which characteristic was treated as the limiting one.

The organization owns these decisions and the evidence behind them. An implementation partner can help build the measurement, documentation and monitoring that support them, but only an independent assessor or auditor issues any report on the results. Before scoping that work, confirm which characteristics your customer or regulator actually names, and ask your assessor which evidence they expect for each one. The NIST AI Risk Management Framework page is the natural starting point for the framework's own description of these characteristics.

What each of the seven characteristics asks an organization to show

What evidence shows an AI system is valid and reliable?

An assessor expects documented test and evaluation results showing the system meets its intended purpose on data that resembles the setting where it runs. Valid and reliable is the foundation for the other six characteristics, so this evidence usually comes first. Typical artifacts include:

Test plans and results covering accuracy, error rates and performance across the populations and conditions the system will face
Validation records showing who reviewed the methods and why the chosen metrics fit the use case
Production monitoring reports showing that performance drift is detected and reviewed

The NIST AI 100-1 publication places this characteristic under MEASURE 2.5. Acceptable thresholds should be set by people and recorded with the reasoning behind them.

How does an assessor test whether an AI system is safe?

An assessor looks for proof that the team identified harms the system could cause, tested for them before release, and can limit or stop the system when harm appears. Expected evidence includes:

A hazard or harm analysis tied to the deployment context, covering harms to people, property and the environment
Pre-deployment test results for failure modes, edge cases and misuse scenarios
Runtime safeguards such as guardrails, human override and shutdown procedures, with records of when they were used

Safety is evaluated under MEASURE 2.6. The evaluation should cover harms that matter to affected people, not only technical error rates, and the decisions made from the results should be written down.

What does secure and resilient mean for an AI system in practice?

It means the assessor can see that the system resists attack, keeps working under stress and recovers from failure. Evidence usually covers:

Threat models and adversarial testing results, including data poisoning, evasion, model extraction and prompt injection where they apply
Access control, logging and supply chain records for models, datasets and dependencies
Resilience tests such as failover, rollback and recovery drills, with documented outcomes

MEASURE 2.7 evaluates this characteristic. DeployOpen runs security testing of applications, APIs, cloud and infrastructure, and AI systems and agents, and those findings can feed this evidence. The organization still owns the risk decisions and the remediation records.

What records prove an AI system is accountable and transparent?

The assessor expects a clear chain of responsibility and documentation that people can read without the builder present. Evidence includes:

Named owners for the system, its risks and its decisions, with records of approvals
Model and system documentation describing purpose, data sources, limitations and known failure modes
Records of disclosures to users and affected parties, plus logs that allow decisions to be traced after the fact

This characteristic is evaluated under MEASURE 2.8. Accountable and transparent relates to all of the others, so gaps here often weaken the evidence for the rest. Ask who signs off on the system and where that sign-off is recorded before anything else.

How can an organization show its AI decisions are explainable and interpretable?

The organization should show that it can describe, at a level suited to its audience, how the system reaches an output and what that output means. Evidence includes:

Explanation methods chosen for the model type, with the reasoning for the choice
Samples of explanations reviewed by domain experts or affected users, with their feedback recorded
Documentation of interpretability limits, so users know when an explanation is weak

MEASURE 2.9 evaluates this characteristic. Interpretability can conflict with accuracy or privacy, so the team should record each tradeoff and why it was accepted. Ask a vendor to show the explanation outputs its product actually produces, not only a general description.

What does privacy-enhanced mean for an AI system's data handling?

The assessor looks for evidence that personal and sensitive data is limited, protected and handled under documented rules across the AI lifecycle. Evidence includes:

Data inventories and purpose limits covering training, tuning, inference and logs
Decisions on privacy-enhancing techniques, such as minimization, pseudonymization or differential privacy, with their measured effect on accuracy
Retention, deletion and access records for training data and outputs

MEASURE 2.10 evaluates this characteristic. NIST notes that privacy-enhancing techniques can reduce accuracy under conditions such as data sparsity, so the team should document that tradeoff and justify its choice.

How is harmful bias tested and documented in an AI system?

The assessor expects evidence that the team checked whether the system treats groups unfairly, managed any harmful bias it found and recorded what it decided. Evidence includes:

Bias testing results across relevant groups, with the fairness metrics chosen and the reasons they fit the use case
Data representativeness analysis and records of mitigation steps and their measured effect
Post-deployment monitoring results and a record of who reviewed them

Fairness with harmful bias managed is evaluated under MEASURE 2.11. The framework leaves metric and threshold selection to human judgment, so the people making those choices and their qualifications should be on file.

Why valid and reliable is the base for every other characteristic

Valid and reliable is the one characteristic that AI 100-1 treats as a necessary condition of trustworthiness. In *Figure 4* of the framework, it sits underneath the other six characteristics, and the reasoning is simple: a system that produces wrong or inconsistent outputs gives its other properties nothing sound to rest on. A model that misclassifies loan applicants cannot be called fair in any meaningful sense, because the fairness of its decisions depends on the decisions being correct in the first place. The same applies to explainability. An explanation of a wrong or unstable output explains an error, and a safety control that triggers on the wrong inputs protects against the wrong things. For a risk owner, the practical step is to confirm that validity and reliability evidence exists before reviewing the other characteristics, and to ask which TEVV results support the claim that outputs are accurate for the intended purpose.

AI 100-1 is also clear that addressing the characteristics one at a time will not make a system trustworthy. Tradeoffs are usually involved, and rarely do all seven characteristics apply with equal weight in every setting. The framework states that trustworthiness is only as strong as its weakest characteristic, so a strong privacy control or a well-documented accountability chain does not offset an unreliable model. Reviewers should therefore look at the characteristics together, asking where one reduces another and which one would fail first under stress. The framework expects human judgment to set the metrics and thresholds for each characteristic, and the owner of that decision should be named in the governance record.

*Illustrative example:* a retailer deploys a demand forecasting model that scores well on accuracy in testing but drifts badly when a new product category is added. Its documentation covers privacy, security and fairness, yet the forecasts that drive purchasing decisions are unreliable. Because validity and reliability sit at the base, the weak link limits the whole system, and the remediation should start with monitoring for drift and setting a threshold that triggers retraining or human review, before any other characteristic is reported as satisfied.

Which tradeoffs between characteristics must the organization resolve?

AI 100-1 gives interpretability and privacy as a tradeoff pair. Explaining how a model reached a decision can reveal the training data or individual records behind it, while strong privacy protection can limit how much of the model's logic can be exposed. The organization has to decide how much explanation each affected party needs and how much data exposure the privacy commitments allow. The answer differs for a credit decision shown to a customer than for an internal triage model.

Decision: the depth of explanation provided to users, operators and regulators, set against the privacy risk of exposing training data or personal attributes.
Who should be involved: the privacy officer, the model owner, the team that answers user complaints, and legal counsel for any regulated decisions.
Record to keep: the explanation level chosen for each audience, the privacy risk that limited it, and the reason the balance was acceptable.
Review trigger: a change in the data set, a new explanation request type, or a privacy incident.

Check that the record names who accepted the residual privacy or explanation gap and when that acceptance is reviewed.

Where the Core measures each characteristic

The MEASURE function is where AI 100-1 turns trustworthiness characteristics into testable work. The cards below follow the order an assessor reads the evidence file: how metrics are chosen, how each characteristic is evaluated, and where environmental impact fits. NIST does not validate or endorse any individual organization's approach to using the AI RMF.

Metric selection under MEASURE 1

MEASURE 1 covers choosing and maintaining the metrics used to track the most significant risks identified in MAP. Before any characteristic is tested, the file should show which metrics were selected, why they fit the system's context, and who reviewed them. Ask whether the metric choices and their thresholds were set through documented human judgment, since AI 100-1 says that judgment should decide specific metrics and threshold values. Check that the file also records when those choices were reviewed.

One evaluation per characteristic

MEASURE 2.5 through MEASURE 2.11 each evaluate one of the seven trustworthy characteristics, from validity and reliability to fairness with harmful bias managed. Map each subcategory to the system's own tests, owners and results rather than copying generic language. Note that a characteristic can be out of scope for a given setting, and record the reason. The file should show a result or documented gap for every characteristic that applies.

Environmental impact and sustainability

MEASURE 2.12 addresses the environmental impact and sustainability of the AI system. It is the only subcategory in MEASURE 2 that sits outside the seven characteristics, so it is easy to skip. The evidence file should state how energy use, compute and resource consumption were estimated or measured, and what was done with the results. Where a figure cannot be measured, record the method used and the gap so an assessor can see it was considered.

TEVV documentation for review

The evaluation results under MEASURE 2 are only useful if the testing, evaluation, verification and validation records can be reviewed. Keep test plans, datasets, versions of the system tested, results and the people who signed off on each. An assessor will look for tradeoff decisions here, since AI 100-1 says tradeoffs should be resolved in a transparent and justifiable way and that trustworthiness is only as strong as its weakest characteristic. Confirm with your own assessor which records they expect in the file.

How the planned AI RMF revision could change these characteristics

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, and it had not published a revised version as of October 17, 2026. The July 2025 Action Plan, in its recommendation to the Department of Commerce through NIST, asks for the framework to be revised to eliminate references to misinformation, diversity, equity and inclusion, and climate change. The seven characteristics themselves are not described as being removed, but the wording, examples and supporting subcategories that touch those topics may change. The reader's practical question is which of their characteristic evidence depends on wording that could move. Two areas deserve a specific check: the discussion of fair with harmful bias managed, and MEASURE 2.12, which covers environmental impact and sustainability. If your evaluation records map to MEASURE 2.12 or to the fairness and diversity language in GOVERN 3, treat those entries as the most likely to need rewording.

Keep your characteristic evidence tied to the exact version you assessed against. Record the document name, its date (January 2023 for AI 100-1) and the subcategory identifiers your tests cite, so that a later revision cannot silently change what your results mean. Store MEASURE 2.5 to MEASURE 2.11 results, metric thresholds and the human judgment behind those thresholds in a form that can be read without the current wording. Where a customer contract or state law names the framework, record which version it refers to, because the revision could affect laws that cite the latest version.

Before you change any policy, assessment template or customer-facing statement, confirm the current status directly with NIST through the NIST AI Risk Management Framework page. Ask whether a revised version has been published, what sections are changing, and whether the AI 100-1 numbering will change. Also check the status of the Trustworthy AI in Critical Infrastructure profile work, since a sector profile may give you a different reference point. Change documents only after the revised text is published, and log the reason for each change. Assessors and customers will expect to see when and why your references moved.

How to turn the characteristics into evidence an assessor can test

This sequence turns the seven trustworthy AI characteristics from abstract goals into a dated, justified file of measurements, tradeoff decisions and monitoring records that an independent assessor can sample and test. The organization owns every step, and an implementation partner can help prepare the material.

Select the system and its intended use
Name the AI system, its intended purpose, the people it affects and the settings where it will run. Record the system boundary, including third-party models, data and components that feed it. Someone accountable for the system signs the scope, and the output is a scope statement that the later evaluations reference. Rarely do all seven characteristics apply equally in every setting, so this record decides which characteristics are in play and why. Confirm the scope with the AI owner before any metric is chosen.
Name metrics and thresholds with human sign-off
For each applicable characteristic, choose the metrics that will show whether the system meets it, such as error rates for valid and reliable or access logs for accountable and transparent. Set a threshold for each metric. AI 100-1 says human judgment should decide both the metrics and the threshold values, so record who approved each one and the date. The output is a measurement register that lists the characteristic, metric, threshold, owner and approver. Ask the reviewer to confirm that each characteristic has at least one metric or a stated reason for leaving it out.
Run and document evaluations for each characteristic
Test the system against each metric in the register, using test data and conditions that resemble deployment. Keep the test plan, datasets, configurations, results and any failures in a versioned record. Map each evaluation to the MEASURE subcategory it supports, such as MEASURE 2.5 through MEASURE 2.11 for the seven characteristics and MEASURE 2.12 for environmental impact. The output is an evaluation report per characteristic that a tester who was not on the build team could reproduce from the notes alone.
Record each tradeoff decision and its justification
Where one characteristic pulls against another, such as interpretability against privacy or predictive accuracy against interpretability, write down the conflict, the options considered, the option chosen and the reason. NIST says tradeoffs should be resolved in a transparent and justifiable way. Include the measured effect of the choice, for example the accuracy change after a privacy-enhancing technique was applied. The output is a decision log entry for each tradeoff, approved by the accountable owner, that links back to the evaluation results.
Set up production monitoring against the same metrics
Deploy monitoring that tracks the same metrics and thresholds in production, along with the user problem reports and appeals that the MEASURE 3 subcategories describe. Define who receives alerts, how a threshold breach is escalated and which MANAGE actions follow. The output is a monitoring specification and a sample of alert and ticket records showing that the controls operate. Confirm that the monitoring still reports on the metrics approved in the register, so production results can be compared with pre-deployment evaluations.
Assemble the evidence file for an independent assessor
Gather the scope statement, measurement register, evaluation reports, decision log, monitoring records and the review history into one indexed file. Check that each claim traces to a dated record and that the versions of the model and the metrics match. NIST does not validate or endorse any organization's use of the AI RMF, so the file is evidence for an independent assessor or customer reviewer to test, not a certificate. The output is a file index and a short internal check confirming every trace link works. Ask the assessor which format and sampling approach they expect before the file is finalized.

How the Generative AI Profile tags each risk to the characteristics

NIST AI 600-1 tags each of its generative AI risks with the trustworthy characteristics it affects, so a reader can see at a glance which of the seven characteristics a given risk touches. The tagging is the bridge between the risk list in the profile and the evaluation work in the Core. Information security is the clearest example: the profile tags it as privacy-enhanced, safe, secure and resilient, and valid and reliable. A single risk can therefore pull in several characteristics, and an evaluation scoped to only one of them would miss part of it.

A buyer can use these tags to scope an evaluation of a generative AI system before testing starts. Take each risk the vendor or internal team has accepted as relevant, read its tagged characteristics, and map those characteristics to the MEASURE 2 subcategories that evaluate them. Information security, for example, points toward evaluations of privacy, safety, security and validity together. Ask the vendor to show which tests cover each tagged characteristic for each relevant risk, and to say where a characteristic has no test at all. Gaps in that answer are often more useful to record than the passing results.

Confirm the full tag list in NIST AI 600-1 itself before you rely on it, because this page does not reproduce the tags for every risk. Read the risk definitions and their tags together, and check whether the version your contract or regulator names is the one you are working from. Record the tags you used in your scoping documentation so an assessor can trace each evaluation back to a characteristic and a risk. Treat the tags as the starting point for scoping, not as proof that a characteristic has been measured.

Who owns the characteristics, who prepares the evidence, and who assesses it

Your organization owns the trustworthy AI characteristics in full. NIST AI 100-1 states that human judgment should be used when deciding on the specific metrics for each characteristic and the threshold values that trigger action, and that tradeoffs between characteristics, such as interpretability and privacy or predictive accuracy and interpretability, should be resolved in a transparent and justifiable way. No vendor can make those calls for you, because they depend on your mission, your risk tolerance and the people your system affects.

Metrics and thresholds: Decide which measures evaluate valid and reliable, safe, secure and resilient, and the other characteristics for each system, and set the values that count as acceptable.
Tradeoff decisions: Record which characteristic gives way when two conflict, why, and who approved it.
Accountability: Name the owner who accepts residual risk and can stop or supersede the system.
Policy and risk tolerance: Keep the trustworthy AI policy and risk tolerance that the metrics must reflect.
Review cadence: Decide how often thresholds are revisited as the system and its context change.

Before engaging anyone, confirm that these decisions are written down, signed by an accountable executive, and traceable to the MEASURE subcategories they support.

Common questions about the trustworthy AI characteristics

Do all seven trustworthy AI characteristics have to be met?

No single characteristic is a pass or fail test, and NIST does not say every characteristic must be fully achieved. AI 100-1 notes that rarely do all characteristics apply in every setting, so the first task is deciding which ones matter for a given system and why. It also warns that trustworthiness is only as strong as its weakest characteristic, so a system that is accurate but unexplainable, or secure but unfair, still leaves a gap that a customer or regulator may ask about. Document which characteristics apply, the reasoning for excluding any, and how the remaining ones are measured.

Can our organization document the tradeoffs between characteristics itself?

Yes, and NIST expects the organization to do it. AI 100-1 gives examples such as interpretability against privacy and predictive accuracy against interpretability, and says tradeoffs should be resolved in a transparent and justifiable way. It also says human judgment should set the specific metrics and threshold values. The record should show the options considered, the decision, the accountable owner and the evidence behind it. An outside reviewer can challenge that reasoning, but the decision itself belongs to the organization. Confirm internally who has authority to accept a tradeoff before the first assessment.

What drives the effort of evaluating each characteristic?

The effort depends on how many characteristics apply, how much testing each one needs, and how mature the existing test and monitoring setup is. The MEASURE 2 subcategories are the largest group in the Core, with one set of evaluations for each characteristic plus environmental impact under MEASURE 2.12. Effort rises with system criticality, the number of deployment settings, the availability of labeled test data, and whether results must be reproduced over time. Ask any provider for a written list of the MEASURE 2 subcategories in scope, the evidence each one will produce, and which tests they expect the organization to run versus prepare.

Does an assessor certify that the characteristics are met?

No. The AI RMF has no certification, and NIST does not validate or endorse any organization's use of it. An independent auditor or assessor can test evidence against a stated scope and report on what they found, but that is an assessment for a specific customer or contract, not a certificate of trustworthiness. Ask any assessor to state in writing what they will examine, which characteristics are covered, and what their output will be called. Implementation partners can prepare systems, test records and documentation, but they do not issue reports or certificates.

What does the work need from our internal team?

Evaluating the characteristics needs people who own the system, people who can run and interpret tests, and people who can make risk decisions. Engineering and data science teams typically run and document TEVV work, security staff cover the secure and resilient and privacy-enhanced characteristics, and legal or compliance staff review fairness, transparency and accountability claims. Leadership must accept or reject residual risk. Name these roles before work starts, because MAP and MEASURE outputs are only useful when someone is accountable for acting on them.

How do the characteristics relate to the Generative AI Profile?

NIST AI 600-1 tags each of its 12 generative AI risks with the trustworthy characteristics it affects, so a team can see which characteristics each risk touches. For example, the profile tags information security with privacy-enhanced, safe, secure and resilient, and valid and reliable. That tagging helps prioritize: a risk tied to several characteristics usually needs evidence from several MEASURE subcategories. Confirm the current tags directly in the profile, since the tags are a guide to where to look rather than a substitute for a documented risk analysis.

Will the characteristics or their wording change?

Confirm this before relying on any wording. America's AI Action Plan from July 2025 recommends that NIST revise the AI RMF to remove references to misinformation, diversity, equity and inclusion, and climate change. NIST says AI RMF 1.0 is being revised as part of that effort and has not yet published a revised version, and AI 100-1 expects a formal review no later than 2028. Track the NIST AI RMF page for updates, and keep your characteristic definitions and evidence in a form that can be re-mapped if the framework text changes.

How DeployOpen prepares characteristic evidence ahead of an assessment

DeployOpen helps organizations prepare the systems, controls and evidence that show how their AI systems meet the trustworthy AI characteristics in NIST AI 100-1. The organization owns its risk decisions and metric thresholds, and an independent assessor or auditor reviews the evidence, since NIST does not certify or validate any organization's use of the framework.

How we scope

Engagements are fixed-scope, with the AI systems, characteristics and MEASURE subcategories agreed in writing before work starts.
We confirm which of the seven characteristics apply to each system, since NIST notes that rarely do all of them apply in every setting.
The written scope names who decides metric thresholds and tradeoff resolutions, so the organization keeps ownership of those choices.

How we build

We set up measurement and testing for the characteristics in scope, including security testing and monitoring on the self-hosted platforms.
We document how each tradeoff, such as interpretability against privacy, was resolved and why, in a form a reviewer can follow.
Testing covers AI systems and agents where they are in scope, using the same evidence structure across characteristics.

How we hand over

Deliverables include the characteristic evidence register, test records, configuration documentation and the tradeoff decision log.
Each evidence item is mapped to the MEASURE subcategory it supports, so an assessor can trace a claim to its proof.
Handover names the gaps still open and the owner of each, so the organization can close them before any independent review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so evidence stays current as systems change.
We can re-run characteristic tests after material model, data or configuration changes, as set out in the written scope.
Pending revisions to AI 100-1 are tracked, and any change to the evidence structure is agreed with the organization in writing.