How to Reduce AI Costs Without Routing PHI to Non-BAA Models

Compliance is the constraint, cost is the result

Healthcare organizations want to use a wider range of models, including lower-priced options, for the growing set of AI workloads. The risk is that some of those models are not covered by a Business Associate Agreement. This guide holds one rule fixed: PHI is never sent to a model that lacks a BAA. Every cost decision is evaluated only after that rule is satisfied.

The Security Rule frames the obligation. Sections 164.306 and 164.312 apply to covered entities and business associates, and the Rule requires reasonable and appropriate administrative, physical and technical safeguards for the confidentiality, integrity and availability of ePHI, including protection against unauthorized uses or disclosures. An AI model call is a transmission of data to a processing service, so the safeguard has to exist where the call is made.

A proposal to amend the Security Rule was published in the Federal Register on January 6, 2025. As of October 2026, design against the current text of the Rule and treat the proposal as a proposal.

The practical consequence is that cost reduction becomes a routing problem. A broader portfolio helps only if the system can tell, per request, which models are eligible.

Detecting and handling PHI at inference time

Classification is the weakest point in most designs, so it deserves explicit attention. Pattern-based detection finds structured identifiers such as record numbers reasonably well but can miss PHI embedded in free text, such as a clinical note that identifies a patient through context. Model-based detectors cover more ground but can produce both false negatives and false positives. No detector should be assumed to be complete, and any approach should be tested against the organization's own data before it gates production traffic.

This is why uncertainty needs its own path. When classification is not confident, the safe default is to treat the request as PHI-bearing and restrict it to BAA-covered models, or to escalate it for human approval. Human-in-the-loop safeguards and data anonymization are both named as mitigation tactics in CMS AI guidance, which is agency reference practice rather than a HIPAA requirement.

Redaction has its own tradeoffs. Removing identifiers can reduce the usefulness of a response, and it changes the request. Integrity controls under 164.312(i) concern detecting improper modification of transmitted ePHI. Redaction is an intentional modification, so a sound design records what was changed and why. Blocking is the strictest action and suits cases where redaction would destroy the task or the classification is unreliable.

Cost levers that work inside the boundary

Three levers are legitimate and compatible with the constraint, provided each is applied after classification and not before it.

Model tiering matches the model to the task. Summarizing a public policy document does not need the same model as complex clinical reasoning. Non-PHI workloads can use a broader set of models, while PHI-bearing work stays on BAA-covered models selected for the task.

Reducing redundant calls removes repeated or duplicate requests. Caching needs care here. A cache that stores prompts or responses derived from PHI holds ePHI itself, so cache scope, keys and retention should follow the same classification and access policy as the original call. Do not serve a response generated from one patient's data to another request.

Rate limiting caps volume per user, application or model. It also contains runaway loops in agent or tool-call workflows.

The effect of each lever depends on workload and traffic, so measure it in your own environment. Compliance does not depend on those measurements. The routing restriction holds whatever the numbers show.

Runtime enforcement compared with static and after-the-fact methods

Teams often start with developer discipline, static allowlists or periodic review. Each has a place, but only enforcement in the path acts on the individual request.

• Developer discipline: Depends on every team routing correctly. Cannot distinguish PHI from non-PHI at the moment of the call and leaves no durable record of what was permitted.
• Static allowlists: Define which models an application may use, but not what each request contains. A PHI-bearing request inside an allowed application still reaches whatever model the list permits.
• After-the-fact review: Finds problems once data has already been sent. Useful for detection and improvement, but it cannot prevent a disclosure.
• Runtime policy enforcement: Classifies each request and applies allow, redact, block, rate limit or escalate before inference. Produces a record of each decision as a by-product of enforcement.