AI governance needs a decision record, not another slogan

A company can approve an AI tool and still have no clear answer to a practical question: may this team upload these documents for this purpose? The tool name is the same, but the data, users, consequences, and downstream actions can be completely different.

Consider an illustrative assistant used to summarize internal operating procedures. The pilot uses public examples. Later, someone adds employee notes because the answers become more specific. Then another team connects customer correspondence. The original approval is still referenced, although the system being operated is no longer the system that was reviewed.

Useful AI governance keeps decisions connected to the actual use case. It records what is allowed, who owns the outcome, which evidence supports the decision, and what changes require another look. Privacy belongs inside that operating process, not in a statement added after the data has already moved.

1. Govern the use case, not the product logo

A tool-level list is useful for procurement and access management. It is too coarse to explain whether a particular workflow is acceptable. The same platform might help draft public marketing copy, summarize confidential negotiations, or influence a decision about a person. Those uses need different scrutiny.

Start each record with purpose, users, affected people, data categories, outputs, actions, and an accountable owner. Define what the system will not do. A summary assistant that cannot make an eligibility decision has a different boundary from one that recommends who should receive a service.

NIST describes its AI Risk Management Framework as voluntary and intended to support trustworthiness throughout AI design, development, use, and evaluation. It is a structure for risk management, not a law, a certification, or automatic evidence that a deployment is acceptable.

Use such frameworks to organize questions, then answer those questions with evidence about your system. Applicable legal and contractual requirements need their own review by the appropriate owner. Do not replace that work with a claim that the vendor follows a framework.

2. Build an inventory that can trigger a decision

An inventory is valuable when it changes what happens. A spreadsheet containing product names and no owners will become outdated quickly. Keep the record small enough that the person responsible for the workflow can maintain it.

The prohibited employee notes are an example scope decision, not a claim that one rule fits every organization. The record should make the actual boundary unmistakable. If the business needs to expand it, that becomes a visible change request instead of an undocumented convenience.

3. Follow the data through its full route

The user sees an upload box and an answer. The data may pass through document storage, parsing, an index, retrieval, a model provider, application logs, support tooling, and backups. Review the route, not just the visible screen.

For each stop, record the data entering it, the purpose, who can access it, how long it remains, and what happens when deletion is requested. Distinguish source documents from extracted text, embeddings, cached answers, evaluation samples, and support attachments. A promise about one copy does not automatically describe the others.

NIST’s Privacy Framework is also a voluntary tool for identifying and managing privacy risk. That perspective is useful because the question extends beyond preventing a breach. An authorized processing activity can still create an unwanted consequence for an individual.

For the example assistant, a procedure may contain a real person’s name in an old incident description. The document could be useful while that identifying detail is unnecessary. Decide whether the detail can be removed before indexing, whether the entire document should be excluded, or whether the task requires a more controlled environment.

Data minimization is a design question: what is the least information that still allows the intended job to be done?

4. Ask vendors about distinct data uses

A statement that data is not used for model training answers one question. It does not, by itself, describe retention, human support access, abuse monitoring, subprocessors, regional processing, or deletion from derived stores.

Ask separate questions and preserve the answers that apply to your exact product, plan, region, and configuration. Record where a setting changes the behavior and who can change that setting. A sales slide is not the same artifact as a current agreement or technical control you have tested.

The AI vendor security questionnaire provides a way to make those questions concrete. Use it as a conversation starter, then attach the relevant evidence to the use-case record rather than accepting a generic security score.

Work through an exit scenario before committing sensitive material. Can the organization export what it needs, revoke access, remove indexed copies, and understand any residual retention? Who confirms completion? What remains in backups or operational records, under which agreed limits?

If the answers are incomplete, narrow the pilot to data and actions appropriate for that uncertainty. A limited pilot is a legitimate outcome. So is declining a use case whose essential requirements cannot be met.

5. Write a risk register that names the response

A useful risk statement connects a cause, a failure, an affected party, and a consequence. The assistant may be inaccurate is too broad. An outdated procedure could cause an operator to skip a required check is specific enough to investigate.

Prioritize by consequence, exposure, and evidence rather than creating precise-looking numbers from guesses. Record uncertainty explicitly. Each significant risk needs a decision: reduce it, avoid the use, limit the deployment, or accept the residual risk through the designated accountable process.

NIST’s Generative AI Profile is a companion to the AI RMF focused on generative AI. It provides a useful reference for organizing this review. The register here is an original working example, not an official NIST template or approval.

6. Rehearse the ambiguous case

Policies become useful when they decide a case that is not obvious. For the illustrative assistant, imagine a procedure owner requesting that a folder of historical incident notes be added. The notes contain both valuable lessons and information about individual employees.

First ask what answer quality is missing today. Perhaps the assistant needs a sanitized explanation of a recurring failure, not the entire incident archive. The solution could be a new approved procedure document rather than broader access to sensitive history.

If the source is necessary, map who would see the resulting answers, what details could be inferred, and whether the current evaluation covers that use. Identify the decision owner and the evidence required before the scope changes. Preserve the reasoning, including why a narrower alternative was insufficient.

Now test the output with a safe representative example. Does the answer include unnecessary personal details? Does it make an unsupported judgment about an individual? Does it direct the user to an accountable person when the source cannot support an answer?

The resulting record should show a real decision, even if the decision is to keep the folder excluded. Governance earns trust by making the reason visible and giving the requester a workable next step.

7. Make changes and incidents part of normal operations

An approval should describe the conditions under which it remains valid. New users, new data, new tools, altered retention, or a shift from drafting to acting can change the risk. Define these review triggers in advance so teams know when to return.

Give exceptions an owner, an expiration date, and a scope. An exception that never expires can become an undocumented replacement for the rule. Review recurring requests as evidence that the underlying process may need improvement.

Provide a clear incident route. People should know where to report an incorrect disclosure, harmful recommendation, or use outside the approved boundary. The response should identify immediate containment, evidence preservation, affected workflows, and the person who coordinates further review.

Use the AI pilot guardrails checklist to connect these decisions with a limited deployment. Set the stop conditions before the pilot begins. Otherwise a team may keep expanding because no one defined what would count as enough evidence or an unacceptable failure.

Review should produce action, not merely a meeting: update a source, reduce access, revise a workflow, add a test, or retire the use.

8. Keep the process proportional

A small internal drafting task using approved nonsensitive material should not necessarily face the same review as a system influencing consequential decisions about individuals. A single heavy process encourages teams to work around it. A process with no meaningful escalation misses important differences.

Define a few review paths based on the data, affected people, action authority, and reversibility. Explain the evidence required for each path. Keep the decision criteria readable by the people proposing the work, not only by the reviewers.

Do not use a framework checklist as a substitute for understanding the task. Nor should governance become a reason to retain more personal data than the task needs so that every interaction can be documented. Evidence collection itself needs purpose and limits.

When the organization cannot name an accountable owner, establish the intended use, or enforce the essential data boundary, the right next step is to resolve that gap. Buying another governance tool will not make the missing decision on its own.

This guide does not determine legal compliance for a jurisdiction or sector. Keep that assessment separate and involve the qualified people responsible for the obligations that actually apply.

9. Show the thing

Build a review packet containing the use-case record, data route, vendor evidence, risk register, evaluation results, decision, and change triggers. Keep the detail proportional, but make the links between the artifacts clear.

For the illustrative knowledge assistant, proposed acceptance criteria include an accountable owner for every active use, no unexplained data destination, a tested boundary for excluded material, a documented deletion route, and a named person able to suspend the workflow. A reviewer should be able to locate the evidence for each claim without asking the author to reconstruct it.

Run a tabletop change: a new team wants access and a new source contains personal information. Use only the packet to decide what must happen next. If the answer is unclear, improve the record and process before expanding the system.

Learn where the use could affect people. Build the controls and decisions that address those effects. Show the evidence, including the limits. That is an operating practice people can maintain after the initial policy launch.

Source notes checked September 23, 2026. NIST frameworks cited here are voluntary resources. The records, examples, and acceptance criteria are illustrative and do not establish compliance with any law or contract.

Continue the field guides: An AI evaluation should end in a release decision or The permission boundary belongs outside the AI prompt.

Try this

Choose one AI workflow already in use or proposed for a pilot. Write its purpose, users, affected people, allowed data, output authority, owner, and fallback. Trace the data from input through every vendor, index, log, and retained copy you know about; mark unknowns instead of guessing. Add three concrete failures to a risk register, each with a control, evidence, and owner. Then rehearse one scope change, such as a new user group or a source containing personal information. Record who decides and what evidence they need. Finish by naming the conditions that would pause or retire the workflow.