How to Connect ChatGPT and Claude to Governed Business Metrics Without Direct Warehouse Access

By Luca Martial, CEO & Co-founder at Kaelio | Ex-Data Scientist | 2x founder in AI + Data | ex-CERN, ex-Dataiku · April 6th, 2026

The easiest way to connect an LLM to company data is also the riskiest: point the model at the warehouse and hope prompts will do the rest. That approach breaks down quickly. The model sees physical tables instead of business definitions, permissions get flattened behind broad credentials, and every new AI client creates another custom integration to maintain.

There is a better pattern. Instead of exposing raw warehouse access, expose governed business metrics through a context layer that ChatGPT, Claude, or another AI client can call. The model should receive the business interface to your data, not the entire internal structure of the data warehouse.

Why Direct Warehouse Access Fails

When teams wire a model straight to Snowflake, BigQuery, or Databricks, they usually hit the same three problems.

1. Physical schema is not business context

Raw tables do not tell the model which revenue definition is canonical, which join path is approved, or how churn is segmented for the board deck. Even strong model reasoning cannot replace missing business structure.

2. Permissions get too broad

In practice, direct access often means one shared service credential or an execution path that is looser than the warehouse and BI paths humans normally use. That is exactly the opposite of what teams want for production analytics.

3. Every model vendor becomes a separate integration problem

One custom connector for ChatGPT. Another for Claude. Another for your internal agent framework. The query logic drifts, the permission handling drifts, and the sources cited by each client drift.

That is the integration tax MCP is trying to reduce.

What the Governed Architecture Looks Like

The production-safe pattern is straightforward:

1. The user asks a question in ChatGPT, Claude, or another AI interface.
2. The model calls a governed service through MCP or API.
3. That service returns approved metrics, dimensions, filters, lineage, and constrained query tools.
4. The warehouse query runs through governed execution paths.
5. The final answer returns with source references or citations.

This architecture changes the model's job. Instead of inventing business logic from raw schema, it selects from governed business context.

That is why the context layer matters. It is not just a metadata store. It is the layer that converts your stack into something an AI system can consume safely.

What MCP Changes

Model Context Protocol is important because it gives AI systems a standard way to work with external context providers and tools. Instead of building bespoke adapters for every model or app surface, teams can expose one governed endpoint and reuse it across clients.

That matters even more now that OpenAI documents how to build and connect remote MCP servers for ChatGPT apps and API integrations, and has highlighted support for remote MCP servers in the Responses API. The point is not that every deployment must use one protocol immediately. The point is that the ecosystem is converging on a standard way to deliver context.

For data teams, that is a major architectural improvement:

• one governed service
• multiple AI clients
• shared metric definitions
• less vendor-specific glue code

What the Model Should Receive Instead of Raw Tables

If you are designing the interface correctly, the model should receive things like:

• approved metric definitions from dbt or other governed systems
• business-friendly dimensions and filters
• valid join paths
• explanatory descriptions
• source references or lineage context
• access-constrained query tools

If your team already uses a semantic layer such as dbt Semantic Layer or Looker's modeling layer, those investments become upstream inputs into the governed interface. The model should not need to reconstruct them from scratch.

ChatGPT and Claude Should Not Need Different Metric Logic

One of the biggest advantages of this pattern is architectural symmetry. Whether the end user asks in ChatGPT, Claude, or an internal assistant, the answer should come from the same governed business layer.

That means:

• the same metric definition for ARR
• the same access rules
• the same approved filters
• the same lineage and citation path

Without that shared layer, every client becomes its own semantics engine. That is how metric drift starts in AI deployments.

A Practical Rollout Pattern

If you want to connect production AI clients to business metrics, keep the rollout narrow and governed.

1. Start with approved metrics, not raw domains

Expose board-level or team-level KPIs first. Resist the urge to hand the model every table in the warehouse.

2. Keep the initial tool surface read-only

Read-only search, fetch, and governed query tools are much easier to secure and monitor than mixed read-write automation.

3. Preserve source visibility

The answer should make it easy to trace where the number came from. This is important for both trust and debugging.

4. Reuse your existing governance

NIST's AI RMF is clear that trustworthy AI requires ongoing governance and traceability. The easiest way to achieve that in analytics is to reuse the controls your data stack already supports rather than building new ones in the model layer.

Where Kaelio Fits

Kaelio auto-builds a governed context layer from your warehouse, semantic models, BI tools, and business knowledge. It can expose that context through MCP or API, so the same governed answer surface can be used by ChatGPT, Claude, or custom agents. That is the practical difference between "we connected a model to data" and "we deployed a governed AI analytics layer."

If your team wants faster self-serve analytics without raw warehouse exposure, that is the architecture to copy.