GOVERN 1.2 Trustworthy AI policy: requirements and evidence

What GOVERN 1.2 asks for and why a trustworthy AI policy matters

GOVERN 1.2 asks that the characteristics of trustworthy AI are built into the organization's policies, processes, procedures and practices. NIST AI 100-1 names seven characteristics: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Picture a customer security questionnaire or a board member asking how AI risk is governed. If the answer is a slogan such as "we value trustworthy AI," the organization has nothing to show. The NIST AI RMF is voluntary and has no certification, so there is no certificate to point to. What an assessor or customer can examine is the written rule set, who owns it, and whether teams follow it.

The risk this subcategory addresses is that the seven characteristics stay abstract. A team can claim fairness or explainability without any rule that defines the test, the threshold, the owner or the action taken when a result falls short. The Playbook suggests that the policy define key terms and intended uses, connect AI governance to existing risk controls, set standards for data quality, training, testing and validation, and fix monitoring and audit frequency. It also suggests whistleblower and incident response policies, and coverage of deployed and third-party AI systems. Confirm which of these your existing security and privacy policies already cover before writing anything new.

GOVERN 1.2 is hard because it sits underneath the other subcategories. Monitoring, documentation and incident handling all depend on rules that exist in writing first. The work is also not additive: AI 100-1 notes that addressing the characteristics one by one will not ensure trustworthiness because tradeoffs are usually involved, for example between accuracy and explainability or between privacy and fairness testing. The policy must say who decides those tradeoffs and how they are recorded. Ask internal owners to name the decision-maker for each tradeoff before drafting, because a policy that leaves that choice open will not satisfy a regulator or customer.

Which AI systems, teams and third parties a trustworthy AI policy must reach

A trustworthy AI policy only works if its scope matches what the organization actually runs. The decisions below change which systems, teams and suppliers the policy must name, and each one tells you what to inventory and what to check before drafting.

Built in-house versus purchased

Models your teams train or fine-tune carry risks in data sourcing, training and validation that the policy must set standards for. Purchased AI shifts much of that work to the vendor, but the deployer still owns how the output is used, monitored and overridden. Confirm which systems fall into each group and whether the policy sets separate expectations for each, since GOVERN 1.2 asks that trustworthy characteristics reach every system the organization relies on.

Generative AI in use

Staff using chat assistants, code tools or document summarizers create AI use that may never pass through a project review. The policy must name generative AI explicitly, cover approved and unapproved tools, and set rules for entering sensitive data. The Generative AI Profile in NIST AI 600-1 ties suggested GOVERN 1.2 actions to risks such as data privacy and information security, so the policy should address those risks for this group.

Deployed systems and systems in development

A policy written only for production systems leaves gaps in the stages before release. Testing, validation and go or no-go criteria belong in the policy for systems still in development, and monitoring, audit frequency and incident response belong for systems already live. Check that the policy states which lifecycle stage triggers each requirement, so a project cannot skip testing by reaching production under a different name.

Third-party and pre-trained models

The Playbook suggests that AI risk policies cover deployed and third-party systems. Pre-trained models, vendor APIs and embedded AI features each bring data, licensing and performance risks that the organization did not create. Ask each supplier what evaluation evidence it provides, what data it retains, and how it notifies you of changes. Record these dependencies in the policy scope even where the vendor owns the model.

Teams that build, buy, deploy and operate

Data scientists, procurement, business owners, platform engineers and operations staff each touch AI at a different point. The policy must assign obligations to each group, since a rule owned by no one will not be followed. Map the teams against the four activities so every activity has a named owner for documentation, testing and incident reporting. Confirm that the AI actor tasks in AI 100-1 Appendix A match the roles you write down.

What an AI risk management policy should define before anything else

An AI risk management policy should first define its own vocabulary and scope. The NIST AI RMF Playbook suggests that the policy define key terms and intended uses, so that a product team, a procurement officer and an auditor all mean the same thing by "AI system," "high-risk use" and "deployed." Next, the policy should state how it connects to existing risk controls. An AI policy that sits apart from the information security, privacy and third-party risk processes will be bypassed, so the reader should map each AI requirement to the control owner who already runs the matching process. Then set minimum standards for data quality, model training, testing and validation, and the monitoring and audit frequency that applies to each risk tier. The policy does not need final numbers at the outset, but it must name who sets the thresholds and where they are recorded.

The remaining suggestions cover conduct and response. The Playbook suggests whistleblower and incident response policies, which should name a reporting channel, protection from retaliation, an owner for triage and a route to escalate to executive decision makers. The policy should also state whether it covers only AI systems the organization builds or also deployed systems and third-party AI, since many incidents arise from purchased models and embedded features. Finally, the Playbook is neither a checklist nor a set of steps, so the organization should decide which suggested actions fit its context and record why any others do not apply. A short written rationale for each exclusion gives a reviewer something concrete to test, and it is the record a regulator or customer is most likely to ask for.

Confirm the scope and wording of this policy with your legal, privacy and security leads before drafting. The Playbook text and its audit log show content last updated in August 2023, and AIRC says it will update the Playbook after the AI RMF is revised, so check the current version at the NIST AIRC Playbook before citing it in a customer answer. Version control on the policy itself matters as much as its content, because the approval history shows which terms and thresholds were in force when a decision was made.

How an assessor tests a trustworthy AI policy and what passes

This table compares each test step an assessor runs on GOVERN 1.2 with the evidence requested and the findings that most often fail. There is no AI RMF certificate, so the assessor is your own auditor, internal audit or a regulator, and the test measures your policies against the approach you wrote down. Read each row as a question the assessor will ask and the proof you should have ready.

Test step	Evidence requested	Common finding
Read the AI risk policies end to end	Current policy set covering AI risk, data, model testing, monitoring, whistleblowing and incident response, with owners named	Policies exist but are scattered across IT, security and legal documents with no single owner
Check that key terms are defined	Glossary or definitions section, and the same terms as used in procedures and templates	Definitions of 'high-risk', 'model' or 'incident' conflict between documents
Trace each trustworthy characteristic to a written rule	Mapping from the seven characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, fair with harmful bias managed) to specific requirements	Characteristics are named in the policy but no rule, threshold or test is attached to them
Confirm standards for data, training, testing and validation	Documented minimum standards and the test records that show they were applied to a sample of systems	Standards exist for software releases but not for model training or data quality
Check monitoring and audit frequency	Written monitoring cadence, audit schedule, and records of completed reviews	Frequency is stated as 'periodic' with no date, owner or record of execution
Check approval and version history	Approval records by the accountable executive or governance body, change log and dated versions	Policy approved by a working group, or revised with no record of who approved the change
Confirm whistleblower and incident response procedures	Reporting channel, non-retaliation statement, incident playbook and sample closed incident records	Reporting channel exists but the AI incident path is not connected to the general security incident process
Check coverage of deployed and third-party AI	Procurement clauses, vendor AI inventory entries and evidence that the policy was applied to a vendor system	Policy written for systems the organization builds, silent on purchased or embedded AI
Sample operating records and interview owners	Records for a sample of AI systems and interviews with system owners, developers and risk staff explaining how they apply the rules	Staff describe practices that differ from the written policy, or cannot name the policy owner

How to build trustworthy AI characteristics into policy, step by step

This sequence turns the seven characteristics of trustworthy AI from NIST AI 100-1 into written policy areas, each with a named owner, measurable standards and a review date, so GOVERN 1.2 can be shown as met.

Map the seven characteristics to the AI portfolio
Start by listing every AI system the organization builds, buys or uses, then record which of the seven characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed) matter most for each system's intended use. Risk and privacy staff usually lead this with the business owners of each system. Expect tradeoffs between characteristics, since NIST notes that addressing them one by one will not ensure trustworthiness. The output is a characteristics matrix tied to the AI inventory, with each tradeoff recorded and the reason for its resolution noted.
Define key terms and intended uses
Write a short glossary covering terms the policy will rely on, such as AI system, high-impact use, deployer, third-party model and incident, so that every team reads them the same way. Then document the intended and prohibited uses for each system class. Legal or compliance staff should review the definitions against applicable laws identified under GOVERN 1.1. The output is an approved glossary and a use-case register that the policy can reference, which gives reviewers a fixed baseline when they judge whether a deployment is in or out of scope.
Assign owners for each policy area
Name one accountable owner and one delegate for each policy area: data quality, model training, testing and validation, monitoring, third-party AI, whistleblowing and incident response. Owners should come from functions that already hold the related controls, such as security, data governance and engineering, so the AI policy connects to existing risk processes rather than creating a parallel one. The output is a responsibility table approved by senior management, showing who signs off each standard and who can stop a deployment. Confirm the roles against the accountability structures set under GOVERN 2.
Set data, testing and monitoring standards
For each characteristic, write minimum standards the organization will apply: data quality criteria, model training and validation requirements, pre-deployment testing, and the frequency of production monitoring and audit. Where the team does not yet have a defined frequency, record it as an open decision with an owner rather than leaving it blank. Playbook suggestions for GOVERN 1.2 cover these areas, but the thresholds must be set by the organization. The output is a standards annex that engineering can implement and assessors can test, with each standard linked to the characteristic it protects.
Establish whistleblower and incident response routes
Define how staff, contractors and affected people can report concerns about an AI system, who receives each report, how it is triaged, and when it escalates to the risk committee or to an external regulator. Connect this to the incident response process already used for security and privacy events, and state how incidents and errors are recorded. Confirm that reporting channels protect the reporter and that reports are logged in a system that keeps history. The output is a reporting procedure, a triage matrix and an incident playbook that has been tested at least once through a tabletop exercise.
Cover deployed and third-party AI systems
Extend the standards to AI the organization does not build: vendor models, hosted APIs, embedded features in purchased software, and open-source models. For each, record what evidence the supplier provides, what contract terms apply to data use and incident notification, and who monitors the system after deployment. Procurement and legal should confirm these terms before signature. The output is a third-party AI addendum to the policy and a supplier checklist that is completed for every new system before it enters the inventory.
Approve, publish and set a review date
Route the draft policy through the governance body for approval, record the approving authority and version number, and publish it in the document system where staff already find security policies. Set a review date and name the person responsible for triggering an earlier review when a regulation, NIST revision or major incident changes the picture. NIST expects a formal review of AI RMF 1.0 no later than 2028, so the policy should state how it will be updated when the framework changes. The output is a versioned, approved policy with an audit trail of changes and a documented review schedule.

Evidence that shows GOVERN 1.2 is operating, and how to keep it current

GOVERN 1.2 is met when trustworthy AI characteristics appear in the policies people actually follow. The artifacts below show that the policy exists, is owned, is reached by the people it binds and is revisited on a schedule. Each one needs a named owner and a refresh trigger so it stays accurate between assessments.

Approved AI risk policy with version history

The policy itself is the anchor artifact. It should show an approver, an effective date and a change record for every revision, with the trustworthy AI characteristics written into its scope and principles. Check that each revision has a stated reason, such as a new regulation, a new system type or a finding from monitoring. A version-controlled wiki such as XWiki can keep every change with its author and date, and compare or roll back any two versions. The tool records history; approvers still decide whether the policy is adequate.

Definitions and intended-use register

This register holds the policy's key terms, the intended uses approved for each AI system and the uses that are prohibited. Auditors test it by picking a live system and confirming its recorded purpose matches what it does. Review it whenever a new use case is proposed or a system is repurposed. Access controls matter here because owners of each entry must be able to edit their own records without changing the shared glossary. BookStack supports role-based permissions that can be overridden per shelf, book, chapter or page.

Data, testing and validation standards

These standards set the minimum bar for data quality, model training, testing and validation before a system is used. Evidence includes the standard itself, the test plans it requires and sign-off records for systems that passed or were released with conditions. Ask whether thresholds are tied to the risk tier of each system, and whether the standard names who may waive a requirement and how that waiver is recorded. Refresh the standard when test results show that a threshold no longer protects the people the system affects.

Monitoring and audit schedule

A schedule sets how often AI systems are monitored and audited, with the frequency varying by risk. Keep the schedule as a dated plan, along with the monitoring outputs it produced and the findings each review raised. Assessors look for evidence that scheduled reviews happened, not just that a calendar entry exists. Confirm that the schedule is revisited after incidents and after material changes to a system, since a fixed interval alone can miss a shift in how a system is used.

Whistleblower and incident response procedures

These procedures explain how staff and others raise concerns about AI systems, how those reports are triaged and how incidents are escalated and closed. The evidence is the written procedure, the reporting channel's configuration, a log of past reports with their dispositions and records of any tabletop exercise. Check that reporters are protected from retaliation under the procedure and that incidents feed back into the policy and the monitoring schedule. Update the procedure after each real or simulated incident that exposed a gap.

Evidence that the policy reached owners

A policy has only partial effect if the teams building and running AI systems have not read it. Evidence includes acknowledgment records by role, training attendance, and a list of systems mapped to a named owner who confirms they follow the policy. Compare the acknowledgment list against the current AI inventory each review cycle, and re-issue the policy to anyone who joins a team that builds or buys AI. This shows the policy is operating in practice, not only on paper.

Who writes the policy, who builds the evidence, and who tests it

The organization owns its AI risk policy and every decision it contains. Policy owners, AI product owners, and risk and legal staff decide what the policy says, which intended uses are permitted, what data quality and testing standards apply, and who may approve or stop a deployment. NIST's framework treats governance as a cross-cutting function, so these decisions cannot be handed to an outside party.

Policy approval and ownership: Executive leadership approves the AI risk policy and names the accountable owner. An implementation partner may draft the text, but the approval record must come from the organization.
Risk acceptance: Product owners and the risk function decide which residual risks the business will carry, and they document that decision.
Legal and regulatory mapping: Legal staff confirm which laws and contracts apply to each AI system and how the policy addresses them.
Incident and whistleblower handling: Internal staff run the reporting channel, triage cases and make the final call on escalation.
Operating the controls: Teams run testing, monitoring and review on their own systems after handover.

Before engaging anyone, confirm internally which decisions are reserved to named roles, since that list defines what a partner may draft and what must stay in-house.

What meeting GOVERN 1.2 costs in money and effort

This table breaks down the cost components of building trustworthy AI characteristics into AI policies, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where self-hosted open-source tools shift spend from licenses to internal effort. No prices are stated because none are supplied for this topic.

Cost component	One-time or recurring	Who is paid or who carries the effort	What drives it up or down
Policy drafting and legal review	One-time, then recurring on each revision	Internal policy owners, legal counsel, and any outside advisor drafting the AI risk policy	Number of jurisdictions, sector rules, and how many existing policies must be connected to AI governance
Cross-functional workshops	One-time, then recurring as roles change	Time of security, data, product, legal and business leads; facilitation by internal staff or an implementation partner	Number of teams building or buying AI, and whether definitions of key terms already exist
Documentation and monitoring tooling	Recurring (licenses or hosting), or one-time setup for self-hosted tools	Software vendors for commercial tools; internal platform engineers for self-hosted tools such as a wiki with version control	License model and seat count for commercial tools; hosting, backup and upgrade effort for open-source tools
Engineering time for testing and monitoring standards	One-time build, then recurring maintenance	Internal engineers, or an implementation partner preparing test pipelines and trace logging	Count of AI systems in scope, model types, and whether logging and evaluation already exist
Generative AI evaluation and red teaming	Recurring, tied to model changes and releases	Internal evaluation staff or an outside security testing provider	Use of generative AI, number of model versions, and depth of safety evaluation required by policy
Recurring evidence upkeep and review cycles	Recurring	Internal governance and compliance staff who collect, date and approve evidence	Review frequency set in policy, number of AI systems, and quality of the AI inventory
Third-party AI and vendor review	Recurring, at contract renewal and on model updates	Procurement, legal and risk staff; vendors may charge for documentation access	Number of third-party models and data sources, and how much vendors disclose
External testing or independent review	Optional, periodic	Independent assessors or testing firms, paid by the organization	Risk tier of systems, customer or regulator demands, and the scope written in the quote
Auditor sampling and assessment support	Periodic, per assessment cycle	Independent auditor or certification body; the organization pays for the assessor and for staff time to produce samples	Number of policies and systems sampled, and how well evidence is organized before the assessor arrives

Where organizations usually fall short on trustworthy AI policy

Most AI policies state good intentions but stop short of the mechanics that make them enforceable. The gaps below recur across organizations preparing for GOVERN 1.2, and each one leaves a policy that reads well but cannot be tested, owned or acted on.

Characteristics without tests or owners

Policies often list the seven characteristics of trustworthy AI as principles without naming who checks each one or how. AI 100-1 notes that addressing the characteristics one by one will not ensure trustworthiness because tradeoffs are usually involved. For each characteristic, confirm a named owner, a test or metric, and the forum where tradeoffs such as accuracy against explainability get decided.

Third-party and purchased AI left out

Many policies cover models the organization builds and ignore AI embedded in vendor software, purchased APIs and pre-trained models. The Playbook suggestions for GOVERN 1.2 ask policies to cover deployed and third-party systems. Check the inventory against the policy scope and confirm that procurement contracts require disclosure of model changes, training data sources and evaluation results.

Key terms defined differently

The same word, such as "high-risk" or "model," often means one thing in the AI policy, another in the security standard and a third in the procurement template. Where definitions conflict, reviewers cannot tell which requirement applies. Build one glossary, link it from each policy, and record the version and owner so that changes to a term propagate to every document that uses it.

No route for AI issues

Whistleblower and incident response procedures are often written for security or privacy events and never mention AI failures such as biased outputs, harmful model behavior or unexpected data exposure. Staff then have no defined channel to raise concerns, and incidents get handled ad hoc. Confirm that the incident process classifies AI events, names an escalation path, and tells employees how to report anonymously.

Review dates that have passed

Policies frequently carry a review date that was missed, so the document describes a practice the organization no longer follows. Revision history matters here because an assessor will ask which version was in force when a decision was made. Check every policy for its owner, last approval date and next review date, and confirm that the document system records who changed what and when.

Generative AI risks out of scope

Policies written before generative AI adoption often treat language models as ordinary software, leaving out prompt injection, data leakage through prompts and hallucinated outputs. NIST AI 600-1 ties suggested GOVERN 1.2 actions to risks including information security, data privacy and information integrity. Confirm that the policy names generative AI explicitly, sets pre-deployment and ongoing evaluation rules, and assigns owners for those tests.

Questions buyers ask about GOVERN 1.2 cost, effort and outside help

Is GOVERN 1.2 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 no AI RMF certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. GOVERN 1.2 is a subcategory outcome: it asks that the characteristics of trustworthy AI are built into your policies, processes, procedures and practices. Your customers, contracts or sector regulators may ask you to show that work. Before you commit to an approach, confirm with each requester which evidence they accept, since some laws and contracts cite the framework directly.

How long does GOVERN 1.2 work take, and what drives the duration?

The duration depends on how much policy material already exists and how many AI systems the policy must cover. Organizations with an existing risk management policy usually extend it, which is faster than writing a standalone AI policy from nothing. Drivers include the number of business units using AI, whether generative AI or third-party models are in use, how many approvers must review drafts, and how well existing security and data policies can be connected to AI-specific rules. Ask any partner for a written timeline tied to a defined scope, and ask which dependencies, such as legal review or executive sign-off, sit outside their control.

What does GOVERN 1.2 need from our internal staff?

Internal staff own the decisions that a policy records. Expect to involve legal or compliance for definitions and intended uses, security for controls and incident response, data teams for data quality standards, engineering for testing and monitoring rules, and an executive owner who approves the policy. Staff also need time to review drafts and to confirm that the written rules match how AI is really built and bought in your organization. Ask for a named list of reviewers and an estimate of their hours in the written scope, because this internal effort is often the largest cost in the work.

Can a small team write a GOVERN 1.2 policy on its own?

A small team can draft a policy on its own if it has a clear owner, access to legal review and a bounded set of AI systems. The Playbook gives suggested actions and documentation prompts for GOVERN 1.2, but it is neither a checklist nor a set of steps, so the team must decide which items apply. The harder part is keeping the policy current as tools change. Small teams often underestimate the ongoing work of monitoring, whistleblower handling and incident response rules, so decide early who will run those processes after the first draft is approved.

What can an implementation partner do for GOVERN 1.2, and what can it not do?

An implementation partner can help plan the policy structure, connect AI governance to existing risk controls, draft standards for testing and monitoring, prepare documentation and evidence, and help set up the systems that hold records, such as version-controlled wikis. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and it prepares systems, controls and evidence for assessments. It cannot own your controls, approve your policy on your behalf or issue audit reports, attestations or certifications. Only an independent auditor or certification body issues those, and the organization remains accountable for the outcome.

What should a written scope for GOVERN 1.2 include?

A written scope should name the AI systems and business units covered, the subcategory outcomes addressed, and the policy documents to be produced or revised. It should list deliverables such as the policy text, the standards for testing and monitoring, the incident response and whistleblower procedures, and the evidence repository. Ask for the roles of each party, the internal reviewers, the acceptance criteria for each deliverable, the platforms to be deployed or configured, what happens to requests outside the scope, and what support follows delivery. DeployOpen agrees scope, deliverables and timelines in writing before work starts and quotes from that scope.

How does GOVERN 1.2 relate to the Playbook and the planned NIST revision?

GOVERN 1.2 is an outcome, and the Playbook offers suggested actions, documentation prompts and references for it. NIST says the Playbook is not a checklist, and its audit log shows the last content update in August 2023. AIRC has said the Playbook will be updated after the AI RMF is revised. NIST states that AI RMF 1.0 is being revised under the White House AI Action Plan and has not published a revised version as of 17 October 2026. AI 100-1 says NIST expects a formal review no later than 2028. Confirm with your customers or regulators which version they cite, and build the policy so that the outcome, not a specific Playbook wording, drives the controls.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, documentation and evidence behind GOVERN 1.2, the outcome that trustworthy AI characteristics are built into organizational policies and practices. The organization owns its AI policy and decides what it commits to, while DeployOpen prepares the platforms and records that show those policies operating, and only an independent assessor or auditor can judge them.

How we scope

Agree in writing which AI policy documents, business units and AI systems fall inside the engagement before work starts.
Confirm which policy topics the organization already covers, such as definitions, data standards, testing, whistleblowing and incident response.
Identify which self-hosted platforms will hold policy text, approvals and evidence, and who in the organization owns each one.

How we build

Set up a version-controlled documentation space so each AI policy revision records what changed, when and by whom.
Configure role-based access so policy owners, reviewers and approvers each hold only the permissions their role requires.
Connect AI monitoring and evaluation tooling so testing and production traces can be linked back to the policy requirements they support.

How we hand over

Deliver the policy set, configuration records and evidence map in the formats and locations agreed in the written scope.
Document how each policy requirement is tested, who reviews results and how exceptions are approved and recorded.
Walk the organization's staff through the handover so policy owners can maintain the documents without outside help.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work starts, with a quote following from that scope.
Ongoing support, upgrades and continuous testing are available as a retainer for policies that need regular review.
Ask any independent assessor you plan to use which evidence format and sampling approach they expect before we build.