Natural-language input
The prototype connected ordinary business questions with queries against the existing data environment.
Business Software · Professional-services data access
Testing natural-language data access with read-only queries
A professional association completed an experimental MVP that translated routine operational questions into SQL queries, with read-only access, query validation, and a deliberately limited database account.
The business context
Routine questions were waiting for technical help.
Business staff wanted answers to questions already represented in their operational systems: how many appointments were recorded, how many cases were active, or how much work fell within a particular period. Getting those answers depended on someone writing SQL or preparing a report.
The customer wanted to test a more direct route without rebuilding its existing systems. The project focused on a narrow question: could a business user ask in ordinary language and receive a useful answer from an authorized part of the database?
System view
A question, its scope, and a clearly identified sample answer.
Original prototype illustration using a fictional dataset. The sample figures and visible check indicators explain the approach; they are not customer records or results. View full-size interface (new tab)
The operating challenge
A plausible query is not automatically an acceptable query.
Two SQL statements can look reasonable while answering different interpretations of the same request. The application needed to consider the meaning of the question as well as whether the generated statement was allowed to run.
The database also contained sensitive operational information. A natural-language interface could not be granted broad authority merely because it was convenient. Incorrect or manipulated input had to be considered when setting the application's access boundary.
The delivery decisions
Put limits around the query before giving the model access.
Keep the MVP focused on familiar questions
The planned workflow centered on recurring counts and time-period summaries. That gave the team and customer concrete examples to review during regular demonstrations, rather than treating open-ended database access as the initial product.
Validate the generated statement
The implementation checked generated SQL for read-only behavior, allowed scope, and potentially harmful input. Query generation and permission to execute were treated as separate concerns.
Use a dedicated, limited database account
The application used its own database identity with least-privilege permissions. This placed an access restriction at the database layer as well as in the application, instead of relying only on instructions given to the model.
The working detail
Read-only access defined what the experiment could do.
A bounded first product
The business purpose was to retrieve information. The MVP therefore did not need authority to change the underlying records. Making that distinction explicit reduced the scope of the experiment and gave the customer a clearer basis for evaluating the proposed interaction.
Weekly planning and demonstrations kept the work tied to recognizable business questions. The completed MVP established the agreed functionality; broader rollout would need its own evaluation of accuracy, access, and operating behavior.
The delivered result
The agreed experimental MVP was completed.
Restricted execution
Read-only validation and a limited database account formed part of the implementation.
Demonstrable scope
The customer received the agreed MVP functionality through a regular review process.
This is a completed experiment, not evidence of organization-wide adoption or a guarantee that all query or prompt-injection risks have been eliminated.
Case taxonomy
Searchable by industry, technology, product, and business need.
Industry and product
- Business Software
- Professional-services data access
Technology and delivery
- Azure Functions
- Azure AI
- SQL
Business need
- Natural-language queries
- Read-only access
- AI MVP
- Query validation
- Least privilege
- Business reporting
Discuss your project
Which recurring questions could a bounded AI data-access prototype answer?
Tell us how your business works and where your software needs to change.
Get in touch
Ready to build software that fits your business?
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review