Mid-Market AI Governance: Five Decisions, Not a Policy

What the enterprise version costs at your size, and what it does not buy.

Enterprise AI governance arrives as three artifacts, and each carries a hidden staffing requirement. A standing AI committee presupposes people whose job description includes attending it, which at this size means a recurring meeting with no deliverable. A model risk management framework presupposes a validation function independent of whoever built the system, a structure borrowed from bank supervision that collapses where the person who commissioned the build is also the person who would review it. A forty-page policy presupposes a compliance function to interpret it and a training program to deliver it. Without those, each artifact is a shape with nothing inside it.

Copied anyway, the failure is quiet. The document gets drafted, it circulates once, and it is filed. No decision inside it belongs to a person, and the usage it was written to control continues at the rate it did before, because nothing in it changed what anyone can log into on a Tuesday afternoon. The mismatch is the threat model. Enterprise governance answers a regulator and a board, so it produces evidence of process. What a mid-market company is exposed to is narrower: the confidentiality terms in agreements you already signed with your clients, the personal data you hold on employees and customers, and the few systems where a wrong output changes what the company believes to be true. None of that cares whether you held a meeting. It turns on which tool touched which record, and whether anybody could tell you so afterward.

The usage has already started, and a ban converts it into a blind spot.

Settle the factual question before writing any rule, because it decides which kind of rule can work, and the honest default is that somebody at your company put work into a consumer AI account in the last month. The reason is not carelessness. The tool is genuinely good at summarizing a long document, drafting a first-pass reply, and writing the message nobody wants to write at six in the evening. Every incentive an employee has points toward using it, and none point toward asking first.

A prohibition does not change that calculus. It changes whether you can see it. The person pasting a client agreement into a personal account under no policy keeps doing it under a ban, on a personal device, and stops asking questions because the question now has a disciplinary answer attached. Enforcement would require detection, and detection at this size does not exist. So the ban trades a behavior you could have shaped for one you cannot observe, and the company receives a paragraph in exchange.

The permissive version is not permission for everything. It is one sanctioned account with business terms, a short list of categories that go into no tool at all, and a named person to ask when a case is unclear. Compliance follows the path of least effort, so the sanctioned path has to be the easy one. If the approved tool is worse than the consumer version, or getting access takes two weeks and a request form, the rule has already lost, and the only question is when anyone notices.

A rule people route around carries a second cost. Once staff have learned that the AI rules are decoration, the guardrail that genuinely matters reads as decoration too. That is the mechanism at work when an expansion request hits a constraint nobody explained, described in why mid-market AI rollouts stall in month four. A constraint that was never made legible gets experienced as an obstacle, and the person who hits it disengages instead of asking.

Classify the data first, because every rule about tools is downstream of it.

Most mid-market AI policies fail at the same sentence: no confidential information may be entered into AI tools. It is unenforceable, not because anyone disagrees, but because confidential was never defined anywhere a person can check. Each employee draws the line privately and the lines differ widely. A salesperson reads a customer list as ordinary work product. The controller reads the same list as regulated personal data. Both are behaving reasonably against the standard they were handed, which is none.

Three tiers are enough, and the sorting rule is not sensitivity. It is whose promise you would be breaking. Tier one is material you would hand a competitor without flinching: marketing copy, published documentation, public filings. Tier two is internal operational material carrying no outside obligation: schedules, process documents, internal notes, non-personal metrics. Tier three is anything you hold under someone else's promise, which means client files and financials, personal data on employees and customers, privileged material, and anything covered by an engagement letter, a nondisclosure agreement, or a carrier requirement.

The deliverable is one page. Three tiers, a handful of examples under each in your own vocabulary rather than a template's, the systems where each tier normally lives, and a default for anything unlisted, which should be tier three. That page makes every later rule checkable by somebody with no training. Tier one goes anywhere. Tier two goes in the sanctioned tool. Tier three goes only into systems named on the page. An employee holding a document can answer the question in four seconds without finding anyone.

This is a different exercise from asking whether your records are usable, which is the subject of data readiness for one named workflow. Readiness asks whether a system can query the inputs a process depends on. Classification asks what you owe on them and to whom, and a company can pass one while failing the other. It is also the prerequisite that the security questions worth asking before an AI build ends on, since a buyer with no internal standard has nothing to evaluate a vendor's answers against.

The five decisions, and the name that has to sit beside each one.

A decision with an owner is enforceable and a paragraph without one is not, which is the whole difference between what follows and a policy. The first decision is who may approve a new tool. One name, and three checks: which tier of data the tool will touch, whether its terms permit business use and exclude your inputs from training, and whether it can take an action or only produce text. That question gets deeper when you are commissioning a build rather than buying a subscription, worked through in how to choose an AI consultant for a mid-market company.

The second decision is what data may go where, which is the classification page and nothing more. The third is which outputs require a person before they leave, and that line is drawn by consequence rather than importance. Anything reaching a client, a counterparty, a regulator, or a record of account gets a human signature. Anything staying inside as a draft, a summary, or a suggestion does not. Drawing it loosely is the common error, because a review requirement applied to everything is abandoned within a month and then applies to nothing.

The fourth decision is what gets logged and for how long. At this size that means three things: an inventory of which AI accounts exist and who holds them, prompt and output retention on the sanctioned tool set deliberately rather than left at a default, and a record of the fact of use for anything touching tier three. The fifth is who owns the answer when an output turns out to be wrong, which is the decision most companies never make at all.

Naming is the part that gets skipped, and skipping it turns the page back into a document. The owner cannot be the leadership team, and usually should not be whoever handles IT, because four of the five are about obligations rather than systems. At most companies in this range it is the COO or the senior operations person, someone whose job already includes noticing when a process drifts. The predictable wrong answer is whoever championed the first build, since that person's attention returns to their own responsibilities the month after it ships.

Provisioning does the enforcing, because a rule is only as strong as the account behind it.

The strongest control available to a mid-market company is not written down anywhere. It is which accounts exist. Nothing in a policy binds an employee the way the absence of a login does, and nothing makes usage visible the way a company-issued account does. If you take one action out of this memo, provision a business tier of one general purpose tool for the people who need it, through whatever identity provider already handles your email.

What that purchase buys is not features. It is jurisdiction. A business agreement rather than a consumer one, which normally means your inputs are excluded from training by contract instead of by a setting an employee can flip. An administrative console, so the inventory question has an answer. Retention you can configure. The ability to revoke access the day somebody leaves. The same person doing the same task on a personal login gives you none of that.

The purchase is usually small enough to sit below whatever threshold requires a discussion, and it is the only line item in this exercise that changes what happens on a Tuesday.

Every additional tool is another party holding a copy of whatever gets pasted into it, which is why decision one exists at all. The count of places your records come to rest grows through single, individually reasonable purchases.

Who owns the answer when an output is wrong, and how you find out at all.

Every governance template has an incident section, and it is written for a breach: unauthorized access, disclosure, notification obligations, a clock. That is the wrong shape for the failure a mid-market company will actually have. The realistic incident is a wrong output nobody flagged. A figure in a quote that no person checked. A date in a client letter the summary got backwards. A recommendation that dropped the exception a long-tenured employee would have caught. It produces an awkward client conversation, not a notification.

Two things make that governable, and neither is a document. The first is a name, reachable without anyone having to decide whether the thing is serious enough to escalate. The second is a standing instruction that reporting is expected and repairing quietly is not. Absent the second, the person who catches the error fixes the letter and says nothing, because it feels small and mentioning it feels like blaming a colleague, and the same error ships again next month to someone else. The pattern stays invisible because each instance was handled well.

Then you have to be able to reconstruct what happened, which is the practical reason to log anything at this size. Not to satisfy an auditor. To answer a question that arrives three weeks late: which tool produced this, what was given to it, and who was on it. Where nobody can answer that, the response to a wrong output is a conversation about impressions.

A run of unflagged wrong answers is also the most common thing sitting underneath a system that quietly stopped being used, which is where a post-mortem tends to land when you work through what to do after a failed AI pilot. Confident and wrong is the combination that teaches everyone to verify every output, and verification eats the time the tool was bought to save.

Two companies that should skip most of this, and one that needs a lawyer instead.

We are hired to build custom AI systems, so read a memo telling you to write less and buy less with that in mind. There are still situations where everything above is a way to spend a quarter. The first is the company whose work already happens inside a platform it pays for. If the AI features in your CRM, help desk, or productivity suite are where the drafting and summarizing happen, procurement already made most of these decisions for you: the agreement was negotiated, access rides on identity you already manage, retention is configurable in a console, and the log exists. A policy on top of that adds a document rather than a control. Which way that trade runs at volume is taken up in the build versus buy decision for a mid-market company, but on governance the incumbent usually wins by default.

The second is the company that should write nothing at all. Under roughly thirty people, with one category of sensitive material and no system that can change a record or send anything outside the building, five decisions is four more than the situation calls for. Name one person who approves tools and who says out loud which two or three things never go into any of them, and stop there. A policy program at that size is a way to look responsible while nothing changes.

The third is the company that genuinely is regulated, and this is where a consultant is the wrong purchase. If you handle protected health information, client funds, retirement plan data, insurance claims, or privileged material subject to court rules, your obligations live in specific instruments: statutes, engagement letters, carrier requirements, court orders. No governance framework from a build shop substitutes for counsel who has read the instruments that bind you. An hour of a lawyer's attention on the two or three categories that matter beats a quarter of internal drafting, and that work should go to a lawyer rather than to us.

Work out which of these you are in before funding a program, because a program is easier to begin than five decisions and it feels like the same activity while it is happening.

What to put on one page this week, before anyone approves anything.

Two hours produces most of the value, and none of it involves a vendor. Start with the inventory, since it is the only purely factual part. Pull the last two months of card statements and expense reimbursements, then ask whoever administers your email for the list of applications people have signed into with a work address. Write down every AI tool already being paid for or logged into. That list runs longer than expected almost every time.

Then the classification page: three tiers, your own examples, the systems each tier lives in, and tier three as the default for anything unlisted. Then the five names, written before any of the wording. If a decision has no name beside it, it has not been made yet, and no amount of wording will make it so.

Then have the conversation that does more than the page. Tell the people already using these tools what the sanctioned account is, what may never go into any tool regardless of account, and who to tell when something comes back wrong. Do that before the document exists, because the conversation is the control and the document is only the record of it.

That page is also the input a real scope starts from, since which outputs need a person on them is the same question as what a system is allowed to do, and it is where the diagnosis we run begins. If you have not settled which process is worth investing in first, the AI Maturity Index gets you to a named workflow and to whether its output goes to a person or into a record, which is decision three answered before you write it down.

Field-note context

What we look at when an operator asks for an AI policy.

The committee is where the decision goes to wait.

The instinct to form a group gets one thing right: these decisions touch legal exposure, operations, and technology, and no single person holds all three perspectives. It gets the instrument wrong. A committee is a body that meets, and a body that meets produces attendance rather than decisions. The workable version at this size is one owner per decision plus a standing obligation to consult, which is a sentence rather than a calendar invite: whoever approves tools checks with whoever holds the client contracts before approving anything that will touch tier three. That keeps the multiple perspectives and removes the meeting. It also fixes accountability, which a committee structurally cannot, because a decision made by a group is a decision nobody has to defend. The test is worth running on any structure being proposed to you. A manager wants to use a new tool on Thursday. What happens. If the answer involves waiting for the next meeting, the structure has already told you what that manager will do instead.

The rule people route around was written without them.

Rules that get ignored share a shape. They were written by somebody who does not perform the work, they were never explained in terms of what could actually go wrong, and they arrived without a permitted alternative. A prohibition on putting client material into an AI tool, delivered to a team with a real reason to put client material into an AI tool, offering nothing in its place, describes a problem rather than solving one. The cheap fix is fifteen minutes with the three or four people who do the task most. Ask what they use it for now, which parts would be genuinely painful to give up, and what would make the sanctioned route easier than the unsanctioned one. That conversation usually produces a better rule than a template does, because the people doing the work know where sensitive material actually enters the process, which is rarely where a policy assumes. It also turns them into the enforcement mechanism, which matters more than the wording, since they are the only ones positioned to notice a colleague being careless.

The consumer account is a contract nobody read.

The gap between an employee using a consumer AI account and the same employee doing the same task on a company account is almost entirely contractual, which is exactly why it is invisible to the person doing the work. Consumer terms and business terms differ on the points that determine your exposure: whether inputs may be used to improve the provider's models, how long conversations are retained and who can retrieve them, whether the provider is handling the data on your instructions or on its own account, and whether anyone at your company can administer or revoke the access. On a personal login the employee is the customer and the company is not a party to anything. That is most of the risk in mid-market shadow usage, and none of it is a technology problem. Reading two paragraphs of the business terms for whichever tool your staff already prefer gets you to a defensible position faster than any amount of internal drafting, because it tells you which of your worries the contract already handles and which ones need a rule.

Extended questions

The questions operators ask before writing any of this down.

What should a mid-market AI policy actually contain?

Five decisions with a name written beside each one, and a data classification page underneath them. The decisions are who may approve a new tool and what that person checks, what categories of data may go where, which outputs require a person to sign off before they leave the company, what gets logged and for how long, and who owns the answer when an output turns out to be wrong. The classification comes first, because none of the tool rules can be written before you can say which records carry an obligation you owe somebody else, and three tiers sorted by whose promise you would be breaking is enough. That is one or two pages in total. What it should not contain is a standing committee, a model risk management framework, or forty pages of language borrowed from a company with a compliance department, because each of those presupposes staff you do not have and produces evidence of process rather than control over usage. If a line in the document has no owner, it is not a rule yet.

Do we need an AI committee or an AI governance framework?

Almost certainly not at $8M to $50M. Both instruments assume a division of labor that does not exist below a few thousand employees. A committee assumes people whose job description includes attending it, and a model risk framework assumes a validation function independent of whoever built the system, which is a structure borrowed from bank supervision. Copied into a mid-market company they produce meetings and a filed document while actual usage continues unsupervised. What replaces them is one owner per decision plus a standing obligation to consult whoever holds the relevant exposure, which preserves the cross-functional judgment and removes the calendar. The test worth running on any structure somebody proposes is what happens when a manager wants to use a new tool on Thursday afternoon. If the honest answer is that it waits for the next meeting, the structure has already told you what that manager will do instead, and it is not waiting. Accountability improves too, since a decision made by a group is a decision nobody has to defend afterward.

How should we handle employees already using ChatGPT at work?

Assume it is happening, then make the sanctioned path easier than the unsanctioned one. A prohibition changes only one thing, which is whether you can see the usage, because enforcement requires detection that a company without a security team does not have. The person pasting a client document into a personal account continues on a personal device and stops asking questions, so a visible behavior you could have shaped becomes an invisible one. The workable sequence is to provision a business tier of one general purpose tool through the identity provider you already use for email, name the two or three categories of material that go into no tool regardless of account, and tell people who to ask when a case is unclear. Talk to the three or four people who use it most before writing anything, because they know where sensitive material actually enters the process. Nobody should be disciplined for what they did before a sanctioned account existed, and saying that out loud is what gets you an accurate picture of current usage.

Which AI outputs need a human to review them before they go out?

Draw the line by consequence and reversibility rather than by importance. Anything that leaves the company or changes a record of account gets a person: client communications, quotes and pricing, filings and submissions, anything sent to a counterparty, and any write into a system of record where a wrong value quietly becomes the company's official version of a customer, a balance, or a case. Anything that stays internal as a draft, a summary, a suggestion, or a search result does not, because the reader is already the reviewer and a wrong answer costs a few seconds of attention. The common error is drawing the line too broadly. A review requirement applied to every output is abandoned within a month, and once it is abandoned it protects nothing, including the cases that genuinely needed it. Requiring a signature on a narrow set of outputs and actually getting it beats a universal rule that decays into a formality. Name the reviewer by role, and check that the volume is something that role can absorb in a normal week.

Who should own AI governance in a company without a CISO?

A single named operator, usually the COO or the most senior operations person, with the decisions split by exposure rather than by technology. The reason it should not default to whoever handles IT is that four of the five decisions are about obligations and consequences rather than systems: which records carry a promise to a client, which outputs are consequential enough to need a signature, and what the company wants to be able to reconstruct later. The reason it should not be the leadership team collectively is that shared ownership of an operational decision is the same as no ownership. The predictable wrong answer is whoever championed the first AI project, since that person's attention returns to their own responsibilities the month after it ships, which is one of the more reliable ways a working system quietly stops being maintained. The owner needs the authority to say no to a tool and the standing to be told when an output was wrong, and the name belongs somewhere staff can find it without asking.

How does the AI Maturity Index help us write this?

Most of the difficulty in writing any of this comes from trying to answer it for a whole company at once, and the Index removes that by forcing you to pick one process. It asks who handles that process, how often, and which systems feed it, which is most of what a data rule needs in order to name real systems instead of vague categories. It also establishes what the process delivers at the end, an answer somebody reads or a change written into a record, and that fact settles decision three rather than leaving it to be argued later. Ten minutes and no call, and what comes back is resolution: the classification page and the review line stop being abstract questions about the business and become short questions about one workflow. That is the altitude where governance is writable, and also where it stays short enough for anyone to read it.

AI governance without a CISO, and the five decisions that replace the policy.