GOVERN 2.1 roles and responsibilities for AI risk

What GOVERN 2.1 asks for and why AI risk roles stall

If an auditor, a customer questionnaire or an internal review is asking who owns AI risk, the answer has to be written down and understood across the organization. GOVERN 2.1 is the NIST AI RMF outcome that covers this: roles, responsibilities and lines of communication for mapping, measuring and managing AI risks are documented and clear to individuals and teams. NIST AI 100-1 is voluntary, and there is no AI RMF certification, so no outside body will issue a pass for this subcategory. What you can show is a documented allocation of responsibility that people actually follow, and a record that it was reviewed.

Ownership of AI risk is hard to pin down because AI work is spread across data science, product, procurement, security, legal and the teams that run the system after launch. Each group often assumes another one holds the risk decision, and a model reaches production with no named owner for its impacts. The fix starts with an inventory of who does what today, including vendors and business units that buy AI tools without involving IT. Confirm with your own leadership which roles already exist on paper and which are only implied by habit.

The NIST AI RMF Playbook suggests defining AI risk roles for boards, senior management, AI audit, product and project management, design, development, testing, procurement, impact assessment and oversight functions. Use that list as a checklist of gaps rather than a template to copy. For each role, record who decides, who is consulted, who is informed and how issues escalate between them. Illustrative example: a procurement team approves a third-party model without telling the team that will operate it, and no one has the authority to stop the rollout. A short written role map would have shown the gap before go-live.

How an assessor tests GOVERN 2.1 roles

This table compares five things an assessor checks for GOVERN 2.1, with the evidence requested and the findings that most often appear. Read each row as a test step: the evidence is what you should have ready, and the common finding is what usually causes the gap. Because NIST issues no certification, the assessor is usually an internal audit team, a customer's reviewer or an independent reviewer, and the organization owns the conclusion.

Test area	Evidence requested	Common findings
Role definitions exist and are approved	Approved AI risk role descriptions, version history, and sign-off by the body that owns AI governance	Roles are written but never approved, or approved versions differ from the ones in use
Named owners for a sample of AI systems	Inventory entries for sampled systems showing a named owner, backup owner and the role they hold	Roles defined but not assigned, or one person listed as owner for many systems
Owners understand their duties	Interviews with sampled owners, onboarding records, and examples of duties performed in the last review cycle	Owners cannot describe their duties or the decisions they must escalate
Communication paths for incidents and performance	Escalation procedure, contact lists, a sample incident or performance report and proof it reached the named recipients	Procedure exists but reports go to a shared mailbox, or downstream stakeholders are never told
Separation of development and testing	Access rights, approval workflow and test sign-off records showing that the people who build a system do not approve their own test results	Same engineers build, test and release a system, with no record of independent review
Conflicts of interest recorded	Conflict-of-interest register, declarations by role holders, and records of how each conflict was managed or removed from the decision	Register is empty for every reviewer, or declarations were never updated after a role change

How to build the AI risk role register

This sequence turns GOVERN 2.1 into a documented, approved set of AI risk roles, owners and communication paths that the organization can show to an assessor, a customer or a regulator. The organization makes every assignment, and the register is the record of those decisions.

Inventory AI systems and the teams that touch them
Start by listing every AI system in use or in development, including systems bought from vendors, and the teams that build, test, buy, deploy, monitor or approve them. Record which business unit owns each system and which external parties supply data, models or software. Work from procurement records, the engineering backlog and the AI inventory maintained under GOVERN 1 where one exists. The output is a team-to-system matrix that shows where AI risk work currently happens. It is done when each system has at least one named team and each team appears against the systems it touches.
Define roles for each Playbook function
Using the AI RMF Playbook's list for GOVERN 2.1, write a role charter for each function it names: boards, senior management, AI audit, product and project management, design, development, testing, procurement, impact assessment and oversight. Describe what each role decides, reviews or reports, and which AI actor category it sits in. Mark where one person would hold two roles and note whether that combination is acceptable. The output is a set of role charters, one per function, each with scope, responsibilities and the systems it covers. It is done when every function has a charter that a reviewer can read without asking the author for context.
Separate development from testing
Review the role charters for any person or team that both builds an AI system and signs off its test results. The Playbook suggests separating AI development from AI testing so that course correction can happen independently. Where a small team cannot fully separate the two, record the compensating control, such as a second reviewer outside the build team or an independent assessor for high-impact systems. Also identify conflicts of interest, such as a team that approves its own vendor selection, and write the prevention rule next to each one. The output is a separation and conflict register. It is done when each development and testing pairing is either separated or has a recorded compensating control approved by a senior owner.
Assign named owners and deputies
For each role charter, the organization names a specific individual as owner and at least one deputy who can act when the owner is unavailable. Names are a decision for leadership and cannot be delegated to an implementation partner or consultant. Check that each owner has the authority, budget and time the charter describes, and confirm that deputies have received the same role briefing. The output is a named-owner table listing role, owner, deputy and the date of the last confirmation. It is done when no role is left as a team name alone and every owner has accepted the assignment in writing.
Draw the lines of communication
Map how AI risk information moves: from the teams that build and operate systems, through the owners, up to senior management and the board, and out to customers, vendors and affected parties where relevant. Include escalation paths for model failures, safety or security incidents, and complaints from users. The GOVERN 2.1 generative AI actions also call for procedures for reporting incidents and performance to AI actors and downstream stakeholders, and for protections for people who raise concerns, so include a route for reports that bypasses the normal reporting line. The output is an escalation and reporting map with a named route for each incident type. It is done when a tabletop walk-through of one hypothetical incident reaches the right owner without gaps (illustrative test).
Record decision rights in a RACI matrix
Build a RACI matrix that lists the key AI risk decisions, such as approving a new use case, accepting a residual risk, pausing a deployed model or accepting a third-party AI service, and marks who is Responsible, Accountable, Consulted and Informed for each. Keep exactly one Accountable party per decision. Link the matrix to the escalation map so that every decision has a defined path when the usual owner disagrees or is unavailable. The output is the RACI matrix with a short note on each decision that needs a senior sign-off. It is done when every decision has one Accountable party and the matrix agrees with the role charters and the escalation map.
Approve, publish and version the register
Gather the role charters, owner table, separation register, communication map and RACI matrix into one register. Ask a senior leader with authority over AI risk to approve it, and record the approval, date and version. Publish it in the internal documentation system where staff can find it and keep a change history so that reassignments can be traced. Confirm with the owners that the published version matches what they agreed to. The organization owns this approval. An implementation partner can draft the register, set up the document structure and version history, and prepare the evidence pack, but it cannot approve the register or name anyone to a role. The output is an approved, published and versioned register. It is done when every owner can confirm their entry and an assessor can trace each role to an approval record.

Separating AI development from testing and handling conflicts of interest

The Playbook suggests that organizations separate AI development from AI testing so that course correction can be made independently. In practice, the person or team that builds a model, prompt chain or AI feature should not be the only party that decides whether its test results are acceptable. Document this as role terms rather than as a diagram: name the testing role (for example, an independent evaluation lead or a second-line reviewer), state which decisions that role owns, and state which of them the builder may not make alone. In a small team, the same person can hold both roles on different systems, but the record should show that a different person reviewed the test results before release. Confirm with your own counsel and risk owners how this maps to your existing segregation of duties, since the NIST AI RMF does not prescribe a specific reporting line.

Conflicts of interest need explicit rules for three decisions. First, who may approve a system the approver helped build. Second, who may sign off a risk assessment that the signer authored. Third, who may accept a residual risk on a system that earns that person's team a bonus or a delivery milestone. A workable default is that no individual approves their own build or their own risk assessment, and that any exception is recorded with the named approver, the reason, the compensating check, the expiry date and the next review. Keep the exception register in the same system as your AI inventory so auditors and internal reviewers can trace each decision. The organization sets the threshold for exceptions based on its size and risk profile, and should be able to explain that threshold to an assessor.

GOVERN 2.1 in NIST AI 600-1, the Generative AI Profile, extends these roles in two directions. It asks organizations to set roles and procedures for communicating generative AI incidents and performance to AI actors and downstream stakeholders, and to create protections for whistleblowers who report concerns about these systems. Map these to named roles: who triages a generative AI incident, who informs downstream customers, and how staff raise concerns without going through the builder's chain of command. How much formality is needed depends on the size of the organization, the number of generative AI systems in use and the sectors it operates in, and that decision belongs to the organization. Record the decision and the reasoning so it can be reviewed later.

Which evidence shows AI risk roles are documented and clear

GOVERN 2.1 is met when someone outside the AI team can see who decides what, who escalates to whom, and where conflicts are recorded. The cards below name the artifacts an assessor or customer is likely to ask for, and how each one stays accurate between reviews.

Approved role charters

A role charter states the purpose, authority and decision rights of each AI risk role, including boards, senior management, product owners, developers, testers, procurement and impact assessment staff. It matters because GOVERN 2.1 asks that roles be clear to individuals and teams across the organization. Check that each charter names a holder, has been approved by someone with authority over the role, and is reviewed when the organization restructures or adds an AI system. Confirm the review cadence with your own governance policy.

RACI matrix per AI system

A RACI matrix maps each lifecycle activity for a specific AI system (intended use, data sourcing, testing, go or no-go, monitoring, incident response) to who is responsible, accountable, consulted and informed. Per-system matrices show that roles were applied to real systems rather than only described in policy. Check that every activity has exactly one accountable party. Update the matrix whenever a system changes owner, vendor or risk tier, and record the date of each revision.

Escalation and communication procedure

The escalation procedure defines who receives AI risk reports, within what internal path, and how issues reach senior management or the board. It also covers communication with downstream stakeholders and the channels used for generative AI incidents and performance concerns, as NIST AI 600-1 describes. Check that the procedure names roles rather than individuals only, and that a tested contact path exists outside the AI team. Review it after each material incident and at a set interval you define.

Conflict-of-interest register with approvals

A conflict-of-interest register records where a person who builds, tests or approves an AI system has a competing interest, such as a bonus tied to launch dates or a reporting line into the team they assess. Each entry needs a described conflict, a mitigation, and a sign-off from someone independent of the conflict. Assign a named owner for the register and require entries to be reviewed when staffing or vendor relationships change, not only at audit time.

Separation-of-duties record for development and testing

The Playbook suggests separating AI development from AI testing so that course correction can be done independently. The separation-of-duties record shows, for each release, which people built the system, which tested it, and who approved the release, with any exceptions justified in writing. Check that tester access to production or training data is limited to what testing requires. Refresh the record at each release, since team changes often break separation without anyone noticing.

Dated change history of role approvals

A dated change history records every revision to role charters, RACI matrices and the register, with the date, the author, and the approver for each change. Version control in a documentation system lets an assessor compare any two versions and see who changed what. Check that approvals are recorded against the specific version in force at the time of each AI decision, so the organization can show who was accountable on a given date. Confirm your retention period with your records policy.

What meeting GOVERN 2.1 costs in money and effort

This table breaks down the cost components of documenting AI roles, responsibilities and lines of communication under GOVERN 2.1, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No supplied source gives a price or duration, so use the drivers and quote questions to compare written proposals.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up
Executive and manager agreement on roles	Board, senior management and AI system owners, mostly internal time	One-time, then recurring at each reorganization	Number of AI systems, business units and decision bodies that must agree on ownership
Legal and HR review of role charters	Internal counsel, HR, or outside employment and privacy counsel if engaged	One-time, with periodic review	Jurisdictions where staff work, union or works council rules, and reliance on whistleblower protections
Documentation tooling and licenses	Software vendor or none if self-hosted open source is used	Recurring for commercial licenses; one-time setup for self-hosted tools	Number of editors and readers, and whether hosting is internal or vendor-managed
Engineering time to link roles to tickets and repositories	Platform or DevOps engineers, internal or an implementation partner under a written scope	One-time build, then recurring maintenance as tools change	Number of systems in the ticketing, source control and approval workflows that must reflect ownership
Upkeep of the roles register	Designated owner in the AI governance or risk function	Recurring	Frequency of team changes, third-party onboarding and new AI systems entering production
Separation of development and testing duties	Engineering leads and QA, often requiring extra reviewers or tooling	One-time design, recurring staffing effect	Team size; small teams may need compensating reviews rather than fully separate staff
Independent review or assessor time	Internal audit, an independent assessor, or a certification body if an assessment is commissioned	Periodic	Scope of the assessment and number of AI systems sampled. NIST does not certify or validate AI RMF use.

Open-source tools that can hold role and evidence records

GOVERN 2.1 is satisfied by documents people can find, trust and date, so the question for an open-source tool is whether it keeps a defensible record of who wrote a role charter, what changed and when. XWiki can serve as that record. Every change to a page is kept under version control, recording what changed, when and by whom, and users can compare any two versions and roll back to an earlier one. A role charter for the AI risk committee, the accountable owner for each AI system, or the separation between development and testing can live on a page where an assessor or internal auditor sees the history of each edit, not only the current text. XWiki is licensed under LGPL-2.1-or-later, so the licence terms for hosting and modifying it should be confirmed with counsel before it becomes part of the evidence chain.

BookStack, licensed under MIT, suits the operational side of role documentation. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets a team keep a shelf for AI governance where only the AI risk function can edit role definitions, while product and development teams can read them and comment on their own pages. Before relying on it, confirm that the permission model matches your split between owners, reviewers and readers, and test that a role change is reflected in what each account can see. BookStack does not, by itself, keep the change history that XWiki provides, so decide which tool holds the authoritative version.

CISO Assistant, licensed under AGPL-3.0-only, is the most structured of the three. Its README states that it ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and that it runs audits and compliance assessments with automatic mapping between frameworks. Confirm in the current release whether NIST AI RMF is included as a framework or whether you would need to build the GOVERN 2.1 subcategory structure yourself. Also confirm how the AGPL-3.0-only terms apply if you modify the tool or offer it to users over a network, and whether your counsel is comfortable with that obligation for an internal governance system.

Who does what for AI risk roles: your team, a partner and the assessor

Your organization owns every decision about who is accountable for AI risk. Leadership decides which roles exist, who holds them, how they escalate and where development ends and testing begins. These decisions belong to named people, not to a document or a vendor. A partner can draft material, but the accountable owners must read it, change it where it does not match how the business works, and approve it. Your team also runs the roles in practice, including escalations, conflict-of-interest reviews and the handoffs between product, development, testing and procurement.

Role decisions: Assign named owners for boards, senior management, product and project management, development, testing, procurement, impact assessment and oversight, and record who holds each role.
Charter approval: Approve every role charter and lines of communication, and confirm they match the reporting structure in your organization.
Separation of duties: Decide how AI development and AI testing are kept apart so that testing staff can challenge releases without reporting to the people who built the system.
Conflict-of-interest rules: Set the rules for identifying and handling conflicts, and decide who reviews them.
Escalation and incidents: Run escalation paths and the communication of AI incidents to internal and external stakeholders.

Before accepting any partner draft, confirm that each named role has an owner who has agreed to it in writing.

Where AI risk role programs usually fall short

Most organizations can produce a roles document, but the document often fails the first time a model is bought, tested or escalated. The gaps below cluster around ownership, independence and change, which are the points where GOVERN 2.1 is tested in practice.

Roles defined but not assigned

A RACI table that lists functions such as AI risk owner or model validator, without naming the person who holds each role, gives an assessor nothing to test. Each role should map to a named individual, a deputy and a stated scope of decisions. Check whether the people named in the document know they hold the role and whether they have accepted it in writing. Close this quarter by replacing every function label with a named person and a backup.

No owner for vendor AI

When a vendor supplies an AI system, teams often assume the vendor owns its risk, while the buying business owns the outcomes. GOVERN 2.1 expects someone inside the organization to be accountable for every AI system in use, including purchased ones. Check the AI inventory for systems where the internal owner field is empty or names a procurement contact only. Close this quarter by assigning an internal business owner and a technical owner to each vendor AI system.

Testers reporting to developers

If the staff who evaluate a model report to the team that built it, their findings can be overruled by the people whose work they are checking. The Playbook suggests separating AI development from AI testing so course correction can be independent. Check the reporting line of every tester and whether a test failure can be closed by the development manager alone. Close this quarter by documenting a reporting path for testers that bypasses the development chain for release decisions.

Conflicts of interest unrecorded

Staff who approve a system may also earn bonuses tied to its launch, or sit on a review board for a product their team sells. The Playbook asks organizations to identify and prevent conflicts of interest, but few registers capture them. Check whether any register exists and whether reviewers sign a declaration before each decision. Close this quarter by creating a conflict-of-interest register for AI reviewers and requiring a declaration before each approval.

Escalation skipping the risk owner

Incident reports often go from engineers to product leads or executives without reaching the person accountable for AI risk. GOVERN 2.1 covers lines of communication, so the route must be defined, not assumed. Check incident tickets from the last year to see whether the risk owner appears in the chain, and whether any escalation bypassed them. Close this quarter by writing a single escalation path with the risk owner as a required step and testing it with one tabletop exercise.

Charters that go stale

Role charters written before a reorganization often name teams that no longer exist or reporting lines that have changed. Assessors look for evidence that the documentation reflects current practice, and a stale charter shows that the review step is missing. Check the date of the last review and compare names against the current org chart. Close this quarter by setting a review trigger tied to every reorganization and updating the charter with current names.

Questions buyers ask about GOVERN 2.1 roles

Is GOVERN 2.1 mandatory, and is there a certificate for it?

No. The NIST AI Risk Management Framework is voluntary, and NIST does not require private or public organizations to use it. There is also no AI RMF certificate. NIST does not validate or endorse any organization's use of the framework, and it runs no accreditation or conformity assessment program. GOVERN 2.1 asks that roles, responsibilities and lines of communication for mapping, measuring and managing AI risks be documented and clear across the organization. Your obligation to do this comes from your own governance expectations, contracts or regulators that cite the framework, so confirm with each of them which version and scope they expect. Any outside assessment should be scoped in writing with an independent assessor.

How much effort does documenting AI risk roles take, and what drives it?

The effort depends mainly on how many AI systems you run, how many teams build, test, buy and operate them, and how many roles already exist in your policies. The NIST AI RMF Playbook suggests defining AI risk roles for boards, senior management, AI audit, product and project management, design, development, testing, procurement, impact assessment and oversight. Each of those functions adds a mapping exercise: who decides, who reviews, who signs off and who receives incidents. Costs are mostly staff time, which is one-time for the initial role catalog and recurring for updates after reorganizations or new AI systems. Ask any provider to price the inventory of systems, the number of interviews, and the review cycle in a written scope.

Can a small team document AI roles in-house?

Often yes, provided someone with authority owns the work and the team can name the people behind each role. A small organization can start with a one-page role matrix, a list of AI systems, and a short escalation path to a named senior owner. The harder part is separating development from testing when the same few people do both. The Playbook suggests separating AI development from AI testing so course correction can be independent, and identifying conflicts of interest. If one person must perform both functions, document the compensating review and who performs it. Confirm the approach with your assessor before relying on it.

What does GOVERN 2.1 need from executives and managers?

It needs executives to authorize the role model and managers to confirm that the roles match how work actually happens. Executives approve the accountability structure and the decision rights for risk acceptance, while managers provide the day-to-day assignments for teams. Their time is usually spent reviewing the matrix, resolving overlaps and signing off on escalation paths. The generative AI profile, NIST AI 600-1, adds suggested actions for setting roles and procedures for communicating AI incidents and performance to AI actors and downstream stakeholders, and for creating whistleblower protections. Those decisions cannot be delegated to a vendor, so schedule them as named tasks with owners.

Can an outside partner assign roles for our organization?

No. Your organization owns its roles, responsibilities and decision rights. An implementation partner can help draft the role model, document it in your systems and prepare evidence, but the assignments must be made and approved by your own leadership. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and only an independent assessor can issue an opinion on your program. When you scope outside help, ask the provider to state in writing which decisions remain with your staff.

How would an assessor test GOVERN 2.1?

An assessor would look for evidence that roles are documented, approved and known to the people who hold them. Typical evidence includes a current role and responsibility matrix, the AI system inventory linked to owners, escalation and communication procedures, records showing that the matrix was reviewed, and examples of decisions that followed the defined paths. Illustrative test: the assessor picks an AI system, asks who approved its risk decision, and checks that the named person holds the documented role. Confirm the testing approach and evidence format with your assessor before the review starts.

How long does it take to document AI roles and lines of communication?

The timeline depends on scope, the number of AI systems and teams, and how quickly leaders can agree on decisions. No supplied source gives a duration for this work, so treat any figure from a vendor as an estimate to verify. Plan for separate phases: inventorying systems and teams, drafting the matrix, reviewing it with executives and managers, and publishing it with a review date. Recurring work includes updating roles after reorganizations and reviewing the matrix on a fixed schedule. Ask any provider for milestones and dependencies in writing before work starts.

How DeployOpen prepares AI risk role evidence

DeployOpen plans and builds the systems that hold AI risk role documentation, communication channels and separation-of-duties records inside your own infrastructure. The organization still owns its roles and decisions, and an independent assessor or certification body would be the party that tests or certifies them.

How we scope

Engagements are fixed-scope, with the roles, documents and tools in scope agreed in writing before work starts.
The written scope lists which AI actor roles from GOVERN 2.1 are covered, such as governance, product, development, testing and procurement.
Scope also records which platforms hold role documentation and which business units or AI systems the documentation applies to.

How we build

We deploy self-hosted wiki and documentation platforms in your environment with version history on role and responsibility pages.
We configure role-based permissions so development, testing and approval rights are assigned and visibly separated.
We set up a framework register, such as CISO Assistant, to track role assignments and map them against the frameworks you adopt.

How we hand over

You receive the configured platforms, permission matrices and role documentation templates with an administrator guide.
Handover includes a record of the scope, the configuration decisions made and the owners responsible for each role page.
Documents are delivered in formats your team can maintain, so updates to roles and communication paths stay under your control.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retainers can cover periodic reviews of role assignments, permission drift and changes to conflict-of-interest records.
Before any assessment, ask your assessor which evidence formats and review cycles they expect for GOVERN 2.1 records.

GOVERN 2.1 Roles, responsibilities and lines of communication