In most companies, data access is a queue. Business users file requests, analysts translate them into SQL, and by the time the chart arrives the meeting is over. Natural-language data analysis promises to shorten that loop: a sales manager types a question in plain English, and a Claude-backed assistant returns the number, a short explanation, and how it was computed. The promise is real, but so is the failure mode — a system that returns confident, wrong numbers is worse than the queue it replaced. The difference between the two outcomes is architecture, not model choice.
The cardinal rule: the model never computes the numbers
Language models are excellent at understanding questions and terrible as calculators. If you paste a thousand rows into a prompt and ask for the average, you may get the right answer — "may" being the operative word, and unverifiable either way. The reliable design keeps roles separate: Claude translates the user's question into a query, a real query engine (your warehouse, your database) computes the result, and Claude explains what came back. Every number a user sees should have been produced by deterministic code, with the model providing the language on either side of it.
In practice this is a tool use pattern, which works on all four platforms — Bedrock, Vertex AI, Foundry, and Claude Platform on AWS. You expose a tool such as run_query; Claude decides what to query, your code executes it against the warehouse, and the result rows come back for the model to summarize. One availability note: Anthropic's hosted code execution tool, which can also do calculations server-side, is not available on Bedrock or Vertex AI — one more reason the query-engine pattern is the portable default.
Making it safe: scope the door, not the conversation
The tempting shortcut is handing Claude a database connection and a prompt that says "only read, never write, don't look at salaries." Prompts are suggestions; credentials are controls. Safety lives in the tool implementation, not the model's manners:
Read-only credentials. The database user behind the tool physically cannot write, delete, or alter anything, no matter what query the model generates.
Curated views. Point the tool at a set of approved views or a semantic layer — the same governed tables your BI dashboards use — rather than raw production schemas. This solves permissions and correctness at once: users can't reach data they shouldn't, and the model can't misjoin tables that were never meant to be joined.
Per-user scoping. Apply the requesting user's entitlements (row-level security, tenant filters) in the query layer, so the assistant can never answer with data the person couldn't see in a dashboard.
Query limits. Row caps, timeouts, and cost limits keep an ambitious question from becoming a warehouse incident.
A realistic first project
Start with one domain and one audience: say, sales operations asking about pipeline and bookings. Build a semantic layer of five to ten certified views with plainly named columns. Wire up the query tool, and have Claude answer with three things every time: the number, the generated SQL (or a plain-English restatement of the filters and date ranges used), and any caveats — "this excludes returns processed after quarter close." Then run it side by side with the analyst queue for a few weeks and compare answers before widening access. Ambiguity handling matters more than you expect: "revenue last quarter" has at least three defensible meanings, and a good assistant asks "fiscal or calendar quarter?" rather than picking silently.
Common pitfalls
Boiling the ocean. Pointing the assistant at four hundred undocumented tables guarantees wrong joins. Small, curated scope is a feature.
Skipping the definitions. If "active customer" means different things in different teams, the model will inherit the confusion. Encode business definitions in the view layer or the system prompt — once, explicitly.
No answer audit trail. Log every question, generated query, and result. It's how you debug wrong answers, measure adoption, and satisfy the security review.
Treating it as a replacement for analysts. It replaces the ticket queue's bottom tier — routine lookups — and frees analysts for the work that actually needs them. Framing it that way also gets the data team building guardrails instead of resisting the rollout.
Where to go next
The mechanics here are tool use plus structured outputs — both worth reading before you build. For the operational side, see the launch checklist.