AI governance that helps people make better decisions.

The most useful first step in AI governance is to find out what the organization is already doing. People may be using a public chatbot to summarize meeting notes, a browser extension to draft outreach, an image generator for advertisements, an AI feature inside the CRM, or a vendor's model behind a workflow. If those uses are invisible, the organization cannot assess their data, permissions, reliability, or business impact.

Create an AI register that is easy for a department to complete. For each use case, record the owner, business purpose, tool or model, vendor, data entered, people affected, output used, human reviewer, connected systems, known limitations, and current status. Include informal experiments as well as production systems. The register is not a surveillance exercise; it is a map of where decisions and information are flowing.

I recommend using the use case as the unit of governance rather than the brand name of the tool. One company may use the same model for low-risk brainstorming, recruiting support, and medical triage. Those are different use cases with different consequences and should not inherit one approval simply because the vendor is the same. A tool-level approval can be a starting point, but use-case-level review is where the real risk becomes visible.

Give every registered use case a lifecycle status: proposed, piloting, approved, restricted, paused, or retired. Record the approval date, the next review date, and the evidence that supported the decision. This small amount of structure prevents a pilot from becoming permanent by accident and makes it possible to explain why an AI workflow exists months later.

A policy is only useful when it answers who decides. Assign an accountable executive for the program, a business owner for each use case, and a technical owner for the implementation. Bring in privacy, security, procurement, legal, HR, or a subject-matter expert when the use case touches their domain. The business owner should not be able to hand off responsibility to the model vendor after launch.

Write an approval path that matches risk. A low-risk drafting assistant may need a self-service checklist and a manager's approval. A workflow that changes customer records, recommends employment action, handles confidential information, or affects access to a service should receive deeper review. Requiring identical paperwork for every experiment encourages shadow use; requiring no evidence for consequential work invites preventable harm.

Your internal policy should be short enough to be read. It should cover permitted and prohibited data, approved tools, human review, acceptable uses, disclosure where appropriate, intellectual property handling, security expectations, record retention, and incident reporting. Put examples beside each rule. 'Do not enter confidential information' is less useful than explaining what counts as confidential and which approved environment may handle it.

NIST treats governance as a cross-cutting function rather than a one-time gate. That is important. A model update, new data source, new user group, new integration, or change in the decision being supported can change the risk without changing the product name. Set review triggers so the program responds to meaningful changes instead of waiting for an annual calendar date.

Mapping asks what the system is for, where it operates, and who may be affected. State the intended purpose in one sentence and state the non-purpose too. For example: 'This assistant drafts internal support replies for a trained employee to review.' It is not: 'This assistant decides refunds, authenticates customers, or sends messages without approval.' Clear boundaries make later testing and training much easier.

Describe the users and affected groups, including people who never interact with the interface. A candidate may be affected by a recruiting ranking tool, a customer by a fraud model, and a patient by a scheduling or documentation assistant. Ask what happens when the system is wrong, who bears the cost, and whether the affected person can seek correction or human review.

Trace the data path. Identify sources, permissions, transformations, retention, destinations, and model-training settings where the vendor makes them available. Separate information needed to perform the task from information that is merely convenient. Minimizing the data in the prompt often improves privacy and reduces irrelevant context that can distract the model.

Map dependencies too. An AI application may rely on a model provider, retrieval index, browser, payment system, identity provider, third-party API, human queue, and monitoring service. An incident can originate in any of them. Record what happens when a dependency is unavailable, returns malformed data, changes its terms, or produces an answer outside the expected range.

A governance review should ask for evidence, not a confidence statement. Define the desired outcome and the unacceptable outcomes before launch. For a support assistant, measure resolution quality, escalation, policy adherence, customer effort, and whether the final record is correct. For an internal writing tool, measure time saved and review burden rather than assuming a fluent draft is a productive one.

Use a mix of deterministic tests, expert review, and model-based grading where appropriate. Exact values, required fields, permissions, tool arguments, and final database state can often be checked with code. Groundedness, completeness, and tone may need a rubric and calibrated human or model review. See our practical guide to [AI evaluation](/ai-evaluation) for task design, graders, regression tests, and agent trajectories.

Test ordinary requests and awkward ones. Include incomplete information, conflicting instructions, sensitive requests, malicious content, ambiguous language, and cases where the system should refuse or escalate. Measure not only whether the final response sounds correct, but also what tools were called, which sources were used, what data was exposed, how long it took, and what it cost.

Keep evidence versioned. Store the model and prompt version, retrieval or data snapshot, tool versions, test cases, grader results, and decision made. When behavior changes, this history helps the team distinguish a code regression from a vendor update, a data change, a new instruction, or a change in user behavior. Without it, governance becomes retrospective storytelling.

Management begins when the review produces a list of risks. Prioritize them by plausible impact and likelihood, then assign a control and an owner to each material risk. Controls may include access limits, redaction, retrieval restrictions, approvals, output validation, rate limits, a fallback process, user disclosure, or simply deciding not to automate the task.

Build a production feedback loop. Sample traces, review user complaints, watch for changes in refusal and escalation, track important errors, and turn confirmed failures into new tests. A dashboard full of generic model metrics is less useful than a small set of measures tied to the workflow. Monitor the real outcome: whether a ticket was resolved safely, an invoice was correct, or an employee received a fair review.

Plan for incidents before one occurs. Define what counts as an incident, how a user reports it, who can pause the system, how evidence is preserved, who communicates with affected people, and how the root cause is corrected. Practice the process with a realistic scenario. The ability to stop an automated action and return to a human workflow is a governance control, not an admission that the project failed.

Set a retirement rule. A system may be retired because its data is no longer appropriate, the vendor changed, the workflow is no longer valuable, the error rate is unacceptable, or a better controlled process exists. Remove credentials, integrations, indexes, and old access paths; communicate the change; and retain only the records the organization is allowed and required to keep.

In week one, create the register and interview the people closest to the work. Do not wait for perfect taxonomy. Capture the tool, purpose, data, output, owner, and affected people. Highlight anything that changes a customer's record, influences an important decision, handles sensitive information, or acts without a human confirmation.

In week two, publish the short-use policy and create risk tiers. For each tier, define the minimum evidence and approval. Train people with examples from their actual work. A policy that explains how to remove identifying details from a prompt is more likely to change behavior than a page of abstract principles.

In week three, choose one or two consequential use cases and build an evaluation set. Use real anonymized cases where possible. Define the pass condition, failure condition, escalation behavior, and monitoring owner. Run the evaluation before launch and after meaningful changes. If the team cannot explain what success means, pause the launch and fix the requirement.

In week four, review the evidence with the owner and decide: approve, restrict, pilot with controls, or stop. Record the reason and the next review trigger. Then use what you learned to simplify the next review. Good governance gets faster because the organization accumulates reusable controls and evidence; it does not get faster by skipping the questions that matter.