Build the AI inventory before you write the AI policy

Most AI governance programmes begin with a policy document. Most of them stall about six weeks later, when someone asks which systems the policy applies to and nobody can answer.

Why does starting with a policy fail?

Because a policy is a set of rules about a population you have not defined yet.

Written first, it inevitably describes the AI the authors could think of: the models the data science team built, the chatbot marketing launched, the tool everyone argued about. Those are visible, already supervised, and rarely where the exposure is. Meanwhile the AI that would actually fail an assessment is sitting inside a purchased HR platform, quietly scoring candidates, because a vendor shipped a feature and nobody logged it as an AI decision.

An inventory built first tells you what the policy has to cover. It also tells you, usually uncomfortably, how much of your AI estate you do not control.

What belongs in an AI system inventory?

Keep it smaller than you think. An inventory that takes nine months to build is a project, not a control. For each system, record:

• What it does, in a sentence a non-specialist would understand.
• Who owns it, by name.
• Whether you built it, bought it, or it arrived inside something you bought.
• What decision it affects, and who is on the receiving end of that decision.
• What data goes in.
• Whether a person reviews the output before it has an effect.
• Which vendor and which model, where you can establish that.

That last field is where most inventories go soft. Vendors change underlying models without announcement, and a system you assessed against one model may be running on another six months later. Record what you know, note what you cannot establish, and put the question into your next contract renewal.

How do we find AI we did not build?

Four sweeps find most of it.

Through procurement. Every SaaS contract signed in the last three years, read for AI, machine learning, automated decision, or scoring. Renewal dates matter here too, because a renewal is your only real leverage.

Through the software register. Ask IT for the list of approved applications and work through the feature releases. Most vendors added AI features recently and announced them as improvements.

Through the business. Ask each function what it uses to make decisions faster. Do not use the word AI. People do not describe their tools that way, and the question "what helps you decide?" surfaces things "do you use AI?" never does.

Through the network. Whatever your staff have adopted without telling anyone is visible in traffic and in expense claims. This sweep is usually the most uncomfortable and the most productive.

How do we tier what we find?

By consequence, not by technology.

The question is not how sophisticated the model is. It is what happens to a person when it gets something wrong. A system that drafts internal meeting notes and a system that influences someone's credit, employment, housing or care are different problems, however similar the architecture.

A workable first cut is three tiers: systems that affect a person's rights or access to something material; systems that affect money or safety without directly affecting an individual; and everything else. Concentrate your first round of assessment on the top tier and be explicit that the bottom tier is deliberately unassessed for now. That is a defensible position. Silence is not.

When does the policy get written?

Once you know what you are governing, and ideally once you have assessed a handful of top-tier systems, because the assessment tells you which rules would have actually helped.

Policies written after the inventory tend to be shorter, more specific, and harder to argue with. They also survive contact with the business, because they were built from what the business was already doing rather than from a template.