HIPAA-ready AI architecture — not HIPAA compliance

HIPAA compliance is a property of a covered entity or business associate and its full administrative, physical and technical safeguards programme — risk analysis, workforce training, access controls, breach procedures, and signed agreements with every business associate in the chain. No single vendor component can hold that property on its behalf. A privacy layer can change whether PHI reaches a given processor at all; it cannot certify your organization, and it cannot stand in for a BAA where one is legally required.

Products that are not themselves clinical systems still routinely handle PHI once an AI feature is added: a summarizer condenses a clinical note, an intake form's free-text field is passed to a model for triage, a support ticket references a patient's diagnosis, a scheduling assistant reads an appointment tied to a treatment type, or a billing workflow includes a claim number next to a patient name. None of these look like "health records" in the product's data model — they are ordinary text fields that happen to contain individually identifiable health information.

The result is that PHI can reach a model provider's API through the same incidental path as any other customer data — because a feature was built without anyone asking whether the field could contain health information at all.

HIPAA's Safe Harbor de-identification method lists 18 categories of identifiers that must all be removed for data to qualify. Privian's supported entity set overlaps with some of these categories and does not currently cover several others — this gap is the reason masking is a technical control, not a de-identification determination.

• Names — partially covered

  Person names are in Privian's supported entity set on a best-effort basis. Safe Harbor requires removal of all names, which best-effort NLP detection cannot guarantee.

• Geographic subdivisions smaller than a state — NOT covered

  Street addresses, cities, precise geographic detail and most ZIP code rules are not part of the supported entity set.

• All elements of dates (except year) — NOT covered

  Birth dates, admission/discharge dates and dates directly related to an individual are not detected or masked.

• Phone numbers — covered

  Phone numbers are in the supported entity set.

• Email addresses — covered

  Email addresses are in the supported entity set.

• Social Security numbers — partially covered

  US SSN is supported. Other national identifiers beyond US SSN and Canadian SIN are not.

• Medical record numbers — NOT covered

  MRNs are not a supported entity type.

• Health plan beneficiary numbers — NOT covered

  Insurance/health plan member identifiers are not a supported entity type.

• Account numbers — NOT covered as a distinct category

  Privian does not have a general 'account number' detector; only specific formats such as card numbers and IBANs are covered.

• Certificate/license numbers — NOT covered

  Not a supported entity type.

• Vehicle identifiers — NOT covered

  Not a supported entity type.

• Device identifiers and serial numbers — NOT covered

  Medical device identifiers are not a supported entity type.

• URLs and IP addresses — IP addresses covered, URLs not

  IP addresses are supported; web URLs are not a distinct detected category.

• Biometric identifiers — NOT covered

  Not applicable to a text-based prompt gateway.

• Full-face photographs and comparable images — NOT covered

  Privian processes text prompts; image content is out of scope entirely.

• Any other unique identifying number, characteristic or code — NOT reliably covered

  This catch-all category cannot be satisfied by a fixed, best-effort entity list by definition.

The full current entity catalog is listed on the PII masking page. Achieving Safe Harbor requires all 18 categories to be addressed; Privian's detector was not built against that checklist and should not be treated as satisfying it.

Privian's controls are relevant to Path B as one input: reducing identifying content in the prompt. They do not implement Path A — Privian does not sign a BAA — and they do not by themselves complete Path B's de-identification standard.

Privian scans the assembled prompt for its supported entity set on each request, with no cross-request state: names, emails, phone numbers, IP addresses, credit cards, IBAN, US SSN, Canadian SIN, JWTs, provider API keys, GitHub tokens, AWS keys and env-style assignments. As shown above, this set does not cover several categories HIPAA treats as identifiers — dates, medical record numbers, health plan beneficiary numbers, device identifiers and images among them.

Detected values are replaced with deterministic, type-aware placeholders — PERSON_1, EMAIL_2 — for the duration of the request. The masked prompt keeps its shape so the model can still reason about relationships, but the supported identifiers do not cross the boundary as plain text.

The mapping between placeholders and original values is held in memory for the life of the request only. Placeholders in the model's response are replaced back with the original values before your application sees the reply, and the mapping is then discarded. See rehydration for the mechanics.

Every request through Privian follows one describable path: detection and masking, forwarding to the model provider under your own BYOK credentials, and rehydration of the response. Privian does not persist raw prompts or responses; only structural counters are retained for billing and observability. The full hop-by-hop description is on the data path page. None of this changes whether the model provider itself is under a BAA — that is a separate agreement you would need directly with that provider if PHI reaches it.

Can you use an LLM API with PHI?

Only within a compliance programme you control — with a signed business associate agreement covering every processor that touches the PHI, or by removing enough identifying detail before egress that what remains is no longer PHI under HIPAA's de-identification standards. No vendor product makes either path automatic.

Is Privian HIPAA compliant?

No, and the question is mis-framed. HIPAA compliance describes a covered entity's or business associate's full administrative, physical and technical safeguards programme — not a property a single vendor component can hold on its own. Privian does not claim certification and does not sign BAAs.

Does Privian sign a BAA?

No. Privian does not currently offer a business associate agreement. If your use case requires PHI to reach a downstream processor under HIPAA, you need a BAA with that processor directly — Privian is not a substitute for one.

What is a HIPAA compliant LLM?

Strictly, there is no such thing as a certified 'HIPAA compliant model' — compliance attaches to the covered entity's use of a system under a BAA and a documented programme, not to the model itself. Vendors that describe a product as 'HIPAA compliant AI' are usually describing BAA availability plus their own safeguards, which you still have to verify and operationalize.

Does masking PHI satisfy HIPAA de-identification?

Not by itself. HHS recognizes two de-identification methods: Safe Harbor, which requires removing 18 specific identifier categories, and Expert Determination, which requires a qualified expert's statistical assessment. Best-effort detection over a fixed entity set is a useful technical control but is not, on its own, a Safe Harbor determination or an Expert Determination.

What counts as PHI in a support ticket or chat transcript?

Any individually identifiable health information linked to a person — which can include a name next to a diagnosis, a scheduling note referencing a treatment, or a billing reference tied to a claim. PHI often appears in free text that was never tagged as a health record, which is why it can reach an LLM prompt without anyone deciding to send health data.

Can de-identified data still leave the HIPAA boundary safely?

Data that genuinely meets the Safe Harbor or Expert Determination standard is no longer PHI and HIPAA's restrictions on it no longer apply. Reaching that standard is a determination you or a qualified expert make about the specific dataset — a masking layer can reduce identifying content but does not itself make that determination.

What should a healthcare-adjacent SaaS company do instead of assuming compliance?

Decide, per data flow, whether PHI needs to reach the model at all. Where it does, put a BAA in place with every processor in that path. Where it doesn't, minimize what leaves the boundary and treat any residual identifiers as still in scope for your programme rather than assuming a masking tool has resolved the question.

Should we consult anyone before relying on this architecture?

Yes. This page describes technical architecture, not legal advice. Confirm your classification of PHI, your de-identification approach and your processor agreements with your own counsel or compliance officer before treating any configuration as sufficient.

• Solution: OpenAI data privacy
• Solution: Enterprise-ready AI
• Solution: Customer support AI
• Reference: Data path
• Product: PII masking
• Product: Rehydration

This page is provided for architectural and educational purposes only and is not legal advice. Whether your specific data flows require a BAA, whether your de-identification approach meets HIPAA standards, and whether Privian is an appropriate component of your programme are questions for your own counsel or compliance officer.