When you ask AI about your data, what reaches the model? A practical guide to privacy in conversational BI and what to check before you trust a tool.
"AI analytics" makes a lot of people nervous, and reasonably so. If you run a clinic, a store, or a SaaS, your data includes real people. So the question that matters is not "is AI scary?" — it is concrete: when I ask a question, what data is sent to the AI model, and where does it go?
The good news is that the answer, for a well-built tool, is "a lot less than you would think." Understanding the flow lets you judge any tool clearly instead of guessing.
Most conversational-BI tools do not send your data rows to the model to compute an answer. They send the schema — table and column names — plus a handful of sample values so the model understands the data format. The model then writes a SQL query, and that query runs against your real data on the server. Only the final result comes back.
In other words: the AI reasons about the *shape* of your data; the actual computation happens on your data, not inside the model. Your million rows never travel to OpenAI or Anthropic.
If the schema is safe, where is the exposure? The sample values. If a column called `phone` ships three real phone numbers to the model as examples, that is personal data leaving your system — even though the AI never needed the real numbers to understand the column.
A privacy-conscious tool redacts this. VedaX masks emails anywhere they appear and fully redacts the sample values of columns whose names denote personal data — phone, email, ssn, aadhaar, passport, date of birth, card — before any sample reaches the model. The AI still learns "this column holds phone numbers"; it just never sees a real one.
Three more controls matter a lot for analytics specifically:
- Read-only by design — analytics should only ever read. VedaX recommends a read-only connection so a generated query can never modify or delete your data.
- No central warehouse — VedaX analyzes data in a fast per-user engine rather than pooling every customer into one shared store, which shrinks the blast radius.
- Row-level security — access rules are enforced inside the query path itself, not bolted on at the dashboard, so a person cannot reach rows they are not entitled to even through a custom query. For regulated industries, this is often the deciding factor.
Before you connect real data to any AI analytics product, confirm:
1. Does it send raw rows to the model, or just schema plus samples? — (Schema plus samples is what you want.)
2. Does it redact PII from samples — before they reach the provider?
3. Can you connect with a read-only account?
4. Where is the data processed and stored — and can you self-host if you need to?
5. Is the generated SQL shown to you, — so you can see exactly what ran?
If a tool answers these well, "AI analytics" stops being a leap of faith and becomes a controllable, auditable system.
No. Well-built tools send the schema (table and column names) plus a few sample values so the model can write SQL; that SQL then runs on your real data on the server and only the result is returned. Your full dataset is not sent to the model.
VedaX masks emails everywhere and fully redacts the sample values of PII-named columns (phone, email, ssn, aadhaar, passport, date of birth, card) before any sample reaches the AI provider, while leaving numeric and ID columns intact so analysis still works.
Not on your own hardware — VedaX is managed cloud, so this is the wrong tool if in-house hosting is a hard requirement. What it does give you is tenant isolation and row-level security enforced in the query path. Connecting with a read-only database user adds a further guarantee that nothing can be modified.
See it in VedaX: AI business intelligence for small businesses