PHI leaks happen in your logs, not your database

Ask a healthcare engineering team how they protect patient health information and you will get a confident answer about encryption at rest, encryption in transit, RBAC on the database, and an audit log on every query. All of which is correct, and all of which protects the place where PHI almost never actually leaks from.

The leaks happen in the surrounding infrastructure. The logs. The error reporting service. The analytics events. The product debug exports. The AI prompts. The Slack channel where engineers paste data fragments to ask each other for help.

This is where production teams get caught. Not at the database; the database is well-defended. At the seams.

The five places we keep finding PHI it should not be

Over the years, the same five categories come up in almost every healthcare audit.

Application logs. A log line like Updated patient 12345: { name: "...", dob: "..." } is harmless during development and a HIPAA disclosure event in production. Logs get shipped to centralized aggregators with broader access than the database. Logs get archived. Logs get queried by engineers who do not have a clinical reason to see the data. Every "let me just log this so I can debug" is a future incident.

Error reporting services. Sentry, Rollbar, and similar tools capture stack traces with the local variables that were live at the time of the crash. If a function was processing a patient record when it threw, the record is now in the error tool. The error tool is hosted, indexed, and shared with the whole engineering team. None of those properties are appropriate for PHI.

Analytics events. A well-meaning product manager wants to know which features are used. The implementation captures user-id and event-name, which is fine, plus a context blob, which is usually not. "Patient_search_performed" with the search string as a property tells you what the user did and also leaks the patient's name to your analytics vendor.

Debug exports and screenshots. When something goes wrong, engineers and support staff export data to investigate. The export tends to be a JSON blob, a CSV, or a screenshot. The export gets attached to a Jira ticket, dropped into a chat, or saved to a desktop. None of those places have the access controls the production database has.

AI prompts and traces. The new one, and the one that is catching teams off guard in 2026. A copilot or RAG system sends prompts to an external model, and the prompts contain patient context. The model provider logs the prompts. Even with a BAA in place, the surface area of "everywhere our prompts have been" is wider than most teams realize, and the traces stored for debugging often live in tools that were not procured with PHI in mind.

What to actually do

The fix is not "be more careful." Be more careful is what every team thought they were being right before the incident. Three things that actually work:

Redact at the source. Build a single utility that converts a patient object to a loggable representation — with PHI replaced by stable hashed identifiers — and make it the only sanctioned way to log a patient. Make the raw representation hard to use. Code review for log statements that include domain objects. The goal is to make accidental disclosure require effort.

Filter at the boundary. Whatever tool aggregates your logs, your errors, your analytics, your AI traces — put a filter in front of it that scrubs known PHI patterns: dates of birth, names matching your patient table, MRNs. The filter will miss things. It will still cut the surface area by a lot.

Treat the AI surface as in-scope. Every prompt your system sends to an LLM is potentially PHI in transit to a third party. Inventory the prompts. Negotiate BAAs where you can; route to self-hosted models where you cannot. Log the prompts to a HIPAA-eligible store, not to a general engineering observability tool. Treat the trace data as patient data, because that is what it is.

The harder cultural part

The hardest part is not technical. It is making the team feel comfortable surfacing near-misses without fear of blame. The engineer who notices "wait, did our last deploy start logging patient names?" needs to be able to raise that without consequence beyond fixing it. Teams that punish disclosure get fewer disclosures reported, not fewer disclosures occurring.

The compliance program is the floor. The culture is what determines whether the floor holds.