The NIST MEASURE function expects documented, repeatable tests tied to the risks you mapped, run before deployment and again in production. It covers performance, safety, security, privacy, fairness, transparency and the quality of the tests themselves. Here is a practical plan built from its subcategories.
What MEASURE says
NIST describes MEASURE as using quantitative, qualitative or mixed methods to analyze, assess, benchmark and monitor AI risk. It calls for rigorous software testing and performance assessment with measures of uncertainty, comparison to benchmarks, and formal reporting. It also says independent review can improve testing and reduce internal bias and conflicts of interest.
A testing plan from the subcategories
- Document the setup (MEASURE 2.1). Test sets, metrics and tools.
- Test in deployment-like conditions (2.3). Demonstrate performance for conditions similar to production, and record the measures.
- Monitor in production (2.4). Track functionality and behavior of the system and its components once live.
- Show it is valid and reliable (2.5). Record limits on how far results generalize.
- Evaluate safety (2.6). The deployed system should be demonstrated safe, with residual negative risk not exceeding tolerance, and able to fail safely when pushed past its knowledge limits.
- Evaluate security and resilience (2.7).
- Examine transparency and accountability risks (2.8) and explain and validate the model (2.9).
- Privacy (2.10) and fairness and bias (2.11).
- Environmental impact (2.12) where relevant.
- Check the checks (2.13). Evaluate whether your metrics and processes work.
Generative AI additions
For generative systems, test for confabulation on your own domain questions, leakage of sensitive data, and behavior under adversarial prompts, using the profile's twelve risks as a prompt list. Keep a fixed regression set and rerun it whenever the model, prompt or retrieval data changes.
Make it repeatable
Store test inputs, expected behavior, scoring method and results with versions. Automate what you can in your delivery pipeline so a change cannot ship without a pass.
Production monitoring
Track quality signals, user feedback and override rates, and error categories. Set thresholds that trigger review or a pause. Tie those to your incident plan.
Independent review
For high-tier systems, have someone outside the build team review the test design and results. Record their comments.
Example test set for an assistant
Build around fifty to a few hundred real questions, with a labeled expected behavior for each: answer, refuse, or escalate. Include tricky cases such as questions outside scope, requests for other customers' data, and prompts that try to override instructions. Score each run by category and track the trend over time. A regression set like this is cheap to keep and catches most silent failures after model or prompt changes.
Quick check
How many tests are enough?
Enough to cover each mapped risk with at least one test whose result would change a decision. Add more where impact is high.
Can the vendor's benchmark replace our testing?
It is an input, not a replacement. Test on your own data and use case.
Sources
Last reviewed: 19 October 2026.
