PHI minimization is the practice of giving an AI system only the protected health information a role actually needs for the task in front of it, enforced at the moment data is used rather than after the fact. It is the operational form of the HIPAA minimum necessary standard. For an LLM or a RAG pipeline, that means filtering retrieval to authorized records and stripping the fields a role is not cleared for before the prompt reaches the model. The patient stays identified, because the clinician legitimately needs to know who they are treating. What changes is which fields are present for each specific request.
The reason this matters more for AI than for a human reading a chart is structural. A person glances past the fields they do not need. A model ingests everything it is given and can surface any of it in an answer. When the whole record lands in the context window, the only thing standing between a sensitive field and an unintended disclosure is the model's own behavior, which is exactly the control you do not want to rely on.
01What the minimum necessary standard is
The minimum necessary standard is a core requirement of the HIPAA Privacy Rule. It directs a covered entity to make reasonable efforts to limit the use, disclosure, and request of protected health information to the minimum necessary to accomplish the intended purpose. It is a scoping rule, not a deletion rule. The goal is to match access to the legitimate need behind it.
A few features of the standard shape how it lands on AI systems.
It governs use, disclosure, and request. The rule reaches not only what you hand to an outside party but what you pull together internally and what you ask another system to give you. An AI pipeline that assembles a prompt is making a use and a request of PHI, which puts it squarely in scope.
It is role and task based. Minimum necessary is judged against what a person reasonably needs for their role and the specific purpose. The Privacy Rule expects covered entities to identify the classes of workforce members who need access and to limit access accordingly, which maps cleanly onto role-based control.
Treatment is an exception; most other uses are not. Disclosures to a provider for treatment are exempt from the minimum necessary analysis, on the theory that a treating clinician should not be second-guessed at the point of care. Operational, administrative, and analytic uses get no such pass, and a large share of enterprise AI is operational rather than treatment. This is where minimization does most of its work.
None of this is new. What is new is the consumer of the data. The standard was written when the consumer was a person; with AI, the consumer is a model, and the control has to move accordingly.
02Why LLMs and RAG default to over-collecting PHI
The default behavior of an AI pipeline runs against minimum necessary, and it does so for understandable engineering reasons. Builders want the model to have enough context to answer well, so the path of least resistance is to retrieve broadly and pass the whole record. Three patterns push toward over-collection.
Retrieval optimizes for relevance, not authorization. A vector store returns the best semantic match to a query. It has no native notion of whether the requester is allowed to see that match. Authorization that lived in the source system is lost the moment a document is embedded, so retrieval will happily surface a field, or another patient's record, that the asker has no right to.
Whole documents enter the prompt. Even within an authorized record, the convenient move is to inject the entire note or resource. Every field comes along, including the ones the role does not need, because filtering at the field level takes deliberate work that nothing in the pipeline does by default.
The prompt is treated as ephemeral. Teams reason that the context window is transient, so what it contains feels low-stakes. But the moment PHI is placed in a prompt it has been used and, if the model runs outside the boundary, disclosed. The transience of the buffer does not change either fact.
The result is a pipeline that holds far more PHI than any single request needs, defended only by prompt instructions asking the model not to reveal it. That is a posture, not a control. Sound AI data governance inverts it: decide what the model may see before the prompt is built, not what it should refuse to say after.
03Applying minimum necessary at retrieval and at the field level
Minimization becomes real when it operates in two places in the pipeline, in order, before the model is ever invoked.
At retrieval. Resolve the requester's clearance first, then constrain retrieval to the records that role is authorized to read. A passage the asker may not see should never be a candidate for the prompt. This is the difference between a retriever that answers "what is most relevant" and one that answers "what is most relevant among the things this person is allowed to use." Getting this right is the heart of RAG security and of permission-aware retrieval.
At the field level. Within an authorized record, evaluate each field against the role and the purpose, and pass only what is needed. A nurse confirming a medication schedule receives the medication list and not the substance-use history. A scheduling assistant receives appointment and demographic fields and not lab results. The decision is per field, per role, per request.
The ordering matters. Filter retrieval first so unauthorized records never enter the candidate set, then redact fields within what remains, then assemble the prompt. Done in that sequence, the sensitive data the asker is not entitled to is simply not present when the model runs, which is the only state that holds when the model is probed or when an answer is unexpectedly verbose. The withholding has to happen before the prompt, because anything the model receives, it can disclose.
04Redaction versus de-identification for minimization
Two techniques reduce PHI exposure, and they serve minimization differently. Confusing them leads teams to reach for the wrong tool.
De-identification removes enough identifiers that data falls outside HIPAA entirely, under either Safe Harbor, which strips a defined list of eighteen identifier types, or Expert Determination, which uses a qualified statistician to certify that re-identification risk is very small. De-identified data is no longer PHI, so it suits analytics, research, and model training on populations where no one needs to know which individual a record belongs to. But it removes the patient's identity, which makes it unfit for care delivery, where the whole point is to act on a specific person.
Runtime redaction keeps the patient identified and withholds the specific fields a given role is not cleared for, at the moment of the request. This is the technique minimization for clinical and operational AI actually needs. The clinician knows which patient they are treating; the model receives only the fields that role needs for the question. The decision basis is the role and the field, not a fixed identifier list, so the same record yields different views depending on who is asking and why.
The two are complementary rather than competing. De-identify for the data lake and the training set. Redact at runtime for the copilot that serves identified patient care. A clinical AI program usually needs both, and minimization at inference is overwhelmingly a redaction problem, not a de-identification one. For the deeper treatment of how this fits the full HIPAA picture, see HIPAA-compliant AI.
05Worked examples: copilot, prior authorization, billing
The standard is easier to reason about against concrete requests. Each of these is the same patient record, viewed through a different role and purpose.
Clinical copilot. A nurse asks an inpatient copilot to confirm a patient's current medication schedule and any interactions. The minimum necessary fields are the active medication list, allergies, and relevant vitals. The substance-use history and the psychotherapy notes are not needed for a medication-timing question, so they are withheld before the prompt. The nurse still gets a complete, useful answer; the model never holds the fields it did not need.
Prior authorization. An assistant drafts a prior-authorization request for a procedure. The minimum necessary fields are the diagnosis codes, the procedure code, and the clinical documentation that supports medical necessity for that procedure. Unrelated diagnoses, family history, and behavioral-health notes outside the scope of the request are withheld. The output is a focused submission, and the data that traveled to the model is bounded to the authorization's purpose.
Billing clerk. A billing clerk asks an assistant to reconcile a claim. The minimum necessary fields are diagnosis and procedure codes, dates of service, and demographics needed to match the account. The clinical narrative, lab values, and notes are not needed to reconcile a code, so they are redacted. The clerk works the claim without ever being positioned to see clinical detail that the role has no business reading.
In each case the pattern is identical: define the purpose, scope the fields to it by role, withhold the rest before the model runs. The answers do not suffer, because the fields that were withheld were not needed to produce them.
06Proving minimization with content-free evidence
Enforcing minimum necessary is half the obligation. The other half is being able to show you enforced it, because under HIPAA the absence of a record is treated as the absence of a control. When the Office for Civil Rights opens an investigation, or when you have to decide whether an incident was a breach, the question is precise: who asked, what was released, what was withheld, and under what authorization.
An audit trail built for minimization has to satisfy several properties at once.
- Content-free. The record holds the decision, the role, the fields acted on, and a hash, not the PHI itself. Otherwise the audit log becomes a second copy of the data you are trying to protect.
- Signed. Each entry is signed so its integrity can be checked. With HMAC-SHA256, a single altered byte invalidates the signature.
- Hash-chained and append-only. Each entry incorporates the prior entry's hash, so deleting or editing any record breaks the chain and the tampering is visible.
- Verifiable offline. An auditor can confirm the record independently, without trusting the system that produced it or moving any regulated data to do so.
Logged this way, the evidence does double duty. It demonstrates that minimum necessary was applied field by field, and it gives breach response a precise account of exposure instead of a guess. A deterministic decision helps here too: when the same role, field, and policy always yield the same verdict, the record is reproducible and therefore defensible, which a stochastic judgment is not.
07A minimization checklist for AI teams
If you are building or reviewing an AI system that touches PHI, these are the controls that turn the minimum necessary standard from a policy statement into something that actually operates at inference.
- Classify fields by sensitivity before policy runs, so the system knows what each FHIR element or claim field is and can act on it.
- Filter retrieval by authorization, so unauthorized records never become candidates for the prompt.
- Redact at the field level by role, passing only the fields a role needs for the specific purpose.
- Withhold before the prompt is built, never after, so the model cannot disclose what it never received.
- Make decisions deterministic, so the same role, field, and policy always produce the same verdict and the result is reproducible.
- Fail closed, so an error or timeout blocks the request rather than releasing PHI by default.
- Keep the pipeline inside your boundary, so PHI is not disclosed simply by being assembled outside it.
- Record signed, content-free evidence of every pass and redact decision, verifiable offline.
Read top to bottom, the list describes a single property: the model receives the minimum necessary PHI for each request, by role, and you can prove it.
08How Custosa enforces minimum necessary at runtime
Custosa is the runtime data-control plane for enterprise AI. It sits between your data and the LLM and inspects every record and field at runtime, before the model sees it. For a healthcare deployment, that inspection is exactly where the minimum necessary standard is enforced and where PHI minimization happens.
The data plane runs inside your environment, so records never leave your boundary; self-managed, on-premises, and air-gapped options are available, along with a FIPS build. The control plane receives only content-free verdict evidence, never the records themselves. Decisions are made by a deterministic formal policy engine, Cedar, not a model, so the same inputs always produce the same verdict and the system fails closed. Verdicts are per-field Pass or Redact, by role, through a five-level clearance lattice, and the fields a role is not cleared for are withheld before they enter the prompt, so the model cannot leak what it never received.
Every decision is signed with HMAC-SHA256 and hash-chained into an append-only, tamper-evident, content-free evidence ledger that can be verified offline, which is what lets you prove minimum necessary was enforced field by field. For healthcare specifically, Custosa ships a HIPAA Pack, FHIR R4 auto-classification, and X12 EDI claims handling, alongside SOC 2 and SOC 1 packs. Data is protected with TLS in transit and AES-256-GCM at rest, with BYOK on request, and the p99 added-latency target is 50 to 110ms. Custosa is early-stage and in production with design partners.
To be precise about scope: Custosa provides the controls and the evidence; it does not make you HIPAA certified, because no software can. A BAA is still required between a covered entity and any vendor handling PHI, and the covered entity remains responsible for its own compliance program.
Give the model only the PHI each role needs
See how Custosa enforces minimum necessary at the field level, by role, before the prompt is built, and records signed evidence of every decision.
Frequently asked questions
What is the minimum necessary standard?
The minimum necessary standard is a HIPAA Privacy Rule requirement that a covered entity make reasonable efforts to limit the use, disclosure, and request of protected health information to the minimum necessary to accomplish the intended purpose. It does not require the least possible amount of data. It requires that access be scoped to what a person reasonably needs for their role and the task at hand. Treatment by a clinician is a recognized exception, but operational and analytic uses are squarely within scope.
How does the minimum necessary standard apply to AI and LLMs?
It applies to what the model receives, not just what a person reads. An LLM or RAG pipeline makes a use and a request of PHI every time it assembles a prompt, so the minimum necessary standard governs which fields enter the context window. Applied correctly, the model is given only the PHI the requesting role is authorized to use for the question asked. The fields a role is not cleared for are withheld before the prompt is built, so they are never exposed to the model in the first place.
What is PHI minimization?
PHI minimization is the practice of reducing protected health information to the minimum necessary for a given task, by role, at the moment data is used. For AI it means filtering retrieval to authorized records and stripping the fields a role does not need before the prompt reaches the model. It is the operational form of the minimum necessary standard. The goal is not to anonymize the patient, who the clinician legitimately needs to identify, but to limit which fields are present for each specific request.
Does minimum necessary apply at inference time?
Yes. The use and the disclosure that the minimum necessary standard governs happen when the prompt is assembled and sent to the model, which is inference time. A build-time access policy or a catalog label does nothing if the runtime prompt still carries the whole chart. The control has to operate at the moment the data enters the model. Withholding fields after the model has already received them is too late, because the model can disclose what it holds.
How do you prove minimum necessary for AI?
You prove it by recording, for every request, what policy was applied, which role asked, which fields were passed, and which were redacted, then making that record verifiable. A content-free evidence ledger holds the decision metadata, hashes, and signatures rather than the PHI itself, so the audit trail is not a second copy of the data to protect. Signing each entry and hash-chaining it into an append-only log lets an auditor confirm offline that minimum necessary was enforced field by field, without trusting the system that produced the record.