The AI Governance Playbook for AI You Adopted but Never Governed

Most companies never decided to adopt AI. It showed up. Your CRM shipped a summarizer in a quarterly update, and the release notes were three lines long. Someone in finance started pasting draft board commentary into a chatbot because it saved them an hour. A support tool flipped on an auto-reply model and nobody signed a thing. By the time a director asks "so who owns this," there are twenty of these running across the business, and not one of them went through a review.

That is the situation I get pulled into most often. It is rarely a company training its own models from scratch. It is a company that took in AI through vendor updates and employee habit, and now has a board asking what the exposure is and a general counsel asking who signed off. The honest answer, usually, is that nobody did.

So this is a playbook for that company. It assumes you have AI in production that you did not build, that you cannot fully see, and that you have not governed. The goal here is modest and reachable in a quarter: name an owner, get a real inventory, set a threshold tied to what the business cares about, and stand up the two or three controls that earn their place. Nothing exotic. I am going to ground each move in the NIST AI Risk Management Framework, NIST AI 100-1, published January 2023 (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), because it is voluntary, it is public, and its Govern function reads like a checklist for exactly this mess. If you want a certifiable management system on top of it later, ISO/IEC 42001 is the standard your auditors will ask about, and the work below maps cleanly into it.

A quick word on why the framework matters here. NIST built the RMF around four functions: Govern, Map, Measure, and Manage. The AI RMF Core page is clear that Govern is the cross-cutting one, the function that gets infused through the other three (https://airc.nist.gov/airmf-resources/airmf/5-sec-core). NIST also says plainly that after you put the Govern outcomes in place, most users start with Map and move on to Measure and Manage. Govern comes first because without it you are measuring things nobody owns. For a company that adopted AI it never governed, Govern is the whole job for the first ninety days.

The Adopted-AI Governance Playbook

Here is the framework. Five steps, each with a single owner and a way to tell when it is done. If you cannot point at the "done" evidence, the step is not done, no matter how many meetings you held about it.

Name one accountable owner and write it down. Owner: the CEO or the executive team, ratified by the board. Done when a named executive owns AI risk in a written charter, the board minutes record the decision, and every business unit knows who to call. NIST AI RMF Govern 2.3 puts this squarely on executive leadership, which "takes responsibility for decisions about risks associated with AI system development and deployment" (https://airc.nist.gov/airmf-resources/airmf/5-sec-core).
Build a real inventory of the AI already running. Owner: the AI governance lead or CISO, with every department head feeding it. Done when one register lists every AI system in use, embedded or standalone, with its business owner, the data it touches, the vendor behind it, and the decision it influences, and the register has a refresh date no older than one quarter. This is Govern 1.6: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities."
Set a risk threshold tied to business impact. Owner: the AI governance lead, signed off by the executive owner and legal. Done when you have a written tiering rubric, every inventoried system carries a tier, and the high tier automatically triggers review before the system keeps running. This is Govern 1.3: activities are sized "based on the organization's risk tolerance."
Install the two or three controls that earn their keep. Owner: control owners named per control (a human reviewer for high-impact outputs, an engineering owner for logging, a procurement owner for vendor terms). Done when high-tier systems have a documented human check on consequential outputs, logs are retained on a stated schedule, and vendor contracts carry AI-specific terms. These trace to Govern 1.2 and the incident-response and third-party guidance in the Govern Playbook (https://airc.nist.gov/airmf-resources/playbook/govern).
Give every system a decommission path. Owner: the system's business owner. Done when each inventoried system has a named condition that would retire it and a documented way to turn it off without breaking something else. Govern 1.7 asks for exactly this: safe decommissioning that "does not increase risks or decrease the organization's trustworthiness."

That is the spine. The rest of this post is how each step goes wrong and how to get it right, because the steps are easy to write and hard to finish.

Step one: one owner, and it has to be a real one

The most common failure I see is a governance committee with nine names on it and no single accountable person. Committees are useful for input. They are useless for ownership, because when everyone owns a risk, nobody eats the cost of it going wrong.

NIST is direct about where this sits. Govern 2.3 assigns responsibility for AI risk decisions to executive leadership. Govern 2.1 wants "roles and responsibilities and lines of communication" documented and clear to people throughout the organization. Read those together and the instruction is simple: one executive owns the outcome, and everyone can name that person.

Who should it be? In most mid-market companies I work with, it lands on the CISO or a head of risk, at least at first, because they already run an inventory-and-controls discipline for security and the muscle transfers. In larger or more AI-dependent firms it belongs to a dedicated role. If you want to see how I structure that as an outside hire while your team builds the internal capability, that is the shape of a fractional AI leadership engagement (/fractional-chief-ai-officer). The point is not the title. The point is that a person, not a mailbox, answers when the board asks.

The done test is unglamorous and it works. Is there a written charter naming the owner? Do the board minutes record that the board accepted the owner and the mandate? Can a random department head tell you who to call when their new tool starts doing something strange? If any of those is no, you have a diagram, not an owner.

One caution I give every executive who takes this on. Ownership means you get to say no, and you have to be willing to. A governance owner who has never once paused a deployment is a rubber stamp, and the organization learns that fast. The Credo AI comments to NIST make this concrete, describing how companies deploying AI often "lack governance tools to enforce standards, ensure compliance with regulations, or even have visibility on the risks created by the AI systems they are deploying" (https://www.nist.gov/document/ai-rmf-rfi-comments-credo-ai). Visibility and enforcement are the whole job. An owner with neither is decorative.

Step two: the inventory nobody wants to build

You cannot govern what you cannot see, and in an adopted-AI company you cannot see most of it. The AI is embedded in tools you already licensed, buried in vendor features, and running inside browser tabs your policy never contemplated.

Govern 1.6 asks for inventory mechanisms "resourced according to organizational risk priorities." That last clause is the one people skip, and it matters. You are not trying to catalog every autocomplete in every app on day one. You are trying to find the systems that touch money, customers, safety, legal decisions, or sensitive data, and you are willing to be rough about the rest for now.

Run the inventory three ways at once, because any single method misses too much.

Start with procurement and finance records. Pull every SaaS contract and every recurring card charge, and flag anything with a vendor that has shipped AI features in the last two years. Your CRM, your support desk, your HR platform, your marketing suite, your code tooling. Assume AI is on unless the vendor tells you it is off. This catches the embedded models that arrived in updates.

Next, ask the people. Send a short, blunt survey to every team: what AI tools do you use to do your job, including the ones you pay for yourself, and what do you put into them. Promise amnesty and mean it, because if the first honest answer gets someone in trouble, the second survey comes back empty. The Credo AI filing points out that risk gets "compounded by the number and variety of AI models and systems that may be implemented today across an enterprise," and a lot of that variety lives in individual habits your contracts never see.

Then watch the network. Your existing security tooling can show you what domains people hit and where data flows. That surfaces the shadow use the survey missed, the personal chatbot accounts and the browser extensions.

For each system that clears the priority bar, capture six fields and no more to start: what it is, who owns it in the business, what decision or output it drives, what data goes in, which vendor stands behind it, and whether a human sees the output before it acts. Six fields you will maintain beat thirty you abandon by March.

The done test: one register, not four spreadsheets in four departments. Every priority system present. A refresh date under a quarter old. If your inventory is a year old, it is fiction, because AI features ship monthly now and your vendors are not going to call you before they turn one on.

Step three: a threshold tied to what the business cares about

This is the step that separates governance from theater. Without a threshold, every AI system gets the same treatment, which means either you drown trying to review everything or you review nothing and call it "risk-based." NIST Govern 1.3 wants the level of risk management activity set "based on the organization's risk tolerance," and Govern 1.4 wants the process and its outcomes established "through transparent policies, procedures, and other controls based on organizational risk priorities."

The RMF is honest that this is hard. The framing document spends real time on risk tolerance and risk prioritization as open challenges, and it warns that AI risk measurement is genuinely difficult because these systems are socio-technical, trained on data that shifts, and hard to inspect when they fail (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf). So do not pretend to a precision you do not have. Tier by consequence, not by how sophisticated the model is.

Here is a rubric I have used that a board can read in one sitting. Three tiers.

High impact is any system where a wrong output can move money, make or heavily shape a decision about a person (hiring, credit, benefits, discipline), touch safety, expose regulated or sensitive data, or speak to customers or regulators in the company's name. If the output goes straight to a customer or a legal filing without a human in between, it is high by default.

Medium impact is a system that informs an internal decision a human still makes, or handles internal data that would be embarrassing to lose but not catastrophic. A meeting summarizer that a manager reads and sanity-checks. A drafting assistant for internal docs.

Low impact is everything with trivial blast radius. Spelling suggestions. Formatting help. Things where the worst case is mildly annoying.

The rule that makes the rubric bite: nothing high-impact keeps running without a documented review, and new high-impact use gets reviewed before it goes live, not after. Medium gets a lighter check and periodic sampling. Low gets logged in the inventory and left alone. That is the whole tolerance statement, and it is the sentence your executive owner and your general counsel sign.

One worked example, because the tiers only make sense against a real case. A regional lender I will keep anonymous had turned on an AI feature in its loan-origination platform that pre-drafted adverse-action explanations, the letters that tell an applicant why they were declined. Nobody had tiered it. Under this rubric it is high impact on two counts at once: it shapes a decision about a person, and it speaks to a customer in a regulated context. That single classification changed the conversation from "cool feature" to "who reviews these before they mail, and can we show a regulator the logic." The tool did not change. The threshold did, and the threshold is what surfaced the exposure.

The done test: a written rubric, every inventoried system carrying a tier, and a live trigger that stops a high-tier system short of review. If the tier is a column nobody acts on, you have a taxonomy, not a control.

Step four: the two or three controls that earn their keep

You can spend a fortune on AI controls. For a company at this stage, most of that spend is premature. Three controls carry the load, and they map directly to what NIST Govern asks for. Put these in before you buy anything shiny.

A human check on consequential outputs. For everything in the high tier, a competent person reviews the output before it acts, and that review is recorded. This is the oldest control in the book and it still earns its place, because it catches the confident, fluent, wrong answer that automated tests miss. Govern 1.2 asks that trustworthy-AI characteristics get built into policies and practices, and a human-in-the-loop requirement for high-impact decisions is the most concrete version of that. Watch the failure mode: review that becomes a rubber stamp because the reviewer has forty letters to approve in an hour. If you require review, resource it, or the control is a fiction that looks good in an audit and does nothing in practice.

Logging and retention you can query. For high and medium systems, keep a record of the inputs, the outputs, and who acted on them, on a stated retention schedule. I use twelve months as a starting default and stretch it where a regulator or a contract demands more. Logs are how you answer the two questions that arrive after any incident: what did this system do, and who relied on it. The Govern Playbook is full of documentation and monitoring expectations for exactly this reason, including establishing "the frequency of and detail for monitoring, auditing and review processes" (https://airc.nist.gov/airmf-resources/playbook/govern). Without logs, your incident response is a shrug.

Vendor terms that name AI. Since you adopted most of this AI through vendors, most of your real risk lives in their systems and their data handling. So your contracts and your due diligence have to name it. Ask each vendor behind a high-tier system a short set of questions: does your product use AI in this feature, does our data train your models, where does inference happen, how do you handle and disclose AI incidents, and what happens to our data when we leave. The Afiniti comments to NIST make the case that a governance program without privacy and cybersecurity attached "does not adequately mitigate the risks associated with predictive learning technology," and they push NIST to weave third-party risk through the whole framework (https://www.nist.gov/document/ai-rmf-2nd-draft-comments-afiniti). Your vendors are your third-party AI risk, and the contract is where you manage it.

If you have appetite for a fourth, add incident information sharing. CISA and the Joint Cyber Defense Collaborative published an AI Cybersecurity Collaboration Playbook aimed squarely at AI adopters, giving them a way to share incident and vulnerability information and, in return, get a picture of what is hitting everyone else (https://www.cisa.gov/resources-tools/resources/ai-cybersecurity-collaboration-playbook). CISA Director Jen Easterly framed it as shaped by roughly 150 specialists across two tabletop exercises (https://www.cisa.gov/news-events/news/cisa-jcdc-government-and-industry-partners-publish-ai-cybersecurity-collaboration-playbook). Worth knowing that the JCDC playbook scopes itself to cybersecurity and deliberately leaves AI safety and fairness to your own processes, so it complements the RMF Govern work rather than replacing it. It is voluntary, and for a company that just discovered how much AI it runs, joining a sharing loop is a cheap way to stop learning every lesson the hard way.

The done test across all of these: high-tier systems have a named human reviewer and evidence of review, logs exist on a written schedule and someone can pull them, and vendor contracts for high-tier systems carry AI-specific terms. Three yes answers. That is a defensible control set for where you are.

Step five: know how to turn it off

The step people forget. Govern 1.7 asks for processes to decommission and phase out AI systems safely, "in a manner that does not increase risks or decrease the organization's trustworthiness." In an adopted-AI shop this matters more than usual, because the AI is wired into tools other work depends on. Turn off the summarizer and maybe a downstream report breaks. Turn off a vendor feature and maybe a workflow stalls.

So for each inventoried system, write down two things: the condition that would make you retire it (the vendor drops support, a control keeps failing, the use case dies, a regulator moves), and the safe way to turn it off without breaking the thing next to it. You do not need a fire drill for every low-tier tool. You do need it for anything high-tier, because the day you have to kill a system fast is the day you least want to be improvising.

The done test: every high-tier system has a named retirement trigger and a documented off switch that someone has traced through its dependencies.

What this looks like on a ninety-day clock

I get asked for a timeline, so here is the honest one for a mid-market company. In the first two weeks you name the owner and get the board to ratify it, because everything else stalls without that. Weeks three through six are the inventory, run all three ways, and it will be messier and larger than anyone guessed. That surprise is normal and it is the point. Weeks six through nine you tier what you found and write the rubric. Weeks eight through twelve you stand up the three controls on the high tier first and let the rest wait. By day ninety you have an owner, a living inventory, a threshold your executives signed, and controls where the risk concentrates.

That is not a finished program. NIST is explicit that Govern is continual, that you keep executing it "as knowledge, cultures, and needs or expectations from AI actors evolve over time." What you have at day ninety is a floor you can stand on and answer for. For most boards asking the exposure question, a defensible floor beats the elegant program you will not finish this year.

If you want a second set of eyes on your version of this, that is the core of what I do on the advisory side (/advisory), and the fastest way to start is a conversation (/contact).

FAQ

We only use AI through vendor tools. Do we still need our own governance?

Yes, and arguably more than a company building its own models, because you have the risk without the visibility. The AI RMF Govern function repeatedly folds third-party systems into scope, and the Playbook's own suggested actions include verifying that your AI risk policies "include currently deployed and third-party AI systems" (https://airc.nist.gov/airmf-resources/playbook/govern). The Afiniti comments to NIST argue the same point, that third-party data and systems add risk that a governance program has to account for (https://www.nist.gov/document/ai-rmf-2nd-draft-comments-afiniti). The vendor owns their model. You own the decision to run it against your customers and your data, and that is the part you have to govern.

Is the NIST AI RMF mandatory, and what happens if we skip it?

The RMF and its Playbook are voluntary. NIST says so directly, and the Playbook page tells you it is "neither a checklist nor set of steps to be followed in its entirety," meant to be borrowed from as it fits your context (https://airc.nist.gov/airmf-resources/playbook). Voluntary does not mean optional in effect. It is becoming the common vocabulary for what good governance looks like, regulators and insurers are starting to reference it, and if you land in front of one after an incident, "we followed a recognized federal framework" is a much stronger position than "we improvised." Skipping it does not remove the risk. It just means you are carrying it without a map.

How is governing AI different from the IT and security governance we already do?

A lot of the muscle transfers, which is why I often park early ownership with the CISO. The difference NIST keeps flagging is that AI systems are socio-technical and their behavior drifts. They train on data that shifts, sometimes sharply and without warning, and they fail in ways that are hard to detect and harder to explain (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf). A patched server stays patched. A model that worked in March can quietly degrade by September because the world it was trained on moved. So the monitoring is continuous, the review is ongoing, and "we assessed it once at launch" does not hold the way it might for a static system.

Where does ISO/IEC 42001 fit with all of this?

Think of them as complementary. The NIST AI RMF gives you the outcomes and the vocabulary and costs nothing to adopt. ISO/IEC 42001 is the certifiable management-system standard your auditors and larger customers may ask you to hold. The Govern work in this playbook, ownership, inventory, a risk threshold, controls, and documentation, is the same substance a 42001 management system expects, so doing the RMF work first is not wasted effort if you certify later. Start with the free framework, get the substance right, and pursue certification when a customer or a regulator gives you a reason to.

We found way more AI in use than we expected. Is that bad?

It is normal, and finding it is the win. The Credo AI comments describe organizations that, even with a real commitment to doing this well, "lack governance tools to enforce standards, ensure compliance with regulations, or even have visibility on the risks created by the AI systems they are deploying" (https://www.nist.gov/document/ai-rmf-rfi-comments-credo-ai). The dangerous state is not a long inventory. The dangerous state is a short one that is wrong. A big, honest inventory means your amnesty worked and your discovery worked. Now you tier it and put your attention where the impact is.