TextToSQL, AIAnalytics, DataPrivacy, ApacheSuperset, DataSecurity

 

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.It does not have to be. 

A model does not need to see the data to write SQL, any more thanan analyst reads every row before writing a GROUP BY. This post describes an architecture where the model writes the query, the analytics layer runs it, androw-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