Ask a team how they are handling PHI in an AI workflow and the answer is usually a redaction step. Ask what happens to the output, who may read it, and how long it lives, and the answer is usually silence.
- Business problem
- Asked how they handle PHI in an AI workflow, most teams describe a redaction step. Asked what happens to the output, who may read it, and how long it lives, they have no answer.
- Why it matters
- De-identification under HIPAA is a property of a dataset in its context, not a stage in a pipeline — both defined methods depend on what else could be joined to what remains. Re-identification is a join, not a leak, and no regular expression prevents one.
- Architecture response
- Five things a redaction step does not provide: a purpose and lawful basis, context scoped to that purpose (a context window is a use), authorization that follows the purpose rather than the person, a trace complete enough to reconstruct any answer, and a lifecycle for the artifacts the AI produced.
- What Databright Cloud Solutions does
- We design purpose-scoped access, context assembly and logging, de-identification risk assessment, model and prompt versioning, reconstruction-grade audit trails, and retention and disposal for the artifacts your AI creates.
Redaction is a control, not a status
HIPAA recognizes two methods for de-identifying protected health information. Under Safe Harbor, eighteen categories of identifier are removed — names, most dates, geographic detail below a defined threshold, and the rest — and the covered entity must have no actual knowledge that what remains could identify the individual, alone or in combination with other information. Under Expert Determination, a qualified person applies accepted statistical methods and documents that the risk of identification is very small for the anticipated recipient.1
Both definitions hinge on the same thing: de-identification is a property of a dataset in a context, judged against what a recipient could combine it with. A pipeline stage that strips patterns from text is a useful control toward that property. It is not the property.
The practical failure mode is narrower than it sounds. Free-text clinical notes and call transcripts do not present identifiers in tidy formats: a member describes a rare condition, names the employer through which they have coverage, and mentions the week of an admission. No individual field is a Safe Harbor identifier. The combination is recognizable.
Re-identification is a join, not a leak
Most re-identification does not involve a breach. It involves someone connecting a de-identified record to data they already hold.
That has a direct architectural consequence: you cannot evaluate a dataset’s de-identification in isolation from the environment it lands in. The same extract can be adequately de-identified for one recipient and inadequate for another with a richer reference set — which is why the standard is written against an anticipated recipient rather than in the abstract.1
Scope follows purpose, and a context window is a use
The minimum necessary standard calls for reasonable efforts to limit uses, disclosures, and requests to what the intended purpose requires. It is explicitly a reasonableness standard, not an absolute one, and routine disclosures may be handled by policy while non-routine ones get individual review.2
Applied to AI systems, the underused word is uses. Assembling a prompt is a use of every record that goes into it. Retrieval that returns the member’s complete history because the index was built that way is a use of the complete history, whatever the question was.
The remedy is unglamorous: build context per purpose. Define what a purpose is allowed to see, assemble against that definition, and record what was actually assembled — the same discipline that makes any retrieval system evaluable.4
Authorization is per purpose, not per user
Conventional access control asks whether a user may read a record. AI workflows break that model, because the thing reading the record is a process acting on behalf of a purpose, often asynchronously, sometimes on behalf of a user who has gone home.
The question that has to be answerable is therefore compound: this purpose, over this data, for this member, on whose behalf, under which agreement. A service account with broad read access satisfies none of it while appearing to work perfectly.5
Named, scoped, and attached to every request — not implied by which service made the call.
A process acting for a user carries that user’s constraints, and loses them when the basis expires.
Which processor sees what, under which agreement, in which region — recorded rather than assumed.
What a system was refused is as informative as what it was given, and it is the signal that scoping is real.
Auditability means reconstructing the answer
Most logging captures that an event occurred. The question that actually gets asked is different: why did the system say that, about this member, on that date?
Answering it requires the inputs as they stood, the prompt or query that was constructed, the model and version, the output, and the disposition — whether a person accepted, edited, or overrode it. Absent the input snapshot the answer cannot be reproduced, and an explanation nobody can reproduce is an assertion.3
Model and prompt versioning belong here too. A workflow that behaved correctly in March and incorrectly in July, with no record of what changed between them, cannot be investigated.
Derived artifacts have a lifecycle too
This is the most common gap, and the easiest to close before it accumulates.
Retention policy is typically written for source systems. AI workflows generate a second population of artifacts that describe the member: transcripts, summaries,6 embeddings, extracted entities, cached retrieval results, evaluation datasets, and prompt logs containing verbatim PHI. Each is derived from a record with a disposal schedule, and each will outlive it unless someone decided otherwise.
When a member record is deleted or its retention period ends, what happens to the embeddings computed from it, the summaries written from it, the prompt logs containing it, and the evaluation set it was sampled into? If that question has no owner, the workflow is not governed regardless of how good the redaction step is.
What governed actually looks like
Not a heavier process. A workflow that can answer, without a project, what basis it acted on, what it was permitted to see, what it produced, who relied on it, and when all of that will be disposed of.
Every one of those is a data-platform capability rather than a policy document, which is the encouraging part: they are buildable, and they make the system easier to operate whether or not anyone is asking.
Treat de-identification as a risk assessment of a dataset against a recipient, not a pipeline stage. Scope context to a named purpose and record what was assembled. Authorize the purpose rather than the process. Log enough to reconstruct any answer. And give every derived artifact the same lifecycle as the record it came from.
Sources and industry references
- HHS — Guidance regarding methods for de-identification of protected health information: Expert Determination and Safe Harbor
- HHS — Minimum Necessary Requirement: reasonable efforts to limit use, disclosure, and requests for protected health information
- Databright Cloud Solutions — The Source Provenance Problem: knowing where every value came from
- Databright Cloud Solutions — Right Property, Right Time, Right Evidence: evaluating AI that makes claims about records
- Databright Cloud Solutions — The Agentic AI Transition: bounded agents, autonomy levels, and accountable execution
- Databright Cloud Solutions — The Member Call Is a Record: conversation intelligence under PHI constraints
This article provides data-architecture and engineering perspectives. It is not legal, compliance, clinical, or regulatory advice, and it is not a statement of what HIPAA or any other authority requires of a particular organization. De-identification determinations, authorization models, and retention schedules depend on your role, your agreements, the data involved, and facts this article does not address; consult qualified counsel and your privacy officer.