Conver­sa­tional Analytics

Many tools now answer the question about revenue in the south directly in chat, with a number, a chart and a note on how the answer came about. The effort shifts from operating the tool to preparing the data.

A language model translates the question into a query, for example in SQL or DAX, runs it against the data model and phrases the answer. Follow-up questions work, and each answer builds on the last. We introduce this so that the answers can be trusted: on a described model, with verified examples, with the existing permissions, and with tests before release.

Why text-to-SQL breaks down in a company

With plain text-to-SQL, the language model reads table and column names and derives joins, filters and calculations from them. With small, clearly named data that works. In a company there are abbreviations, tables that grew over the years, and three views of what “revenue” means, and the result looks plausible and is still wrong.

With a semantic model, the assistant uses approved metrics, defined relationships and descriptions instead. Many vendors build on this, and with us every project starts at the model. What it looks like is described under Data Modeling & KPIs.

What has to happen before you switch it on

Turning the feature on is not enough. Metrics and columns need clear names, descriptions and synonyms, and helper fields are hidden. For frequent questions we store approved answers or example queries, which go by different names depending on the platform, from verified answers to verified queries.

The assistant may only show what the person asking is allowed to see in the report. We check that with test accounts in different roles. Then comes the question catalog: typical questions from the business teams with a known answer, plus ambiguous questions and ones that should stay unanswered. It reruns after every change to the model. After release we evaluate questions, wrong answers and feedback, and watch capacity consumption.

Which vendor fits

The products develop fast, and names and feature sets change within a few months. Which one fits depends mostly on where your data and model already live. If you maintain your model in Power BI, you start with Copilot. If you work on a data platform, look first at its own assistant, and if you use Looker, at its chat feature. We keep the model independent of any one tool, so you can change vendor later.

Connecting to Teams, Slack or other assistants often runs through the Model Context Protocol (MCP), which allows access to data models without a separate integration per client. Microsoft, for example, offers an MCP server that reads Power BI models under the rights of the signed-in person, row-level security included. Answers then arrive where people work anyway. MCP does move data, though: metadata and query results go to the client and from there possibly to the language model provider. Which clients are allowed is therefore also a data protection and security decision.

Where the questions are processed

Questions, model metadata and sometimes result data go to a language model. Where that happens depends on vendor and configuration. In Power BI and Fabric, a setting in the admin portal decides whether data for Azure OpenAI may be processed outside the geographic region of the capacity. That matters when the service is not available in your region. Fabric data agents have their own settings for cross-region processing.

On Snowflake, accounts outside the natively supported regions can use Cortex Analyst through cross-region inference, in which case requests are processed in other regions. Looker customers in the EU can enable processing within the region. Whether a configuration meets the company’s requirements is for data protection and legal counsel to assess. We implement the settings technically. Hosting and model choice are covered under GDPR-compliant AI.

Where chat reaches its limits

Language models can invent answers, misread questions or pick one of several readings of an ambiguous phrase. Microsoft points out that the behavior is not deterministic: the same question can produce different answers. There are also product limits, for example on the amount of data returned or on official support for languages other than English. So we test questions in German specifically.

Traceable answers help, such as showing the underlying query. For important decisions the answer should be checked against the report. Chat suits ad hoc questions for which no report exists yet. Metrics that are tracked regularly still belong in a dashboard, because everyone sees the same view and can follow changes over time. Both use the same model.