Chat With Your Data Tools: The Healthcare Verdict

Chat with your data tools work, and that was never the problem. Snowflake Cortex, Databricks Genie, ThoughtSpot Sage, Julius AI and the rest all start by moving your data into their platform, so for a healthcare marketer the thing to evaluate is where that copy lives and who touches it before an answer comes back. Curve took a different route with Curve Analyst: the data is already inside a platform that signed your BAA, the model calls fixed query tools instead of writing SQL, and it cannot look up a person. The rest of this piece is about why the architecture matters more than the demo.

TL;DR

• Every chat with your data product has the same shape: load your data into the vendor's platform, then let a model query it. The load step makes the vendor a business associate if any of that data is PHI.
• Each answer passes through more than one party: the warehouse vendor, the model provider behind it, sometimes an orchestration layer. Each hop needs its own coverage or an explicit exclusion.
• Text to SQL means the model can query anything it can see. Unless the tool is scoped at the permission layer, a marketing question can be answered by joining a patient table.
• Healthcare marketing data is patient shaped even with no names in it. A treatment landing page, a booked appointment event, a city and a timestamp describe a condition and a person.
• Whether any of these vendors signs a BAA varies by product and plan. Verify it in writing, then verify the subprocessor list, before a single row leaves your systems.
• Curve Analyst answers from data that is already in Curve, calls fixed query tools rather than generating SQL, is read only, and declines individual lookups.

How "chat with your data" tools actually work

Every product in this category has the same two steps, whatever the marketing page calls them. First you load: connect a warehouse, sync a source, upload a CSV, or point the tool at a database. Then you chat: a language model reads your schema, turns your question into a query, runs it, and summarizes the rows. The chat step is the demo. The load step is the compliance event.

The load step

Sync ad platform exports, CRM records, booking data, and web analytics into one warehouse so an assistant can answer questions across them, and you have created a combined dataset more sensitive than any of its sources. Ad spend on its own is harmless. Booking records on their own are already PHI if you are a covered entity. Joined on an email or a click ID, the ad spend becomes a record of which campaign a specific patient responded to, and that joined table is the exact thing the assistant was built to query.

The chat step

Once loaded, the model needs your schema, and usually sample values, to write a query. Column names, table names, and example rows go to the model provider as part of the prompt. Results come back and are summarized, so result rows pass through the model too. If the model provider is a different company from the warehouse vendor, that is a second party handling the data, on every question, whether or not the answer needs anything sensitive.

Why every hop needs its own coverage

Under HIPAA, a vendor that handles PHI on your behalf is a business associate and needs a BAA. That is the whole rule, and it does not care whether the vendor's role is storage, indexing, transformation, or answering a question. So if patient shaped data goes into the warehouse, the warehouse vendor is a business associate. If the warehouse sends prompts to a model provider, that provider is a subprocessor, and the warehouse vendor's BAA has to cover it, or the provider has to be excluded from anything touching PHI.

Whether any given vendor signs a BAA at all varies by product, by tier, and sometimes by which features you enable. Do not take a sales engineer's word for it, and do not take ours. Ask for the agreement, read which services it covers, and check whether the AI assistant feature is on the covered list or carved out. Vendors add AI features faster than they update their compliance paperwork, and some let a user pick the model from a dropdown, which changes the subprocessor list without changing the contract. And a BAA is only the HIPAA half: the FTC has pursued health data disclosures to ad platforms on unfairness grounds, as in the Hims & Hers complaint, which does not require you to be a covered entity.

Text to SQL: the model can query anything it can see

The feature that sells these tools is text to SQL. You type "which campaign drove the most booked appointments in July" and the model writes a join across your ads table and your bookings table, runs it, and hands you a chart. It is a good trick. It is also the single biggest scoping risk in the category, because a model that can write any query can write any query.

In a typical healthcare warehouse the marketing tables sit next to the clinical ones. Same account, same credentials. A marketing user asks a marketing question, and the model, trying to be helpful, joins the encounters table because it had a cleaner date column. Nobody intended that. The SQL is still in the query log, the encounter rows still passed through the model, and the answer still sits in a chat history the rest of the team can scroll back through.

What scoping actually requires

Scoping means the assistant is pinned to a named dataset, with its own credentials, and cannot see the rest of the warehouse even if a user asks nicely. That is different from a prompt instruction that says "only use the marketing schema." Prompt instructions are suggestions. A model with read access to a table can be talked into reading it. Real scoping lives at the permission layer, below the model, where the model cannot negotiate with it.

Most tools in this category can be scoped this way. Few arrive that way, because the default that demos well is "connect everything and ask anything." Ask to see the service account the assistant runs as, and ask what happens when a user requests a table outside its grant. The right answer is a permission error. The wrong answer is an apology followed by a partial result.

Why healthcare marketing data is patient shaped without a single name

Marketers tend to think of their data as safe because it has no names in it. Spend, clicks, landing page paths, conversion events, UTM tags, cities, devices. None of that looks like a medical record. Put it in one row and read it the way a patient would: a person in a named city, on an iPhone, clicked an ad for a specific treatment, landed on a page for that treatment, and fired a booked appointment event at a specific time. That row states a health condition and a decision to seek care for it, and it needs one more field to become a name, which the click ID or the CRM sync usually supplies.

We wrote about this from the other direction in why you cannot paste a patient funnel into ChatGPT. The chat with your data category is the same problem at larger scale: instead of pasting one funnel, you are syncing every funnel, continuously, into a place where a model can query it.

The checklist for evaluating any chat with your data tool

Run every candidate through the same six questions before anyone connects a source. Get the answers in writing, from the vendor, and from nobody else.

1. BAA. Does the vendor sign one, on the plan you are buying, and does it cover the AI assistant feature specifically? Ask for the list of covered services and find the assistant on it.
2. Subprocessor list. Which model provider receives prompts, schema, and result rows? Is that provider covered under the vendor's BAA, and does the list change when a user picks a different model in settings?
3. Training opt out. Is your data, including prompts and results, excluded from model training in the contract itself, rather than by a toggle a user can flip back?
4. Scoping to a dataset. Can the assistant be restricted at the permission layer to one named dataset with its own credentials? What does it return when a user asks about a table outside that grant?
5. Read-only access. Can the assistant's credentials write or delete anything in the warehouse? A model that generates SQL and holds write permissions is one prompt away from an incident.
6. Audit trail. Is every generated query logged with the user, the timestamp, the tables touched, and the rows returned, and can you export that log without asking the vendor?

If a vendor cannot answer one of these cleanly, that is your answer. The most common gap is number two: the warehouse vendor has a BAA, the model provider behind the assistant is a different company, and nobody has confirmed that the second company sits inside the first company's coverage.

Why Curve Analyst answers from data that is already in Curve

We built Analyst so that the load step does not exist. Curve is already the system your tracking events land in: they arrive server-side on Curve's US hosted infrastructure, Curve strips what should not leave, and forwards conversions to Google Ads, Meta, TikTok, Microsoft, LinkedIn and the others. Analyst is a chat inside that same dashboard, asking questions of that same data. Nothing is exported to a separate AI product to make it work.

The BAA question gets answered once. Curve signs a BAA with every customer on every plan. Analyst runs on Claude through Amazon Bedrock, a HIPAA eligible AWS service, inside infrastructure covered by Curve's BAA with AWS. Customer data is not used to train models. There is no second vendor to chase for a subprocessor confirmation, because the model runs inside the boundary the agreement already describes.

Fixed query tools instead of generated SQL

Analyst does not write SQL. When you ask for ROAS by platform, it calls a query tool that computes ROAS by platform, using the date range and filters from the screen you opened it on. The set of tools is fixed and each has a defined shape: what it takes in, what it returns, which data it reads. The model picks the tool that fits your question and fills in the parameters. It cannot invent a join, cannot reach data the tools do not cover, and cannot be talked into a query nobody reviewed. If your question does not map to a tool, it says so instead of improvising.

Every number came from a query against your account, through a tool with a known definition. It never estimates. If a metric is empty it says so. If data is stale, partial, sampled, or still syncing it tells you before the number, and it treats "unknown" and "zero" as different things.

Read only, and no individuals

Analyst cannot change tracking, edit destinations, or take any action. It does not look up individuals and will not answer person level questions, so "who booked from the Meta campaign" gets declined even though the underlying data could technically resolve it. The scoping problem from the text to SQL section is solved by never giving the model the ability to ask that kind of question.

It has limits. Analyst does not see session recordings or heatmaps, and it does not yet answer about tracking configuration or connector health. For a fuller walkthrough read what Curve Analyst is, and for why the tracking layer underneath is what makes any of this answerable, how compliant tracking makes AI answers possible.

What to ask Curve Analyst

Analyst keeps the date range and filters of the screen you opened it from and offers suggested questions, so you can start wherever you already are in the dashboard. These three cover most Monday morning conversations with a practice owner.

• What is our ROAS by platform this month?
• Which funnel step is losing the most people?
• Show spend versus conversions this month against last month.

The launch post, introducing Curve Analyst, has more examples.

Frequently asked questions

Is Snowflake Cortex HIPAA compliant for marketing data?

It depends on your agreement with Snowflake, the edition you are on, and whether the Cortex features you use are inside the covered services list. Verify the current terms with the vendor directly. The check is the same for every warehouse: is there a BAA, does it name the AI feature, and which model provider sits behind it.

Is Julius AI HIPAA compliant?

Verify with the vendor. The questions do not change because a tool is smaller or easier to set up: where does the uploaded data live, which model provider receives it, is there a BAA that covers that path, and can it be scoped to a single dataset. A CSV upload loads your data into the vendor's platform the same way a warehouse connector does, usually with fewer controls around it.

Can I make a text to SQL tool safe by only loading marketing data?

Partly. Loading only marketing tables removes the risk of the model joining clinical data, which is real progress. It does not change the fact that marketing data in healthcare is patient shaped, so the loaded copy is still PHI if you are a covered entity, the vendor is still a business associate, and every hop still needs coverage.

Does Curve Analyst send my data to Anthropic?

Analyst runs on Claude through Amazon Bedrock inside infrastructure covered by Curve's BAA with AWS. Your data is not exported to a separate AI product and is not used to train models. The account data Analyst queries is the same data already in Curve under the BAA you signed with us.

If you are evaluating a chat with your data tool for a healthcare account, run the checklist above first and get the answers in writing. If you would rather ask questions of data that never left a BAA in the first place, book a demo of Curve and try Analyst on your own account.