Governance is an enablement ladder, not a locked door

If your AI governance can only say no, people will stop asking. That is the part we keep underestimating.

Most makers are not trying to create risk. They are trying to solve the annoying problem in front of them. The meeting notes nobody has time to clean up. The internal FAQ that is always out of date. The approval that still lives in someone’s inbox. The handover that depends on one person remembering to send the right document.

Then they discover they can build an agent in a few clicks.

It can talk to people.

It can read data.

It can call tools.

It can take action.

That is brilliant. It is also exactly why the old governance model breaks.

Because if the only options are “open the floodgates” or “block everything,” we have already lost the plot.

Good governance gives people a safe place to start. Bad governance makes every idea feel like a compliance incident waiting to happen.

The maker is usually not the problem

The maker is not the problem. Governance that arrives too late is.

The person building the agent is often the person closest to the work. They know where the process hurts. They know which information people keep asking for. They know which task is too small to get funded and too irritating to leave alone.

In other words, they are exactly the person we want to activate.

But we often meet them with a model built for a different world.

A world where releases were slower and “an application” was easier to point at. A world where a review board could sit at the end of the line and still feel early enough.

Agents change that rhythm.

A small agent can start as personal productivity in the morning and become a team dependency by the afternoon. It can move from answering questions to taking action. It can connect to systems the maker understands only partly. It can become useful before anyone has decided who owns it.

That does not mean we should panic.

It means we need a better path.

Three ways old governance gets heavy

Policy debt: Rules pile up. Each one made sense when it was created. A connector (the ready-made link an agent uses to reach another system) was blocked because of one incident. A sharing rule was tightened because of one bad rollout. A whole category of tools was frozen because nobody had time to design a better answer.

Individually, the rules are defensible.

Together, they become scar tissue.

Process burden: Everything goes through the same queue. A personal agent over data the maker can already open gets reviewed like a production system for an external audience. A small experiment waits behind a business-critical release. Low-risk work gets the cost of high-risk review.

That is how you teach people that governance is a wall.

Inconsistent enforcement: One connector is blocked. A near-identical path is allowed somewhere else. One environment has strict rules. Another inherited old settings nobody remembers. One team gets a workaround because they know who to ask. Another gives up.

This is where trust starts to evaporate.

Not because people hate governance. Because they cannot understand it.

And if people cannot understand the rules, they cannot follow them with confidence.

Risk-based does not mean relaxed

Risk-based governance is often misunderstood as “lighter governance.”

That is not the point.

Risk-based means the control matches the risk.

A personal agent that summarises documents the maker can already read should not have the same path as an autonomous agent that writes to a production system. A prototype with read-only sources should not be treated like a broadly shared agent with tools, actions, and business impact.

Same platform. Different risk.

That distinction matters even more in regulated tenants. I work in environments where “just open it up” is not a serious proposal. Even the safe lane needs a fence. But the fence should show people where to enter, not only where they are forbidden to go.

The EU AI Act is built around risk-based thinking too. High-risk AI systems have stronger requirements around risk management, record-keeping, monitoring, human oversight, and use in line with instructions.

Most internal agents will not automatically be high-risk AI systems. That is not the claim.

Modern AI governance already thinks in tiers. Our platform governance should do the same.

Build an enablement ladder

The practical move is an enablement ladder.

Not one “yes.”

Not one “no.”

A ladder.

Each rung gives makers a little more freedom because the organisation has a little more evidence.

A first version could look like this:

Personal experiment — a routed developer environment, low-risk or read-only connectors, no broad sharing, clear maker guidance.
Team pilot — limited sharing, named owner, visible data sources, basic test notes, clear stop condition.
Business process — stronger connector rules, solution-aware build, approval path, lifecycle owner, support expectation.
Production use — release gate, monitoring, audit trail, recovery plan, review cadence.
Self-service production path — only after the rules are stable enough to make the safe path repeatable.

The exact rungs will differ by organisation.

The principle does not.

Do not ask, “Are agents allowed?”

Ask, “What is allowed at this level of risk?”

That one question changes the tone of the whole conversation.

It gives makers a place to start. It gives security a way to say yes without pretending every idea is safe. It gives architects a structure to improve instead of a backlog of exceptions to defend.

Contain experiments instead of deleting them

The worst governance pattern is detect-and-delete.

A maker builds something in the default environment. IT discovers it later. Nobody knows what it touches, who uses it, or whether it solved a real problem. The safest visible action is to shut it down.

Sometimes that is necessary.

But as a default pattern, it is a bad deal for everyone.

The maker learns to hide. IT learns to hunt. The organisation learns nothing except who is frustrated this week.

A better pattern is containment.

Microsoft gives us tools for this:

Managed Environments are the premium control set for Power Platform at scale.
Environment routing can send makers into personal developer environments instead of leaving them to build in the shared default environment.
Environment groups can apply rules across a set of environments, so the maker lands inside a governed space from the start.

That is the difference between “don’t build” and “build here.”

One creates shadow work.

The other creates visibility.

And visibility is where governance becomes useful.

Make the rules visible before people break them

A governed space still needs clear signs.

A maker should not need to know the whole control model before building their first useful agent. They need to know the answers to a few practical questions:

Where should I build?
What data can I use?
Which tools are allowed here?
Who can I share this with?
What changes when this becomes more than personal productivity?

This is where platform controls and human enablement meet.

Environment group rules let you set the guardrails once and apply them across every environment in the group: which connectors are allowed, whether generative AI is on, whether the solution checker runs, what the maker sees when they arrive. Managed Environments can cap how widely someone shares an app, flow, or agent, so a personal build does not quietly go tenant-wide. And Copilot Studio data policies draw the line around which data and services an agent can touch, inside the organisation and out.

Those controls matter.

But the control is only half the job.

The other half is the sentence the maker sees when they arrive:

“Start here. These connectors are allowed. Do not use personal data in this environment. You can share with up to five testers. If this becomes a team process, request promotion here.”

That is governance people can use.

Measure friction like a real signal

Compliance metrics tell you whether the rules exist.

Friction metrics tell you whether the rules are working.

How many active makers do you have?
How long does it take a low-risk idea to reach a safe test group?
How many requests are waiting because nobody can decide whether they are really risky?
How often do makers ask for the same exception?
Which connector rule creates the most pain?
Which policy is technically correct but practically impossible to explain?

These are architecture questions.

Because if the safe path is too slow, the unsafe path becomes attractive.

That does not mean every complaint should change policy. Sometimes the answer is still no. But the no should be explainable, consistent, and connected to the risk.

If the same low-risk request keeps getting stuck, the process is telling you where the next rung of the ladder belongs.

The smallest version you can build this week

Do not start with the perfect governance model.

Start with one safe yes.

Pick one agent type your organisation should be able to support without drama. For example:

“A personal productivity agent that uses approved internal knowledge sources, has no write actions, is built in a routed developer environment, and is shared only with a small test group.”

Then write the rule in plain language:

where it must be built
which data sources are allowed
which connectors or tools are allowed
who it can be shared with
what evidence is needed before it moves to the next rung
who owns it if other people begin to depend on it

Now map that rule to the platform.

Use environment routing to put makers in the right place. Use environment groups and rules to apply the settings. Use sharing limits to stop a personal experiment becoming an organisation-wide agent by accident. Use data policies to draw the boundary around connectors and services. Use maker welcome content to explain the lane before people drive out of it.

That is not the whole model.

It is the first rung.

And the first rung matters because it changes the relationship between makers and governance.

Instead of “prove this is safe enough for us to allow,” the conversation becomes:

“Here is what you can do safely now. Here is what changes when the risk goes up.”

Governance should create motion

The goal is not to make AI feel harmless.

It is not harmless.

Agents can touch data, call tools, cross boundaries, and create real business impact. The risk is real.

But freezing the platform does not remove the demand. It only moves the work somewhere less visible.

The architect’s job is to design the path where good ideas can move without pretending every idea belongs in production.

A safe sandbox for experiments.
A clear promotion path for useful work.
Different controls for different risk.
A visible owner when the work starts to matter.

Friction measured as part of the system, not dismissed as maker whining.

That is governed enablement.

It is stricter than “let everyone build whatever they want.”

It is also far more useful than “come back after the steering committee meets.”

Good governance does not slow people down. It gives them the system and the guardrails to innovate safely and with confidence.