Every analytics team lives with the same bottleneck. A business stakeholder has a question — "Which regions slipped last quarter?" — and somewhere between that sentence and the answer sits a SQL query that only a handful of people know how to write. The question is simple. The translation is not. Natural-language analytics closes that gap by letting anyone ask in plain English and having the AI write, run, and explain the SQL for them. This post walks through how that actually works, why it can be trusted, and where it runs.
The Gap Between Questions and SQL
Business questions are expressed in business terms: customers, revenue, last quarter, top performers. SQL is expressed in schema terms: table names, join keys, date functions, group-by clauses, and window functions. Bridging the two requires knowing both the intent behind the question and the exact shape of the data that can answer it.
That bridge is usually a person — an analyst or data engineer who fields a steady stream of ad-hoc requests. It works, but it does not scale. The analyst becomes a queue. Stakeholders wait. Simple questions that should take seconds take a day. And the institutional knowledge of "which table holds revenue and how it joins to customers" stays locked in a few heads.
Natural-language analytics removes the queue without removing the rigor. The stakeholder asks the question directly in chat, and the AI does the translation that the analyst would have done — against the real schema, with the real join logic.
How the AI Translates a Question into SQL
When you type a question, the AI is not guessing at a generic answer. It is reasoning about your connected datasource: the tables, columns, types, and relationships that actually exist. It maps the business language in your question onto those schema objects, then composes a SQL query that expresses the intent.
Consider a straightforward example:
You ask: "Top 5 customers by revenue last quarter"
SELECT c.customer_name,
SUM(o.amount) AS total_revenue
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.order_date >= '2025-10-01'
AND o.order_date < '2026-01-01'
GROUP BY c.customer_name
ORDER BY total_revenue DESC
LIMIT 5;
The AI handled several things at once: it identified the tables that hold orders and customers, inferred the join between them, translated "last quarter" into a concrete date range, recognized "revenue" as the order amount to sum, and applied the "top 5" as an ordering plus a limit. That is exactly the work a human analyst would have done — produced in seconds.
Here is a second example that shows the same reasoning on a different shape of question:
You ask: "How many new accounts did we open each month this year, and which month was highest?"
SELECT DATE_TRUNC('month', created_at) AS signup_month,
COUNT(*) AS new_accounts
FROM accounts
WHERE created_at >= '2026-01-01'
GROUP BY signup_month
ORDER BY signup_month;
The AI grouped by month, counted the rows, scoped to the current year, and returned an ordered series. When you ask which month was highest, it can reason over that result rather than starting from scratch — which brings us to context.
The Safety Model: Read-Only, Row-Limited, Sandboxed
Letting an AI write SQL against a production datasource sounds risky until you look at the constraints it runs under. Every generated query executes inside a safety envelope:
- Read-only. The AI can issue queries that read data. It cannot insert, update, delete, drop, or otherwise modify anything. There is no path from a chat question to a write against your source.
- Row-limited. Results are capped so a careless or overly broad question cannot pull an unbounded volume of data or hammer the source system.
- Sandboxed. Queries run in a controlled execution context, isolated from anything they should not touch.
This model is what makes the feature safe to put in front of non-engineers. The worst outcome of a badly phrased question is a query that returns a limited, read-only result — not a data loss event. Data engineers can hand this capability to the broader organization without giving up the guardrails they would normally enforce by hand.
It is worth being explicit about what this means for risk. The classic objection to letting more people near a database is that someone will run an expensive query at the wrong time, or worse, mutate data they did not understand. The safety envelope removes both failure modes structurally rather than relying on training or convention. Writes are not merely discouraged; they are impossible through this path. Runaway scans are not merely frowned upon; they are bounded by the row limit. That structural guarantee is what lets an organization say yes to broad access instead of defaulting to a small allowlist of trusted query writers.
Why Inline Explanations Build Trust
An answer you cannot verify is an answer you cannot act on. That is why every response includes an inline explanation of what the AI did. Alongside the result, you see the reasoning: which tables it used, how it interpreted "last quarter," what it summed, and how it ranked the output. The generated SQL itself is visible.
This matters for two audiences. For analysts and engineers, the explanation is a review surface — they can read the SQL, confirm the join was correct, and catch a misinterpretation before it propagates into a decision. For business users, the explanation builds confidence that the number on the screen means what they think it means. Trust in self-service analytics is not won by hiding the machinery; it is won by showing it clearly. An explained answer invites scrutiny, and scrutiny is what makes the result dependable.
Multi-Turn, Context-Aware Conversations
Real analysis is rarely one question. It is a thread: you ask something, see the answer, and follow up. Natural-language analytics is multi-turn and context-aware per datasource, so the conversation holds together.
You: "Top 5 customers by revenue last quarter"
(answer returned)
You: "Now just the ones in the EMEA region"
You: "And show their order counts too"
Each follow-up builds on the prior turns. "Just the ones in EMEA" is understood as a filter on the previous result, and "show their order counts too" extends the same query rather than abandoning the context. You refine your way to an answer the way you would in a conversation with an analyst, instead of re-specifying the full question every time. Responses stream back as they are produced, so you see the answer forming rather than staring at a spinner.
Where It Runs: Azure or Fully Air-Gapped
The intelligence behind all of this runs on the AI engine you choose. There are two paths, and they exist for two very different operating environments:
- Azure AI Foundry for organizations that are comfortable running their AI workloads in the cloud and want managed, scalable inference.
- Local, air-gapped Ollama for organizations that cannot let data leave the building at all — defense, healthcare, finance, and any environment with strict data-residency or isolation requirements.
The air-gapped option is the important one for on-prem deployments. The same ask-your-data experience runs entirely on local models, with no external calls, so the natural-language analytics capability is available even on networks that are fully disconnected from the internet. You do not trade away conversational analytics to meet an isolation mandate.
The choice of engine does not change the experience for the person asking the question. The translation, the safety envelope, the inline explanation, and the multi-turn context all behave the same way whether inference happens in Azure AI Foundry or on a local Ollama model. What changes is where the computation lives — which is exactly the decision that data residency and security policy should drive, not the feature set available to analysts. An organization can start on one engine and move to the other as its requirements evolve, without retraining users on a different workflow.
Matching the Engine to the Environment
The decision usually comes down to where your data is allowed to go. If your governance posture already permits cloud processing for analytics, Azure AI Foundry gives you managed inference that scales with demand and requires no local model hosting. If your data cannot leave a controlled boundary — because of regulation, contract, or classification — the local Ollama path keeps every token of every question and every byte of every result inside your own infrastructure. The platform itself is Windows-hosted and runs on-prem, so the air-gapped path is a first-class deployment mode rather than a degraded fallback.
Keeping Usage Accountable
Because every question consumes AI inference, token usage is tracked and each organization operates under a monthly budget. This keeps consumption visible and predictable. Teams can see how the capability is being used, and the budget guards against runaway cost or abuse without requiring anyone to police individual queries by hand. It is the same principle as the safety model: give people freedom to ask, inside boundaries that keep the system healthy.
Tracking also gives administrators a feedback signal. A spike in usage on a particular datasource often means that datasource is answering questions people genuinely need — a good candidate for a curated report or a cleaned-up data model. Flat usage on a source that was expected to be popular can point to a naming or modeling problem that is making questions hard to answer well. The budget is not just a cost control; it is a lightweight window into how the organization is actually using its data.
What This Changes in Practice
Put the pieces together and the workflow changes shape. The analyst stops being a query queue and starts being a steward of the data model — making sure tables are clean, well-named, and correctly related, so the AI generates good SQL. Stakeholders get answers in seconds instead of waiting a day. And because every answer is explained, sandboxed, and read-only, the organization gets self-service analytics without surrendering the rigor that made the data trustworthy in the first place.
Realistic questions that work well include:
- "What was our total revenue by product category last month?"
- "Which sales reps closed the most deals this quarter?"
- "Show me customers who haven't ordered in the last 90 days."
- "Compare this year's monthly signups to last year's."
- "What's the average order value by region?"
Each of these is a sentence anyone can write. Behind each one, the AI assembles the correct SQL against your schema, runs it safely, and tells you exactly how it got the answer. That is the whole promise of natural-language analytics: the question stays human, and the translation — the hard part — stops being a bottleneck.
Getting Started
If you already have a datasource connected, you can start asking questions of it today. Point the chat at the datasource, type a question the way you would say it out loud, and read both the answer and the explanation. Start with something you already know the answer to — it is the fastest way to build confidence that the translation is sound. From there, the natural follow-ups will take you deeper than any single pre-built dashboard could, all while staying inside the read-only, sandboxed, budget-aware boundaries that keep your data safe.