MEASURE is the most concrete of the four AI RMF functions. Here is what to actually track, how to choose metrics, which tools help, and how to know when a number means you have a problem.
What MEASURE Is (and Is Not)
The MEASURE function in the NIST AI RMF is described as: analysing and assessing the AI risks identified in MAP, using quantitative and qualitative methods where possible. That is accurate but not actionable.
In practice, MEASURE is the function that answers three questions: What are we tracking? How are we tracking it? And what does a bad number look like? It spans pre-deployment testing, production monitoring, and structured human evaluation. It is not a one-time activity.
MEASURE does not tell you which specific metrics to use — those depend on your system type, use case, and risk tolerance. What it does is define the category of measurement that should cover each identified risk.
The MEASURE Sub-Categories
| Sub-category | What it means in practice |
|---|---|
| MEASURE 1.1 — Risk measurement methods selected | Before you measure, decide how. Document which quantitative and qualitative methods you will use for each risk in your MAP inventory. |
| MEASURE 1.3 — Internal experts identified | Name the people responsible for measurement in each domain (fairness, security, reliability, etc.). Do not leave this as 'the team.' |
| MEASURE 2.1 — AI risk measurement approaches are tested | Validate that your measurement methods actually capture the risks they are supposed to. A bias metric that only tests one demographic dimension might miss the real bias. |
| MEASURE 2.2 — Scientific findings considered in risk measurement | Use peer-reviewed methods where they exist. For fairness metrics, this means using established definitions (demographic parity, equalised odds, etc.) rather than inventing your own. |
| MEASURE 2.5 — Testing in deployment context | Lab testing is not enough. Test the system in conditions as close to the real deployment context as possible, including edge cases. |
| MEASURE 2.6 — Risk measurement considers data quality | Your metrics are only as good as your evaluation data. Poor-quality or unrepresentative test sets will produce misleading measurements. |
| MEASURE 2.9 — Human feedback incorporated | Combine automated metrics with structured human evaluation. Humans catch failure modes that metrics miss. |
| MEASURE 3.1 — Metrics reviewed by affected parties | Where feasible, involve stakeholders (including potentially affected communities) in reviewing what is being measured and whether the metrics capture the right things. |
| MEASURE 4.1 — Feedback processes active | Post-deployment feedback loops are in place: user corrections, override rates, escalation patterns. |
| MEASURE 4.2 — Measurement results inform system updates | The output of MEASURE feeds back into MAP (risk re-evaluation) and MANAGE (risk response). If measurement is not changing decisions, it is theatre. |
Fairness and Bias Metrics
Fairness metrics are the most asked-about category. The important thing to know upfront: there is no single 'correct' fairness metric. Different definitions of fairness are mathematically incompatible — you cannot optimise for all of them simultaneously. You need to choose which definition fits your use case.
| Fairness metric | What it measures | When to use it |
|---|---|---|
| Demographic parity (statistical parity) | The positive outcome rate is equal across demographic groups. | When equal treatment regardless of outcome is the priority. E.g., job screening where each group should have equal selection rates. |
| Equalised odds | True positive rate AND false positive rate are equal across groups. | When errors in both directions matter equally. E.g., medical diagnosis where missing a condition is as harmful as a false alarm. |
| Equal opportunity | True positive rate is equal across groups (false positive rate can differ). | When false negatives are the primary harm. E.g., recidivism risk tools where incorrectly denying parole is the critical failure. |
| Calibration | Among all individuals scored with probability p, approximately p% have the positive outcome, regardless of group. | When the score itself is used as a probability estimate. E.g., credit risk scores used for pricing. |
| Individual fairness | Similar individuals receive similar outputs. | When group-level metrics are insufficient and case-by-case consistency matters. Harder to operationalise. |
Pick the fairness definition that maps to your system's harm model, then hold it constant. Switching fairness definitions mid-project (or when a specific metric looks bad) is a red flag in any internal audit.Reliability and Performance Drift
Reliability metrics track whether the model continues to perform as expected over time. Models degrade — this is not a failure of deployment, it is a predictable characteristic that needs to be measured.
Key reliability metrics
| Metric | What it detects |
|---|---|
| Prediction distribution shift | The model's output distribution is changing over time. May indicate changing input patterns or model degradation. |
| Input covariate shift (PSI — Population Stability Index) | The distribution of input features is drifting from the training distribution. PSI above 0.2 is typically a warning threshold. |
| Performance on rolling holdout set | Model accuracy/F1/RMSE on a continuously updated holdout of recent production data. |
| Error rate by cohort over time | Is error rate increasing for specific user segments even if overall error rate is stable? |
| Label drift (concept drift) | The relationship between input features and the correct label is changing. This is the hardest drift to detect automatically — it requires fresh labelled data. |
What 'acceptable drift' means
There is no universal threshold. Your MAP risk tolerance session should have produced a documented threshold for each metric. If it did not, use these starting points and adjust based on your domain:
- PSI > 0.2: model retraining should be evaluated.
- Accuracy drop > 3% from baseline: investigate root cause before next release.
- Error rate disparity across demographic groups > 5 percentage points from baseline: escalate to responsible AI lead.
Security and Adversarial Robustness
Security metrics cover the AI system's resistance to manipulation and adversarial inputs. For most commercial AI products, the relevant threats are:
| Threat | Metric / test | Tools |
|---|---|---|
| Prompt injection (for LLM-based systems) | Rate of successful injection attacks in red team testing. Measure the fraction of injection attempts that cause policy violation or unintended output. | LLM red teaming frameworks, Garak, PromptBench |
| Model extraction attacks | Information disclosure rate — how much of the model's behaviour can be reverse-engineered via API queries. | MLSecEval, custom adversarial query suites |
| Data poisoning (for systems with user-influenced training) | Performance degradation under poisoned data conditions. | ART (Adversarial Robustness Toolbox) |
| Membership inference | Can an attacker determine whether a specific record was in the training data? | ML Privacy Meter, ART |
For most product teams building on top of foundation models (Claude, GPT-4, etc.), your security measurement focus should be on prompt injection and misuse vectors at the application layer. The model provider handles model-level adversarial robustness for the foundation model.Transparency and Explainability Metrics
Transparency metrics are the hardest to automate and the most context-dependent. They cover whether the model's decision-making process is understandable to the relevant stakeholders.
- Feature importance consistency: Do the top explanatory features match domain expert expectations? Flag large deviations.
- Explanation stability: Do similar inputs produce similar explanations? Unstable explanations undermine trust even when the output is correct.
- Human comprehension test: Can a domain expert correctly interpret an explanation and use it to evaluate whether an output is trustworthy? Run structured tests with representative users.
- Counterfactual completeness: For high-stakes decisions, can the system generate meaningful 'what would need to change to get a different outcome' answers?
Recommended Tools by Metric Category
| Category | Open-source tools | Commercial/managed options |
|---|---|---|
| Fairness and bias | Fairlearn (Microsoft), AI Fairness 360 (IBM), Google What-If Tool | Arthur AI, Fiddler AI, Credo AI |
| Drift detection and monitoring | Evidently AI, NannyML, WhyLabs (free tier) | WhyLabs (enterprise), Arthur AI, Arize AI, Fiddler AI |
| Explainability | SHAP, LIME, InterpretML | Fiddler AI, Truera, Arthur AI |
| LLM-specific evaluation | RAGAS (RAG quality), DeepEval, Garak (security) | Braintrust, LangSmith (LangChain), Arize Phoenix |
| Adversarial robustness | ART (IBM), Counterfit (Microsoft), Garak | Commercial red teaming services |
Setting Thresholds That Mean Something
The hardest part of MEASURE is not choosing metrics — it is setting thresholds that connect to actual risk. A threshold that is not grounded in the harm model is just a number.
The right process for threshold-setting:
- Go back to your MAP risk inventory. What is the harm if this metric goes wrong?
- Quantify the harm where possible: what error rate would cause a materially bad outcome for users?
- Set the threshold conservatively (err toward caution), document the reasoning, and get sign-off from the AI risk owner.
- Review thresholds quarterly. They should evolve as you learn more about real-world failure modes.
Do not set thresholds based on what your current model achieves. Setting a threshold at 'current performance minus 2%' is not risk-managed measurement — it just automates the status quo. Thresholds must be connected to harm, not to the model's current capability.Quick Reference: MEASURE Checklist for Each Release
- Automated CI/CD quality gates passed (accuracy, fairness, drift vs. baseline).
- Human evaluation sample reviewed and documented.
- Fairness report generated and reviewed by responsible AI owner.
- Adversarial input test results within acceptable bounds.
- Explainability spot-check completed for any new model or significant feature change.
- Production monitoring dashboards reviewed for any anomalies in the previous sprint.
- Any threshold breaches from prior sprint addressed or formally accepted with rationale.