AI Cost Control in Healthcare Data Analytics.

AI tools have made data analytics accessible to a much wider group of people. That is genuinely useful. It has also introduced a cost problem most organizations are not yet set up to manage.

This piece is aimed at business leaders and operations people, not engineers. If you are making decisions about how your team uses AI for data work, or wondering why your cloud bills are climbing, this is for you.

Before getting into the cost problem, it helps to understand what is happening when you use a tool like Claude, ChatGPT, or Cursor to do data analysis.

At their core, all of these tools do the same thing: they predict the next likely sequence of characters based on the input you give them. There is no reasoning engine, no understanding of your business. When you ask one of these tools to analyze data, it makes a plan, generates code to execute that plan, runs the code, checks for errors, fixes them, and keeps iterating until it gets a result.

One way to work around this is to give it a known benchmark. If you know last quarter's revenue was a million dollars, tell it that, and ask it to confirm that figure before trusting anything else it produces. If the known number checks out, the others are more likely to as well.

Analysts have always worked iteratively. You rarely write a script once and get it right. You run it, check the output, adjust, run it again. A good analyst might go through a script thirty times before it is right.

The difference with AI is speed. What takes an analyst a day, a computer does in a few minutes. Cloud data platforms charge based on how much compute is used. More iterations, running faster, against larger datasets, means a larger bill.

The deeper issue is that AI tools do not carry the contextual awareness an analyst develops over time. An experienced analyst working on a healthcare data lake knows to filter down to one day of data while developing and testing, not two years. That instinct comes from understanding what the work costs. An LLM does not have that instinct.

This is why having a person in the loop still matters, even when the AI is doing most of the technical work. A human analyst would not have made that mistake.

Most modern data environments are structured in three layers. The raw layer contains data close to how it arrived from source systems. A middle layer cleans and contextualizes it. The top layer, the gold layer in Databricks terminology, contains the curated, reporting-ready data that analysts and business users work with.

When AI tools can run queries and take actions autonomously, it becomes important to be deliberate about which layer those tools can access. The gold layer exists for a reason. Pointing AI tools at raw data when they only need the curated layer is one of the more common sources of unnecessary cost.

Beyond access controls, the specific configurations worth putting in place are not new. What has changed is that machine speed makes enforcing them more consequential than it used to be.

• 01
  Query time limits

  A hard ceiling on individual query duration. The simplest brake on a runaway agent loop, and the one most teams skip.
• 02
  Caps on server size

  Constrain the warehouse cluster the AI can spin up so the worst-case bill is bounded before it becomes a problem.
• 03
  Explicit dataset permissions

  Written, enforced rules about which tables, schemas, and layers an AI tool is allowed to touch. Default-deny on raw.
• 04
  A human in the loop

  Someone reviewing the plan before it executes against anything large. Not on every query, only on the ones that cost real money.

When multiple teams are running agentic queries independently, the math compounds quickly. One team generating ten times the usual compute cost through unchecked querying becomes thirty times when three regional teams are doing the same thing simultaneously. Governance that was adequate for human analysts working at human speed may not be adequate for AI tools working at machine speed.

In healthcare and other regulated environments, there is more to think about beyond compute costs.

LLM providers store the data you send them. For most standard plans, that data is used to train future versions of their models. Enterprise and HIPAA-compliant plans typically prohibit this, but they cost more, and vendors in regulated industries know they can charge a premium for compliance-grade contracts.

The legal landscape here is still developing. There is not much case law in the US yet. In Europe, regulatory attention is moving faster. In practice, contract negotiations around AI use are inconsistent, and the responsibility for working through them tends to fall on whoever is doing the work.

For data engineering work specifically, AI can make an expert significantly faster on the right class of problems. Code is a particularly good fit because it either runs correctly or it does not. That is a verifiable output in a way that a written summary or business recommendation is not.

These tools also open analytical work to people who understand the business but do not know how to write code. A partner or operations lead who has spent years understanding how a business runs is often better positioned to ask the right questions of data than a technical analyst still learning the domain. AI removes the coding barrier. Having someone technical review the output is still sensible, but the constraint is meaningfully reduced.

The cost and governance problems are real but manageable with the right structure in place. Teams that get the most out of these tools treat governance as a prerequisite, not something to sort out later.