Skip to main content

HIPAA-Compliant AI: Blocking PHI from Reaching External LLM Providers

If you want healthcare teams to use external LLMs safely, the control objective is straightforward: PHI must not reach the provider in identifiable form, and any route that cannot enforce that rule must fail closed. Keeptrusts gives you that boundary at the gateway with hipaa-phi-detector, pii-detector, data-routing-policy, healthcare-compliance, and audit-logger, which means compliance teams can verify the behavior in one place instead of hoping every application prompt builder remembered to sanitize patient data correctly.

Use this page when​

  • You need a practical pattern for keeping PHI out of upstream LLM prompts.
  • You want to combine HIPAA-style PHI detection, zero-retention routing, and audit evidence.
  • You are standardizing healthcare AI routes across multiple applications and teams.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, Governance reviewers

The problem​

Most healthcare AI leaks do not start as dramatic security events. They start as convenience. A clinician copies a chart excerpt into an assistant. A case manager pastes a discharge note into a summarization tool. A support team adds a general-purpose model to a workflow because it is faster than waiting for a platform review. Each step feels local and reversible, but the combined effect is that patient identifiers can cross organizational boundaries before anyone has enforced minimum-necessary handling.

That is exactly where ad hoc controls break down. Application developers are rarely the right place to implement PHI governance. They can forget a sanitization helper, bypass one route during a migration, or introduce a new prompt template that includes patient names, addresses, dates of service, medical record numbers, or insurance identifiers. By the time a privacy team reviews the architecture, the route is already live.

HIPAA also creates a second requirement beyond redaction itself: evidence. It is not enough to say that your system probably removed PHI. You need a repeatable control boundary, a record of policy outcomes, and a way to show auditors that healthcare traffic was either de-identified before routing or blocked outright. That is why a gateway-first design matters. It creates one enforced path for AI requests instead of a scattered set of application-level promises.

There is also an important implementation detail to keep straight. The documented Keeptrusts hipaa-phi-detector is a heuristic, text-focused control. It is designed to catch PHI-like text before the upstream call and participate in output redaction when present in the chain. That makes it very useful for operational enforcement, but teams should still treat HIPAA readiness as a broader governance program that includes provider selection, access control, logging, and review workflows. The gateway gives you the technical boundary. Your compliance program still owns policy decisions and rollout discipline.

The solution​

The most reliable pattern is to split healthcare AI routing into three policy decisions.

First, decide whether the route is allowed to process only de-identified content or whether any detected PHI should hard stop the request. If the answer is “no identifiable PHI leaves the organization,” configure hipaa-phi-detector with action: block. That turns PHI detection into a strict upstream boundary.

Second, constrain the provider set with data-routing-policy. Even if a prompt is de-identified, healthcare teams usually still want zero-retention and no-training guarantees where available. If no compliant provider is available, the route should block rather than silently falling back.

Third, govern the output. PHI protection alone is not enough for healthcare AI. A model can avoid PHI leakage and still return unsafe medical guidance. That is where healthcare-compliance matters. It can block known medical phrases and prepend disclaimers when the output looks like diagnosis or treatment advice. Pair that with audit-logger so the request path is reviewable after the fact.

This layered design is what makes the approach workable across real teams. Developers do not need to hand-code every guardrail into every assistant. Instead, platform owners define a governed route, and applications inherit it. Privacy teams can then review one YAML policy pack and one event trail rather than reverse-engineering the behavior of ten separate prompt builders.

You can see the underlying healthcare patterns in the existing docs for Healthcare (HIPAA), Healthcare (EU GDPR), HIPAA PHI Detector, Healthcare Compliance, and Secure Healthcare AI. The blog-level takeaway is that they work best together, not in isolation.

Implementation​

This route uses a strict boundary: detected PHI blocks the upstream call, and only zero-retention providers are eligible for the remaining de-identified traffic.

pack:
  name: healthcare-phi-blocking
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: openai-zdr
      provider: openai
      model: gpt-5.4-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0

policies:
  chain:
    - data-routing-policy
    - hipaa-phi-detector
    - pii-detector
    - healthcare-compliance
    - audit-logger

policy:
  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

  hipaa-phi-detector:
    action: block
    mode: hipaa_18
    safe_harbor_method: true

  pii-detector:
    action: redact
    healthcare_mode: true

  healthcare-compliance:
    blocked_patterns:
      - prescribe
      - stop taking
      - surgery is necessary
    required_disclaimers:
      - This is not medical advice. Consult a licensed clinician.
    fda_class: II

  audit-logger:
    immutable: true
    retention_days: 2555
    hipaa_audit_controls: true

This is intentionally conservative.

hipaa-phi-detector blocks PHI-like request content instead of trying to salvage it. pii-detector still operates in healthcare mode because mixed traffic often contains personal data that may not match the PHI heuristics exactly. data-routing-policy ensures that even permitted traffic can only reach an approved zero-retention provider. healthcare-compliance governs the output side so a de-identified request cannot still produce unsafe clinician-facing language without a disclaimer or block. audit-logger preserves the evidence trail.

The operational validation loop is short enough to use during rollout:

kt policy lint --file ./healthcare-phi-blocking.yaml
kt gateway run --policy-config ./healthcare-phi-blocking.yaml --port 41002
kt events tail --policy hipaa-phi-detector
kt events tail --policy healthcare-compliance

That gives you the three checks that matter most.

  1. The configuration parses and loads cleanly.
  2. PHI-related requests generate the expected policy outcome before the upstream call.
  3. Medical-output controls are visible in events and can be reviewed by security or privacy teams.

For organizations that allow de-identified summarization but not raw PHI, a common variant is to change hipaa-phi-detector.action from block to redact. The principle remains the same: the gateway owns the decision. Applications do not decide case by case whether to forward patient identifiers.

Results and impact​

The practical benefit of this design is not only fewer data leaks. It is operational clarity.

Security teams know where PHI routing is enforced. Privacy teams know which event stream to review. Engineers stop duplicating redaction logic across services. Procurement and governance teams can tie approved-provider decisions directly to live traffic behavior rather than checking policy documents that may not match production reality.

This also improves incident handling. If an application team asks why a request failed, the answer is in the event record, not buried in application logs. If a privacy reviewer asks whether a given route was limited to zero-retention providers, the answer is in the routing policy and provider metadata. If leadership asks whether healthcare AI adoption is expanding faster than the governance layer, the gateway gives you measurable evidence instead of anecdote.

It is also a better pattern for change management. New assistants, new provider targets, and new departments do not require a new PHI-sanitization implementation each time. They require a governed route and a reviewable policy pack. That is exactly the kind of standardization that makes HIPAA programs sustainable instead of fragile.

Key takeaways​

  • If the requirement is that PHI never reaches an external model, let the gateway enforce that with hipaa-phi-detector.action: block.
  • Constrain provider choice with data-routing-policy so compliant routing is technical, not aspirational.
  • Use healthcare-compliance for output governance because data minimization alone does not make a medical response safe.
  • Treat audit-logger as part of the control, not a reporting afterthought.
  • Use the existing healthcare docs as the reference set: Healthcare (HIPAA), Healthcare (EU GDPR), HIPAA PHI Detector, Healthcare Compliance, and Secure Healthcare AI.

Next steps​