MEASURE 2.11 Fairness and bias: requirements and evidence

What MEASURE 2.11 asks for and why teams struggle with it

If your team listed fairness and bias risks during MAP, MEASURE 2.11 asks you to show two things: that those risks were actually evaluated, and that the results were written down. NIST AI 100-1 frames this as an outcome, not a fixed test. It does not name a metric, a threshold or a pass mark that your system must reach. The AI RMF is also voluntary, and NIST does not run a certification or conformity assessment for it, so no one will hand you a badge for meeting it. The assessor you face is usually a customer, an internal audit function or a regulator asking whether your evidence matches the risks you claimed to manage. Start by pulling your MAP 1 and MAP 5 records and confirming that every fairness risk you named has a matching evaluation entry, an owner and a documented result, even where the result is that the risk was tested and found acceptable.

Teams struggle here for two reasons. The first is that harm can arise without any discriminatory intent. AI 100-1 Section 3.7 identifies systemic, computational and statistical, and human-cognitive biases, and notes that each can occur without prejudice. A credit model trained on historical approvals, a triage tool fed by uneven referral data or a ranking system tuned on click behavior can each produce unequal outcomes with no one choosing that result. That means your evaluation has to look at data sources, labels and feedback loops, not only at the model's final output. Ask the TEVV team to document where training and evaluation data came from, who is missing from it and which proxy features, such as postal code standing in for ethnicity, could carry group membership into the model.

The second reason is that metrics depend on context. The Playbook points to general fairness measures such as demographic parity or equalized odds, but a measure that suits a loan decision may be wrong for a clinical or hiring decision, and the two can conflict with each other. Choosing a metric is therefore a decision with a named owner, usually made with domain experts and affected-community input, and it should be recorded with the harm types you chose to prioritize. Confirm with your domain and legal leads which metrics and thresholds will drive a go or no-go decision, and state in writing what you will do if the results disagree.

Which AI systems, data and teams fall under MEASURE 2.11

MEASURE 2.11 applies wherever an AI system can affect people differently by group, and the scope you draw determines which datasets, models and teams must be evaluated. The decisions below are the ones that most change the amount of work, and the organization owns each of them.

Systems with outputs that affect people

Start by listing every AI system whose outputs influence decisions about individuals, such as eligibility, pricing, ranking, screening, content moderation or service routing. Fairness evaluation under MEASURE 2.11 is most relevant where a harm would fall on a identifiable group. Record the decision each output feeds and who is affected by a wrong result. A system that only summarizes internal engineering tickets usually sits outside this scope, but confirm that assumption against the MAP 1 context record.

Training data and its sources

Bias often enters before any model is trained. Inventory each training dataset, its collection method, its time period and the populations it over- or under-represents. Note whether the data came from historical decisions that may encode past discrimination. The Playbook asks teams to analyze bias in training data, so this inventory is the starting point for that analysis and for choosing which groups to examine.

TEVV and evaluation datasets

The test, validation and evaluation sets are where fairness results are measured, so their composition matters as much as the training data. Check whether each group has enough examples for a metric to mean something, and whether the evaluation set reflects the deployment population rather than a convenient sample. Record the sampling method so an assessor can reproduce the group breakdown.

Third-party models and data

Pre-trained models, vendor APIs and purchased datasets carry bias you did not collect and may not be able to inspect. Under MEASURE 2.11, decide which third-party components you must evaluate directly, which you will test through outputs, and what the vendor must disclose. Ask vendors for their own fairness documentation and note where that documentation is missing, since the gap becomes a documented risk.

Proxy features and protected attributes

Some features, such as postal code, school name or purchase history, can stand in for protected characteristics even when those characteristics are excluded from the model. The Playbook asks organizations to find such proxies. Scope the feature review to every input the model uses, including features derived by pipelines, and document which ones were tested for correlation with group membership.

AI actors who take part

The Playbook tags MEASURE 2.11 to TEVV, Domain Experts, Operation and Monitoring, AI Impact Assessment, AI Deployment, End-Users and Affected Individuals and Communities. Name a person or team for each category, because AI 100-1 Appendix A describes the tasks each one performs. Confirm with your own leadership who owns the final scope decision, since the organization, not an outside partner or auditor, is accountable for it.

Which harm types and bias sources the evaluation must cover

The evaluation has to cover the harm types that MAP already identified, and the Playbook suggestions for MEASURE 2.11 name five: allocational harms (unfair withholding or distribution of opportunities, resources or information), representational harms (demeaning, stereotyped or erasing portrayals of groups), quality of service harms (uneven accuracy or usefulness across groups), stereotyping, and erasure. For each system, the TEVV team should write down which of these apply, which groups of people could be harmed by each one, and who is in those groups. Domain experts and affected individuals and communities are the sources to ask, because a test team alone rarely knows how a decision lands in a particular population. Confirm that the group list came from the MAP outputs and the intended purpose, not from whatever demographic fields happen to be in the test data.

AI 100-1 Section 3.7 groups AI bias into three categories that the evaluation should check separately: systemic bias, which sits in institutions, processes and data collection; computational and statistical bias, which comes from sampling, modeling choices and errors; and human-cognitive bias, which enters through the way people design, label, interpret or act on outputs. The framework notes that each of these can occur without prejudice or discriminatory intent, so a clean intent review does not clear a system. NIST SP 1270 gives more detail on these categories and should be consulted directly when building the bias checklist for a specific system.

Proxies need their own check because a model can produce group-correlated outcomes without ever receiving a protected attribute. Postal codes, school names, device types, job titles or spending patterns can carry the same information, and removing the protected field from the input does not remove the effect. The Playbook asks teams to find features that act as proxies for group membership, so the TEVV plan should list candidate proxies, measure how strongly each one predicts group membership in the evaluation data, and record the decision taken for each one. Where the organization cannot collect protected attributes for testing, it should document how it estimated group outcomes and what limits that approach has.

How an assessor tests fairness and bias evaluation

This table compares six checks an assessor or internal reviewer would likely run against MEASURE 2.11, with the evidence each check asks for and the gaps that appear most often. Read each row as a question to put to your own team before an outside reviewer asks it. NIST does not publish an assessor procedure for the AI RMF, so treat these checks as a practical review approach rather than an official test.

Check	Evidence requested	Common findings
Are MAP fairness issues traced into measurement?	MAP 1 and MAP 5 records of fairness concerns, mapped to specific MEASURE 2.11 tests with owners and dates	Fairness risks listed in MAP documents never reappear in test plans, so measurement covers only accuracy
Are harm types and affected groups documented?	Written harm taxonomy (allocational, representational, quality of service, stereotyping, erasure) and named groups for each use case	Harm types are copied from a template without linking to the deployed decision, or affected groups are listed only as demographic labels
Are fairness metrics named, justified and applied to the right populations?	Metric definitions, reasons for selecting each metric, the population and subgroup slices used, and context-specific metrics where general metrics fall short	Demographic parity or equalized odds reported with no rationale, or computed on a training sample instead of the population the system serves
Was bias in training and TEVV data analyzed?	Data provenance records, representation counts by group, label quality checks, and documented decisions on reweighting or exclusion	Analysis covers the training set only, and the TEVV test set is never compared against the production population
Were proxy features examined?	Feature inventory, correlation or sensitivity analysis against group membership, and a record of which proxies were removed, kept or constrained	No proxy review at all, or a review that checks only explicitly protected attributes
Are results documented and fed back?	Dated test reports, decisions on residual bias, sign-off by accountable roles, and links to MANAGE 1 and MEASURE 3 follow-up	Results stored in a notebook with no owner, no threshold for action, and no record that the model owner changed anything

How to implement the fairness evaluation step by step

This sequence turns the fairness and bias issues flagged in MAP into a documented evaluation that tests specific harms, metrics and data sources, and that is revisited when the system or its context changes. Each step ends with a named artifact so the record can be reviewed by internal governance and independent assessors.

Pull the MAP fairness findings
Start from the fairness and harmful bias risks recorded during MAP, including the context, intended purpose and impact characterization for the system. The AI team and the risk owner confirm which findings are in scope for MEASURE 2.11 and which are accepted or deferred. The step is complete when the team holds a single list of in-scope fairness findings, each traced to its MAP entry. Output: a fairness findings register that links each item to its MAP record.
Define harm types and affected groups
Domain experts, TEVV staff and representatives of affected communities, where practical, agree which harm types apply to each finding. The Playbook's harm categories are allocational, representational, quality of service, stereotyping and erasure. The team also names the groups that might be harmed and records why each group was chosen. The step is complete when every in-scope finding has at least one harm type and a named group set. Output: a harm and group definition table with rationale.
Select general and context-specific metrics
TEVV owners choose fairness metrics for each harm and group pair. General metrics such as demographic parity or equalized odds give a common baseline, while context-specific metrics reflect the decision the system supports. The team states what each metric measures, what result would count as a concern and why the chosen metrics fit the use case. The step is complete when a reviewer can trace every metric back to a harm. Output: a metric selection record with definitions and acceptance thresholds set by the accountable owner.
Analyze bias in training and TEVV data
The data team examines training and TEVV datasets for systemic, computational, statistical and human-cognitive sources of bias, which AI 100-1 identifies as bias categories that can arise without discriminatory intent. They check group representation, label quality, collection context and gaps in coverage. For generative systems, the team also reviews benchmark coverage and the proportion of synthetic data, as the Generative AI Profile suggests. The step is complete when each data source has a documented bias review. Output: a data bias analysis with known gaps and their effect on the metrics.
Test features that act as proxies
The team looks for input features, such as postal codes, schools or purchase patterns, that may stand in for protected attributes even when those attributes are excluded from the model. Techniques include measuring how well each feature predicts group membership and checking whether removing a feature changes outcomes for the affected groups. Results go to domain experts for a judgment on whether the feature is acceptable for the use case. The step is complete when each candidate proxy has a recorded decision. Output: a proxy feature assessment with the reasoning for keeping, modifying or removing each feature.
Run the evaluation and record results
TEVV staff run the selected metrics on the agreed test sets under conditions close to deployment, then compare results against the acceptance thresholds. Each run records the dataset version, tool versions, metric values and any results that fall outside the thresholds, so the work can be reproduced. Concerns are routed to the accountable owner for a decision on mitigation or go or no-go. The step is complete when every metric has a documented result and an owner for each exception. Output: a fairness evaluation report with raw results, the test configuration and the decisions taken.
Set a review trigger
The accountable owner defines the events that reopen the fairness evaluation, such as a material change to the model, its training data, its users or its deployment context, and any production signal of unequal outcomes from monitoring. The team also records who receives monitoring alerts and how they reach the TEVV team. The step is complete when the triggers are written into the governance record and tied to the monitoring plan. Output: a fairness review trigger schedule linked to production monitoring.

Evidence that passes a MEASURE 2.11 review and how to keep it current

A MEASURE 2.11 review looks for a chain of documents that starts with the fairness and bias issues identified in MAP and ends with documented results and decisions. Each artifact below should cite the MAP finding it answers, and each needs a named owner and a trigger for review.

Harm-type register

A register that lists each harm type the team considered for the system, such as allocational, representational, quality of service, stereotyping or erasure, and the groups that might be harmed by each. It is the first place an assessor looks for the link back to MAP. Every entry should name the MAP finding it traces to. Keep it current by revisiting entries whenever the use case, user population or deployment setting changes, and record who approved each change.

Group definitions and rationale

The definitions of the demographic or other groups used in the analysis, with the reasons each was chosen and the data sources used to identify members. Weak or missing definitions usually cause later metrics to be meaningless. Document which groups were excluded and why, including groups the data cannot reliably represent. Review the definitions when new population data arrives or when affected communities raise concerns.

Metric specification and rationale

A written specification for each fairness metric in use, such as demographic parity or equalized odds, plus any context-specific metric the team adopted. It should state the thresholds, the test populations and why that metric fits the harm it measures. Assessors often challenge a metric that does not match the harm type in the register. Re-run the review when the model, threshold or decision policy changes, because a metric can pass before a change and fail after it.

Data bias analysis report

A report on bias in training and TEVV data, covering representation of each group, label quality across groups, and any synthetic or augmented records. For generative AI, it should also show the proportion of synthetic training data where the team considered model collapse. Keep the analysis tied to the dataset versions used in each evaluation. Refresh it when training data, labeling guidelines or source systems change.

Proxy feature test log

A log of the features tested as proxies for group membership, including postal codes, language, device type or other fields correlated with protected attributes, and the result of each test. The log should record which features were removed, transformed or kept with a documented reason. Keep it current by rerunning the proxy tests whenever features are added to the pipeline, since new fields can reintroduce the same proxy.

Results report with limits and decision record

The results report states the measured outcomes for each group, the limits of the tests (sample size, populations not covered, metrics not used), and the decision made in response, such as acceptance, mitigation or a no-go. The decision record names the accountable approver and links the decision to the residual risk. Assessors look for limits stated plainly. Update the report at each evaluation cycle and after any incident or user complaint about unfair outcomes.

What meeting MEASURE 2.11 costs in money and effort

This table lists each cost component of evaluating fairness and bias under MEASURE 2.11, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since the largest costs are usually people's time rather than software licenses. No prices or durations are given because none are supplied for this topic, so ask each party to price their component separately.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Internal engineering time	Both: initial build of bias tests, then recurring reruns	Number of models and use cases in scope, number of protected or proxy attributes examined, how many pipelines feed the TEVV data	Scope fairness work to the use cases MAP 1 and MAP 5 flagged as high impact, and reuse one test harness across models
Domain expert and affected-community time	Recurring, tied to each material change	Number of groups that might be harmed, need for interviews or structured review, availability of subject matter experts	Define harm types and groups once in MAP, then reuse the list; plan consultation windows ahead of release dates
Dataset analysis for bias in training and TEVV data	Initial audit, then recurring when data changes	Volume and lineage of training data, quality of demographic labels, number of third-party datasets	Document data sources and label quality at collection time so later analysis does not start from scratch
Metric tooling and compute	Recurring license or hosting cost, often near zero for open-source tools	Number of fairness metrics (for example demographic parity or equalized odds) and context-specific metrics, evaluation frequency, dataset size	Use open-source fairness libraries, run evaluations on representative samples, and automate runs in existing pipelines
External fairness review	Optional, usually one-time per major release or per high-risk use case	Independence required by the organization's risk policy, model complexity, number of use cases reviewed	Ask the reviewer to scope against the documented MEASURE 2.11 results so the review does not restart the analysis
Evidence upkeep	Recurring	Frequency of model updates, number of stakeholders who review the evidence, how results are stored and versioned	Keep fairness results in the same versioned documentation as other TEVV records, such as model cards and datasheets
Independent auditor sampling	Recurring at each assessment cycle	Number of AI systems in the assessment sample, depth of testing the auditor performs, quality of prior documentation	Maintain a current evidence index for each system so sampling requests can be answered quickly
Open-source software license spend	Typically none for the tools themselves	Support contracts, managed hosting or add-on commercial services, if the organization chooses them	Removing license spend does not remove labor; budget for people, compute and review time separately

Which self-hosted open-source tools support the fairness evidence

No single open-source tool computes a fairness verdict for MEASURE 2.11. Adversarial probing and production tracing produce different pieces of evidence, and an assessor will expect the organization to combine them with its own fairness metrics, bias analysis and documented decisions.

garak for adversarial bias probing

garak is an Apache-2.0 scanner that probes language models for toxicity generation and related failures such as hallucination, misinformation and jailbreaks. For MEASURE 2.11, its JSONL report records every attempt and evaluation, and its hit log lists attempts that produced a flagged output. Those records can support a documented test of harmful outputs across the groups identified in MAP. garak does not compute fairness metrics such as demographic parity or equalized odds, and it does not analyze training or TEVV data for bias. Confirm which probes match your use case in your own environment before you cite results.

Langfuse for production trace evidence

Langfuse is an MIT-licensed observability platform that captures traces of each request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For MEASURE 2.11, traces let reviewers sample real outputs by subgroup, metadata field or outcome, and check whether harmful bias appears after deployment. Langfuse does not decide what counts as biased or calculate fairness metrics unless you build those calculations on the exported data. Confirm that your deployment captures the demographic or segment metadata you need, and that your privacy review allows storing it.

Who owns the fairness evaluation and what a partner can take on

Your organization owns MEASURE 2.11. The fairness and bias harms identified during MAP are yours to evaluate, and the conclusions about whether a system's outputs are acceptable for its context are yours to sign. NIST's framework is voluntary, so no outside body assigns this ownership. It sits with the people who understand the use case, the affected populations and the risk tolerance set under GOVERN 1.

Harm and group decisions: Your domain experts and product owners decide which harm types (such as allocational or representational harm) and which affected groups apply to the system.
Metric selection: Your TEVV staff choose fairness metrics suited to the use case and record why they were chosen over alternatives.
Results and actions: Your accountable owners review the documented results and decide whether to remediate, restrict or accept residual bias.
Ongoing monitoring: Your operations team keeps fairness checks running as data and populations change.

Confirm internally that each of these roles has a named person and that the sign-off path is written down before any outside party is engaged.

Common questions about MEASURE 2.11 cost, effort and help

Does the NIST AI RMF require a certificate for MEASURE 2.11?

No. The NIST AI RMF is a voluntary framework, and NIST describes no certification, accreditation or conformity assessment program for it. NIST does not validate or endorse any individual organization's use of the framework. An organization can show how it evaluates fairness and bias under MEASURE 2.11 through its own documentation, and a customer or regulator may ask to see that documentation. Anyone offering an AI RMF certificate is not offering one that NIST issues. If a contract or regulator asks for independent assurance, ask which assessor will check the work and against what criteria, and confirm that scope in writing before work starts.

How much effort does MEASURE 2.11 take, and what drives it?

The effort depends mostly on how many AI systems are in scope, how many people each system affects, and how much bias-relevant data the organization already holds. Effort rises when training and TEVV data are poorly documented, when the affected groups are hard to define, or when several use cases share one model. It also rises when the team must agree on fairness metrics and justify them for each context. No duration is set by NIST for this subcategory, so ask any provider for a breakdown of work by system, data source and stakeholder group rather than a single total.

Can our team carry out MEASURE 2.11 in-house?

Often yes, if the team has data science skills, access to TEVV data and people who understand the affected population. The Playbook tags MEASURE 2.11 with several AI actor categories, including TEVV, Domain Experts, Operation and Monitoring, AI Impact Assessment, AI Deployment, End-Users and Affected Individuals and Communities. That means a single engineering group rarely covers the whole subcategory alone. Teams often keep ownership of decisions and evidence in-house, then bring in outside help for metric design, bias analysis of training data, or independent review of the results.

What should we outsource for MEASURE 2.11, and what should we keep?

Keep decisions, risk acceptance and ownership of the fairness documentation inside the organization, because the organization owns its controls and any go or no-go call. Outside help is commonly used for preparing test datasets, running bias analyses, setting up repeatable evaluation pipelines and documenting results in a consistent format. DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and can prepare systems and evidence, but it does not issue audit reports or attestations. Any independent review of fairness results must come from an assessor or auditor the organization selects.

What does the work need from domain experts?

Domain experts identify which harms matter in the use case and who could be harmed. The Playbook suggests identifying harm types, including allocational, representational, quality of service, stereotyping and erasure, along with the groups that might be harmed. Engineers can compute metrics, but they usually cannot judge whether a gap in error rates is a material harm for a lending, hiring or clinical decision. Experts also help find proxies for protected attributes, such as postal codes or school names, and they confirm whether a chosen fairness metric fits the context. Ask for their sign-off to be recorded in the documentation.

How often should we re-evaluate fairness and bias?

NIST does not set a fixed interval in the sources for this subcategory, so the schedule should follow the organization's own risk tolerance and change events. Re-evaluate after material changes such as new training data, a new model version, a new user group, or a shift in the population the system affects. Production monitoring under MEASURE 2.4 can flag drift that suggests a fairness check is due. Confirm the review cadence with your governance owner and write it into the policy so auditors and customers can see it was set deliberately.

How does MEASURE 2.11 relate to the Generative AI Profile actions MS-2.11-001 to MS-2.11-005?

NIST AI 600-1, the Generative AI Profile, lists five suggested actions for MEASURE 2.11, numbered MS-2.11-001 to MS-2.11-005. They are tagged to the generative AI risks Dangerous, Violent, or Hateful Content, Environmental Impacts, and Harmful Bias and Homogenization. Two of them call for applying use-case appropriate benchmarks to quantify systemic bias, stereotyping and hateful content in outputs, and for checking the proportion of synthetic training data to reduce concerns about model collapse. The actions extend the base subcategory rather than replace it, so a generative system needs both the core evaluation and these profile-specific checks. Confirm the exact wording of each action in the published profile.

How DeployOpen works on MEASURE 2.11 fairness and bias

DeployOpen helps organizations prepare the systems, test records and documentation that show how fairness and bias were evaluated for an AI system. The organization keeps ownership of its controls and its risk decisions, and any independent assessment is performed by a qualified outside party.

How we scope

Confirm which AI systems and MAP-identified harm types fall within the fixed written scope.
Agree which affected groups, fairness metrics and TEVV datasets the evidence must cover.
Define which NIST AI 600-1 suggested actions apply when the system is generative AI, and why.

How we build

Set up evaluation pipelines that compute agreed fairness metrics on documented test and training data.
Run bias and stereotyping benchmarks suited to the use case and record every result and tool version.
Review data and features for proxies of protected attributes and log the findings with their limits.

How we hand over

Deliver fairness test plans, metric definitions, raw results and reproducible scripts to the organization.
Document harm types, groups, data sources and open issues in a format your assessors can trace.
Walk the internal owners through each artifact so they can rerun evaluations after model changes.

How we support

Offer ongoing support as a retainer for rerunning fairness evaluations after updates or new data.
Help teams monitor fairness metrics in production and route results to the accountable owner.
Coordinate evidence requests from internal reviewers or independent assessors, without issuing any attestation.

MEASURE 2.11 Fairness and bias