AI Governance Policy: What to Include, and How to Prove It

Write the policy as two lists and a few rules. That is the short answer. List what AI may be used for. Then list what it may not do, and the data that never goes in.

Say who approves a new system. Say where a person signs off. That is before AI output reaches a customer, a regulator or a payment. Then cover the rest. What may vendors do with your data? Who do you call when things go wrong? When is the page next reviewed?

Next, keep an inventory. That is a list of your AI systems, with an owner beside each one. Make sure each system can show a record of what it did. And report four numbers to the board every quarter.

We call that the One-Page Answer. The rest of this guide is how to fill it in well.

What should an AI governance policy include?

Eight sections, each a sentence or two. The sample wording is ours, as an example. Your lawyer adapts it to your field and where you do business.

Use "may" and "may not." Skip "should consider."

A policy that needs a table of contents will not be read. And rules no one reads govern nothing.

Why a policy alone fails

Board members seldom stop at "do we have a policy?" The next question is always some form of "show me why it did that."

So the One-Page Answer has three more working parts. They are the inventory, the evidence and the reporting line.

Run one dispute through two firms to see the gap. An AI assistant told a client her claim fell outside the window. She disagrees, and her lawyer sends two paragraphs. Your in-house lawyer asks three things. What did the system see? What did it say? And who checked?

At Company A, the assistant is a widget a vendor switched on in July. The vendor's dashboard keeps a summary of each chat, not the chat. Someone in marketing edited the prompt twice. No one wrote down which version was live that day. Three people spend a week piecing it together. What they rebuild is a guess with good manners.

At Company B, every answer is stored with the source file and page it came from. The line that backed it up is stored too. Every model call is traced. The rule behind the answer was changed on a known date, by a named person, with a sign-off. The lawyer opens one record and reads it.

Both firms had a policy. Company A's was nicely formatted.

How to build an AI inventory

An AI inventory is a list with one row per AI system. Each row says what the system does and who owns it. It says what data the system touches, and which vendor and model sit behind it. It says whether the vendor may train on your data. And it says who approved it, and when.

The rows people miss are the ones they didn't build. Your CRM, your support desk and your meeting software may all have added AI since you signed. If a model writes, decides or suggests things inside them, it goes on the list.

NACD, the National Association of Corporate Directors, is a US group for board members. Its boardroom tool asks about this straight out. "Are policies and procedures in place to address AI risks from third-party software and other supply-chain issues?"

Here is a quick test. Ask three team leads which AI tools their teams use. Then compare their answers with your list. The gap is the finding.

What evidence should each AI system produce?

Evidence is the record that lets a stranger work out what a system did. They should not need to ask the people who built it. For every row on the list, answer six questions yes or no:

1. Can we show the source file and page behind any answer?
2. Can we show every model call: input, output, time and cost?
3. Is access limited by role in the database, not only in the app?
4. Does a named person sign off before an output has an effect that matters?
5. Can we switch the system off today, and does one named person know how?
6. Do we own the code, the accounts and the keys?

A "No" is fine. A blank is the problem. Every No becomes a line in the next budget, with a name and a date beside it.

Proof is cheap when a system is built to make it. It is costly to bolt on after launch.

We build every system to answer yes to all six. Access is checked row by row inside the database, on every query. That is called row-level security. Each value pulled from a file is stored with its source and the passage that backs it up. Every model call is traced, using OpenTelemetry and Langfuse. And people approve where it matters.

Whoever builds yours, ask for all six in writing before the contract.

123

1. 1The rules in force. Every answer names the version of the policy it used.
2. 2A source stored with every value. Act, part and section, with the passage that backs the answer.
3. 3Humans approve where it matters. A protected topic waits for a senior consultant.

What will the board ask about AI?

You don't have to guess at the questions. Two sets are published.

Gartner has a guide of eight questions boards should ask about an AI plan. It covers four topics, listed in the table below. The NACD's boardroom tool asks things like these:

• "Have we established an AI governance board or committee?"
• "Who will lead our AI effort, and what makes them qualified to do so?"
• "How do we measure success?"

Here is where the One-Page Answer meets each of Gartner's four topics. The mapping is ours, not Gartner's.

Which framework should an AI governance policy follow?

Start with NIST's AI Risk Management Framework. NIST is the part of the US government that writes tech standards. Its framework came out in January 2023. Using it is your choice.

It groups the work into four parts: Govern, Map, Measure and Manage. NIST added a Generative AI Profile in July 2024.

Our one page lines up with it well. The mapping is ours again. The policy and its owners are Govern. The inventory is Map. The six checks are Measure. The incident and review rules are Manage.

If you sell into the EU, the AI Act adds hard rules for systems it calls high-risk. Article 14 says those systems must be built so the people watching over them can:

• Know the system's limits.
• Stay aware of the pull to over-rely on its output.
• Override or reverse that output.
• Stop the system through "a 'stop' button or a similar procedure."

The sign-off section and the switch-off check are where that lands. For how to design the sign-off step itself, see our guide to human in the loop AI.

Which rules apply to you depends on your field and where you do business. That reading belongs to your lawyer. The page is the frame that reading sits on.

Do small companies need an AI governance policy?

Yes, sized to the company. With two AI tools, your list has two rows. The rules fit in half a page.

Picture a firm with two systems. It can't say what they do, who owns them or what data they touch. That firm has a bigger problem than one with twenty that can.

The board's question does not shrink with headcount. The page does.

When not to write one, and when it turns into theater

You have no AI in use and none planned. Write the eight sections and leave the inventory empty. Put a date on the next review and go back to work. Don't pay for a program to govern nothing.

It has no owner. A page without a name beside it is a draft. Put a name on it or don't send it.

No one enforces it. The page says a person approves what customers see. Meanwhile, the support team sends AI drafts unread. That is worse than no policy. The board finds out the first time someone asks for the evidence.

It pretends to be the legal reading. It isn't one. It is the frame your lawyer's reading sits on.