You need a head of AI governance. You need a team. You need people with the right skills. So you hire.

This is the wrong approach. The enterprises that excel at AI governance don’t hire their way to excellence. They build capability.

There’s a difference. Hiring assumes the market has people who already know how to govern AI at scale. Mostly, it doesn’t. People know how to do one or two things—maybe fairness auditing, maybe model monitoring—but building integrated governance across fifty systems at an enterprise? That’s not a hiring problem. That’s a building problem.

What You Actually Need

The governance capability you need has four components:

1. Governance thinking. The ability to look at an AI system and ask the right questions. Will this cause harm? Are we accountable for this? Can we defend this decision? Is there risk we haven’t considered? What governance is needed?

This is not a skill you hire. This is something teams develop through experience. You need people who’ve governed multiple systems and learned patterns. People who can look at a new system and see what’s likely to go wrong.

You develop this by having people govern systems over years. Not by hiring “senior governance people” from other companies. Those people know governance at their company. They don’t automatically know your company.

2. Governance infrastructure. Tools, processes, standards that make governance scalable. Monitoring platforms. Decision support systems. Audit trails. Governance databases.

Some of this you buy. Much of it you build. You need people who understand what governance infrastructure you need and can build it. Not necessarily software engineers. But people who can design systems that work.

You develop this through iteration. You implement monitoring. It doesn’t work. You redesign it. You implement decision gates. They’re too slow. You automate them. Over time, you build infrastructure that works.

3. Governance integration. Governance doesn’t sit in a separate team. It integrates with how teams build and operate systems. Model developers think about fairness because governance is integrated into development. Operations teams monitor for drift because monitoring is integrated into operations.

This requires people who understand how to embed governance into existing work. This is not a “governance team” skill. This is a skill that lives in product, engineering, and operations teams. You build it by teaching people how governance applies to their work.

4. Governance judgment. The ability to make trade-off decisions under uncertainty. A fairness metric is slightly worse than before, but retraining costs money and time. Is it worth it? A new regulation might apply, but it’s unclear. Should we prepare? A model is failing for a small segment of users. Should we pull it?

These are judgment calls. They depend on understanding risk, understanding business, understanding technical constraints. There’s no “right answer” in a textbook. You develop judgment through experience making hard decisions and seeing what happens.

Why Hiring Fails

Most enterprises hire a governance team. They get smart people. But:

1. They don’t understand the existing systems. A new governance head comes in and wants to implement a governance framework. But they don’t know what systems you have, which are critical, what risks matter. They implement a framework that’s generic and often wrong for your specific situation.

2. They’re not integrated into how you build. Governance gets siloed. Model developers do their thing. Governance team checks boxes separately. Governance doesn’t actually affect decisions.

3. They leave. You hire someone smart. After two years, you’ve figured out governance. Now the person leaves. You’ve lost the person but not the capability. You have to rebuild with the next person.

4. They can’t scale team skills. You hire a governance head and a team. But most of your organization still doesn’t understand governance. So you’re bottlenecked. The governance team has to review everything.

What You Should Build Instead

Instead of hiring a governance team, build governance capability:

1. Develop governance thinking in existing teams.

Your model development teams should be able to think about governance. Not become governance specialists. But understand governance enough to ask the right questions about their models.

This means: – Governance training (not abstract, but for your systems) – Governance reviews where the team explains their thinking – Governance mentoring (someone who’s done this before works with them)

Over a year, your teams are thinking about governance. You’ve scaled thinking across the organization.

2. Build governance infrastructure iteratively.

Start with one capability. Monitoring. Build it. It’s imperfect. Improve it. Build the next capability. Decision gates. Improve them. Over time, you have infrastructure that works.

This requires people who understand what infrastructure you need and can build it. This could be engineers. It could be people from ops or product who understand the problem deeply.

3. Integrate governance into existing processes.

Don’t add a governance review step. Integrate governance into your existing review.

Model review: Include governance questions (fairness, data quality, monitoring). Don’t have a separate fairness review.

Incident response: Include governance questions (why did this happen? what should change?). Don’t have separate governance postmortems.

Deployment process: Include governance gates (this model meets standards). They’re not separate gates; they’re part of the deployment process.

4. Build judgment through experience.

You need people who’ve made governance decisions and can explain their thinking. These might be internal people who’ve grown into governance roles. They might be external advisors who work with your teams on hard decisions.

The key is that people are making decisions, not just implementing frameworks. They’re learning what works.

The Organizational Structure

The governance capability you need doesn’t live in a “governance team.” It’s distributed:

• Governance thinking lives in model teams, operations teams, product teams
• Governance infrastructure lives in a platform or engineering team
• Governance integration lives in the processes where decisions are made
• Governance judgment lives in experienced people scattered across the organization

You might have someone coordinating governance (a CTO, a governance lead). But they’re coordinating a distributed capability, not running a separate team.

How to Start Building

Year 1: Build governance thinking in your core teams. Pick one system. Work through governance with the team. Document what you learned. Do it again with the next system. By end of year, teams are thinking about governance.

Year 2: Build one governance capability (monitoring, decision gates, audit trails). Improve it based on what you learn. Build the next capability. Start integrating governance into your processes.

Year 3: Your teams are thinking about governance. Your infrastructure is working. You’re making trade-off decisions with some maturity. You can scale to more systems.

Year 4+: You’re scaling governance across your portfolio. You’re not bottlenecked by a small governance team. You’re bottlenecked by how fast you can develop systems and learn from them.

Why This Matters

Organizations that build governance capability scale better. They don’t hit the wall where governance is so much overhead that teams stop doing it. They don’t lose continuity when a key person leaves.

Organizations that hire governance teams often hit that wall. The team becomes a bottleneck. The team leaves. Governance collapses.

What You’re Actually Building

When you build governance capability, you’re not building a governance function. You’re building an organization that thinks about governance as part of how it operates.

That’s hard. It takes years. It’s messier than hiring a team and hoping they know what to do.

It’s also more durable. When people understand why governance matters, when it’s integrated into how they work, when they’ve learned from making decisions—that capability survives.

This is the difference between hoping someone else will handle governance (hire a team) and building an organization that governs itself (build capability).

One scales. One doesn’t.