That has two strategic implications. First, AI analytics initiatives should be scoped as knowledge-codification programs, not just self-service BI upgrades. If the organisation cannot state which definitions apply to which decisions, under what conditions, and when escalation is required, deploying an LLM simply automates ambiguity at scale. Second, the control point moves upstream. Instead of reviewing outputs one by one, organisations need governance over semantic definitions, contextual rules, approval workflows, and change management when business conditions shift.
For CIOs and data leaders, that suggests a more disciplined rollout model:
- limit AI analysts first to low-consequence use cases where ambiguity is acceptable;
- separate metric definitions from decision-context rules so both can be audited and updated;
- require explicit confidence and escalation conditions when context is incomplete or conflicting;
- assign named business owners for the logic behind high-impact answers, not just the underlying data assets.
The organisations that get value from AI analysts will not be the ones with the biggest models, but the ones that treat contextual business judgment as managed enterprise architecture. Without that layer, confident answers can become a new source of operational risk precisely because they look decision-ready.
If you work with data, you have probably had a leader ask some version of this question: Can we point an LLM at our data and have it analyze everything for us?
It is an understandable ask. Leaders want faster answers without having to send every question through the BI queue. They see what large language models (LLMs) can do with text and assume the same pattern should apply to business data.
The problem is that enterprise data does not explain itself.
I saw this while testing an AI analyst against real business questions. I would ask which accounts presented the greatest risk in the current quarter or which opportunities were most likely to close in the next 30 days. The system responded confidently with account or opportunity names. Some were wrong; some were fabricated; and others had little to do with the question.
The system produced answers without understanding the scope of the request or what the business meant by “at risk” and “likely to close.” It also did not know whether “current quarter” meant quarter-to-date performance or expected results by quarter end.
An AI analyst cannot understand the business just because it can access the warehouse. It can write SQL and return a number that looks credible. The risk is that it has to infer the business logic behind the answer. If the company has not defined that logic, the model will fill in the gap.
Most companies never documented all that business logic because experienced analysts supplied it. A strong BI team knew which revenue number leaders trusted. They understood when a dashboard was good for direction but not safe for an operating review. They knew when a result needed context before anyone acted on it.
In many companies, the analyst was the semantic layer.
That arrangement could work when the same analysts stayed close to the business. It becomes a problem when the system is expected to answer on its own. The LLM is now being asked to use judgment that the organization never gave it.
The problem is harder to detect when the answer isn’t obviously broken. It can sound reasonable while being wrong in a way that affects the business.
A defined semantic layer helps. It provides the system with approved definitions and the logic that connects them to the data. But those definitions still have to be applied to the right situation. The model may use the correct revenue definition and still choose the wrong time period. It may accurately calculate performance yet still misunderstand what the leader is trying to decide.
The data can be correct. The definition can be correct. The answer can still be wrong.
Beyond the semantic layer
A semantic layer can define what counts as an at-risk account or what makes an opportunity likely to close. The contextual layer tells the system whether those definitions apply to the question being asked. An account may meet the formal risk criteria and still fall outside the period the leader is trying to manage. The definition is valid; its application is wrong.
That context also changes over time. A definition approved at the start of a quarter may no longer fit after the forecast changes or leadership shifts the decision it is trying to make. The system needs to know which context is current and which assumptions have expired. Otherwise, it can apply an outdated assumption correctly and still produce the wrong answer.
Analysts used to supply that judgment as part of their job. They knew when a definition was technically correct, yet still wrong for the decision before them. An AI analyst needs to have that judgment available before the question arrives. If a person has to reconstruct it every time, the system loses much of the speed it was meant to create.
The agent also needs operating rules for handling incomplete or conflicting context. Those rules define when the agent can continue and when the uncertainty is significant enough for a person to step in. They also prevent temporary signals from quietly becoming permanent business logic.
Business ownership does not disappear
Business owners cannot review every answer without becoming a bottleneck. They need to review testing and evaluation results across many answers and understand when the context behind those answers has changed.
The business maintains that context by tying each definition to the decision and the period for which it was built. When any of those shift, the affected context is flagged for business review.
That review also has to cover the evaluation process itself. If the outcome has shifted, the system can improve its score while getting better at the wrong task. While the system can collect new information and propose changes, material updates to the context still need business approval.
That responsibility belongs with the business owner. Engineering can build the system correctly and the system can operate exactly as designed, while the assumptions underneath it are wrong.
Analysts used to carry much of that responsibility through experience. With an AI analyst, the business has to own the judgment behind the answer and decide when that judgment needs to change.
Who owns the logic behind your AI answers? Let us know: [email protected].
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.