Does Using an AI Agent on Patient Records Require a BAA With the Model Vendor? It Depends on What the Model Receives

Chris Sowa · Founder, RedactSure
Published September 26, 2026 · Last updated September 26, 2026

It depends on what the model receives, and that is a determination the covered entity makes with counsel, not one a vendor makes for it. If the model receives protected health information, the model vendor is creating, receiving or maintaining PHI on the entity’s behalf and a business associate agreement is the ordinary consequence. If the model receives a record with the identifiers replaced by tokens before it reads the screen, the question becomes whether what it received is PHI at all, and the answer turns on the HIPAA de-identification standard and the entity’s own analysis. What an architecture can change is not the rule but the facts the rule is applied to. Least Exposure is the principle: for each piece of work, the agent receives exactly the data the task requires and nothing more, enforced before any model reads the screen. This page sets out the rule, the three positions an entity can take, and what each requires it to show. Nothing here is legal advice, and no architecture makes an organization compliant. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

A business associate is a person or entity that creates, receives, maintains or transmits PHI on behalf of a covered entity, under 45 CFR 160.103. The definition is about the data handled, not the technology.
HHS’s cloud computing guidance states that a cloud provider storing encrypted ePHI is a business associate even if it does not hold the decryption key and cannot view the information. RedactSure, which stores ciphertext under customer-held keys, is a business associate on that reading and signs a BAA.
The de-identification standard at 45 CFR 164.514 offers two methods, Safe Harbor and expert determination, and Safe Harbor permits a re-identification code as long as it is not derived from the individual’s information. Whether a tokenized screen meets either method is a question for the entity’s privacy officer and counsel, workflow by workflow.
Most entities RedactSure works with execute a BAA with the model vendor regardless, as belt and braces. What the architecture changes is what that BAA has to cover: a vendor that never received an identifier is a vendor whose breach exposes none.
The minimum necessary standard at 45 CFR 164.502(b) applies whether or not a BAA exists. A BAA permits a disclosure; it does not make a full-screen disclosure to a model the minimum necessary for the task.

What does the rule say?

Three provisions carry the analysis.

The business associate definition. Under 45 CFR 160.103, a business associate is a person or entity that, on behalf of a covered entity, creates, receives, maintains or transmits protected health information for a function or activity regulated by the rules. A model vendor whose model reads a patient’s chart to draft a denial appeal is receiving PHI on the entity’s behalf. The consequence is a BAA, with the vendor’s own obligations under the Security Rule attached.

The cloud computing guidance. HHS addressed the case of a provider that stores encrypted ePHI without the key and answered directly: the provider is a business associate, and lacking an encryption key does not exempt it from business associate status. Encryption changes the risk; it does not change the status. Any vendor that holds ciphertext of patient records, RedactSure included, should expect to sign a BAA and should offer one without being asked.

The de-identification standard. 45 CFR 164.514 sets out when health information is not individually identifiable and therefore not PHI. Safe Harbor requires removal of eighteen categories of identifier, including names, geographic subdivisions smaller than a state, all elements of dates except year, Social Security numbers, medical record numbers and account numbers, with no actual knowledge that the remainder could identify the individual. It permits the entity to assign a code for re-identification, provided the code is not derived from information about the individual and the mechanism is not disclosed. Expert determination allows a qualified expert to conclude that the risk of identification is very small. Either method is the entity’s to apply.

What changes when the model receives tokens?

The facts the rule is applied to. Under render-layer tokenization, identifiers are replaced with consistent tokens (USER_001, MRN_001, DOB_001) at the point where the screen renders, before any model reads it. The tokens are assigned by the environment and are not derived from the patient’s information; real values live in hardware-encrypted enclaves with keys the entity holds, and resolve only at approved destinations, a payer portal or a claim submission, at the moment a named person approves the action.

What the model receives is therefore a record with the configured identifiers removed and replaced by codes the model cannot reverse. Whether that record is de-identified under Safe Harbor depends on what else is on the screen. A workflow whose exposure policy tokenizes names, medical record numbers, dates of birth, addresses and account numbers but leaves service dates in clear has not removed all elements of dates, and Safe Harbor is not met on its face. A workflow whose policy tokenizes dates as well may meet it. A workflow that leaves rare diagnoses and a small-town ZIP code in clear may fail the actual-knowledge test even with every listed identifier removed. Each is a field-by-field question, and the exposure policy is the document that answers it, which is why the policy is written per workflow and confirmed by the person who owns the work under Supervised Delegation.

The architecture does one further thing the rule cares about: it makes the question checkable. The run history in the AI Control Record holds every screen as the model received it, tokens included. The privacy officer does not have to reason about what a model might have seen; the record shows what it did see, for every run, and holds no PHI itself.

The three positions an entity can take

Position one: treat the model as a business associate and execute a BAA. This is the conservative position and the one most entities take today, whatever the architecture. It costs a contract and the vendor’s willingness to sign one; the major model vendors offer BAAs on their enterprise terms. Under this position the architecture still matters, because a BAA permits a disclosure but does not make it minimum necessary, and because the vendor’s own breach, sub-processor or retention failure exposes only what the vendor received. A model vendor that received tokens has nothing to lose on the entity’s behalf.

Position two: determine that what the model receives is not PHI, and document it. This requires the exposure policy to remove every Safe Harbor identifier for the workflow, or an expert determination, and a written analysis the entity is prepared to defend. It is a real position, available under the rule, and it is the entity’s determination alone. The vendor’s role is to make the facts inspectable: the policy, the run history and the resolution inventory.

Position three: execute the BAA and document the analysis anyway. In practice most entities that examine the question end here. The BAA covers the regulatory relationship; the analysis and the record show that the disclosure under it was the minimum necessary and that the model held no identifier. If a regulator or a plaintiff asks what the model saw, the answer is a document, not an argument.

None of these positions is created by a product. The architecture changes what the model received, and the record proves it; the entity decides what follows.

What about the vendor that runs the environment?

That vendor is a business associate. RedactSure receives and maintains the ciphertext behind the tokens, and HHS’s guidance is explicit that not holding the key does not change the status. RedactSure signs a BAA, and an entity should treat any vendor’s reluctance to sign one, whatever its architecture, as the end of the conversation.

The distinction that matters for the entity’s risk is between what each party can read. The environment vendor holds ciphertext it cannot decrypt, under keys the entity keeps. The model vendor receives tokens. The entity’s own staff see real values in the systems of record exactly as they do today, under permissions that do not change. Each party’s exposure is bounded by what it holds, and the record shows what that was.

What the record shows

Whether using an AI agent on patient records requires a BAA with the model vendor depends on what the model receives, and the covered entity decides with counsel. The business associate definition turns on handling PHI; HHS’s cloud guidance says holding encrypted PHI without the key is still handling it, which is why RedactSure signs a BAA as the environment vendor. The de-identification standard says when information stops being PHI, and it is applied field by field to what the model was actually shown. Render-layer tokenization changes those facts: identifiers replaced by codes not derived from the patient before any model reads the screen, real values resolving only on a named person’s approval, and a run history holding every screen as tokens. An entity can execute a BAA with the model vendor, determine that the tokenized record is not PHI, or do both and document it; most do both. What no position changes is the minimum necessary standard, and the strongest answer to it is a model that never received the identifier.

Frequently asked questions

Is RedactSure HIPAA compliant?

No vendor is. Compliance is the covered entity’s determination about its own program. RedactSure’s architecture is aligned with PHI data-minimization requirements, it signs a BAA, and it produces the run history the entity’s analysis needs.

Does tokenizing identifiers make the data de-identified?

Not automatically. Safe Harbor requires all eighteen identifier categories removed, dates included, with no actual knowledge that the remainder identifies the individual. Whether a given workflow’s exposure policy meets that is the entity’s determination; the policy is written so it can be.

Do the major model vendors sign BAAs?

The major vendors offer BAAs on their enterprise terms; the entity should confirm the current terms for the model it chooses. Because the environment is model-agnostic, choosing a model with acceptable BAA terms does not change the security posture.

What does a BAA with the model vendor cover if the model only receives tokens?

The regulatory relationship, and any residual PHI the entity’s analysis concludes the model could receive. Its practical value is that the entity is covered under either position, and its practical scope is small, because the vendor received nothing identifying.

Does the minimum necessary standard apply to a model?

The standard applies to the covered entity’s uses and disclosures, and a disclosure to a model is a disclosure. An entity that shows a model the full chart to draft an appeal should be able to explain why the full chart was necessary. Tokenization is the mechanism that makes the disclosure the minimum.

What should the privacy officer ask a vendor?

Under what circumstances does the model receive real patient values, in writing, with the architecture. Does the AI Have a Break-Glass Path to Patient Data? gives the template for the written answer.

How Can Staff Use AI on Patient Records Without the Model Ever Holding PHI? · Does the AI Have a Break-Glass Path to Patient Data? · Can an AI Agent Work in Epic Without the Model Holding PHI? · What Is an AI Control Record? · On the RedactSure blog: Secure AI for Healthcare

Sources

Regulation and guidance

45 CFR 160.103, Definitions (business associate). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103
U.S. Department of Health and Human Services, Guidance on HIPAA and Cloud Computing. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
U.S. Department of Health and Human Services, Guidance Regarding Methods for De-identification of Protected Health Information, 45 CFR 164.514. https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
U.S. Department of Health and Human Services, Minimum Necessary Requirement, 45 CFR 164.502(b). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

RedactSure documents

RedactSure, “Secure AI for Healthcare” (2026). https://redactsure.com/blog/secure-ai-for-healthcare/
Product behavior described on this page (render-layer tokenization, enclave vault with customer-held keys, supervised approval, run history) reflects RedactSure’s current design. This page is not legal advice.

Bring your hardest questions.

A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.

Book a security review Book a demo · Something else

About the author

Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.