The other half of the company data
RAG answers questions about documents. But much of what the board wants to know is in no document at all: it is in tables. Revenue by branch, average ticket by channel, overdue balances by bracket, stock sitting still for more than ninety days. Today that becomes a request to IT, which becomes a SQL query, which becomes a spreadsheet — and three days later the question has already moved on.
NL to SQL, or text-to-SQL, is the technique that closes that loop: a person asks in plain language, the system generates the query, runs it and returns the result with the query in plain sight. The gain is not technical, it is the response time to a business question.
Why demos impress and rollouts disappoint
The difference is the database. On a small base with clear names and no junk, translation is nearly always right. On a real production database the problems the demo never had show up: tables named TB001, column names abbreviated in a mix of Portuguese and English, status fields with codes only the old-timers know, dates stored as text, duplicated customers, amounts in cents in one table and in currency units in another.
The BIRD benchmark was built precisely to measure this — large databases, dirty content and external knowledge required. In the original 2023 paper, the authors report 40.08% execution accuracy for the best system evaluated at the time, against 92.96% human performance. Models have improved a great deal since, but the lesson holds and it is the most important one here: the difficulty is not SQL syntax, it is understanding what the data means.
The semantic layer is the project
What makes NL to SQL work at a company is not the model, it is writing down what things mean. That has a name: the semantic layer. In practice it is a living document, versioned alongside the code, defining every metric and every business term.
The minimum contents: which tables and columns may be queried and what each one means in plain language; business metrics written as an agreed formula — is net revenue before or after returns, an active customer bought within how many months; the correct relationships between tables; the allowed values of status fields; and the synonyms people actually use, because nobody asks by column name.
Writing this is usually 70% of the project effort, and it is an asset that survives changing model and changing tool. Without the layer, any answer is a well-formatted guess; with it, the same question starts having a stable answer.
Security: the AI never touches the production database
Three non-negotiable rules. The connection is read-only, with its own user, against a replica and never the transactional database — that way a badly formed query degrades a report, not the day’s sales. Access respects the permissions of whoever asked: if the person cannot see payroll, neither can the automation, and that is enforced in the database, not in the prompt text.
And every generated query is validated before execution: SELECT only, only on allowed tables, with a row limit and a maximum execution time. Remember that the user question is external content and may carry a malicious instruction — the same prompt-injection problem AironCore addresses. The query has to be checked by rule, not by the model’s goodwill.
Show the SQL, and do not automate the decision
The interface should always display the generated query next to the result. That solves two problems at once: those who understand SQL can check it, and those who do not learn to be suspicious when a number looks odd. A system that returns only the number trains the company to trust something nobody audited.
And the automation rule applies here too: use it to answer a question, not to trigger a decision. The result feeds a conversation, a report, an analysis. Whoever cuts the credit line, approves the purchase or cancels the contract is still a person.
When NL to SQL is not the answer
If the question is always the same, the right answer is a dashboard, not a question translator. NL to SQL shines on the long tail: the question that comes up once, does not justify building a report, and today dies because asking is too much trouble.
It is also not the answer when the data is wrong. If the records contain duplicated customers and inconsistent status codes, the AI will answer precisely about wrong data — with an air of authority it did not have before. In that case the project is data quality, and it is better to find that out first.
Where to start
Pick five to ten questions the board actually asks and write the correct SQL answer for each one by hand. That set becomes the project test and the seed of the semantic layer. Then connect a read-only replica and measure: how many of the ten does the system get right unaided.
At JBKR this work usually runs alongside systems integration, because the data is almost never in one place. The initial 30-minute assessment is free and exists to say, without hedging, whether your case is an AI project or a fix-the-records project first.
