Ask a modern AI assistant a plain-English question about a business, such as how many customers renewed last quarter, and it may answer instantly in a polished sentence.
The harder question is whether the answer is right.
That problem is becoming more important as companies connect AI systems to internal databases, dashboards and operational records. A model that sounds fluent can still misunderstand a metric, choose the wrong table or apply the wrong business rule. In a demo, that may be a technical limitation. In a real company, it can become a decision-making risk.
Haricharan Shivram Suresh Chandra Kumar has spent much of his career working on the data layer behind that problem. A principal data engineer at the health insurance marketplace eHealth, he builds data platforms intended to help AI systems query company information without guessing at what the data means.
His book, AI-Native Data Engineering, focuses on how data systems need to change as large language models become part of business workflows.
Language models are designed to produce convincing text. That is not the same as producing a correct business answer.
When a question involves several tables, a date range or a company-specific rule, the system has to understand more than language. It has to understand how the business defines the metric. A human analyst may know that "renewed customer," "active member" or "revenue" has a precise internal meaning. A model may treat those terms as ordinary words and infer the rest.
That is where the risk begins.
"The dangerous failure is the model that hands you a precise, confident, completely wrong number, because it guessed what your data meant and guessed badly," Kumar says. "The model that admits it does not know is the safe one. My whole job is to remove the guessing."
In regulated industries such as health insurance, that distinction matters. If an AI system misunderstands eligibility, coverage, plan details or subsidy logic, the error is not abstract. It can affect a real person's options and a company's compliance obligations.
Raw data rarely explains itself.
A column labeled revenue may refer to gross revenue, net revenue, recognized revenue or revenue after refunds. A column labeled active may depend on product status, billing status, account status or a date-specific rule. The database may store the value, but it does not always carry the full business meaning.
Kumar's work focuses on reducing that ambiguity. In self-service analytics systems, one way to do that is through a semantic layer: a shared set of definitions that tells the system what important business terms mean and how they should be calculated.
Instead of allowing AI to infer the meaning of a question from context alone, the system narrows the available meaning before a query is run.
"People think the hard part is the AI. The hard part is the dictionary," Kumar says. "Before you let anyone ask a question in English, you have to decide, precisely and in code, what every word in that question is allowed to mean."
That is less glamorous than a chatbot demo, but it is the work that makes the answer more reliable.
A useful business AI system should not only return an answer. It should make the path to that answer visible.
That means showing what data was used, what query was run, what definition applied and whether the result falls within a reasonable range. If the question is ambiguous, the system should ask for clarification. If the data is incomplete, it should say so or hand the issue to a person.
"An answer you cannot audit is a rumor with good grammar," Kumar says. "In healthcare especially, someone will eventually ask how the system reached a decision."
That requirement changes how data teams design AI-connected systems. Guardrails, validation checks and visible logic become part of the product rather than back-end details.
Many AI analytics tools work well in controlled examples. Real companies are messier.
Definitions drift. Teams use the same term differently. Tables change. Data arrives late. A question that seems simple in English may require several assumptions before it can be answered correctly.
Kumar designs for those moments. The goal is not to force the model to answer every question. The goal is to make the system reliable enough to know when it should answer, when it should ask a follow-up and when it should stop.
"Anyone can build a version that performs well in a clean demo," Kumar says. "The real engineering is in the difficult 20%: what happens when the data is missing, when two teams define the same metric differently, and when the question is vague."
That is where trust is won or lost.
For years, data engineering was often described as moving data from one place to another and keeping dashboards running. AI has raised the stakes.
If companies want AI systems to speak about their own operations, the underlying data has to be defined, governed and traceable. Otherwise, the organization risks replacing slow manual analysis with fast, confident mistakes.
The future of AI in business may depend less on whether chatbots sound smart and more on whether their answers can be checked.
The fluency has already arrived. The trust still has to be built.