PHI redaction
PHI redaction is the runtime operation that identifies Protected Health Information inside an AI prompt or completion and removes, masks, or tokenizes the identified fields before the content reaches the LLM endpoint. PHI is the 18 HIPAA identifiers (names, dates, geographic subdivisions smaller than a state, phone, email, MRN, account numbers, full-face photos, and the other defined elements). Redaction sits at the AI gateway above the TLS termination point so the content can be read in cleartext, classified, and rewritten before it crosses the trust boundary into a vendor model.
What PHI redaction has to cover
The 18 HIPAA Safe Harbor identifiers define the surface area. A SOAP note that names the patient, the date of admission, the city, and the diagnosis carries four identifiers in a single sentence. Cloud Radix reported that 57% of healthcare professionals use unauthorized AI tools to process PHI (SOAP notes, diagnostic plans) without a Business Associate Agreement. The redaction control catches the identifiers in the prompt and returns either a sanitized prompt to the model or a block when the route is not BAA-covered.
How redaction interacts with the BAA-covered route
Some healthcare workflows require the model to see the PHI to be useful (clinical summarization, ICD-10 coding, prior-authorization drafting). Those workflows have to run on a BAA-covered LLM endpoint with the redaction control configured to pass the PHI through after verifying the route's BAA status and the caller's role. Other workflows do not require the PHI (administrative drafting, scheduling assistants); the redaction control replaces the identifiers with tokens before forwarding. The per-decision audit record names which identifiers were detected, which were redacted, which were passed through, and which BAA-covered route handled the request. HIPAA's accounting-of-disclosures obligation reads against that record at audit time.
Related reading
- AI Inline Enforcement Architecture: Where the Policy Decision Sits and What It Has To Commit
AI inline enforcement runs the policy decision in the request path, before the model API call returns to the calling application. The architecture places a deterministic policy decision point between the application identity and the model endpoint and commits a per-decision audit record before the response forwards. This piece walks through the architectural components, the decision-time data shape, the failure modes the implementation has to handle, and the regulatory profile that the inline placement satisfies (EU AI Act Article 12, NIST AI agent identity and authorization Pillar 2 and Pillar 3, Fannie Mae LL-2026-04, DORA Article 6).