The allowlist is the AI feature
What I learned from the first version of Nia, which turned plain-English questions into SQL over an allowlisted set of tables.
In procurement software, useful answers are often already in the database. The hard part is finding them. A person might want to ask, “Which orders are waiting on me?” without learning a report builder or searching through several screens.
For the first version of Nia at Tija, users could ask in plain English and an LLM, through LangChain, wrote SQL against an allowlisted set of tables.
The table list did more than help the model write a query. It defined the part of the product the assistant was allowed to talk about.
Make the question space visible
An enterprise database contains years of decisions: tables with similar names, records in different states, and relationships that make sense to the team but are not obvious from a prompt. Giving a model a vague “ask anything” instruction does not make those boundaries disappear.
An allowlist is a small, concrete starting point. It narrows the available data and gives the team a scope they can inspect. If a user asks something outside it, the assistant should be honest about the limit instead of filling the gap with a plausible-sounding answer.
That still does not make generated SQL automatically correct. A query can use permitted tables and still misunderstand the question. The allowlist constrains scope; it does not replace product rules, access checks or careful review of what the answer means.
Keep the model in its lane
I found it useful to treat the LLM as an interpreter for the question, not as the owner of business truth. The product owns which records a person may see and what terms like “waiting on me” mean. The model can help translate a sentence into a query, but a convincing sentence is not evidence that the query is right.
At Tija, I also built inventory insights with Google Gemini and stock-transfer suggestions ranked by travel distance. Those features solve different problems from Nia’s question-to-SQL flow, even though both use AI. Keeping the job of each feature clear makes it easier to decide what to test and where a human still needs to make the call.
This post describes the first version I worked on. A teammate later rebuilt Nia as a fuller agent. The early version taught me a useful design rule: before asking what an AI feature can do, decide what data and decisions it is allowed to touch.