AI in Healthcare: HIPAA Compliance When Every Model Is a Third Party

The pressure to adopt

Healthcare organizations are under enormous pressure to adopt AI. Clinical decision support, administrative automation, patient communication, medical coding, radiology triage, prior authorization. The capabilities are transformative. Every month brings a new model that performs better on medical benchmarks, and every executive team is asking the same question: why are we not using this yet?

The answer is compliance. Specifically, the compliance reality that every model provider your data touches becomes a business associate under HIPAA.

This is not a minor inconvenience. It is a structural problem that gets worse with every new model you want to evaluate.

The BAA problem

Under HIPAA, any entity that creates, receives, maintains, or transmits protected health information on behalf of a covered entity must sign a Business Associate Agreement. When a healthcare organization sends patient data to an AI model provider, that provider is a business associate.

Not all providers offer BAAs. Those that do have varying terms, liability caps, and breach notification timelines. Some cap their liability at the fees paid in the prior twelve months. Some define “breach” more narrowly than HIPAA does. Some require that you notify them of your own breaches but give themselves extended timelines to notify you of theirs.

Managing BAAs across multiple AI providers is a legal and operational burden that scales linearly with the number of providers. One BAA is manageable. Five is a compliance project. Ten, across different departments experimenting with different models for different use cases, is a governance nightmare. And every single one of those agreements represents a node in your risk graph that you do not control.

PHI exposure is the real risk

Even with a BAA in place, sending protected health information to a model provider creates risk that no agreement can fully mitigate. The provider’s employees have some level of access to the infrastructure that processes your data. The provider’s subprocessors, cloud hosts, and logging systems all become part of your attack surface. A breach at any provider is potentially your breach.

BAAs allocate liability. They do not prevent incidents. A signed agreement does not stop a misconfigured storage bucket, an over-permissioned employee, or a zero-day exploit on the provider’s infrastructure. It just determines who pays afterward.

Healthcare organizations understand this distinction intuitively. It is why many compliance officers remain uncomfortable with sending PHI to third-party AI systems regardless of what the BAA says. The risk is real and the agreement is paper.

The minimum necessary standard

HIPAA’s minimum necessary standard requires that covered entities limit the use and disclosure of PHI to the minimum amount necessary to accomplish the intended purpose. This is not a suggestion. It is a regulatory requirement.

Most AI implementations in healthcare violate it routinely. A clinician asks an AI assistant a question about drug interactions for a specific patient and the system sends the patient’s entire clinical note, medication history, problem list, and demographic information to the model. The model needed a medication list and an allergy profile. It received everything.

This happens because it is technically easier to send full context than to surgically extract the relevant subset. Prompt construction in most AI applications is optimized for model performance, not data minimization. The result is that model providers receive far more PHI than the minimum necessary for any given request.

An auditor reviewing these interactions would find systematic over-disclosure. The defense that the model performs better with more context does not satisfy the minimum necessary standard.

Gateway-level tokenization changes the equation

AOSentry takes a fundamentally different approach. Rather than relying on agreements to manage the risk of PHI exposure, it removes the exposure.

PII and PHI tokenization happens at the gateway, before any data reaches any model provider. Medical record numbers, patient names, Social Security numbers, dates of birth, diagnoses, and other identifiers are replaced with format-preserving encrypted tokens. The tokens maintain the relational structure of the data so the model can reason about it, but the actual PHI is gone.

The model processes the clinical question without ever seeing the actual patient. It reasons about “Patient [TOKEN-4a7f]” with “Condition [TOKEN-9b2e]” and returns its analysis using those same tokens. The response is de-tokenized at the gateway before returning to the clinician, who sees the real patient data in context. The model never did.

This changes the compliance equation in a material way. If a model provider never receives PHI, the argument that they are a business associate under HIPAA weakens significantly. They cannot create, receive, maintain, or transmit PHI if the PHI was replaced with meaningless tokens before it reached them. The BAA requirement may not apply at all.

For organizations that want additional assurance, AOSentry can be deployed on-premises or within the organization’s own cloud infrastructure. PHI never leaves the healthcare organization’s network boundary. The tokens travel to model providers. The PHI stays home.

Audit trails that satisfy regulators

HIPAA requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use PHI. AOSentry’s dedicated PII access log captures every tokenization and de-tokenization event with the accessor’s identity, a timestamp, and the reason for access.

These logs are hash-chained and tamper-evident. Each entry’s integrity can be independently verified. An auditor can confirm not only what PHI was accessed and by whom, but that the log itself has not been modified after the fact. This is a higher standard of audit integrity than most EHR systems provide today.

Every interaction with every model through the gateway is logged with the same rigor. Which department, which user, which model, what was tokenized, what was de-tokenized, when, and why. The audit trail is complete and immutable.

Cost governance across departments

Healthcare organizations that begin experimenting with AI quickly discover that usage sprawls across departments. Radiology tries one model. Pathology evaluates another. The revenue cycle team builds automations against a third. Without centralized governance, costs become unpredictable and unauditable.

AOSentry’s budget controls allow organizations to set spending limits by department, team, or use case. When radiology’s monthly AI budget is exhausted, requests are throttled or routed to more cost-effective models rather than generating surprise invoices. Finance gets predictable costs. IT gets centralized visibility. Compliance gets a single control plane instead of a dozen shadow integrations.

The path forward

The question is not whether healthcare will use AI. That is already decided. The capabilities are too significant and the competitive pressure too intense for any health system to abstain indefinitely.

The question is whether healthcare will use AI in a way that the existing regulatory framework can accommodate. HIPAA was not written with large language models in mind, but its principles are sound: minimize exposure, control access, maintain audit trails, hold parties accountable for the data they handle.

Gateway-level tokenization does not require rewriting those principles. It satisfies them. The model gets the clinical question. The patient keeps their privacy. The compliance officer keeps their job. That is the architecture healthcare needs, and it is available today.