Every week, another executive asks some version of the same question: “Can we just point our AI at the data lake and ask it questions?” The short answer is yes. The more useful answer is: it depends entirely on what’s underneath.
The gap between “AI gave me a number” and “AI gave me the right number” is almost always a data problem, not an AI problem. And the organizations that figure this out early, before deploying AI tools to decision-makers, save themselves significant cleanup cost and lost credibility.
The Hallucination Problem Starts in Your Schema
When you point a large language model at a database, it tries to construct a SQL query based on what it can infer from your table and column names. If those names are clean, descriptive, and consistent, you get solid results. If they’re not, and in most enterprise data environments they’re not, the model guesses. Sometimes it guesses well. Often it doesn’t.
Consider a data lake with column names like X000478 or tables that share similar names across different domains. An LLM has no reliable way to know that “sales” means booked contracts in one department and invoiced revenue in another. It will make an assumption, return a number, and that number will look perfectly credible.
There’s also a subtler problem: most semantic models have fields that look similar, like Revenue vs. Revenue_Adjusted, but mean different things depending on context. Only your analysts know which is which. An LLM querying your data has no way to know that distinction exists, let alone how to resolve it correctly.
The model will try to construct a SQL query based on what it can infer from your data. If you have hundreds of tables and tens of thousands of columns, many with cryptic or inconsistent names, it will fill in the gaps with assumptions. Those assumptions produce answers that look correct and aren’t.
This isn’t a flaw in the AI. It’s a reflection of data that was built for transactional systems, not for machine interpretation. The fix isn’t to find a better model. It’s to build a better data layer.
Introducing the Platinum Layer
Most data teams are familiar with the medallion architecture: a Bronze layer where raw data lands, a Silver layer where it’s cleaned and deduplicated, and a Gold layer where it’s modeled for reporting: star schemas, semantic layers, KPIs, and all the structure that makes Power BI and Tableau work well.
The Platinum Layer sits on top of Gold and is designed specifically for AI consumption. It’s not a replacement for good reporting infrastructure. It’s an enhancement that makes that infrastructure legible to language models.
What Goes into a Platinum Layer
Building an effective Platinum Layer involves three distinct workstreams:
1. Schema cleanup. Every table and column name is reviewed for interpretability. Cryptic identifiers get replaced with plain-language equivalents. Joins are standardized so that relationships are unambiguous. The scope is deliberately narrowed. You don’t expose everything in the data lake, because excess context can confuse a model just as much as missing context can.
2. Context markdown files. Alongside the cleaned schema, you build a library of markdown documents that describe how the business actually works. Custom fields in Salesforce or an ERP. Non-standard calculations that the finance team uses. Domain-specific terminology. Definitions that differ by department. These files give the model the institutional knowledge it can’t derive from data alone.
3. A custom MCP server. The Model Context Protocol (MCP) layer sits between the LLM and your Platinum Layer. It contains rules for how to query well, what synonyms to expect from users, and how to handle ambiguous requests. It can enforce that the model reads the context files before attempting a query, something that turns out to matter more than you’d expect.
Without explicit enforcement, LLMs will sometimes skip reading context files entirely and fall back on inference and return plausible-sounding wrong answers. One mitigation: embed a token inside each markdown file that the model must retrieve before it can proceed with a query. It’s a small architectural detail that has a meaningful effect on accuracy.
Where This Works and Where It Doesn’t
With a well-built Platinum Layer, natural language querying becomes genuinely useful for executive ad-hoc questions, operational reviews, and exploratory analysis. Queries that aren’t on a standard dashboard. Questions that come up mid-meeting. Research that would otherwise require a data analyst to build a custom report.
What it doesn’t replace is deterministic reporting. LLMs are probabilistic by nature. They’ll get the right answer most of the time, but “most of the time” isn’t good enough when you’re presenting to a board or committing to a multi-million-dollar decision. For those use cases, validated Power BI or Tableau reports remain the standard. The Platinum Layer is a complement to those systems, not a substitute.
What Becomes Possible with a Platinum Layer
A well-built Platinum Layer doesn’t just enable natural language queries. It opens up a broader set of AI-powered capabilities that weren’t reliably accessible before.
Natural language querying. Executives can ask questions in plain English and get accurate, grounded answers without waiting for an analyst to build a custom report or pull data manually.
AI-generated reports and summaries. Board presentations and financial summaries can be drafted directly from your data, with AI pulling the relevant figures and framing the narrative. The key word is “drafted.” These still need human review before they go anywhere official.
Anomaly alerting. Rather than discovering a problem in a board meeting, AI can flag anomalies in your data as they emerge, surfacing issues that might have taken days or weeks to become visible through normal reporting cycles.
These capabilities share a common dependency: they all require the model to have accurate, interpretable, well-documented data to work from. Shortcut the foundation and you get outputs that look impressive in a demo and fail in production.
A Signal Worth Paying Attention To
Mid-market companies are increasingly fielding the same question from leadership: “Is our data ready for AI?” It’s moving from a technical conversation to a strategic one, and organizations that can’t answer it confidently are finding themselves slower to act when AI opportunities emerge.
The companies best positioned to take advantage of AI tools are the ones that built a clean, centralized data foundation before they needed it. That work takes time, and it’s much harder to do in a hurry.
How to Know If You’re Ready
The Platinum Layer amplifies a good data foundation. It can’t compensate for the absence of one. Before investing in AI query capabilities, it’s worth knowing exactly where your organization stands.
The organizations seeing real results from AI-powered data tools aren’t the ones that found a clever prompt or a smarter model. They’re the ones that put in the foundational work first and started with the right question.
Need a starting point? Take our AI Data Readiness Assessment to see how your data foundation measures up and where to focus next.
