Everybody says AI governance matters. They are right. But that is the easy part.
The harder part is admitting the second truth out loud: governance slows things down. And if a company is serious about AI adoption, that tension becomes impossible to avoid.
You cannot let AI run wherever it wants. You also cannot build a review machine so heavy that the business abandons the official path entirely. Both of those outcomes are bad. Both are happening somewhere right now.
The real question is not which value wins. It is whether leaders can design systems where neither has to.
Shadow AI Is Telling You Something You Are Not Asking It
When employees use AI tools outside the approved path, the first instinct is to treat it as rule-breaking. That framing is not wrong, but it is incomplete.
Shadow AI is also feedback. It tells you the official path is not keeping up with how people need to work. If you only read it as non-compliance, you miss the more important message: the workaround is beating the sanctioned route on usability. That is a design failure, not a discipline problem.
Microsoft's 2023 Work Trend Index found that 70% of workers said they would delegate as much work as possible to AI to reduce their workload. That data is a few years old, but the direction has not reversed. People want help, and they want it now. When the approved channel cannot meet that need in a reasonable timeframe, they stop waiting — not because they are careless, but because the friction is real and the alternative is right there.
Shadow AI is a speed signal before it is a compliance signal. Organizations that miss that distinction will keep patching symptoms.
The Governance Problem Has Gotten Harder
The original governance problem — what data goes into the model — was at least bounded.
In 2023, Samsung employees used ChatGPT to help with internal tasks and ended up exposing proprietary source code and internal meeting notes in the process. The data left before anyone had finished writing the policy to prevent it. That was a painful lesson, and it was also a relatively legible one: sensitive input, external model, data leakage. You could draw a box around it.
The newer problem is less legible.
AI systems are no longer just answering questions. They are taking actions. Agents can trigger workflows, write to databases, call external APIs, send communications, provision infrastructure. When that happens, governance has to cover a fundamentally different surface.
Passive tools vs. agentic systems — they are not the same problem
| System type | What governance needs to cover |
|---|---|
| Language model generating output | Data classification, input controls, output review |
| Agent taking action across systems | Non-human identity controls, scoped permissions, action audit trails, execution halts |
Treating these as the same risk tier — one policy to cover both — is how organizations end up looking thorough on paper while leaving real exposure untouched.
NIST's AI Risk Management Framework and the EU AI Act both encode this kind of differentiation. The Act distinguishes between unacceptable, high, limited, and minimal risk use cases precisely because a single standard applied to all AI use is not sophisticated. It is just blunt. The governance question has always been about the right level of scrutiny for the actual consequence. It is just harder now to define what that consequence is.
The Leadership Trap
Most conversations about AI governance eventually collapse into a fake choice:
- You are serious about risk, or
- You are serious about speed
It is a bad frame. It turns a design problem into a values debate. The cautious people start to sound anti-innovation. The fast-moving people start to sound reckless. The meeting goes in circles. Meanwhile adoption keeps happening — just not in the way anyone planned.
The organizations that will struggle most are not the ones that chose governance. They are the ones that chose governance without redesigning how decisions get made.
Policy without redesigned process is just overhead.
When AI Is in the Workflow, Governance Is in the Workflow
If AI were still a side pilot, weak governance would be annoying but survivable. That is not where most organizations are anymore.
AI is moving into actual work — decisions, service delivery, customer interactions, internal tooling, operating expectations. Once it is embedded there, governance is no longer a control topic sitting beside the work. It is part of how the work functions.
That means governance has to answer more than:
- What is allowed?
- What is banned?
- Who signs off?
It also has to answer:
- How fast can we make a good decision here?
- Where does human judgment stay in the loop — and where does requiring it create its own risk?
- Who is accountable when an agent acts on a decision that turns out to be wrong?
- What is genuinely high risk in this organization, as opposed to theoretically high risk?
- Who owns the line between experimentation and production use?
Those are not policy questions. They are leadership questions. And most governance frameworks are not built to answer them.
What Actually Needs to Change
There is no single clean solution. But some ideas are more honest than pretending a 30-page policy document will hold things together.
1. Consequence should determine process, not the reverse
Drafting an internal summary is not the same risk as using AI in a hiring decision. Summarizing public documentation is not the same as giving an agent write access to a production system.
The EU AI Act got this right at a regulatory level. Organizations should apply the same logic internally:
- High consequence → careful human review, clear accountability chain
- Medium consequence → lightweight fast-track with defined guardrails
- Low consequence → automated controls, no human queue
The passive-versus-agentic distinction matters here specifically. A chatbot and an autonomous agent are not the same risk tier. Governance that treats them as equivalent will either tie up low-stakes tools in unnecessary process or — more likely — let genuinely risky agentic systems through on the same lightweight path as everything else.
2. Slow decisions have a cost, and the math compounds
Leaders spend a lot of time thinking about what governance controls. They spend far less time thinking about what governance costs. That asymmetry is a problem.
A 48-hour manual review queue sounds manageable in isolation. Spread across ten teams each running three active experiments:
- 30 decisions delayed per week
- At a six-week release cadence: ~5 learning cycles lost per quarter — not to bad judgment, just to waiting
Add vendor evaluations, model version approvals, and cross-functional sign-offs on top, and what looks like appropriate caution in one thread becomes slow-release rot across the enterprise.
Governance debt accumulates quietly. A data breach is a visible event. Fragmented tooling, eroded program credibility, and six months of slower learning are not. Both are real costs. Only one triggers a board conversation.
3. The official path has to be easier than the workaround
This is the most practical truth in the whole discussion, and it does not get said plainly enough.
People are not comparing the sanctioned route to some ideal standard. They are comparing it to the thing they can use right now. If the workaround is faster and clearer, it wins. The solution is not stricter enforcement. It is making the official path genuinely usable.
- Near term: clearer guidance, faster review SLAs, sensible defaults
- Longer term: remove the manual queue for work that does not warrant it — API-level data masking, policy-based access controls, automated logging, deterministic guardrails
The goal is governance that runs beneath the surface rather than sitting on top of it as overhead.
4. Ambiguous decision rights turn governance political
A lot of transformation work fails when nobody knows who actually decides what. AI governance is not immune.
Key questions that need explicit answers — not working assumptions:
- Who sets the threshold for acceptable risk?
- Who decides when a pilot becomes a production system?
- Who can say no, and who can override?
When those answers are fuzzy, governance becomes about whoever has more organizational leverage at a given moment. That is not a sustainable way to manage risk. Clarity on decision rights is not bureaucratic neatness. It is what keeps governance functional when the pressure to move is high.
Which Risk Is Leadership Willing to Sit With?
Both sides of this debate are right about something.
The governance side is right that AI can create damage fast. Data leaks. Bad outputs spread. An agent with misconfigured permissions can take actions across multiple systems before anyone notices. One visible incident can set adoption back by a year.
The transformation side is right that slow systems also create damage — it just lands differently. Adoption fragments. The central program loses credibility. Teams stop bringing real work to the official path because they have learned it will not move fast enough. Learning slows. Competitors do not.
The real question is not risk or speed. It is which kind of risk leadership is willing to take seriously.
The dramatic risk is easier to discuss in a board meeting. The quieter risk is easier to rationalize away. But quiet risks compound. Governance debt is still debt.
What Trust Actually Requires
The goal is not tight governance. It is not fast governance either. It is governance that people trust enough to actually use.
That is a harder bar than compliance. It requires:
- Trust from risk owners
- Trust from senior leaders
- Trust from the people being asked to use AI responsibly while also getting their work done
- Clarity about what the rules are, and consistency in how they are applied
- A process that moves fast enough to stay relevant
None of that comes from policy language alone. It comes from design — of the path, the defaults, the controls, and the decision rights.
Policy describes what you want. Design is what people actually experience.
The Uncomfortable Version
If AI governance only works when the organization moves slowly, it is not ready for what is coming.
That is not an argument for weakening governance. It is an argument for redesigning it so that trust can scale without requiring a human queue on every decision. That means:
- Distinguishing between passive tools and action-taking agents
- Pricing in the cost of latency, not just the cost of incidents
- Building the official path to be easier than the workaround — not just more legitimate
Writing better policy is the easy part. Redesigning how the organization makes decisions under pressure — that is the actual work.
Questions Worth Arguing About
Not as abstract discussion topics. As questions that need actual answers.
- Name specifically — not in categories — which AI decisions should always remain slow and deliberate in your organization. If you cannot name them, the framework is not operational.
- Where is governance reducing real risk, and where is it creating delay with no corresponding reduction in exposure? These are not the same list.
- What would it cost, in learning cycles and time-to-market, to run your current review queue across the whole enterprise for a quarter? Has anyone done that math?
- Which governance controls could be automated for low- and medium-risk work — and what is actually preventing that?
- Is governance in this organization designed as a control layer, or as a capability that helps responsible adoption move faster?
The hard part is no longer deciding whether AI governance matters. That question is settled.
The harder part is building governance for a world where AI is useful enough that people will keep reaching for it regardless of whether the official path is ready — and capable enough, in its agentic forms, that ungoverned action is no longer just a data problem.
That is not a policy problem alone. It is a leadership problem. And for most organizations, it is increasingly a transformation problem they have not fully named yet.
Top comments (4)
This resonates strongly with what I'm exploring with NAEOS.
I particularly agree with the idea that governance shouldn't sit on top of engineering as a separate approval layer. It needs to become part of the workflow itself.
The distinction between passive AI and action-taking agents is especially important. Once an agent can modify code, call APIs, access infrastructure, or trigger workflows, governance can no longer depend primarily on human review queues. The constraints need to become executable.
That's one reason I'm exploring quality gates as the initial wedge for NAEOS: instead of telling an agent "follow our engineering rules," the system should be able to enforce those rules at the point where the agent produces a change.
And I think your line about the official path being easier than the workaround captures the adoption problem perfectly.
The interesting question for me is what happens when those automated controls start accumulating organizational knowledge: not just "this change violates rule X," but "why does rule X exist, who decided it, and under what conditions can it change?"
At that point, governance starts looking less like policy management and more like an engineering infrastructure problem.
bayu911, thank you. "Constraints need to become executable" is the load-bearing sentence of the whole argument, and you said it back to me better than I did. Once an agent can mutate infra and call tools, a human review queue is no longer fast enough and no longer where the decision really lives; the control has to sit in the loop, enforced where the change is produced.
The quality-gates wedge is the right first move precisely because it's the moment an agent's output becomes a mutation, the spot where you can actually stop something. And your "official path easier than the workaround" read is exactly the adoption story I've seen; the moment the workaround is cheaper than compliance, the policy is dead.
On the organizational-knowledge axis, I think you're pushing in the right direction: gates that merely forbid are brittle; gates that carry their own rationale (author, the condition under which they're allowed to change) turn into a governance substrate. My suggestion is to record that rationale as first-class metadata on the gate from day one, so the memory is a byproduct rather than a later project.
Counter-question: at NAEOS, does the "why" live as per-gate rationale in config, or is it a registry the agent introspects at run-time? Thanks for sharing this.
I think the answer is: both, but with different responsibilities.
The rationale should live as first-class metadata on the gate itself—author, intent, scope, constraints, and the conditions under which the rule can change. That makes the gate self-explanatory and keeps the organizational memory close to the enforcement point.
The registry would then provide the runtime introspection layer. An agent shouldn't have to infer the "why" from scattered configuration files. It should be able to query the applicable gate, its rationale, precedence, and constraints when it needs to reason about a failure or decide how to respond.
So conceptually:
Gate → enforces the constraint
Metadata → explains why the constraint exists
Registry → makes that knowledge discoverable at runtime
I like your suggestion of making the rationale a byproduct of the gate from day one. It also creates an interesting feedback loop: every enforced constraint becomes a potential piece of organizational memory rather than another opaque CI failure.
The next design question I'm thinking about is how much of that metadata should be immutable versus evolvable, because the history of why a rule changed may become just as valuable as the current rationale.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.