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

When governance starts to feel like a huge pain in the neck, people will inevitably find a way to skirt around it. It's human nature.

In my 20-plus years in enterprise architecture, across Oracle, MuleSoft, Salesforce, and now working with some of the world's largest companies, I’ve watched this pattern repeat with every major technology shift. It works like this: 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. And instead of fixing the control layer, employees start routing around it.

Right now, this pattern is playing out at two levels of the enterprise. Boards are hiring Chief AI Officers to circumvent IT, and developers are abandoning governed protocols to circumvent overhead. Really, this is the same instinct at different altitudes, and it needs the same architectural fix.

So far, every major technology shift I've seen has come with ways to balance speed, scale, and scope. When the cloud arrived, we had architectures. Cybersecurity became a board-level concern, and with it came 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. 

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 couldn't. In my experience, the CAIO role is usually created because the board wants AI implemented yesterday. 

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 holding on with both hands just trying to keep production systems stable. Sometimes, this is misconstrued by leadership as a need to refocus and create a separate AI team. 

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.

Organizations ended up with dozens of MCP connections, each with its own credentials, security posture, and 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. Suddenly, the very protocol that was supposed to simplify things starts to feel like an obstacle.

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 titled "MCP is Dead; Long Live MCP!" His argument is that for an individual developer working on their own machine, the lighter tools win. But I say that 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.

It's about security at scale. It shouldn't be surprising that what works for one person on a laptop falls apart for a team of 50 building software that has to be maintained and secured. 

The difference between levels

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

And in both cases, moving around the friction works fine for a while. The solo developer works faster with lighter tools, and the new CAIO makes their own decisions without having to navigate IT. But at scale, you can start to see the cracks in the plan. Ungoverned agent connections scatter across the org, and AI experiments are running against production systems with no visibility into who’s accessing what.

Imagine sitting in an incident review asking how an AI agent got write access to your ERP, and a table of blank stares and total quiet.

Build a governance layer fast enough and useful enough that people stop going around it

This is what concerns me most about the current moment. You don’t see the damage until something breaks.

In my role, I talk to CDAIOs every week, and the same concerns keep bubbling 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, but they lack the architecture to support them.

Now you have a CAIO building an AI strategy that doesn't connect properly to the existing infrastructure, and 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 that splits the stack into two zones.

The top zone is where AI teams experiment. This zone changes fast, and it should. New approaches show up constantly, and teams need the freedom to try them, swap them, and learn. And lighter, faster tools belong here, because the blast radius of experimentation is contained. The CAIO owns this space.

The bottom zone is where the business runs. This is where agents actually do things like process an order, check inventory, verify a payment, and route an approval. This zone needs to remain stable and well-governed because failures here will affect customers, revenue, and compliance. And a governed protocol like Enterprise MCP, deployed centrally with proper auth and visibility, earns its place here. The CIO owns this space.

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.

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.

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 just needs 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. You can't replace enterprise infrastructure overnight. You also can't treat your infrastructure as something precious to protect and gatekeep. If you do, every AI team in your company is going to go around you. So, if 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've built. Here are the 100 capabilities already exposed and ready to go."

Do what you're best at

Even though 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. We have to work strategically and get the architecture right to avoid a 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 and Chief Strategic Architect at Workato, where he advises some of the world's largest enterprises 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.