The first question a security reviewer asks about an AI analytics feature is not about accuracy.
It is: “What leaves our network, and where does it go?” If the honest answer is “a few thousand rows of the orders table, to a third-party model provider, on every question”, the review is over.
This post describes an architecture where the model writes the query, the analytics layer runs it, and row-level data never enters a prompt, with specifics on what crosses each boundary and what stops a bad query.
There are four steps, and only one of them involves the model provider:
Describe. The application builds a description of the datasets the user may query: tables, columns, types, and what each column means.
Generate. The question and that description go to the model, which returns SQL. This is the only call that leaves your trust boundary (unless the model is local, covered below).
Validate and execute. The SQL is parsed, checked against policy, and run by the analytics layer under a restricted database role. The warehouse returns a result set to your application, not to the model.
Present. The result is rendered as a chart or table for a user who is already authorised to see it.
A written explanation of the result is a second model call. Send it the aggregated result only, never the underlying rows. “EMEA revenue fell 12% quarter-on-quarter” needs a dozen numbers, not a million records.
Read the complete technical guide
