AI Data Protection in Behavioral Health Needs Two Data Classes
A behavioral health LLM request may contain electronic protected health information under HIPAA, substance use disorder records under 42 CFR Part 2, or both. The request path needs identity, destination and data-class controls before transmission, while consent, permitted-use decisions and business-associate terms remain with the provider. This article shows how to protect managed HTTP model traffic without turning a security log into a second clinical record.
A care coordinator has two charts open beside one summarization tool. The first contains a treatment plan for anxiety. The second came from a federally assisted substance use disorder program and carries 42 CFR Part 2 protections. Both requests may contain electronic protected health information, but the second can require a different disclosure analysis. AI data protection behavioral health controls need to preserve that distinction before either prompt reaches an LLM.
A green lock icon in the browser only confirms transport encryption. It says nothing about the identity behind the request, the model tenant receiving it, the Part 2 status of the record or the authority for the disclosure.
TL;DR
- HIPAA requires authorized access, activity controls, person or entity authentication and transmission protection for systems that contain or use ePHI.
- Part 2 adds specific protections for qualifying substance use disorder records, including formal security policies and detailed consent requirements.
- An authenticated HTTP control point can enforce identity, data-class and destination policy before model transmission.
- Consent decisions, clinical judgment, contracts, EHR controls, local models and vendor-native inference remain outside that control point.
HIPAA puts the request path inside the security analysis
The HIPAA technical safeguards in 45 CFR 164.312 require access limited to authorized persons or software programs, unique user identification, mechanisms that record and examine system activity, integrity protections, person or entity authentication and transmission security.
A care-management application that sends ePHI to an LLM becomes part of the path those safeguards must address. The source application may know the clinician and encounter. The model provider may see only one API credential for the application. Without identity propagation, the access decision collapses several clinicians and services into the same technical caller.
Pass the authenticated person or workload identity, role and record classification to the enforcement point. Then bind the approved provider and model to that context. AI governance for behavioral health covers the use-case owner and approval structure around this request-level control.
Part 2 needs its own classification
The security requirements in 42 CFR 2.16 require a Part 2 program or other lawful holder to maintain formal policies and procedures that reasonably protect patient-identifying information against unauthorized uses, disclosures and reasonably anticipated threats. For electronic records, those policies cover creating, receiving, maintaining, transmitting, using, accessing, destroying and de-identifying information.
A generic PHI label cannot express that extra context. The source system should mark Part 2 status when it knows it, because a downstream gateway should not infer legal status from diagnosis text or a provider name. That would turn a security classifier into a legal decision engine.
I would block an uncertain external route rather than let a content scanner guess that a therapy note falls outside Part 2. The clinician can return through an approved workflow with the right record context. Shadow AI in behavioral health covers the unmanaged tools that bypass that workflow.
A valid credential cannot supply valid consent
The Part 2 consent requirements in 42 CFR 2.31 identify elements including the patient, information to be disclosed, authorized discloser, recipient or recipient class, purpose, expiration, signature and date. The section also bars reliance on consent that is expired, materially deficient, revoked or known to contain materially false information.
An API token proves possession of a credential. It cannot show that consent covers this purpose, this recipient and this record at this moment. The application or privacy workflow must resolve that question and supply a policy-relevant result or purpose marker to the request layer.
The gateway can then enforce an approved destination for Part 2-classified content and preserve the context it received. It should never label the request legally permitted on its own. Consent management, revocation state and permitted-use analysis stay in the clinical and privacy systems that own those facts.
Business-associate duties survive encryption
The HIPAA administrative safeguards in 45 CFR 164.308 require risk analysis, risk management, information-system activity review and written assurances when a business associate or subcontractor handles ePHI on behalf of a covered entity or business associate.
TLS protects the HTTP connection. It cannot supply the required agreement, assess the provider's controls or resolve the provider's role. A behavioral health organization still needs to determine if the model provider creates, receives, maintains or transmits ePHI on its behalf and establish the required written arrangement where applicable.
Route enforcement applies the approved-provider decision to live traffic. If one tenant is approved for ePHI and a consumer endpoint is excluded, the policy should permit the first only under the documented conditions and stop the second before transmission. AI vendor risk for behavioral health covers the provider diligence that precedes that rule.
Data protection includes the gateway record
A request log can contain the same diagnoses, medication history, trauma narrative and identifiers that the control was meant to protect. Copying full prompts into a general SIEM creates another store of clinical information with a broader audience.
Keep the event narrow enough to avoid duplicating the clinical note. Identity, calling application, data class, destination, time, policy result and a protected encounter reference often support testing without duplicating the note. A hash or restricted evidence pointer can preserve integrity and support an investigation. Full payload retention needs a documented reason, a limited audience and a deletion rule aligned with that purpose.
A privacy analyst may need record context that a SOC analyst should never see. Field-level access should preserve that separation. Behavioral health AI audit trails examines the separate evidence and disclosure-accounting questions without treating the traffic record as the clinical chart.
The managed HTTP boundary leaves visible gaps
An inline gateway can inspect authenticated HTTP traffic between a behavioral health user or agent and an LLM endpoint. It can validate supplied identity, classify the request, enforce the approved destination, redact specified data and block before transmission.
Coverage ends at that routed boundary. An assistant performing inference entirely inside an EHR vendor's environment may never cross it. A local model on a clinician's laptop, dictation on a personal phone and a file transferred outside the LLM route need vendor, endpoint or device controls. The gateway also cannot determine clinical necessity or obtain patient consent.
Name those exclusions in the control inventory. A useful statement says which care-management applications and model endpoints were routed and tested on a specific date. "All behavioral health AI is protected" invites a reviewer to open the one embedded assistant the gateway never sees.
DeepInspect
DeepInspect is a stateless proxy for authenticated HTTP traffic between behavioral health users or agents and LLM endpoints. It evaluates application-supplied identity, record classification, approved destination and policy before forwarding. Each permit, redaction, reroute or block creates a signed per-decision record outside the calling application's write path.
For managed routes, DeepInspect can keep ePHI or Part 2-classified content away from unapproved models and apply the provider decision before transmission. It does not determine consent, decide if a disclosure is legally permitted, execute a business associate agreement, protect local models, cover vendor-native inference or replace EHR access controls.
Book a demo today.
Frequently asked questions
- Is every behavioral health record covered by HIPAA and Part 2?
HIPAA applies to covered entities, business associates and relevant protected health information. Part 2 applies to qualifying records maintained in connection with a Part 2 program and to lawful holders in the circumstances defined by the rule. A behavioral health label alone establishes neither status. Classification should come from the source and applicable legal analysis.
- Can we send ePHI to an LLM if the connection uses TLS?
TLS addresses transmission protection on the network hop. The organization still needs authorized access, an approved use, the right provider arrangement and a destination policy. Encryption cannot determine if the clinician, application, data and provider combination is permitted.
- Should the gateway store every prompt and response?
A broad default creates another clinical repository. Store the smallest event needed for enforcement testing and investigation, then use a protected reference for content kept elsewhere. If a documented purpose requires full payloads, apply clinical-grade access, retention and deletion controls to that store.
- What should happen when Part 2 status is unknown?
The route should follow the organization's written treatment for uncertainty. A fail-closed policy can stop external transmission and direct the user back to a workflow that supplies record context. The security control should preserve the reason for the block while leaving the legal classification to the accountable privacy and clinical teams.