AI Governance

What every executive should know

1. 1. Governance is a short list of owned decisions, not a document

   The instinct when a topic feels serious is to write a policy about it. A policy is necessary, but it isn't governance by itself. Governance is what happens when someone specific is responsible for a decision, that decision is written down, and something checks that it's actually being followed. A policy with no owner and no enforcement is a paragraph, not a program.

   The fastest way to tell which one you have: ask who is responsible for AI decisions at your company right now, by name. If the honest answer is "nobody, really," you have a document at best, not governance.

2. 2. What a usable AI policy actually says

   A policy that works fits on a couple of pages and answers the questions employees actually run into, not the questions a lawyer finds interesting:

   • Which AI tools are approved for use, and which account type, personal or business-tier, is required.
   • What information may never be entered into an AI tool, the data types from Briefing 3.
   • Which uses require a human review step before the output reaches a client, a contract, a financial figure, or a public statement.
   • When AI use must be disclosed, particularly for client deliverables.
   • Which decisions can never be handed to AI at all: hiring, discipline, compensation, termination, financial sign-off, legal judgment, and safety-critical calls.
   • Who the policy applies to, which should be everyone with access to company systems and data, not just staff, and what happens when it isn't followed.

3. 3. Disclosure, consequences, and who the policy covers

   That disclosure requirement is worth pausing on. A policy that requires disclosing significant AI involvement in a deliverable doesn't just set an expectation. It gives you a defensible answer when a client or a regulator asks how something was produced, and it removes the ambiguity that let the behavior happen quietly in the first place.

   The last bullet is worth pausing on too, in both directions. First, consequences: a policy that says what's prohibited without saying what happens if someone does it anyway isn't really a policy, it's a suggestion. The consequence doesn't need to be severe by default. It needs to be defined in advance and scaled to what happened.

   Second, scope: it has to apply to ownership and leadership too, by name, not just to employees. This is easy to get backward. The instinct is to write the policy for the people leadership is worried about, which usually means staff, and leave an unstated assumption that the owner or the executive team is trusted enough not to need it. In practice, ownership and leadership often have the broadest access to the most sensitive information in the business, financials, strategic plans, acquisition talks, so exempting them isn't the low-risk choice. It's frequently the highest-risk one.

4. 4. What actually enforces the policy

   Here is what a reasonable starting set of software controls looks like in practice:

   • Business-tier or enterprise AI accounts issued to employees, instead of relying on personal accounts nobody tracks.
   • Multifactor authentication on every AI account.
   • Role-based access, so the accounting team's AI tool access looks different from the marketing team's.
   • Network-level controls that restrict which AI tools and websites are reachable from company devices.
   • Logging on approved tools, so there's a record of what was used and when.
   • None of this requires exotic technology. Most of it is a configuration decision inside tools your business likely already has, made deliberately instead of left on the default setting.

5. 5. Someone has to own it, specifically

   Every one of the following needs a name next to it, not a department: who approves a new AI tool before anyone uses it, who reviews a vendor's terms of service before that tool touches company data, who is told when something goes wrong, and who keeps track of which AI tools are actually in use across the business.

   This does not need to be a full-time role or a committee. In most businesses this size, it's a meaningful slice of one person's existing job, with clear authority to say yes or no, including the authority to hold ownership accountable to the same policy everyone else follows.

6. 6. Keep a running inventory, not a one-time list

   The fix for shadow AI isn't a one-time audit. It's a living list: which AI tools are in use, which department uses them, what data they touch, what account type they run on, and when their vendor terms were last reviewed. A list you build once and never update is already out of date by the time you need it.

7. 7. Train people on the specific failure modes, not AI in general

   Governance-relevant training is narrower and more useful than generic AI training: which accounts to use, what data never goes into a prompt, when a human review step is required, and what needs to be disclosed. Fifteen focused minutes on your actual policy beats an hour on AI in general.

8. 8. Review it on a schedule, not when something breaks

   A policy and a set of controls are a starting point, not a finished project. A short, recurring leadership review, quarterly is enough for most businesses this size, is what keeps governance from quietly going stale six months after it was written.

Action plan

This is the fourth in an eight-part series designed to give your leadership team a shared, working understanding of AI, without turning your business into a training exercise.