What GOVERN 3.2 asks for when people and AI work together
When a customer, contract or regulator asks how humans control your AI, the answer is GOVERN 3.2 of the NIST AI RMF. It is a voluntary outcome, not a requirement, and it asks that your policies define and differentiate the roles and responsibilities people hold in human-AI configurations and in oversight of AI systems, with proficiency standards and training for operators and overseers. No certificate exists for it: NIST does not validate or endorse any organization's use of the framework, so any party offering an AI RMF certificate is selling something NIST does not recognize. What you can show is a documented role model, the evidence that people hold those roles, and records that the model works in practice. The risk is concrete. AI 100-1 Appendix C notes that human-AI configurations range from fully autonomous to fully manual, and that in some tasks, such as perceptual judgment, the AI side of the interaction can amplify human biases. In practice this shows up as automation bias, where reviewers accept outputs without checking them, and as unclear accountability, where a decision is made by a model, approved by a reviewer and owned by nobody. Roles are hard to make specific because the same system may sit at different points on that range for different tasks, and the human's authority to override it is often not written down. Where the AI makes a low-stakes recommendation and a person signs off on a high-stakes one, the two roles need different definitions. Start by mapping each AI-assisted task to a point on the autonomy range, then name the human role at that point: who operates the system, who reviews its outputs, who can override or stop it, and who answers for the outcome. Write proficiency standards for each role, such as the training completed and the cases a reviewer must be able to handle before taking the role. Confirm with your own assessor which evidence they will sample, since NIST publishes no assessment procedure for this outcome. Assessment-ready records include role descriptions, training completion, override logs and the risk information you track about each configuration, all of which must be retained and version-controlled.
Which AI systems, roles and teams fall under GOVERN 3.2
GOVERN 3.2 applies wherever a person and an AI system share a task, whether the person reviews, overrides, operates or monitors the output. The cards below set out the scoping decisions that determine which systems and teams own the human role definitions, proficiency standards and training that this outcome asks for.
Systems with human review or override
Any AI system where a person can accept, change or reject the output falls under GOVERN 3.2. The scope question is whether the review is real: a reviewer who approves most outputs without reading them still shapes the human-AI configuration. Record the decision point, the reviewer role, the information the reviewer sees and the authority to override. Check whether the override path is tested, not only documented.
Generative AI interfaces
Generative AI interfaces put staff and customers in direct contact with the model, so the human role is less fixed. NIST AI 600-1 ties GOVERN 3.2 actions to acceptable use policies for generative AI interfaces, including criteria for queries an application should refuse. Confirm who writes those criteria, who can change them, and whether users are told when they are interacting with generative output.
Third-party models operated by staff
When staff run a vendor model inside their own workflows, the organization owns the human role even though it does not own the model. Scope these deployments by who operates the model, who reads its output and who decides what happens next. Vendor documentation may describe intended use, but the operator roles, proficiency standards and escalation paths are the organization's to define.
Teams that build and deploy
The Playbook tags GOVERN 3.2 with the AI Design actor category, so design teams are the first owners of the human role definitions. Builders decide what the human sees, what the interface asks them to confirm and where automation stops. Include product, data science and engineering leads in scope, and confirm that design decisions about oversight are written down before release.
Teams that operate and monitor
Operators and overseers carry the human role day to day, and they need proficiency standards and training that match the system's risk. Scope in the staff who run queues, approve outputs, watch dashboards and handle escalations, including contractors and shared service teams. Check that each group has a named training record and that monitoring teams can explain how they would detect a failure of the human review step.
How an assessor tests human roles in AI systems
No assessor tests GOVERN 3.2 on behalf of NIST, because NIST does not certify or validate anyone's use of the AI RMF. An independent auditor or assessor, engaged by the organization, tests whether the organization's policies define and differentiate human roles in human-AI configurations and in oversight, and whether those definitions match what happens in day-to-day operation. The organization owns the policy, the role assignments and the training program. The assessor only forms and reports an opinion, and only the assessor issues any report. Confirm with the assessor in advance which standard or internal criteria the engagement will be measured against, since the AI RMF itself has no conformity assessment procedure.
A typical test starts with a sample of AI systems drawn from the organization's inventory. For each system, the assessor traces the documented role definitions (for example, who may operate the system, who reviews its outputs, who may override or deactivate it) to the access rights actually granted in identity and application systems, to the training and proficiency records for those people, and to the monitoring or escalation logs that show overseers acting on the system's behavior. Gaps usually appear where a role exists in the policy but no account carries it, or where an operator has broader rights than the role allows. Ask your team to produce this trace for each sampled system before the assessor arrives, so that mismatches are found internally first.
Interviews close the gap between paper and practice. The assessor asks operators and overseers to explain, in their own words, what the system is for, when they are expected to intervene, how they would recognize a failure, and what they would do next. Consistent answers that match the written procedure are strong evidence. Vague answers, or answers that depend on a single expert, are findings. The organization should decide in advance who will be available for interviews, what records they can point to, and how an assessor's observations will be tracked to closure with named owners and dates.
What assessors request and where findings usually arise
This table compares what an assessor typically tests for GOVERN 3.2, the evidence they ask to see, and the findings that appear most often. Read each row as a question an assessor will put to the organization, then check whether the evidence exists and is current. The main takeaway is that roles written in a policy do not satisfy the outcome unless named owners, records and training results show they operate.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Role definitions for human-AI configurations | Role and responsibility policy for each AI system, with named operators, overseers and escalation owners, plus the configuration each role applies to | Roles exist on paper but have no assigned owner for one or more AI systems, or the same person is listed as operator and sole overseer |
| Differentiation of operator and oversight duties | Responsibility matrix separating who uses or interacts with outputs from who monitors, overrides or can deactivate the system | Operators hold override authority without documented criteria, or overseers have no access to logs or outputs they are expected to review |
| Human-AI configuration risk tracking | Register of human-AI configurations (fully autonomous through fully manual) with risk notes, review dates and changes logged | Configuration changes, such as moving a task from manual review to automated approval, are not recorded or re-assessed |
| Proficiency standards for operators and overseers | Written competence criteria per role, such as required knowledge of model limits and known bias patterns, with sign-off records | Standards are generic statements with no measurable criteria, so no one can show who met them |
| Training completion | Training records per named role, dates, assessment results and refresh schedule tied to the role matrix | Training is completed by staff who are not in the role matrix, or records do not show the assessment result, only attendance |
| Generative AI refusal criteria (GV-3.2-003) | Acceptable use policy for each generative AI interface, listing query categories the application must refuse, and test results showing refusals work | Refusal criteria are not written down, or testing covers only the policy text and not the interface's actual responses |
| Generative AI threat modeling (GV-3.2-005) | Threat model for each generative AI system, with owner, review date and records of how findings fed into controls or oversight roles | Threat model was produced once at launch and never updated after model, prompt or data changes |
How to implement GOVERN 3.2 in sequence
This sequence turns GOVERN 3.2 from a policy statement into a working record of who does what with each AI system, how well they must perform, and how that is checked over time. Each step produces an artifact that the next step depends on, so the organization can show an assessor how its human roles were defined and kept current. The Playbook suggestions are a starting point to adapt, not a checklist to complete in order.
Inventory each AI system and its configuration
Start with the AI system inventory maintained under GOVERN 1, and record for each system where it sits on the range from fully autonomous to fully manual. Note which tasks a person initiates, reviews, overrides or can stop, and which tasks run without any human input. AI 100-1 Appendix C points out that the AI side can amplify human biases in some tasks, such as perceptual judgment, so flag those tasks now. Owners of each system confirm the entry. The step is done when every system has a documented configuration and no system is left without one.
Define human roles for each configuration
For each system, write down who uses it, who interacts with its outputs, and who monitors its behavior. Keep these roles distinct, because an operator acting on a recommendation and an overseer checking the system's performance need different authority, access and escalation paths. Product owners draft the roles, and risk or compliance leads review whether the separation holds for high-impact decisions. The output is a role matrix per system that names the function responsible for each role, not only individuals, so it survives staff changes.
Set proficiency standards for operators and overseers
Define the knowledge and skills each role needs before it can operate or oversee the system. Typical standards cover understanding the system's known limits, recognizing failure modes, knowing when to override or halt, and interpreting the outputs the system gives. The Playbook asks organizations to set these standards explicitly. Ask the business owner and the risk function to approve the standards together. The step is complete when each role has a written standard that a supervisor can check against a person's experience.
Build training that meets each standard
Map each proficiency standard to a training path, combining documentation, hands-on exercises on the system and scenarios that involve errors or unusual inputs. A learning platform such as Moodle can track completion, but completion settings should reflect the standard, not just attendance. Activity completion in Moodle can be set to mark an activity complete when a learner views it, when they receive a grade, or when they tick it manually, so choose the condition that matches evidence of competence. The output is a training record per person and role, with the standard it satisfies.
Record risk information for each human-AI configuration
Document the risks that arise from how people and the system interact, such as over-reliance on outputs, automation bias, unclear escalation or reviewers who cannot explain a decision. Record these in the same risk register used under MAP and MEASURE so they are tracked and not stored separately. For generative AI, the Generative AI Profile ties GOVERN 3.2 to the Human-AI Configuration risk and asks for acceptable use criteria and threat modeling. Risk owners sign off each entry. The step is done when every configuration has a linked, owned risk record.
Keep role and configuration changes under version control
Store the role matrices, proficiency standards and configuration records in a wiki or document system that keeps version history, so every change shows what changed, when and by whom. XWiki keeps this history for each page and allows comparison and rollback. BookStack can restrict who may edit each page through role-based permissions, which keeps approval rights separate from authoring rights. Confirm both features against the version you deploy. The output is an auditable change trail for each governance record.
Set the review cadence and trigger events
Agree on a scheduled review of each configuration, and on trigger events that force an earlier review, such as a material model change, a new user group, a significant incident or a change in the system's autonomy. Set the interval with the business owner and the risk function, and write it into the record. Confirm any review frequency required by an internal policy, a contract or a regulator before fixing it. The step is complete when each system has a named reviewer, a cadence and a list of triggers, and the calendar for those reviews exists.
What NIST AI 600-1 adds for generative AI interfaces
For GOVERN 3.2, the Generative AI Profile in *NIST AI 600-1* adds five suggested actions, GV-3.2-001 through GV-3.2-005, tagged to the risks Human-AI Configuration, Information Security, Harmful Bias and Homogenization, and CBRN Information or Capabilities. The two actions most relevant to an interface your staff or customers use directly are GV-3.2-003, which asks for acceptable use policies for generative AI interfaces including the criteria for queries the application should refuse, and GV-3.2-005, which calls for threat modeling of the generative AI system. Both are suggested actions, not mandatory requirements, and the profile does not prescribe how to write them. Treat the list as a starting point for deciding who owns each decision.
The refusal criteria are where human roles become concrete. Someone must decide which query categories are blocked, who can approve an exception, and which operator or overseer reviews refused and borderline sessions. A useful check is to confirm that each refusal category maps to a named owner, a documented escalation path and a record of overrides. The Human-AI Configuration risk in the profile applies here because users can over-trust fluent output, and the AI side of the interaction can amplify human judgment errors. The policy should say when a human must review a response before it reaches a decision, not only what the model is permitted to say.
Threat modeling under GV-3.2-005 should cover prompt injection, data leakage through the chat interface, and misuse by insiders as well as external users, since these are the Information Security concerns the profile ties to this subcategory. Ask the team responsible for the interface to name who approves the threat model, who re-runs it after a change to the model, prompts or connected data sources, and which findings reach the operators who handle escalations. Records of these reviews are the evidence an assessor will look for. Confirm the scope of these actions with your own risk owners and with the current text of the profile before adopting them as commitments.
Evidence that shows defined and trained human roles
GOVERN 3.2 asks for human roles that are defined, differentiated and trained, not just named in a policy. The cards below cover the records that show those roles exist, that people hold them, and that the roles are still accurate when someone checks. Each one needs an owner and a review cadence so the evidence stays current between assessments.
Role definition documents per system
A short role sheet for each AI system that states who uses it, who monitors its outputs, who can override or stop it, and who answers for its decisions. Tie each role to the human-AI configuration in use, since AI 100-1 Appendix C notes configurations range from fully autonomous to fully manual. Review each sheet whenever the system's configuration changes, and record the date and approver of every revision so the history can be shown.
RACI or role matrix
A matrix that maps each AI lifecycle task to one accountable person and the people responsible, consulted or informed. It shows where human oversight sits in practice, such as who signs off a model change or who reviews flagged outputs. Check that every role in the matrix matches a person on the current staff list, and that no task has two accountable owners. Reconcile the matrix against access records at each review.
Proficiency standards for operators and overseers
Written criteria that state what an operator or overseer must know and be able to do before working on a system, such as interpreting model confidence, recognizing a known failure pattern or applying the escalation path. The Playbook suggests setting these standards for both groups. Separate the standards by role, because an operator and an overseer need different skills. Update them when the system's risks or tooling change.
Training and completion records
Course content, assessment results and completion dates for each person in a defined role, linked to the proficiency standard they must meet. A learning management system can record completion automatically when a learner views an activity, receives a grade or ticks it manually, depending on the conditions the course sets. Confirm which trigger your course uses, because a view alone may not show proficiency. Schedule refresher training and track overdue records.
Access permissions by role
Exports of who holds which permissions in each AI system, documentation platform and review tool, with the role each permission traces back to. Access should follow the role matrix, so an overseer who can override outputs has the documented training and an operator cannot approve their own changes. Review these exports on a fixed schedule and after staff moves. Record every exception and its approver.
Records of human-AI configuration risk review
Dated reviews that assess the risks created by each human-AI configuration, including the chance that the AI side amplifies human bias in tasks such as perceptual judgment, and the team's response. Keep the records under version control so reviewers can see what changed, when and by whom. Confirm that each review feeds back into the role sheets and training standards, since a risk finding that changes no role is hard to defend.
What meeting GOVERN 3.2 costs in money and effort
This table compares the cost components of GOVERN 3.2 work, who carries each one, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal effort and to frame a written quote, since no fixed price applies to this outcome. The main takeaway is that the largest recurring costs come from keeping role definitions and operator training current as systems and staff change.
| Cost component | One-time or recurring, and who pays | Main cost drivers and how to contain them |
|---|---|---|
| Role design time | One-time at setup, then recurring at each review. Paid mostly through internal staff time, with optional consultant time. | Number of AI systems and human-AI configurations in scope. Reuse one role model across similar systems and document exceptions. |
| Proficiency standard development | One-time per role family, then recurring when systems change. Internal risk, HR and domain owners, with optional external support. | Number of distinct operator and overseer roles. Keep standards task-based so one standard covers several systems. |
| Training content and delivery | Content build is one-time. Delivery and refreshers are recurring. Paid as internal staff time or external course fees. | Number of operators, generative AI scope and course format. Build modules once and reuse them across teams. |
| Learning platform and licenses | Recurring. Commercial learning platforms bill per user or subscription. Open-source options such as Moodle carry no license fee for the software itself. | Number of learners and hosting model. Self-hosting the learning platform in your own infrastructure removes license spend but adds infrastructure and upkeep effort. |
| Evidence upkeep | Recurring. Internal compliance and operations staff, with platform costs for version history and access records. | Turnover of roles, frequency of configuration changes and the number of systems. Version-controlled documentation and role-based permissions reduce manual tracking. |
| External review and auditor sampling | Periodic. Paid to an independent reviewer or auditor. NIST does not certify GOVERN 3.2, so any external review is a voluntary engagement. | Scope of the review, number of samples requested and how ready the evidence is. Ask for the sampling approach and deliverables in writing before work starts. |
| Testing of human oversight in generative AI | Recurring. Internal red team time, or external testing if scoped in writing. Open-source probing tools such as garak carry no license fee. | Generative AI scope, number of applications and frequency of retesting. Confirm tool capabilities and licensing terms with each vendor before adoption. |
Who owns GOVERN 3.2, who helps and who assesses
Your organization owns GOVERN 3.2. The outcome asks that policies and procedures define and differentiate roles and responsibilities for human-AI configurations and for oversight of AI systems, and no outside party can decide those roles for you. Your leadership, risk function and the teams that build and run each system set the boundaries of human authority, the proficiency expected of operators and overseers, and the escalation paths when a person must override or stop a system.
- Role definitions: Name who uses, interacts with and monitors each AI system, and state what each role may approve, change or switch off.
- Proficiency standards: Decide the knowledge and skill an operator or overseer must show before taking on the role.
- Training ownership: Assign who designs, approves and refreshes the training, and who tracks completion.
- Risk decisions: Record which configurations are fully autonomous, partly supervised or fully manual, and who accepts the residual risk of each.
- Policy approval: Have the accountable executive sign the policy so the roles carry organizational authority.
Check that every role in your policy maps to a named person or position, and that each owner can explain the limits of their authority without referring to a document.
An implementation partner can prepare the documentation, workflows and technical evidence that show your roles are in use. DeployOpen, for example, prepares systems and evidence for assessments in your own infrastructure, but it does not decide your human roles or issue any assessment result. Work of this kind is commonly outsourced because it is time-consuming, and it is only useful once your leadership has settled the roles it documents.
- Documentation drafts: Write role descriptions, RACI tables and procedures from decisions your team has made and approved.
- Workflow configuration: Set up approval, review and override steps in the tools your teams already use.
- Access and permissions: Configure role-based access so that the system permissions match the documented roles, for example in wiki or knowledge base platforms with per-role permissions.
- Training records: Build course content and completion tracking, such as activity completion records in a learning management system.
- Evidence collection: Export version histories, access logs and test results that show roles were followed in practice.
Before engaging a partner, ask for a written scope listing each document, configuration and evidence item, and confirm that your team approves every role definition before implementation starts.
An independent auditor, assessor or certification body tests your controls and issues any report or certificate. The AI RMF has no certification program, so a conformity claim based on the framework comes from your own statement or from an assessment you commission, not from NIST. NIST does not validate or endorse any organization's use of the framework, so the assessor's role is to test your evidence against your own stated approach.
- Design review: Check that the role definitions are clear, approved and consistent with the risks you recorded.
- Operating tests: Sample real decisions and overrides to confirm people in the defined roles acted as documented.
- Training checks: Review proficiency standards and completion records for operators and overseers.
- Independence: The auditor must not write the policy, configure the workflows or train the staff it later assesses.
- Reporting: Only the assessor issues findings, and the assessor's reporting scope is set by the engagement agreement.
Confirm with any assessor which framework and evidence they will test against, and whether they accept self-assessment against the AI RMF or require a named external standard.
Where organizations fall short on human-AI oversight
GOVERN 3.2 asks organizations to define who does what when people and AI systems work together and when people oversee AI. The gaps below tend to appear together, because roles written only for the builder leave operators and overseers without standards, and training that is never tied to access leaves nobody able to show competence.
Roles written only for the builder
Many policies describe who builds and deploys a model but say nothing about the people who use its output, monitor it or can stop it. Close this by writing a role table for each AI system that names operators, overseers, system owners and escalation contacts, and states what each may approve, override or shut down. The Playbook suggests defining the human roles in using, interacting with and monitoring AI systems, so check that every role in that list has a named holder.
No proficiency standard for overseers
Organizations often assign oversight to a reviewer without stating what that person must know to judge the system's output. Set a written proficiency standard for each oversight role covering the system's known failure modes, the decisions the reviewer can make and the signs that the reviewer should escalate. AI 100-1 notes that the AI side of a human-AI interaction can amplify human biases in some tasks, so the standard should include recognizing automation bias, not only reading the output.
Training not linked to access
Training records often sit in an LMS while system access is granted by a separate ticket, so nobody can show that an operator was trained before using a system. Link the two: grant production access only after the required course is complete and recertify on a set schedule. Moodle can mark an activity complete when a learner views it, receives a grade or ticks it manually, so confirm which completion condition your assessment design requires before relying on it as evidence.
Human-AI configuration risk not tracked after deployment
Teams often record the human-AI setup at go-live and never revisit it, even as staff change, prompts are edited and users find new workarounds. Keep a configuration register for each system that lists who holds each role, which decisions require human sign-off and what changed and when. Version control on the register lets an assessor see how oversight evolved, and it should be reviewed after each material change to the system.
Permissions that do not match documented roles
A role written on paper can differ from what the platform actually allows, so an operator may be able to approve outputs they were only meant to review. Map each documented role to a platform role, then test the overrides on the shelf, book or page level in the documentation tool or the AI platform. Recheck the mapping whenever permissions are changed, and record the test results as evidence.
No tests of human-AI interaction risk
Oversight is rarely tested in practice, so organizations do not learn whether reviewers catch unsafe outputs or whether users can be steered into accepting them. Include overseers in adversarial testing and record which outputs they accepted or refused. For generative AI, the garak probe suite covers hallucination, toxicity and jailbreaks, and its hit log shows which attempts succeeded, giving the oversight team a concrete list of cases to review. Confirm coverage with your test scope before treating a run as complete.
Questions buyers ask about GOVERN 3.2
Can an organization get certified against GOVERN 3.2?
No. GOVERN 3.2 is an outcome in the NIST AI RMF, and the framework has no certification, accreditation or conformity assessment program. NIST states that it does not validate or endorse any individual organization's use of the AI RMF. What a customer or regulator can accept is evidence that your documented roles, oversight duties and training records exist and operate. Ask any firm offering a GOVERN 3.2 certificate what body issued it and under what program, because the framework does not provide one.
How long does defining human roles for AI systems take?
The duration depends on how many AI systems are in scope, how many teams touch them, and how much of the role model already exists in other policies. Effort is driven by the number of human-AI configurations, from fully autonomous to fully manual as described in NIST AI 100-1, by how many operators and overseers each system needs, and by whether roles are already tied to accountability structures under GOVERN 2. Ask any partner for a written scope listing the systems, roles and approval steps before agreeing to a timeline, since no fixed duration for this work is set by NIST.
Can our internal team define GOVERN 3.2 roles without outside help?
Often yes, if the team has authority over the AI systems and access to the people who run and oversee them. The Playbook suggests defining who uses, interacts with and monitors each system, tracking risk information about human-AI configurations, and setting proficiency standards for operators and overseers. Internal teams usually struggle with the proficiency and training part, because it requires agreed skill criteria and a way to record that each person met them. An outside partner can help with the documents and evidence trail, but the organization still owns the roles and decides who fills them.
What does the planned AI RMF revision mean for GOVERN 3.2?
GOVERN 3.2 sits under GOVERN 3, which covers workforce diversity, equity, inclusion and accessibility. The July 2025 AI Action Plan recommends revising AI RMF 1.0 to remove references to diversity, equity and inclusion, and NIST says the framework is being revised and has not published a revised version as of October 2026. The human role definitions and proficiency expectations in GOVERN 3.2 are not, by that account, the same as the team composition outcome in GOVERN 3.1, so confirm with NIST's published revision whether wording changes. Any laws or contracts that cite the current version should be checked against the revision when it is released.
How do we show GOVERN 3.2 evidence to a customer?
Customers typically want a role matrix, the oversight procedures tied to each AI system, records of operator and overseer training, and a trail showing how those documents changed over time. Keep the documents in a wiki with version history so you can show what changed, when and by whom, and set permissions so only approved editors can change roles. Training completion records can come from a learning management system, but confirm that the system records completion according to the conditions you set. Share the evidence pack rather than asserting compliance, and let the customer's assessor draw their own conclusions.
How do generative AI actions under GOVERN 3.2 change the work?
NIST AI 600-1 adds five suggested actions for GOVERN 3.2, numbered GV-3.2-001 to GV-3.2-005, tagged to risks including Human-AI Configuration and Information Security. Two of them ask for acceptable use policies for generative AI interfaces, including criteria for queries an application should refuse, and for threat modeling of generative AI systems. Expect more effort if your organization runs or deploys generative AI, because the role model then needs to cover who may configure prompts, who reviews refusals and who responds when the system misbehaves. Confirm the full action wording in the Generative AI Profile before scoping.
When should we bring in an implementation partner for GOVERN 3.2?
Bring in a partner when internal teams lack time, when several AI systems share operators and overseers, or when you need the oversight evidence to be consistent across teams. A partner can prepare the role model, configure the wiki and training records, and set up test activities, such as garak probes for generative AI systems that produce a JSONL report and hit log. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. DeployOpen prepares systems and evidence, but an independent assessor is needed for any formal assessment, and DeployOpen does not issue reports or certificates.
How DeployOpen prepares role and oversight evidence
DeployOpen helps organizations prepare the systems, documentation and training records that show who does what in human-AI configurations and who oversees AI systems. The organization owns its roles, proficiency standards and oversight decisions, and DeployOpen prepares the self-hosted platforms and evidence that support them.
How we scope
- Engagements are fixed-scope, with the covered AI systems, roles and oversight functions agreed in writing before work starts.
- The written scope names each operator and overseer role, the systems they touch and the decisions each role can make.
- Scope also states which GOVERN 3.2 suggested actions the organization has chosen to address and which remain with the organization.
How we build
- We configure self-hosted documentation platforms so role definitions and proficiency standards are versioned and easy to review.
- We set role-based permissions so access to AI system interfaces and oversight tools matches the roles defined in policy.
- We configure training and completion tracking so operator and overseer proficiency can be shown with dated records.
How we hand over
- Handover includes the role and responsibility policy, the human-AI configuration register and the training records in agreed formats.
- Documentation explains how each role was set up, which permissions it holds and where the change history can be reviewed.
- The organization receives runbooks so its own staff can update roles and records after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Periodic reviews can check that role assignments and training records still match how the AI systems are used.
- Assessors and auditors are engaged by the organization. DeployOpen prepares evidence but does not issue reports or certificates.
