Connecting AI to enterprise data: the layer every solution skips

A CIO's guide to governed data access

Connecting AI to enterprise data is treated as the easy step in almost every vendor pitch — the detail you delegate downward once you have picked a capable solution. It isn't a detail. It is the entire risk surface, and it is the one thing that should keep a CIO up at night.

The AI itself is becoming a commodity. The major solutions — built on Claude, OpenAI, and Gemini — are converging on similar capabilities, similar pricing, and increasingly similar interfaces. What none of them hands you is the part that actually determines whether your agent is safe to put in front of regulated data: how it reaches that data, what it costs every time it does, and who is accountable when something breaks at 3am. That layer — governed data access — is where enterprise value and enterprise risk both concentrate. This post is about how to evaluate it.

We are going to be honest about the trade-offs, including ours. If a vendor will not tell you where their approach bites, you are not reading an evaluation — you are reading a brochure.

Three doors into your enterprise data

Any AI agent that touches enterprise data goes through one of three doors. Each opens onto the same room. Each has a different lock, a different cost, and a different answer to the question that matters most: who is accountable when it fails?

Figure 1 — Three doors into enterprise data, scored on the CIO's lens.

Door one — native connectors. Purpose-built integrations, coded deliberately against a system's API. They are slower to stand up because each operation is built on purpose. In return you get predictable calls, predictable results, an auditable trail, and — critically — the only clean path to OAuth2 today. The cost is engineering time, paid once. This is the boring backbone serious shops keep, and it is the right door when you need to write data back and save it, not merely read it.

Door two — third-party MCP. The Model Context Protocol is built for interoperability and speed of reach. Connect once and you often get immediate access to every operation a system exposes — no per-operation coding. That breadth is real and worth having. But it is metered interoperability, not free interoperability, and we will come back to its sharp edges in a moment.

Door three — web scraping. The access of last resort, for when no API and no MCP service exists. It has genuine value — sometimes it is the only way in — but it carries real exposure: terms-of-service and legal risk, brittleness, silent breakage, and variable data quality. It is the door you use knowingly, with eyes open, not the one you design around.

The instinct is to read this as “pick the right door.” That is the wrong instinct, and it is the heart of what follows.

The MCP reality check

MCP is the loud favourite right now, and the AI solution vendors are enthusiastically pro-MCP. We agree it is powerful. We also think the enthusiasm skips past four things a CIO should hear plainly.

It costs tokens on every call. MCP is synchronous and metered. Each operation consumes tokens, so cost scales with usage — indefinitely. For “fetch one record,” that is fine. As a pattern for steady, high-frequency access, the meter never stops running.

It is volume-limited. Synchronous and capped means MCP is the wrong tool for bulk data movement. It is built for breadth of reach, not depth of throughput. Ask it to move volume and it will fight you.

The ecosystem is young. Few mature services expose a clean MCP surface yet, and even large providers ship MCP integrations with bugs. This will improve. Today it means you are building on fresh concrete.

And the detail nobody volunteers: MCP's own OAuth2 frequently still rides on a traditional connector to mint the token. You use the connector to obtain a token that the MCP server then consumes. In other words — MCP does not replace the connector. It often depends on one. The narrative that MCP changes everything quietly omits that MCP frequently stands on the very thing it is supposed to supersede.

None of this is a case against MCP. It is a case against treating MCP as a religion rather than a tool with a shape.

“But won't Skills make this layer unnecessary?”

This is the sharpest question a CIO can ask right now, so let us take it head-on rather than around.

A Skill is a procedure package — a markdown file that teaches an AI agent how to perform a repeatable task: what steps to take, in what order, in what format. It originated with Anthropic but is now an open standard the major labs have converged on; the same SKILL.md works across Claude, OpenAI's tooling, and Gemini. It is portable, it is largely free, and it is genuinely useful. We are not going to pretend otherwise.

Here is what a Skill is not. It is not a connector. It does not mint OAuth2 tokens. It does not own your audit trail, control your per-call token cost, move bulk volume, or give you a single accountable vendor. A Skill is a smarter agent reaching into the access layer — it does not build that layer, and it does not govern it.

Figure 2 — A portable, AI-agnostic Skill sits on top of the governed access layer and depends on it.

So what do Skills actually change? They commoditize the procedure layer. The “we package your repeatable workflows for you” pitch — which several solutions leaned on — is now something a customer can do themselves in markdown, on whichever AI they like. And that is precisely the point: when the procedure layer commoditizes, the durable value moves down, to the layer Skills depend on but cannot replace. Governed access.

We will go further, because it is the honest position: some customers will write their own Skills rather than buy ours, and that is fine. The claim is not “Skills need GoodBards specifically.” The claim is “Skills need an access layer — and GoodBards is the governed, accountable one.” We even ship our own Skills that drive our connectors and native tools, which makes the dependency concrete rather than rhetorical. The Skill rides on the layer.

Notice what just happened to the competitive picture. You are no longer choosing between three AI solutions on the strength of their underlying engines. Whichever you pick, the engine is commoditizing and the procedure layer is commoditizing. The governed access layer is the part that stays valuable — and that is the part you have to decide who owns.

Why connectors don't die

Given all the energy around MCP and Skills, it is worth saying clearly: traditional connectors are not legacy. They are the predictable backbone.

They give you calls and results you can reason about. They are the only clean route to OAuth2 right now — which is why, as noted, MCP often borrows them. And they are the correct tool whenever you need to collect data and save it back, with predictable behaviour you can put in front of an auditor. Their cost is engineering time, spent once, after which they are cheap and stable to run. For regulated workflows and write-back operations, this is not the old way. It is the right way.

When scraping is legitimate — and when it's a liability

Scraping earns honest treatment in both directions. It is the access of last resort, and “last resort” is not a slur — when a system exposes no API and no MCP service, scraping may be the only way to reach data you have every right to use. That value is real.

So is the liability. Scraping breaks silently when a page changes. It carries terms-of-service and legal exposure that sits with you, not the site. Data quality varies, and there is no contract, no SLA, and no one to call when it fails. Use it deliberately, scope it tightly, and never let a critical workflow depend on it as though it were a governed integration. It isn't one.

The real question: who assembles the middle?

Step back and look at the whole solution, because this is where the competitive picture resolves.

Figure 3 — The same agent and data, two ways to wire the middle: DIY stack versus one governed layer.

With a raw AI API, you are the systems integrator for the access layer. Connectors, MCP clients, OAuth2 flows, scrapers, logging, error handling — six moving parts, six failure modes, often six different vendors, all stitched together and owned by your team. A mature engineering organization absolutely can build this. The question is whether they should own the risk of it.

With a governed solution, that middle collapses into one accountable surface. One audit trail. One place to switch access methods without re-architecting. One vendor to call when something breaks. The frontier AI providers are positioned a layer up — they sell you a brilliant engine and leave the governed road it drives on to you. That is not a criticism of their product. It is a description of where their product stops and your integration burden begins.

Flexibility is the thesis

Here is what a single access pattern cannot give you, and why it matters more as you grow.

Companies change. Volume that was trivial last year is expensive this year. Token costs for AI keep climbing, and a workload that made sense on metered MCP in month one can quietly turn into a line item your CFO circles in month twelve. The vendor selling you one door is selling you their roadmap, not your architecture.

The portfolio answer is to start a workload on MCP for speed, and migrate it onto a built connector the moment volume makes the token math turn against you — on the same platform, without re-architecting. Read-heavy exploration stays on MCP. Regulated write-back lives on connectors. The genuine edge case goes through a scoped scraper. And as the economics move, you move with them, because all three doors are yours.

That is the position worth holding. Not “MCP wins” or “connectors win” or “Skills changed everything.” The AI engine is commoditizing. The procedure layer is commoditizing. What endures is a governed data access layer that offers all three doors, owns the accountability, and lets you change your mind as the company and the cost curve change theirs.

Connecting AI to enterprise data was never the easy step. It is the layer every solution skips — and the one a CIO should own deliberately, rather than own the risk of having outsourced without noticing.