How much AI governance does a company your size need

Ask what governance a mid-sized company needs for AI and the answer comes back the same every time: stand up a centre of excellence, hire a lead, write a policy. For a company of two hundred people that advice is not cautious. It is the wrong shape, and it usually ends with an expensive hire supervising work that has not started.

Key takeaways

• Governance should be sized to the number of active users and the risk they can reach, not to how important the topic feels.
• Below roughly a hundred users, one person with protected time beats any structure.
• A centre of excellence with its own build team is the right answer above a few hundred users, and premature below that.
• Hire the person who owns a process before the person who owns the technology. The reverse order produces tools nobody adopts.
• Whatever the model, the deciding question is who fixes it when a source system changes.

The default advice and why it misfires

The centre of excellence became the standard recommendation because it was written for organisations with thousands of users, several regulators and a dozen systems that must not break. In that setting it is sensible.

Copied into a company of two hundred, it produces something else. The unit exists before the demand does, so it spends its first year writing standards nobody has asked for. Meanwhile the actual work continues quietly in spreadsheets, outside whatever the new unit governs. Two years later the company has both a policy and no visibility, which is the worst combination available.

The useful question is not what good governance looks like in general. It is what the smallest structure is that answers three things: who decides, who knows what exists, and who repairs it.

Four models and the threshold for each

Model	Fits around	Costs	Breaks when
One person with protected time	Up to 100 active users	One day a week	Requests arrive from several departments at once
A network of owners in teams	100 to 300 users	A few hours weekly per team	Nobody keeps a shared view of what exists
A small central unit that does not build	300 users or a regulator	Two to four people	Delivery queues form behind it
A centre of excellence with a build team	Above a few hundred users	A team plus a budget line	Demand does not justify the standing cost

The thresholds are ranges, not rules. What moves a company up a row is rarely headcount alone. It is the arrival of a second department with its own requests, or a regulatory obligation somebody must track continuously.

One person with protected time. Someone gets a day a week, keeps the list of what exists, answers questions and rules on the doubtful cases. The paperwork is one page and a spreadsheet. It looks improvised and it is usually enough for the first year.

A network of owners. One person per team, a few hours weekly, close enough to the work to see what is being built. They do not approve. They know, and they escalate what needs a decision. This is the model that fits most mid-sized companies and the one least often proposed to them.

A small central unit that does not build. Two to four people running intake, classifying risk and holding the standards, while the building stays in the teams. The moment this unit starts delivering solutions itself, a queue forms behind it and the model has failed.

A centre of excellence with its own build team. Justified when demand is continuous and large enough that a standing team is cheaper than repeated projects. Below that, the standing cost is real and the demand is not.

What the role actually costs

The cost that surprises people is not the salary. It is that the role only works if the time is protected. A person given this alongside a full job will do it for six weeks and then stop, because the day job has deadlines and this does not.

So the honest budget line is a fraction of a person, stated in hours, defended by whoever set it. A day a week that survives a busy quarter is worth more than a full-time role that arrives in month nine.

The second cost is continuity. Every model above rests on somebody being able to answer what happens when a source system changes. If that answer is a name in each row of the table, the model holds. If it is a role that turns over, or an external supplier on a support contract, the company has bought availability rather than knowledge.

Hiring, and in what order

Most companies hire the technical person first. It feels like the safe order and it is the expensive one, because a strong engineer with no mandate builds tools that are correct and unused.

The first hire, or first reassignment, should be someone who owns a process and is trusted by the people who run it. That person knows where the time goes, which is the only reliable source of use cases. Technical capacity can be bought by the week. Credibility inside the organisation cannot.

When the technical hire does come, the useful test is not model knowledge. It is whether the candidate can describe what they would do when an interface changes under two hundred running automations. Anyone who has maintained something in production answers immediately. Anyone who has only built answers vaguely, and maintenance is the part you are hiring for.

FAQ

We have 150 people. Do we need a policy?

You need a written rule, which is shorter than a policy. One page saying what needs no permission, what needs a short intake, and who decides by when. That page prevents more trouble than a document nobody finishes reading.

Can one person cover both governance and delivery?

For a while, and it is common below a hundred users. Watch for the moment the same person is approving and building, because the review stops being a review. That is the signal to split the roles, not the headcount.

Should this sit under IT or the business?

Risk assessment belongs with IT. Deciding what is worth doing belongs with whoever owns the process, because only they know whether a task is a genuine constraint or a habit. Putting both under IT is how companies end up with a well-governed set of tools that solve nothing anyone cared about.

What if we already built a centre of excellence and it is too big?

Move the building back into the teams and keep the unit for intake, risk and standards. That is the third model in the table, and it is a smaller change than it sounds: the people stay, the delivery queue disappears, and the unit stops being the bottleneck it was created to remove.