AI how-to guides Technology and data
How to query your data in natural language
Put a governed semantic layer between the AI and your data, defining metrics, dimensions and joins once, and let a language model translate each question into a query on that layer, run it with the user's permissions and explain how the number was built. Data owners keep control of the definitions; business users self-serve. Start with one domain and the questions people already ask the data team.
What AI does
- Translates a plain-language question into a query against the agreed metrics and dimensions.
- Runs the query with the user's own permissions and returns a table, chart or dashboard.
- Explains in plain words how the number was built: which metric, filters, period and source.
- Asks for clarification when a question is ambiguous instead of guessing.
- Suggests follow-up questions and drill-downs on the result.
What stays with people
- Defining and approving metrics: what counts as revenue, an active customer or churn.
- Deciding who can see which data, and keeping those permissions current.
- Judging the answer before acting on it, especially for decisions with financial or regulatory weight.
How to put it in place
-
Collect the questions people actually ask
Look at the dashboard backlog, data team tickets and recurring reports, and list the questions behind them. Choose one domain, such as sales or operations, where the questions repeat and the data is reasonably clean.
-
Define the semantic layer for that domain
Agree the metrics, dimensions, joins and filters with the business and the data owners, with one definition per term. This layer is what stops the AI from inventing its own version of a metric.
-
Connect the model to the semantic layer, not the raw tables
Let the language model generate queries against the governed layer, with read-only access and the user's own permissions. Limit query cost and size so a vague question cannot overload the warehouse.
-
Build a test set and measure answers
Write real questions with their correct results and check the system against them before release and after every change. Include ambiguous and trick questions to see whether it asks for clarification or guesses.
-
Put it where people work and show the reasoning
Embed the answers in the tools people use, such as Teams, Slack or the CRM, with an explanation of how each number was built. Pilot with one team and collect the questions it fails on.
-
Govern changes and expand domain by domain
Track every change to a metric with reviewer and reason, and require approval for new metrics. Add domains one at a time, expanding the semantic layer and the test set as you go.
What you need
- A data warehouse or lakehouse with the domain's data reasonably clean and documented.
- A semantic layer or metric store, or the will to build one, with owners for each metric.
- Permissions in the data platform that can be applied per user.
- A set of real business questions with known answers to test against.
- A data team that owns definitions, quality and the approval of new metrics.
When it is not worth it
- When the data is scattered, undocumented or untrusted: fix the data foundations first.
- Very few users with fixed questions that a standard dashboard already answers.
- Highly specialised analysis that needs a data scientist's judgement rather than a quick answer.
Risks and how to control them
- Plausible but wrong numbers: ground queries in the semantic layer, show how each number was built and test against known answers.
- Data exposure: run every query with the user's permissions and never give the model broader access than the person asking.
- Malicious or careless input (prompt injection, destructive SQL): allow read-only queries only, validate generated SQL and cap cost and size.
- Inconsistent definitions across teams: one approved definition per metric, with change tracking and rollback.
How Thinkia does it
We start by mapping your current BI estate, the maturity of your semantic layer, the most recurring questions and the dashboard backlog, then define metric ownership, the natural-language query policy, where answers will be embedded and the governance workflow. Metrics, dimensions, joins and policies are defined once in the semantic layer and reused by every natural-language query, with version control and column-level lineage.
Users ask in plain language; the system grounds the query in the semantic layer, generates the dashboard and explains how each number was built. We pilot embedding in one team's flow, with Teams, Slack, Notion or the CRM as surfaces, then roll out by team; approval workflows for new metrics, usage and quality telemetry, and change tracking with reviewer, reason and rollback keep IT in control.
The Thinkia solution behind this guide
- AI dashboard builderDashboards from a question, not a ticket
- AI-ready data platformA platform AI use cases ship on
Thinkia products involved
Frequently asked questions
What is text-to-SQL?
It is the use of a language model to turn a question in plain language into a database query. On its own it can produce queries that run but answer the wrong question, which is why it works better on top of a governed semantic layer.
Can I just connect ChatGPT to my database?
Technically yes, but it is risky. Without agreed metric definitions, per-user permissions and read-only limits, you get inconsistent numbers and possible data exposure. Put a semantic layer and access controls in between.
How accurate is natural-language querying?
It depends on how clean and well-defined your data is and how ambiguous the questions are. Research benchmarks on real databases show models still make mistakes, so measure on your own questions and show users how each answer was built.
What is a semantic layer and why does it matter?
It is a shared definition of your metrics, dimensions and relationships, so revenue or active customer means the same thing everywhere. The AI queries those definitions instead of guessing from raw tables, which keeps answers consistent.
Does it replace our BI tool and data team?
No. It takes routine questions off the data team's queue and lets business users self-serve, while the team owns definitions, quality and complex analysis. Existing dashboards remain for fixed reporting.
Keep exploring
Related guides
Related decisions
- Fix the data first or start with AI now: which comes first?
- Microsoft Copilot vs custom AI agents: when is the suite assistant enough, and when do you need your own agents?