Natural Language to Filters and SQL

Every product with data eventually grows a filter panel with fourteen dropdowns that nobody uses. Users know what they want ("unresolved billing tickets from enterprise customers this week") but translating that into the right combination of status, category, tier, and date controls is work. A text box that understands the request is one of the most immediately useful AI features you can ship.

It's also the one where a careless design can do real damage. Let a model write SQL against your production database with your app's credentials, and a vague question can scan every table, while a malicious one can try to read another customer's data. In this lesson you'll build both safe versions: natural language to validated filters (the right default for most product features) and natural language to read-only SQL for internal and analytics tools, with guardrails enforced by the database rather than by the prompt.

Filters first: the model fills a form, your code writes the query#

The safest query the model can write is no query at all. In the filter design, the model's only job is to turn a sentence into a structured object, the same object your existing filter panel produces. Your code turns that object into SQL, exactly as it does today.

That design has properties that are hard to get any other way:

• The output space is bounded. The model can choose statuses from an enum and dates in a format. It can't invent a join or touch a table you didn't list.
• Queries are parameterized. No model text is ever concatenated into SQL.
• Permissions don't change. The compiled query goes through the same workspace scoping as every other list view.
• The interpretation is visible. A filter object renders as chips the user can read and correct.

Most "ask your data" features in a product are filters in disguise: find tickets, find orders, find customers. Reach for raw SQL only when users genuinely need aggregations, joins, or ad hoc analysis you can't anticipate.