Does HIPAA require an AI-specific audit log?

The audit-control standard in 45 CFR 164.312(b) requires mechanisms to record and examine activity in information systems containing or using electronic protected health information. It does not prescribe a product called an AI audit log. A covered entity should determine which systems contain or use ePHI, including applications that send it to an LLM, then implement controls that make the relevant activity examinable. An identity-bound request record can close the gap between EHR access and the model call.

Is every LLM call involving a Part 2 record a reportable disclosure?

That legal determination depends on the participants, purpose, consent and applicable permission. The Part 2 rule permits specified uses and disclosures while restricting others. The technical trail should preserve the source facts without assigning a legal conclusion automatically. Privacy staff can use identity, destination, data class, timestamp and purpose metadata to decide if the event belongs in an accounting or investigation. Record the decision and reviewer separately.

Should a provider retain the full therapy note in the AI log?

A broad security log should avoid becoming a second clinical repository. Store the event metadata needed for control testing and use a hash or restricted reference to the payload where possible. If the provider has a documented clinical, legal or quality reason to preserve the complete request and response, place them under access controls suited to behavioral health records. The October 2026 retention matrix should name the owner and deletion trigger.

What evidence should a behavioral health AI vendor provide?

Ask for user and tenant identity, model destination, event time, policy outcome, administrative access history, retention behavior and export format. The vendor should state which features call external models over HTTP and which perform inference inside its own environment. For Part 2-classified data, the provider also needs enough context to evaluate the vendor's role and permitted use. A SOC 2 report cannot substitute for interaction-level evidence.

Behavioral Health AI Audit Trails Must Separate Access, Disclosure and Model Use

HIPAA's Security Rule requires covered entities and business associates to implement mechanisms that record and examine activity in information systems containing or using electronic protected health information. A behavioral health clinician who sends a progress note to an LLM creates activity in another system path, one that may sit outside the EHR audit view.

Substance use disorder records can add 42 CFR Part 2 restrictions and patient rights to the same request. AI audit trail behavioral health design therefore needs three linked views: access to the clinical record, transmission to the model and any disclosure that must be accounted for under the applicable rule.

TL;DR

HIPAA audit controls cover activity in systems that contain or use electronic protected health information.
42 CFR Part 2 protects substance use disorder records and includes rights to certain disclosure accountings.
A model-request record should capture identity, data class, destination, policy and outcome before transmission.
A gateway log supports investigation; EHR access logs and legal disclosure accountings remain separate records.

HIPAA names the activity to examine

The HIPAA technical safeguards at 45 CFR 164.312 require unique user identification under access control, audit controls that record and examine system activity, person or entity authentication and transmission security. These outcome-focused requirements leave each covered entity or business associate to select mechanisms appropriate to its environment under the broader Security Rule.

An EHR audit record can show that Dr. Rivera opened a note at 2:16 p.m. It may lose sight of the next step if a browser extension or care-management application sends part of that note to an LLM. The model provider records an API credential, while the EHR records chart access. Neither record necessarily binds the named clinician, note classification, destination model and policy decision in one event.

An AI request trail can cover the seam between chart access and model transmission. HIPAA AI audit trails covers the wider Security Rule mapping.

Part 2 changes the data classification

The 42 CFR Part 2 confidentiality regulations restrict uses and disclosures of records maintained in connection with a federally assisted Part 2 program. Under 42 CFR 2.16, formal policies and procedures must reasonably protect patient identifying information against unauthorized uses, disclosures and anticipated threats. Its electronic-record provisions cover creating, receiving, maintaining, transmitting, destroying and accessing those records.

Part 2 status cannot be guessed from a generic "clinical" label. A therapy note may be PHI under HIPAA, a Part 2 record or both, depending on the program and record. The source application needs to supply that classification before an external policy point can act on it.

At a care coordinator's desk, two tabs show two patients beside one summarization button. One chart contains general anxiety treatment. The other comes from a federally assisted substance use disorder program. Identical button clicks carry different disclosure constraints.

Disclosure accounting and traffic evidence answer different questions

Part 2's 2024 revisions include patient rights to an accounting of certain disclosures of electronic records for the prior three years under Section 2.25, plus a list of certain intermediary disclosures under Section 2.24. HIPAA also has its own accounting framework at 45 CFR 164.528. A legal or privacy team decides which events belong in those accountings and which exception or consent applies.

A gateway record provides source evidence for that determination. It can show that an authenticated care-management service transmitted Part 2-classified content to a named model endpoint at 9:03 a.m., after policy version 22 permitted the route. It should also show a block or redaction when the route violated policy.

The gateway record alone lacks several legal facts, such as the purpose of a disclosure, applicable consent and the identity of a recipient beyond the technical endpoint. Treating every model call as a completed legal accounting entry would collapse technical telemetry into a legal judgment. I would rather preserve the clean source event and let privacy operations make the classification they are accountable for.

The minimum request record has six parts

Start with the authenticated person or service identity supplied by the behavioral health application. Add the record class, including a distinct Part 2 marker when the source system knows it. Capture the destination model and tenant, event time, policy version and enforcement result. A clinical context reference can bind the event to the encounter without copying the patient's name into a general log.

The full prompt and response need tighter handling. They may contain diagnoses, medication history, trauma narratives, family details and patient identifiers. A general SIEM is often the wrong repository for that payload. The event can hold a hash and restricted evidence reference while the complete content stays under a clinical access model.

Signed audit logs for AI requests explains the integrity mechanism. Signing makes later changes visible. A separate write path prevents the calling assistant from erasing an event after it receives a model response.

Review should reconstruct a specific encounter

A quarterly control test needs more than a screenshot of an enabled setting. Select a model interaction tied to an encounter and reconstruct the sequence: EHR access, application action, gateway decision, model destination, response handling and clinician review. Record the systems that supplied each artifact and the reviewer who resolved discrepancies.

For a blocked event, confirm that the request stopped before transmission and that the user received an actionable message. For a permitted event, confirm that the destination and data class matched the approved use. A 2026 policy review should also compare the approved inventory with actual model traffic, because browser assistants can appear between annual governance meetings.

AI governance for behavioral health covers the use-case inventory and owner. Test that approved scope against dated requests made by staff and applications.

Retention needs a field-level decision

HIPAA documentation, Part 2 disclosure accounting and clinical records can follow different retention rules. State law and contractual duties can add further periods. The behavioral health provider should map each AI audit field to its purpose and governing schedule instead of inheriting the observability platform's default.

Identity, model, policy outcome and encounter reference may support a security investigation. A complete prompt may belong with a clinical record only when the organization has a defined reason to retain it. A block event may need enough content to explain the detected class while avoiding a duplicate copy of the note.

The policy should also identify who can retrieve each field. A SOC analyst may need the route, classification and block reason. Access to the underlying therapy narrative belongs to a narrower clinical or privacy group. AI vendor risk for behavioral health covers the same questions when a third-party platform controls retention and export.

The HTTP boundary leaves named exclusions

A proxy can evaluate HTTP traffic routed through it between authenticated users or agents and LLM endpoints. It misses dictation or summarization performed entirely inside an EHR vendor's environment. It also misses a local model on a clinician's workstation and a personal phone outside device management.

The control description should list those populations. Managed care-management applications may produce identity-bound gateway records. The EHR's embedded assistant may produce vendor audit exports. Local experiments may be prohibited through endpoint policy and reviewed through device controls. Each statement has a named evidence source.

Claiming universal AI visibility across a behavioral health group invites a reviewer to test the embedded assistant first. A narrower claim tied to routes, applications and October 2026 test results will survive that question.

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. Every permit, redaction, reroute or block creates a signed per-decision record outside the calling application's write path.

For covered routes, those records can connect an encounter reference and Part 2 marker to the model and policy used. DeepInspect does not decide if a disclosure is legally permitted, produce a patient accounting, cover vendor-native inference or replace EHR audit controls. Book a demo today.