GOVERN 3.1 Diverse team decision-making: requirements and evidence

What GOVERN 3.1 asks for and why teams struggle with it

GOVERN 3.1 is an outcome in the voluntary NIST AI 100-1 text, not a certification. If a customer, contract or regulator asks how your AI risk decisions are made, the direct answer is that decisions about mapping, measuring and managing AI risk across the lifecycle should be informed by a team that is diverse in demographics, disciplines, experience, expertise and backgrounds. NIST does not validate or endorse any organization's use of the AI RMF, and no independent body issues an AI RMF certificate. Any evidence you show is your own record, and an independent auditor or assessor reviews it if the buyer or regulator requires that. The risk this outcome addresses is narrow teams missing harms to groups they do not represent, such as a credit model that performs differently for applicants from a region no one on the build team has worked in, or a support assistant that misreads dialects its testers never used.

The difficulty is that diversity is easy to claim and hard to evidence. An organization can show a headcount or a hiring policy, but the outcome concerns decisions: who reviewed the context in MAP 1, who challenged the impact characterization in MAP 5, and who signed off on the go or no-go determination in MANAGE 1. The Playbook suggests actions such as defining policies and hiring practices that promote interdisciplinary roles, letting staff raise concerns without fear of reprisal, and seeking external expertise where internal expertise is lacking. For each system, record which roles reviewed which decisions, what external input was sought, and how a concern raised by a team member was resolved. Confirm with your own legal and HR advisers which personal attributes you may lawfully record and report before you design that record.

The topic is exposed to change. The July 2025 AI Action Plan recommends that NIST revise the AI RMF to eliminate references to diversity, equity and inclusion, along with misinformation and climate change, and NIST says AI RMF 1.0 is being revised. As of October 2026, GOVERN 3.1 remains in the published 1.0 text, so your current program should cite that text. Plan for the possibility that a later version changes or removes the wording, and keep the underlying practice, which is documented review of AI risk decisions by people with relevant and varied perspectives, in your own policies regardless of how the framework text reads. Ask any customer or regulator which version of the framework they reference before you map your evidence to it.

Which decisions, teams and third parties does GOVERN 3.1 cover?

GOVERN 3.1 asks that decisions about mapping, measuring and managing AI risk are informed by a diverse team. In practice, the work depends on a handful of scoping choices: which systems and lifecycle stages need diverse review, who counts as part of that review, whether vendor-built AI is inside the boundary, and whether reviewers are internal or external. The cards below set out each choice and what to check.

Which systems and lifecycle stages

Start with an inventory of AI systems and decide which ones receive diverse review, and at which lifecycle stages. Decisions about mapping, measuring and managing risk all fall under GOVERN 3.1, so a system that is only reviewed at design but later changes its data, users or deployment context may still lack the diverse input the outcome describes. Check that the inventory records each system's lifecycle stage and that high-impact changes trigger a new review. Illustrative example: a credit scoring model retrained on new data should go back through the same review as its original launch.

Governance and oversight roles

The AI RMF Playbook ties GOVERN 3.1 to the AI actor category Governance and Oversight. Decide who in this group signs off on risk decisions, such as risk owners, compliance leads and executives with authority to stop a deployment. Confirm that these people are not only technical staff, and that their reporting lines are independent enough to challenge the team that builds the system. Appendix A of AI 100-1 describes the tasks of each actor category, which is a useful starting point for writing role definitions.

AI design and domain expert roles

The Playbook also tags GOVERN 3.1 with AI Design, which covers the people who build and test the system. Diversity here means more than engineering headcount. Include domain experts who understand the business process the AI supports, along with data scientists, security engineers and legal or privacy staff. Ask whether each discipline can raise concerns that change a design decision, and whether that input is recorded. Without this step, a team can be diverse on paper yet still reach decisions through a narrow set of perspectives.

Affected-user and external perspectives

Diversity in demographics, experience and background matters most when the people affected by an AI system are not in the room. The Playbook suggests seeking external expertise where internal expertise is lacking, which can mean outside specialists or representatives of affected groups. Decide which user populations are most exposed to harm, how their perspectives will be sought, and who decides whether that input changes the risk determination. Record the method used so an assessor can see how the input was obtained.

Vendor-built AI inside the boundary

Many organizations use AI built by third parties, and GOVERN 3.1 still applies to the decisions they make about it. Your team may not control the vendor's design team, but it does control whether the vendor's system is reviewed by diverse staff on your side. Check how contracts and procurement reviews allow business, legal and domain staff to test the system before adoption. Ask vendors what diverse evaluation they performed, and confirm what they will share. Where a vendor cannot describe its evaluation, record that gap as a risk decision.

Internal or external reviewers

Decide which reviews are performed by internal staff and which need external reviewers. Internal teams know the system and its context, while external reviewers can bring expertise and independence that internal staff lack. The Playbook recommends an approach that covers both, with a documented rule for when outside expertise is required. Keep a record of who reviewed each decision, their discipline and their relationship to the system. The choice affects cost and effort, since external review is usually paid for per engagement and internal review uses staff time that recurs with each change.

How an assessor tests diverse team decision-making

This table sets out each test step an assessor would take for GOVERN 3.1, the evidence requested and the findings that usually come up. Read it as a preparation checklist: each row shows what the organization should have ready before fieldwork starts. An assessor reports only on the organization's own records, since NIST does not issue results.

Test step	What the assessor checks	Evidence requested	Common finding
Policy and role review	Whether policies and hiring or role definitions call for interdisciplinary and diverse AI risk teams	Written AI governance policy, role descriptions for AI risk roles, hiring criteria for AI teams	Policy exists but names no roles or review criteria
Decision sampling	Whether a sample of AI risk decisions across the lifecycle was informed by people from more than one function or background	Decision records, meeting minutes, risk acceptance sign-offs, attendee lists for selected systems	Decisions made by a single function, such as engineering alone
Reviewer traceability	Whether each decision shows who reviewed it, in what role and with what expertise	Named reviewers and roles on each decision record, with dates and sign-off authority	Reviewers referenced only by team name or not recorded at all
Staff interviews	Whether staff from different teams feel able to raise AI risk concerns and know how to do so	Interview notes, reporting channels, examples of raised concerns and how they were handled	Staff describe concern channels that exist on paper but are not used or trusted
Policy adherence	Whether the documented policy is followed in practice for the sampled systems	Comparison of policy requirements against decision records, training attendance and team rosters	Policies exist but are not followed for newer or smaller AI projects
External expertise check	Whether the organization identifies skills gaps and brings in outside expertise where internal skills are missing	Skills gap assessments, contracts or engagement records with external experts, rationale for not using them	No documented gap analysis, so the need for outside input is never considered
Scope and currency	Whether the team definition covers current AI systems and is updated when systems or staff change	AI system inventory, team rosters with dates, change records for reorganizations	Inventory lists systems that have no named decision team

How to implement diverse team decision-making step by step

This sequence turns the GOVERN 3.1 outcome into working practice: named decision points, written role and reviewer rules, a safe channel for concerns, and a route to outside expertise. Each step leaves a record an assessor can read.

Inventory the AI risk decisions that need diverse input
Start by listing every decision where AI risks are mapped, measured or managed across the lifecycle, from use case approval and data selection to testing sign-off, deployment, monitoring and retirement. Assign each decision an owner in the AI governance function, and mark which ones affect people outside the build team, such as customers, employees or affected communities. The output is a decision register with one row per decision, its lifecycle stage, its owner and a flag for whether it needs multi-discipline review. The step is done when the register is approved by the accountable executive named under GOVERN 2.
Set policy for interdisciplinary and domain roles
Write the policy that defines which disciplines must be represented for each decision type, such as data science, security, legal, privacy, domain operations and affected-user representation. The Playbook suggests policies and hiring practices that promote interdisciplinary roles and demographic and domain diversity, so state how those criteria are applied in staffing and in reviewer selection. Confirm the policy language with HR and legal counsel, since hiring criteria carry employment law obligations that vary by jurisdiction and may be affected by the pending AI RMF revision. The output is an approved policy with a named owner and a review date set by the organization.
Document reviewer composition for each decision
For every entry in the decision register, record who reviews the decision, their discipline, domain experience and the reason they were chosen. Note any gaps where a discipline or perspective is missing and how the gap is covered, either by an internal colleague from another team or by an external expert in the next step. This record is the evidence that a diverse team informed the decision, so keep it with the decision minutes and the risk documentation for the system. The check is that no high-impact decision has a reviewer slate drawn from a single function without a stated reason.
Create a channel for raising concerns without reprisal
Set up a documented route through which any staff member, including contractors and people who are not on the AI team, can raise concerns about an AI system, a decision or a review process. Publish the policy that prohibits reprisal for good-faith reports, name the intake owner, and define how concerns are logged, triaged and answered. Test the channel with a tabletop exercise so the people who would use it know the route exists. The output is a concern log with an intake record for each report, a triage decision and a closure note, which gives assessors a traceable link between raised concerns and changes to the decision.
Set a method for bringing in external expertise
Define the triggers that require outside expertise, such as a discipline the organization lacks, a population the team cannot represent, or a decision with severe potential harm. Specify how external reviewers are selected, how they are engaged under written terms, how conflicts of interest are checked and how their input is recorded and adjudicated. Ask prospective providers to confirm these terms in writing, and confirm with your own legal and procurement teams what is needed for confidentiality. The output is an external expertise procedure and a register of engagements, each linked to the decision it informed.
Run reviews and record how input changed decisions
Apply the reviewer slates to live decisions, and keep minutes that show who contributed, which concerns were discussed and what changed as a result. Where a reviewer's input was not adopted, record the reason and who accepted the residual position. This step produces the evidence that diverse input influenced outcomes rather than being collected for appearance. Sample a set of decisions after the first cycle and check that the minutes, concern log and external engagements agree with the decision register.
Review the sequence on a set cycle
Review the decision register, reviewer records, concern log and external engagements at a cycle the organization sets in its policy, and update the register when systems, teams or regulatory expectations change. Track the status of the NIST revision, since the July 2025 AI Action Plan recommends removing references to diversity, equity and inclusion from AI RMF 1.0, and NIST says it is being revised. Where the GOVERN 3.1 text changes, update the policy wording and confirm the outcome you are meeting with your legal counsel. The output is a dated review record approved by the accountable executive.

Where the Playbook's suggestions fit into a diverse review process

The NIST AI RMF Playbook suggests four moves for GOVERN 3.1: define policies and hiring practices that promote interdisciplinary roles and demographic and domain diversity, let staff raise concerns without fear of reprisal, and seek external expertise where internal expertise is lacking. None of these is a requirement by itself. The Playbook says it is neither a checklist nor a set of steps, so the useful work is deciding which suggestions your organization adopts, assigning each one an owner, and writing down where it applies to AI risk decisions. A practical starting point is a short register that maps each suggestion to the review gates where mapping, measuring and managing decisions are made, such as the go or no-go review for a new system.

Treat the Playbook as a dated source. Its audit log shows the last content update in August 2023, and AIRC has said it will update the Playbook after the AI RMF is revised. Confirm the current revision status of AI RMF 1.0 with NIST before you cite Playbook wording in a policy, because the July 2025 AI Action Plan recommends removing references to diversity, equity and inclusion. The NIST AI RMF page is the place to check for changes. Also note that the Generative AI Profile in NIST AI 600-1 lists no suggested actions for GOVERN 3.1, so generative AI teams will find no profile-specific guidance here and must rely on the base Playbook text.

Link the practice to the AI actor categories the Playbook tags for this outcome: Governance and Oversight, and AI Design. AI 100-1 Appendix A describes the tasks of each category, and those task descriptions are the best basis for writing role definitions. Governance and Oversight owners can document who can challenge a risk decision and how external experts are engaged, while AI Design owners can record which disciplines contribute to design reviews. Keep the records as evidence: meeting minutes showing who was consulted, a register of concerns raised and how they were resolved, and records of any external review. Human oversight roles that sit in GOVERN 3.2 should be cross-referenced here, not redefined.

Which evidence shows diverse team decision-making is working

Six artifacts show whether a diverse team actually informs AI risk decisions across the lifecycle, rather than existing only on an org chart. Together they cover who was assigned, what was debated, how people were hired, whether concerns surfaced, when outside expertise was brought in, and which decisions were made by whom. Keep each one current on a routine cadence so it is ready for an assessor between audits.

Role and reviewer assignments per decision

For each AI risk decision, record which people were assigned to inform it, their discipline, their domain experience and their reviewer role. Assignments should show that the group spans relevant disciplines, such as data science, legal, security, affected business functions and, where relevant, people who represent affected users. Check that every material decision has a named assignment before it is made, not reconstructed afterward. Refresh the assignment record whenever team membership changes, and review it at each lifecycle gate.

Review minutes showing dissenting input

Minutes from risk reviews should record the substance of objections, questions and alternative views, along with how the team responded. A record where every item passed without comment is a weak signal that diverse input was not actually sought. Ask the reviewers to note dissent, unresolved concerns and the rationale for overruling them. Store minutes with the decision they support so an assessor can trace the path from input to outcome.

Interdisciplinary hiring and staffing policy

A written hiring or staffing policy should set criteria that require interdisciplinary skills and domain knowledge for AI risk roles, and should promote demographic and domain diversity. Confirm that the policy is approved by governance leadership, referenced in role descriptions and applied in practice to recent hires or reassignments. Review the policy whenever the AI RMF revision changes the outcome language, since the GOVERN 3.1 wording is under review and organizations should track the revised text.

Concern-reporting records

The Playbook suggests letting staff raise concerns without fear of reprisal, so keep a log of concerns raised through internal channels, with the date, the category, the response and the closure decision. Track whether concerns come from people outside the core AI team and whether any were escalated. An empty log is not automatically good evidence, so pair it with evidence that the channel is known, accessible and used. Review the log at each governance meeting.

Records of external expert engagement

Where internal expertise is lacking, the Playbook suggests seeking external expertise. Keep records of each engagement, including the scope, the expert's qualifications, the questions asked, the advice received and how that advice changed the decision. Contracts and statements of work belong in the same file. Record the engagement date and reassess whether the gap still exists each review cycle, so the file shows the organization identifies gaps and acts on them.

Decision register with reviewer lists

A register lists each AI risk decision, its date, the decision owner, the reviewers consulted and the outcome. It is the index an assessor uses to sample decisions and check that the reviewer list matches the role assignments. Give each entry a unique identifier and link it to the minutes and assignments. Update the register at the time of each decision rather than in batches, and reconcile it against the AI inventory at least once per review cycle.

What meeting GOVERN 3.1 costs in money and effort

This table breaks down the cost components of putting GOVERN 3.1 into practice, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. No figures are given because none are sourced for this outcome, so use the table to frame questions for internal budgeting and for any quote. Treat the largest recurring item, staff time for diverse review, as the one most sensitive to scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Staff time for diverse team reviews	Internal staff from governance, design, data science, legal and affected business units	Recurring	Number of AI systems in review, number of lifecycle stages covered and how often decisions are revisited
Documentation of team composition and decision records	Internal governance or compliance staff	Recurring	Depth of records required by internal policy and by any regulator or customer asking for evidence
Policy and hiring practice definition	Internal HR, legal and leadership, possibly external counsel	One-time, with periodic review	Current policy maturity, number of business units and the extent of changes to hiring criteria
Governance tooling or open-source tooling	Licensed vendors receive license fees; open-source tools carry no license spend but need configuration and upkeep	Licenses recur; setup is one-time	Choice between licensed and open-source tooling, integration with existing ticketing and inventory systems
External expertise for gaps in internal skills	External consultants, advisers or domain specialists billed by scope or time	Usually one-time for setup, recurring if used for ongoing reviews	Internal skill gaps in demographic, domain or regulatory expertise, and how many decisions need outside input
Training for staff who sit on review teams	Internal training budget or external training providers	One-time for onboarding, recurring for refreshers	Team size, staff turnover and the number of disciplines represented on the team
Independent assessment or audit sampling	Independent auditors or assessors, not DeployOpen, when an assurance report is required	Recurring at each assessment cycle	Whether a customer, contract or regulator requires independent evidence and how many records are sampled
Change management after the NIST AI RMF revision	Internal policy owners and any outside advisers engaged for updates	Recurring as the revised text is published	Whether the organization maps its wording to the revised AI RMF once NIST publishes it

Who owns diverse review, who can help and where the auditor stops

Your organization owns GOVERN 3.1 in full. Decisions about mapping, measuring and managing AI risks across the lifecycle must be informed by a team that reflects demographics, disciplines, experience, expertise and backgrounds, and only your leadership can decide who sits on that team and how their input counts. No outside party can accept that accountability on your behalf.

Reviewer composition: Decide which disciplines (legal, security, data science, domain operations, affected-user representation) must review each AI system before go or no-go decisions.
Hiring and role policy: Set the policies that promote interdisciplinary roles and demographic and domain diversity, as the Playbook suggests.
Escalation rights: Confirm that staff can raise concerns without fear of reprisal and that those concerns reach a documented decision owner.
Final risk decisions: Keep the accept, mitigate or stop decision with named executives, not with a consultant or tool.
Revision tracking: Record how your review policy will change if NIST revises GOVERN 3.1 following the July 2025 AI Action Plan.

Check that every reviewer, their role and their decision rights appear in a dated record that an assessor can read without help from you.

Common gaps in diverse team decision-making and how to close them

GOVERN 3.1 asks that decisions about mapping, measuring and managing AI risk are informed by a diverse team across the lifecycle. The gaps below are the ones that most often leave that outcome on paper only, and each one has a fix an assessor can check.

Policy names diversity without reviewers

A governance policy may say that AI risk decisions draw on diverse perspectives but never name who reviews what. The Playbook suggests defining policies and hiring practices that promote interdisciplinary roles and demographic and domain diversity, so the policy should assign reviewer roles by decision type. Check that each high-impact AI decision has named reviewers from more than one discipline, with their roles written into the approval procedure rather than left to the policy's general wording.

Reviews limited to one function

When engineering alone signs off on model risk, the team that built the system is also the only team judging it. Add reviewers from legal, privacy, security, domain operations and affected business units, matched to the AI actor categories in Appendix A of AI 100-1, which include Governance and Oversight and AI Design. Check the review record for at least one reviewer who did not build the system and who can challenge its design assumptions.

No safe route for staff concerns

Staff who notice a problem with an AI system often stay silent if they fear reprisal or do not know who to tell. The Playbook suggests letting staff raise concerns without fear of reprisal, so the fix is a documented intake channel, a named owner who triages each concern, and a record of what happened to it. Check whether concerns raised in the last review cycle led to a documented decision, including decisions to take no action.

No external expertise for missing skills

Small teams often lack the statistical, fairness, accessibility or domain expertise needed to judge a model, and the gap goes unnoticed. The Playbook suggests seeking external expertise where internal expertise is lacking, so the fix is a written trigger for bringing in outside reviewers and a budget line for it. Check the skills inventory against the mapped risks and confirm that each missing skill has a named external source or a documented reason it is not needed.

Decisions made without records

Verbal approvals and chat threads leave no evidence that a diverse team informed the decision. Record who reviewed each AI risk decision, which disciplines and backgrounds they represented, what dissent they raised, and how the owner responded. Keep these records with the AI inventory entry for the system. An assessor testing GOVERN 3.1 will look for this trail first, so confirm that every production system has at least one review record dated before deployment.

Unclear review of vendor AI

Third-party AI often arrives with its design decisions already made, and internal teams may assume the vendor's testing covers their context. Assign internal reviewers to vendor AI decisions the same way as built systems, and ask the vendor for the information those reviewers need about training data, evaluation and known limits. The Generative AI Profile lists no suggested actions for GOVERN 3.1, so check the vendor contract and onboarding file for named internal reviewers and a record of their review.

Questions buyers ask about GOVERN 3.1 and diverse review

Is GOVERN 3.1 mandatory under the NIST AI RMF?

No. The NIST AI RMF is a voluntary framework, and NIST says neither private nor public sector organizations are required to use it. GOVERN 3.1 is an outcome in the framework's Govern function, so it binds an organization only if a contract, customer requirement or specific law makes the framework or its outcomes binding. Some US state laws name the AI RMF, so check whether any law that applies to your organization refers to it and what that law expects. Your legal or compliance team should confirm the obligation in writing before you scope any work.

Is there an NIST AI RMF certification I can get for GOVERN 3.1?

No. NIST does not certify, accredit or endorse organizations that use the AI RMF, and it describes no conformity assessment program for the framework. Any firm offering an AI RMF certificate should be asked which body accredits it and what standard it tests against. What you can produce is internal evidence showing how diverse review informs AI risk decisions, which an independent assessor may examine if a customer or regulator asks for it. DeployOpen prepares systems, documents and evidence for such reviews, but it does not issue audit reports or certificates.

Will the diversity wording in GOVERN 3.1 change?

It may. The July 2025 America's AI Action Plan recommends that NIST revise the AI RMF to remove references to diversity, equity and inclusion, among other terms. NIST says AI RMF 1.0 is being revised as part of that plan and has not published a revised version as of October 2026. GOVERN 3.1 remains in the published 1.0 text. Confirm the current status directly with NIST on its AI Risk Management Framework page before you write policy language, and design your review process around the underlying goal of informed, multi-perspective risk decisions so it survives any wording change.

What drives the effort of a diverse review process for AI risk?

The effort depends on how many AI systems you run, how many risk decisions each one generates, and how many disciplines your current teams already cover. Organizations with a small number of low-impact systems typically need a lighter process than those with many high-impact systems across several business units. Other drivers include whether you must recruit for missing expertise, how much documentation your reviews require, and whether you rely on external experts for areas such as legal, privacy or affected-community perspectives. Ask any provider to break its quote into policy design, role mapping, review workflow, training and evidence collection.

Can our own staff set up diverse team decision-making for AI risk?

Often yes, provided someone with governance authority owns the work and the people involved can give it time. The Playbook suggests defining policies and hiring practices that promote interdisciplinary roles, letting staff raise concerns without reprisal, and seeking external expertise where internal expertise is lacking. Internal teams can draft these policies and set up review records. Outside help is most useful for gap analysis, facilitating reviews in unfamiliar domains, or checking that the process produces traceable decisions. Whatever you choose, the accountable executive and the review records must remain inside your organization.

What does GOVERN 3.1 require from staff day to day?

It requires people from enough different backgrounds to be in the room when AI risk decisions are made, and it requires that they can speak up. In practice, this means documented criteria for who reviews a decision, clear authority for each reviewer, a way to record dissent or concerns, and access to expertise outside the immediate AI team when needed. Staff also need enough domain knowledge to challenge design and testing choices. Skills and proficiency for human roles are a separate outcome, covered under GOVERN 3.2, so keep the two distinct in your documentation.

How long does preparing diverse review for AI risk usually take?

No reliable duration applies across organizations, so treat any timeline as unconfirmed until you have a written scope. The main factors are the number of AI systems in scope, whether roles and policies already exist, how much recruiting or training is needed, and how many approvals your governance structure requires. Ask a provider to state its assumptions about each factor, the deliverables it will produce, and which steps depend on decisions only your organization can make. Confirm any expected end date with your internal governance owner before committing.

How DeployOpen prepares evidence for GOVERN 3.1

DeployOpen starts every engagement with a written scope that names the AI systems in question, the decisions the team must document, the people who sit on the review group, and the deliverables and timelines both parties accept before work begins. For GOVERN 3.1, that scope usually covers how the organization records who informed each AI risk decision across the lifecycle and what each person's discipline, experience and background contributed. Because the organization owns its controls and decisions, the scope also states which internal roles approve the work and which decisions remain with the organization's own leadership. Fixed-scope work is priced from that written scope, so the reader should expect the quote to follow the decisions and systems listed in it.

Within that scope, DeployOpen prepares the operating pieces an assessor will ask to see. Typical work includes a decision register that records each AI risk decision, the date it was made and the reviewers involved, along with templates for documenting team composition, interdisciplinary role assignments and the process for seeking external expertise where internal expertise is lacking. Where the organization runs its platforms on its own infrastructure, these records can be stored in the organization's existing ticketing, document or GRC tools, configured inside its own accounts or data centers. The organization decides whether to adopt these templates, changes them to match its policies and confirms that they reflect how decisions are actually made.

DeployOpen does not issue audit reports, attestations or certifications, and no AI RMF certification exists. Independent assessors, auditors or internal audit functions decide whether the evidence shows what the organization says it does. Before engaging, ask the implementation partner to confirm in writing which artifacts it will produce, which remain the organization's responsibility, and how review sign-off is recorded. Confirm also whether the organization's own review cycle, including any changes made while the NIST AI RMF is being revised, is built into the templates so the evidence stays current.

GOVERN 3.1 Diverse team decision-making