In a lot of companies, executives and business teams want answers from company data, but they do not know SQL.
That part is obvious.
What is less obvious is that SQL is not the real problem.
The real problem is this:
How do you let non-technical users ask business questions about company data without exposing raw SQL, direct database access, or completely uncontrolled AI generated queries?
That was the problem I wanted to solve.
The naive solution looks attractive
The first idea is always the same:
Connect an AI assistant directly to the database and let people ask questions in natural language.
At first, this sounds great.
In practice, it creates a different set of problems:
• the business definition of a metric is not stable
• different prompts may produce different SQL for the same question
• there is no strong boundary between approved and unapproved logic
• scheduling, monitoring, and delivery workflows are still missing
• auditability becomes weak very quickly
• private environments become painful to manage
In other words, query generation is only one small part of the problem.
The harder part is making the answers reliable.
The pattern I ended up using
Instead of letting AI write arbitrary SQL for business users, I flipped the model.
The system starts from real SQL written and approved by analysts.
The flow looks like this:
- An analyst writes a real SQL query.
- They define only the minimal input parameters needed for the business question.
- That query becomes a governed KPI.
- The KPI can contain multiple query variants.
- Business users never see SQL.
- They only see KPI cards and ask follow-up questions in plain language.
- AI maps the question to the right KPI variant.
- The backend executes only approved query paths.
- The UI renders the result as a scalar, a short list, or a chart.
That design changes everything.
The SQL remains controlled.
The business experience becomes flexible.
Why query variants matter
This was one of the most important parts of the design.
A single KPI often needs more than one query behind it.
For example, imagine a fintech KPI about money movement.
The same KPI may need:
• a default comparison variant for today versus yesterday
• a trend variant for a daily bar chart this week
• a breakdown variant for operational exceptions like refunds or failed payments
From the business user’s point of view, this still feels like one KPI.
From the backend point of view, it is a governed set of approved query variants.
That means the user can ask:
• How are we doing versus yesterday
• Show the daily trend this week
• Are refunds rising
But the system is not improvising SQL every time.
It is resolving the question to a predefined execution path.
That is the difference between flexibility and chaos.
What the AI actually does
This is the part I think many teams get wrong.
In my flow, AI does not generate arbitrary SQL against the database.
Its role is narrower and much more useful:
• interpret the user’s question
• map it to the correct KPI
• select the correct query variant
• resolve the right time context and parameters
• explain the result in business language
So the AI is acting as a language and intent layer, not as an unrestricted database operator.
That matters because it gives business users a natural interface without giving up control, auditability, or execution safety.
Why this works better for business users
Business users do not want to think about joins, schemas, or prompt engineering.
They want answers like:
• How did onboarding perform last week
• Show daily wires and P2P transfers this week
• Are failed payments increasing
They also want charts, lists, and short explanations.
If the underlying SQL is already approved and versioned, you can give them that experience safely.
The UI becomes simple because the backend is strict.
That is a much better tradeoff than giving everyone direct AI to database access.
Execution still matters
Even with this model, execution is still the real backbone.
In my case, query execution, scheduling, and monitoring all follow the same deployment model.
They can run:
• in the cloud
• or on-prem through a dedicated installed agent
In general, on-prem is the preferable setup for sensitive environments, because the data never needs to be exposed outside the customer environment.
The platform orchestrates the workflow, but execution stays close to the database.
That turned out to be a very important distinction.
A lot of teams do not just need answers.
They need answers without opening up their data environment too much.
What this unlocked
This approach gave me a few things at the same time:
• business users can ask follow-up questions in plain language
• analysts still control business logic
• the results stay tied to approved SQL
• charts and tables stay consistent with the same KPI definition
• scheduling and monitoring remain part of the same operational system
• cloud and on-prem execution both fit naturally into the model
So instead of treating natural language as a replacement for data workflows, I ended up using it as an access layer on top of governed workflows.
That feels much more robust.
Final thought
I think a lot of teams are focusing on the wrong question.
The question is not:
Can AI generate SQL
The more important question is:
How much execution freedom should AI have around company data
For business-facing analytics, I have become convinced that natural language works best when the SQL underneath is already approved, versioned, and operationally controlled.
The hard part is not letting AI write SQL.
The hard part is making business answers reliable.
I’m building this approach in DataPilot, where approved SQL becomes governed business KPIs and business users can ask follow-up questions without touching raw SQL.
If you want to see the product context behind this model, it’s here:
https://getdatapilot.com/product/business-kpis
Top comments (0)