Picture a customer service lead who has done everything right. Her team answers the same policy questions all day, so she measured how long it takes, picked one use case, found a willing group of agents to try it and wrote down what success would look like. Now she has one email out to IT, and it says, more or less: can we go ahead?
On the other side of that email is a CIO or IT lead who wants to say yes. They also know that if something goes wrong, it will be their name on it. So the request goes into a queue, a review gets scheduled, someone asks for a policy, and the team waits.
In the first post in this series, we said AI stalls for business reasons, and that each of those reasons is a decision made late or not made at all. Governance is where that shows up most clearly. It gets blamed for slowing AI down. In our experience the cause is usually different: the decisions IT needs were never made up front, so they get made one request at a time, after the fact.
This post is for the IT lead being asked for that yes, and for the risk or compliance lead standing next to them. It’s also the last in the series, so it ends with the five rules the series has argued for.
Why governance gets the blame
Most mid-market companies don’t have an AI governance function. They have an IT team that already runs security, access and change control well, and a business that has started asking for things IT has never been asked to approve before.
Without agreed rules, every request is a fresh judgment call. Which data can it see? Who checks the output? Who can turn it off? A committee forms to answer those questions, meets monthly, and ends up reviewing things that are already half built.
Good governance isn’t a committee that meets after the fact. It’s a few decisions made early, owned by IT and tested in stages. Make them once, write them down, and the next request is a matter of applying them rather than debating them.
Start with who can open what
Ask most IT leads what worries them about AI and they’ll talk about the model. The first governance question is usually closer to home: who can open what today, and should they? Copilot surfaces only what a person already has permission to view, so files shared too widely years ago are the bigger exposure, and we’ve set out how to find and fix that before you deploy. One agent setting also deserves a decision before the first agent is shared. A Copilot Studio maker can set a connection to use the maker’s own credentials instead of each person’s sign-in, and Microsoft flags that as an oversharing risk that admins can switch off per environment.
With that settled, governance comes down to four decisions.
Decision one: a risk tier for every use case
Not every use case needs the same scrutiny. A tool that drafts internal meeting notes and one that reads employee records shouldn’t go through the same gate, and treating them the same is how governance gets slow.
So every use case gets a tier, Low, Medium or High, before it’s built. The tier is set by a short list of factors: how sensitive the data is, what decisions the output affects, who is affected, whether regulation applies, how accurate it needs to be, the potential for bias, and the security exposure.
The tier sets the controls and the approvers, so the conversation about risk happens once, at the start, instead of at every stage. The exact controls for each tier are yours to agree with IT and risk. The point is that a Low-tier request shouldn’t wait in the same queue as a High-tier one.
Decision two: where a person stays in the loop
Wherever output affects money, customers, employees or legal matters, a person reviews it before it counts. And there are no automated decisions about people: AI can help a manager prepare, summarize or draft, but it doesn’t decide who gets hired, promoted or disciplined. Writing that line down early means nobody has to argue about it later, when a pilot is going well and someone wants to take the human out. We’ve described the approval pattern that makes that review auditable.
Decision three: where and how it gets built
The third decision is about the build itself, and it’s where IT’s ownership is most concrete.
The solution is built in your tenant, not ours. It starts in a lower environment, never in production. The people building it work under named accounts that IT issues, with only the access the work needs.
The business decides what problem to solve; IT decides how it’s allowed to run. That split is the heart of governance that keeps up. The business owns the rules of the work: what the output is for, who reviews it, what counts as success. IT owns access: who can see what, where it runs and what reaches production.
Decision four: how it’s released, and who can turn it off
A solution reaches people in stages: the IT and project team, then a small group of pilot users, then pre-production. Each stage ends in a go/no-go that your side decides, against a threshold agreed before the stage starts, so “go” is a fact rather than a feeling. At each stage, three kinds of test get run and recorded: permission tests (someone without access sees nothing), untrusted-input tests (a document or email written to make it misbehave) and accuracy checks on real samples. We’ve written up how we test agents like production software, down to a GO or NO-GO before anything goes live.
The part most often left until something goes wrong is the off switch. Before go-live, there’s a cutover and rollback plan, and a named owner who can disable the solution. Not a team, not “IT”, a person, who knows they are that person.
Production stays with you. IT approves every production change in writing, and that written record is a big part of auditability. When someone asks later why a solution was allowed to run, who approved it and what was tested, the answer is a set of documents, not a recollection: the risk tier, the review rule, the test results from each stage, the go/no-go decisions and the production approval.
If you can show who decided, against what threshold, and who can switch it off, you have governance an auditor can follow.
What this isn’t
It’s worth being plain about one thing. Our AI Value Blueprint looks at people, process and value, and it works without production access. It isn’t a security audit or a penetration test, and it doesn’t replace either. If you need those, they’re a separate piece of work with the right specialists. What the Blueprint gives IT is a clear, governed set of use cases with the risk questions already asked, instead of scattered requests arriving one at a time.
The five rules of the series
This is the last of five posts. Each one made one argument. Taken together, they’re the rules we’d hand to any leadership team starting AI from the business side.
- Start with the team’s known problem, not with a tool. The business already knows where the week goes, and scoring the candidates tells you which one goes first.
- Value hours honestly, and keep capacity apart from cash. Round down, use conservative capture, and never count freed time as money saved.
- Put an AI Business Analyst between the business and IT, someone who sits with the team doing the work and translates it into something IT can govern.
- Map the work a license should take on. A license is a tool per person; it doesn’t tell you which work, in which team, it should change.
- Make governance decisions early and test them in stages, with the business owning the rules and IT owning access.
None of the five is about the technology, and every one of them is a decision you can make before you spend. It’s hours back, not headcount: the goal throughout has been capacity your teams can put to better use, not fewer people doing the work.
If you’re the IT or risk lead being asked for a yes, our security and data brief sets out how we work inside your environment: your tenant, named accounts, least access, staged release and written approval for production. Download the security and data brief, or see how the AI Value Blueprint works.
CB5 Solutions helps organizations understand the layers of AI, get the most from what they buy, and build an AI program that pays back inside their IT standards. We start every engagement with one business problem and a governance baseline. Let’s pick yours.
That’s the end of the series: five posts, five rules, and one business problem worth starting with.