Summary
You already have an artificial intelligence (AI) governance system. It is not written down anywhere. It lives inside a few people’s heads. The manager remembers which tool got restricted and why. The analyst knows which customer fields are off-limits, and one engineer understands what happens when a vendor changes a model underneath a workflow. That system works fine right up until one of those people is on vacation, changes roles, or leaves. Then you discover your governance was never a system at all. It was a set of people, and people do not scale, do not transfer cleanly, and do not answer email from a beach.
A policy cannot fix this, because a policy states belief. It does not carry memory. The National Institute of Standards and Technology (NIST) organizes AI risk management around four functions: govern, map, measure, and manage. Every one of them assumes documented roles and controls sitting behind the principle, not only the principle itself. MIT Sloan calls the healthiest version of this minimum viable governance. It is oversight sized to risk and built directly into the workflow rather than bolted on top of it. Deloitte’s 2026 research found real value in companies where senior leadership actively shapes AI governance. That value evaporates the moment the work gets handed entirely to a technical team with no memory of why any of it matters. Ten documents are what turn your company’s private, fragile memory into something the organization can depend on.
One: build the tool register
Every department believes it is the only one that bought a research assistant. Nobody is lying. Nobody could see what already existed. Three teams solve the identical problem three separate times, and you end up paying for the same capability under three different invoices. The register exists to end that particular kind of blindness. It gives you one place that answers whether a product is approved, restricted, or retired. That is the answer someone needs before starting a purchase order that duplicates work already done elsewhere.
A useful record names the product, its owner, and its current status, drawn from a small set: approved, approved with conditions, experimental, restricted, retired. “Available” is not a status. It is the absence of a decision wearing the costume of one, and a register that lets that slide has stopped doing its job.
Two: build the use case inventory
Approving a tool feels like governance, but it is not. A research assistant pointed at a public website and that same assistant connected to a customer record are two entirely different risks wearing one name. The inventory is what separates them, tracking not the product but every real thing the product gets used for.
Each entry needs the business problem it solves, its lifecycle stage, and its owner. A use case should never sit in pilot status forever only because nobody scheduled the conversation about what comes next. A tool with no linked use case is a gap you have not found yet.
Three: write the data rules
A classification policy defines confidential information in the abstract. Abstractions do not help the person holding a customer complaint next to an open chat window. The real question always arrives concrete: can this note go in, can that transcript go in. The data rules exist to answer that exact question, in your company’s own language, not a definition borrowed from a template.
Name which tools are cleared for which classification, and name the authoritative source when two records disagree. NIST recommends aligning AI governance with your existing data policies, instead of inventing a second structure to maintain. That is the whole reason this document exists in the first place.
Four: build the human review matrix
“Human in the loop” sounds like a safeguard. It names no reviewer, no standard, no timing, and no actual power to stop anything. Five employees can hear the same phrase and build five different mental models of what it is supposed to protect. The review matrix replaces the phrase with a decision: who reviews, what they are checking for, and what they can do when something is wrong.
Most workflows sort into four levels. Full approval sits in front of every action. Conditional approval triggers only on specific conditions. Sampled review checks a portion after the fact, and exception-only review catches whatever leaves the approved path. A review requirement with no reviewer capacity behind it is not a control. It is a sentence nobody funded.
Five: build the incident response process
Without a clear route for reporting a problem, someone quietly fixes it themselves and moves on. The same failure keeps recurring somewhere else, because nobody ever connected the two events to each other. That is not a technology gap. It is an organizational one, and it repeats for exactly as long as it stays invisible.
Name what counts as an incident, who owns the first response, and who holds the authority to pause a workflow outright. Security should lead security incidents, and privacy should lead privacy events. One coordinator should hold the full record, so nothing falls through the seam between the two.
Six: build the vendor record
A contract and a security questionnaire feel like diligence, but they miss the layers stacked underneath most AI products. One company supplies the application, another the model, and a third the infrastructure connecting them. Any one of those layers can change what you are exposed to, without a single new signature. The vendor record makes that whole stack visible in one place instead of scattered across three departments’ private notes.
Each entry needs the vendor, the contract dates, and the approved data classifications. It should also note whatever the vendor can substitute underneath the product without telling anyone. Review should trigger before renewal and immediately after any material change, not whenever the calendar happens to remind someone.
Seven: keep a decision log
Governance decisions get made in meetings and message threads, and the reasoning behind them evaporates the moment the action lands in a project plan. A new employee sees that a tool got approved without ever learning why an earlier version got restricted. A different team quietly repeats an experiment leadership already killed, for a reason nobody wrote down where the next team could find it.
Each entry needs the decision, the date, and the person who held the authority to make it final. Only that person should mark anything final. Keep the original entry even after a later update replaces it, so your company’s memory does not quietly rewrite itself.
Eight: write the workflow training guide
A general course on prompting teaches background. It does not teach the one decision an employee faces mid-task. Someone can understand a product perfectly well and still enter the wrong information. Nobody ever connected the policy to the specific thing in front of them.
The guide should cover the approved tool, the required inputs, the review point, and the manual fallback for when the system itself goes down. Training should use real cases pulled from the actual workflow. A polished demonstration prepares nobody for the incomplete record that shows up on an ordinary Tuesday.
Nine: build the performance scorecard
A vendor dashboard shows prompts and usage, and neither one says whether the business improved. A workflow can look genuinely impressive on activity while quietly growing the review and correction work happening out of frame. The scorecard connects activity back to the result that justified building the thing in the first place.
Put five areas side by side: the business outcome, workflow performance, quality, adoption, and cost. Every measure needs an owner and a threshold. The review has to end in an actual decision, not only a status update nobody acts on.
10: write the retirement plan
Closing a tool feels like the easy step, which is exactly why it is the one almost everyone skips. AI products quietly retain files, connections, and accounts well past the point anyone remembers they exist. A connected workflow can keep attempting actions long after the visible product itself has closed its doors.
Name the system being retired and the owner accountable for closing it. Every dependency needs to surface before the date gets picked. Closing a redundant tool is portfolio discipline, not a mark of failure. Say so plainly enough that nobody hesitates to use it.
Treat the documents as one memory, not ten files
A new model can force changes to the tool register, the vendor record, the training guide, and the scorecard all at once. A new sensitive data source can touch the data rules, the review matrix, and the use case inventory together, in the same motion. Treat these as ten separate files, and one change quietly creates nine contradictions nobody notices until an employee follows the wrong instruction. Treat them as one connected memory, and updating a single record carries the change everywhere it matters.
Match the weight to the risk, not the org chart
A small company needs every one of these ten functions and none of the overhead that usually travels with them. Several can share one workspace: one tool list, one use case list, one shared data page. A low-risk internal assistant needs a short entry and a basic scorecard. A customer-facing agent with real system access needs the full depth of everything on this list. MIT Sloan’s minimum viable governance model is built for exactly this. Oversight gets sized to what a workflow can do, never applied the same way regardless of the stakes.
Run this 30-day plan to build the first working version
Week one. Build the tool register and use case inventory. Gather contracts, expense records, and team surveys, and treat an unapproved tool as a signal of unmet need before assuming misconduct.
Week two. Write the data rules, the review matrix, and the incident process. Test each one against a real, active workflow, not a hypothetical one.
Week three. Build the vendor record and the decision log, and write the first training guide. Assign real owners and link each production use case to its tool and its rules.
Week four. Build the scorecard and the retirement plan. Review every active workflow and decide, honestly, which ones deserve expansion and which ones deserve an ending.
What you tell them at the end
Governance earns trust the moment it helps someone make a better decision during ordinary work. It loses that trust the moment it becomes a binder nobody opens until an auditor asks for it. The tool register tells your employee what they may use. The data rules tell them what may enter it. The review matrix tells them when someone else has to look, and the incident process tells them exactly what to do the instant something breaks. None of that is paperwork. It is your company’s memory, finally written down where the next person can find it.
