In most mid-sized companies, AI is already in the building. It rarely came through the front door. No board approved it and no IT budget paid for it: someone in marketing started drafting proposals with an assistant, someone in finance pasted a report into a chat window for a quick summary, and a vendor switched on a new feature in a system the company was already paying for while nobody read the release note.
By the time the topic reaches the leadership table, the question is almost always the same one: which tool should we buy? It is a fair question, but it is out of sequence. Buying technology to govern a practice you have not yet mapped is like insuring a warehouse without knowing what is inside.
AI governance is not a technology project. It is a governance exercise, and the same one the company has already run before, for cash handling, signature authority, or system access: decide what is allowed, who is accountable, how it gets documented, and how often it gets revisited.
Doing that work first does not slow technology adoption down. It is what makes adoption possible. A company that already knows what it uses, with what data, and at what level of exposure can hold a useful conversation with a vendor and judge a proposal on its own terms. A company that does not know is buying blind and usually buying more than it needs.
Start with the inventory: you cannot govern what you do not know exists
The first step costs no money. It costs organizational honesty.
Building the inventory means answering four things for every tool in use: who uses it, what for, what information goes into it, and what happens to what comes out. It sounds basic, and it is. It is also precisely where most companies that claim to have an AI governance problem, stop.
Two practical warnings. First, much of the AI already running inside the business was never bought as AI. It arrives embedded in the CRM, the ERP, the office suite, and the recruiting platform. An inventory that only asks about chat assistants will come back short.
Second, if the exercise feels like a hunt, the answers will be incomplete, and an incomplete inventory is worse than none because it manufactures a false sense of control. The point is not to find out who broke a rule that did not exist yet. The point is to find out where you stand.
And the inventory is not a one-time document. It is a living list with one named owner.
Policies people can follow, not documents for the archive
A forty-page AI policy nobody reads protects nobody. At best it protects the feeling of having done something.
What works is a short document that answers a handful of questions clearly and then turns into real procedure:
What information never leaves the organization?
Personal data on customers and employees, contract terms, non-public financials, source code and intellectual property. The rule must be specific enough that someone can apply it without calling anyone for guidance.
Which use needs approval, and who grants it?
With criteria and with turnaround times. If approving a new tool takes six weeks, the team will keep using whatever it wants and simply stops mentioning it.
Which decisions are never delegated without human review?
Anything that affects a person, including hiring, performance, credit and collections, and anything that leaves the building as your own deliverable. The system suggests; a person signs.
How do you document what was used?
When a customer, a partner or an auditor asks how the company reached a conclusion, “the system suggested it” is not an answer. The ability to reconstruct the path, usually called explainability, must be built before you need it, not once someone is already asking.
None of these four points requires buying anything. They require deciding. And they are leadership decisions rather than IT decisions: the technology team can implement controls, but it should not be the one deciding on its own how much risk the business is willing to carry.
A policy nobody knows about does not exist
The real gap is not between companies that have an AI policy and companies that do not. It is between companies where the policy lives in daily work and companies where it lives in a shared folder.
Closing that distance takes four moves, and all four are about communication before they are about technology.
Explain the reasoning, not just the rule. A team that understands what happens when a contract gets passed into a public tool, who else might see it and which clause is being breached, complies far better than a team that simply was told not to do it.
Train by role. What the sales team needs to know is not what finance needs, or HR. A generic one-hour session for the whole company is forgotten within a week.
Reinforce at the point of use. Reminders where the work happens, real cases discussed openly in meetings, including your own mistakes, which teach the most, and an easy channel for asking “is this allowed?” without it costing anyone credibility to ask.
Measure whether it is working. Not through training attendance, which measures nothing, but through behavior: how many new tools were reported voluntarily, how many questions come through the channel, how many incidents were caught and how quickly. If nobody ever asks anything, that does not mean everything is fine. It means nobody is looking.
Annual review is not enough: technology does not wait for your calendar
Most corporate governance frameworks assume an annual review cycle. For AI, a year is an eternity. In twelve months, the capabilities of the tools change, so do vendor terms of service, and so do the features that quietly ship switched on by default in software you already run.
My recommendation, and this is my own judgment rather than an established standard, is to run two clocks. A calendar clock: review the inventory quarterly and the policy a couple of times a year. And a trigger clock: review when a vendor changes its terms, when a new capability is enabled in a system already in use, when the company enters a market or signs a contract with different requirements, or when the applicable legal framework shifts.
That last point deserves to be said plainly. AI regulation is moving in several jurisdictions, and nobody should assume that what applied a year ago still holds today. I would verify the current position with local legal counsel before making any decision that depends on it.
What you risk by leaving this until last
There is a comfortable and widespread assumption: “that is a problem for banks, we are not regulated.” It is an incomplete reading.
Data protection obligations apply to any company handling customer and employee information, whatever the sector. Confidentiality is not imposed by a regulator; it is imposed by the contracts the company has already signed with its customers, and those contracts rarely anticipated information being processed in third-party tools. And explainability will be demanded by a major customer during a procurement process long before any auditor asks.
The risks of skipping this groundwork are not abstract: sensitive information leaving through tools nobody authorized; breaches of confidentiality clauses signed without this in mind; decisions that cannot be explained or reconstructed when someone asks; dependence on vendors whose terms and behavior are not understood. And the most expensive one of all: finding out about the problem when someone outside the company is already asking.
The underlying point is that governance you do not build at the start gets built later, at higher cost, with the mess already inside. Getting the order right first, meaning inventory, rules, communication and cadence, is not a brake on technology adoption. It is what lets you understand which solution you actually need and evaluate it without depending on what the vendor tells you.
This article was co-created with the assistance of artificial intelligence under supervision, editing, and verification of our team.