Yes, an AI agent can read PHI. Software has processed patient data for decades, and HIPAA has never prohibited it.
The interesting questions are elsewhere: how much data the agent actually needs, where it travels while being processed, and what remains in logs after the work is done.
The short answer
PHI can be processed by an AI agent under a BAA with appropriate safeguards. Three rules govern how:
- Minimum necessary — the agent should receive only the fields the task requires
- Safeguards — administrative, physical, and technical protections under the Security Rule
- Accountability — a contract defining permitted uses, plus logging that shows what happened
The failure modes are rarely legal. They are architectural: sending the whole chart because filtering is harder, or forgetting that prompt logs retain everything.
Minimum necessary, applied to agents
The Privacy Rule limits uses and disclosures to the minimum necessary for the purpose. HHS notes the Security Rule mirrors this in access management — access to ePHI should be authorized "only when such access is appropriate for the user or recipient's role."
An agent has a role too. Consider what each actually needs:
| Agent task | Genuinely needs | Does not need |
|---|---|---|
| Eligibility verification | Name, DOB, member ID, payer, service type | Clinical notes, medication history |
| Inbox triage | Sender, subject, document type, patient match | Full chart context for routing |
| Prior authorization | Diagnosis and procedure codes, clinical justification for that request | Unrelated encounter history |
| Appointment scheduling | Name, contact, appointment type, availability | Diagnoses |
Ask a vendor which fields the agent receives. The convenient engineering answer is "the whole record, and we only use what we need." That is a different risk profile from sending four fields, and it is worth knowing which one you are buying.
Where PHI actually travels
This is the question most evaluations skip, and the one where AI genuinely differs from a traditional EHR module.
When an agent processes a message, PHI may move through:
- The vendor's application — receives and prepares the data
- A model provider — runs inference; the data leaves the vendor's infrastructure
- A cloud host — stores data at rest
- Telephony or document services — if voice or faxes are involved
- Logging and observability infrastructure — captures traces for debugging
Each is a location where PHI exists. HHS requires a business associate to obtain the same assurances from subcontractors handling PHI that you obtained from the vendor — so each hop needs its own agreement, and the chain is only as good as its weakest link.
The practical ask: a named subprocessor list, with notice before it changes. A model provider can be swapped without any visible change to the product you use.
The logs nobody checks
Prompt logs are the most commonly overlooked PHI store in AI systems.
Debugging traces, prompt archives, and vector stores all tend to retain content sent through them. They are built by engineers for troubleshooting, and they frequently predate anyone writing a retention policy that contemplates them. A deletion request that clears the primary database may leave PHI sitting in observability tooling for as long as its default retention allows.
Four questions:
- Are prompts containing PHI logged?
- How long do those logs live?
- Who can read them — engineering, support, the model provider?
- Are they included when we request deletion?
An honest vendor will have thought about this. A vendor who has not will usually say so by hesitating, which is itself the answer.
De-identification: a real option, with a real bar
De-identified data is not PHI and falls outside HIPAA. But the bar is specific, and partial masking does not clear it.
HIPAA provides two methods:
- Expert determination — a qualified statistician concludes the re-identification risk is very small, and documents the analysis
- Safe harbor — removal of eighteen specified identifier types, including names, geographic subdivisions smaller than a state, all date elements more specific than a year, phone numbers, and record numbers
Redacting the name is not de-identification. A record with dates of service, a ZIP code, and an account number is still identifiable under safe harbor. If a vendor claims it processes de-identified data, ask which method and ask to see the documentation.
Practical safeguards worth asking about
| Safeguard | The question | Why it matters |
|---|---|---|
| Encryption | In transit and at rest? | Addressable under the Security Rule — expected baseline, but ask |
| Tenant isolation | Is our data separated from other customers? | One breach should not be everyone's breach |
| Role-based access | Who internally can see our PHI? | Access control is a Security Rule standard |
| Redacted views | Are sensitive fields masked in operational dashboards? | Support staff rarely need complete records |
| Model training | Is our PHI used to train anything? | Should be contractually prohibited |
| Breach notification | How many hours until we are told? | "Promptly" is not a commitment |
On encryption specifically: HIPAA does not name an algorithm. The Security Rule marks some specifications required and others addressable, meaning an entity implements the measure where reasonable and appropriate or documents an equivalent alternative. Encryption is addressable — which in practice means everyone should be doing it, and a vendor without it needs a very good explanation.
Where we stand
As of 7 August 2026: PHI stays within your tenant, sensitive fields can be auto-redacted in operational views while preserving full data for authorized debugging, agents and credentials are isolated per workspace, and customer data is never used to train models. A BAA is available for customers handling PHI.
Our SOC 2 audit is in progress and ISO 27001 certification is underway — neither is finished, and our security page says so per framework.
Frequently Asked Questions
Can an AI agent legally read protected health information?
Yes, provided the vendor is under a business associate agreement and the arrangement meets HIPAA's Privacy and Security Rule requirements. Nothing in HIPAA prohibits software from processing PHI, and practices have used software to handle patient data for decades. What HIPAA requires is that the entity handling it has appropriate safeguards, a contract defining permitted uses, and accountability if something goes wrong.
Does the minimum necessary standard apply to AI agents?
Yes, in the same way it applies to staff. The Privacy Rule limits uses and disclosures of PHI to the minimum necessary to accomplish the purpose, and an agent verifying insurance eligibility does not need the full clinical note to do it. In practice this means asking a vendor which fields the agent actually receives, because the easy engineering choice is to send everything and filter later.
Where does PHI go when an AI agent processes it?
That depends on the architecture, and it is the question buyers most often skip. Data may pass from the vendor's application to a model provider for inference, to a cloud host for storage, and potentially to telephony or document-processing services. Each hop is a place PHI exists, each needs its own agreement, and the only way to know the real path is to ask for a named subprocessor list rather than a reassurance.
Is PHI stored in AI prompt logs?
Often, unless someone deliberately prevented it. Debugging infrastructure, prompt traces, and vector stores routinely retain the content sent through them, and these systems are frequently overlooked when retention and deletion policies are written. Ask specifically whether prompts containing PHI are logged, how long those logs live, who can read them, and whether they are included when you request deletion.
What is the difference between de-identified data and PHI?
De-identified data is health information from which identifiers have been removed under one of two HIPAA methods: expert determination, where a qualified statistician concludes re-identification risk is very small, or safe harbor, which requires removing eighteen specified identifier types. Properly de-identified data is no longer PHI and falls outside HIPAA. Partial masking that leaves dates, ZIP codes, or record numbers in place does not meet either standard.
Should staff be able to see everything an AI agent sees?
Not necessarily, and role-based access should apply to agent outputs the way it applies to any other system. The Security Rule requires access controls allowing only authorized persons to reach ePHI, and that principle extends to operational dashboards showing agent activity. A support view that exposes complete records to anyone troubleshooting is a wider surface than most practices intend.
What encryption does HIPAA require for AI systems?
HIPAA does not mandate a specific algorithm. The Security Rule sets standards while categorizing some implementation specifications as required and others as addressable, and encryption is addressable — meaning an entity must implement it where reasonable and appropriate, or document why an equivalent alternative was chosen. In practice, encryption in transit and at rest is the expected baseline, and a vendor without it should be able to explain why.
What to do next
Ask two questions of any agent vendor: which fields does the agent receive, and what is the full list of systems our PHI passes through.
Those two answers describe the actual privacy surface of the deployment far better than a security page does. Then read the BAA against the clauses that matter for AI.
