Why Your Board And Developers Are Having The Same Fight About AI Governance

When governance feels like friction, people go around it. 

In my 20-plus years in enterprise architecture, across Oracle, MuleSoft, Salesforce, and now working with some of the largest companies in the world, I’ve watched this pattern repeat with every major technology shift. Someone builds a control layer, and it works well. But soon, the technology it's meant to govern starts moving faster than the control layer can keep up with. And instead of fixing the layer, people route around it.

Right now, this pattern is playing out at two levels of the enterprise simultaneously: boards hiring Chief AI Officers to route around IT, and developers abandoning governed protocols to route around overhead. It's the same instinct at different altitudes, and it needs the same architectural fix.

So far, every major technology shift has come with ways to balance speed, scale, and scope. When cloud arrived, we had architectures. Cybersecurity became a board-level concern, and with it, we had frameworks. When data became strategic, we had governance models. With AI, we’re still writing them.

Companies are deploying models without defined accountability, integrating systems without fully understanding exposures, and scaling faster than anyone can track what’s at risk. 

What this looks like at the executive level

At the board level, companies are hiring Chief AI Officers. If you’re a CIO watching this happen, it’s easy to read this as a threat. If you’re the new CAIO, you might have the impression that you’ve been brought in by leadership to fix what IT could not. In my experience, the CAIO role is usually created for one reason: the board wants AI implemented fast. 

Traditionally, the bottom of the tech stack moves on a different clock from the top. At most organizations, these two layers aren’t cleanly separated. It’s possible that in some organizations, the CIO and the infrastructure team could start to look like “the folks in the way” when in reality they’re simply trying to keep production systems stable. Sometimes this friction is misconstrued by leadership as a need for a refocusing, and a need to create a separate AI team. 

What this looks like at the engineering level

At the engineering level, a similar thing is happening with the tools AI agents use to connect to enterprise systems. Over the past year, Model Context Protocol (MCP) emerged as the standard for this. Companies rushed to adopt MCP. Build one MCP connection, and any AI agent can discover it and use it.

But adoption created a new problem. Organizations ended up with dozens of MCP connections, each with its own credentials, its own security posture, its own logging. All of those tool definitions get loaded into the AI agent's memory at once, eating up the context the agent needs to actually think and reason well. The protocol that was supposed to simplify things started to feel like something you need to go around in order to innovate.

So developers started looking into lighter, faster alternatives to MCP with simpler command-line tools, local scripts, and skills files that an agent can pick up without the overhead of a full protocol. Charles Chen, an engineering leader at Motion, recently wrote a sharp piece on this called MCP is Dead; Long Live MCP! His argument: for an individual developer working on their own machine, the lighter tools win. But the moment you need to know which tools agents are using across your org, who has access to what, and how to enforce security consistently, you need a governed protocol.

What works for one person on a laptop falls apart for a team of 50 building software that has to be maintained and secured. 

Same instinct, different altitude

The developer abandoning MCP because it feels clunky and the board hiring a CAIO because IT feels too slow are responding to the same thing. Innovation moves around friction.

And in both cases, it works fine for a while. The solo developer moves faster with lighter tools. The new CAIO moves faster without having to navigate IT. But at scale, the cracks show up quickly. Ungoverned agent connections scatter across the org, and AI experiments running against production systems with no visibility into who’s accessing what.

One morning you may find yourself in an incident review asking how an AI agent got write access to your ERP and no one can tell you how.

The architecture that fixes both problems

This is what concerns me most about the current moment. When governance trails innovation, you don’t see the damage until something breaks.

I talk to CDAIOs every week, and the same concerns keep coming up: they can’t see what data their models are actually using, they can’t govern it consistently across cloud and SaaS, and regulatory exposure under GDPR, CCPA, and the AI Act is growing faster than they can track it. For the first time, the tools to answer these questions exist. What’s missing is the architecture to support them.

Now you have a CAIO building an AI strategy that doesn't connect properly to the existing infrastructure, a CIO sitting on decades of tested integrations that nobody's using because they weren't made accessible to the AI team. We need to build a governance layer that's fast enough and useful enough that people stop wanting to go around it.

There's a reference architecture taking shape across the industry right now, and it maps to both of these problems at once. It splits the stack into two zones.

The top zone is where AI teams experiment. Which models to use, which agent frameworks to build on, how agents interact with employees and customers. This zone changes fast, and it should. New approaches show up constantly, and teams need the freedom to try them, swap them, and learn. The CAIO owns this space. And lighter, faster tools belong here, because the blast radius of experimentation is contained.

The bottom zone is where the business runs. This is where agents actually do things: process an order, check inventory, verify a payment, route an approval. The business logic, the workflows, the error handling, the connections to your core systems. This zone needs to stay stable and governed, because failures here hit customers, revenue, and compliance. The CIO owns this space. And a governed protocol like Enterprise MCP, deployed centrally with proper auth and visibility, earns its place here.

This is also where the MCP-versus-CLI debate resolves. The developers who abandoned MCP for lighter tools were working in the top zone, where speed and flexibility matter most. But the governed protocol they rejected is exactly what the bottom zone requires. Enterprise MCP exists for exactly this zone. It’s a centrally managed implementation of the protocol with unified auth, access controls, audit logging, and visibility across every agent connection. MCP with the governance that makes it safe to run in production.

When these two zones are clearly separated, both roles move at their own speed. When they aren't separated, you get a power struggle at the leadership level and ungoverned chaos at the engineering level. 

The working version of this: the CAIO iterates on top without breaking what's underneath, the CIO opens up capabilities to agents without losing control, and the developer picks the right tool for the right layer instead of rejecting governance entirely.

You already have the hard part built

If your organization has 100 existing automation workflows, you don't need to start from scratch. Your existing workflows are 100 capabilities an AI agent can use today, complete with error handling, business rules, and system connections that have already been tested in production. The CAIO doesn't have to recreate the integrations and business logic that already exist. They just need access to a stable, well-governed set of capabilities they can point agents at.

The companies I've seen try to rebuild from scratch, because a vendor convinced them they could do it all with one agentic framework and good vibes, are learning a hard lesson. Enterprise infrastructure doesn't get replaced overnight. You cannot treat your infrastructure as something to protect and gatekeep. If you do, every AI team in your company is going to route around you. When your CEO asks why the AI team can't just connect directly to SAP, you should have an answer ready, and it should be this: "They can. Through the governed layer we already built. Here are the 100 capabilities already exposed and ready to go."

Where this lands

I’ve never seen the gap between the speed of innovation and the maturity of governance this wide. But the tools to close it exist now, if we build the architecture to use them. `

The CIO and CAIO are responsible for different layers that move at different speeds. With the proper architecture, both roles can do what they’re best at. But if you get the architecture wrong, you’ll end up with the same pattern I’ve seen repeated for 20 years: people going around the governance layer instead of building on top of it. 

‍Andres Ramirez is VP, Chief Strategic Architect at Workato, where he advises some of the largest enterprises in the world on AI infrastructure and integration architecture. He has over 20 years of experience in enterprise architecture across Oracle, MuleSoft, and Salesforce. He holds an M.S. in Software Management from Carnegie Mellon University.