What audit records does OCR request first after an AI incident?

OCR typically opens with a request for the access logs, the audit logs, the risk analysis, and the policies and procedures relevant to the incident. For AI incidents, the audit log request asks for the records of AI requests during the relevant period that involved PHI. The covered entity has 30 days under the audit program timeline to produce the records. Inability to produce the records is itself a finding, separate from the underlying disclosure.

How long should AI audit records be retained?

HIPAA documentation retention under 45 CFR § 164.530(j)(2) is six years from the date of creation. AI audit records should follow the same retention. Some state laws extend the period to seven years past the last patient encounter. The operational standard most covered entities adopt is seven years to cover the longer state requirements and to align with the EU AI Act Article 19 retention floor for healthcare deployments serving EU patients.

Do we need to record the AI response, not just the prompt?

Yes. Model responses can contain PHI that the model inferred from context, completed from partial data in the prompt, or surfaced from its training corpus. An audit trail that captures the prompt but not the response misses the second half of the disclosure. A complete record contains the prompt, the response, the decision outcome, and a tamper-evident hash of both. The hash allows a reviewer to confirm later that the displayed records match what was originally written.

What is the difference between an audit log and an accounting of disclosures?

The audit log under the Security Rule records activity in systems that contain PHI. The accounting of disclosures under 45 CFR § 164.528 lists disclosures of PHI to third parties that the patient is entitled to receive on request. The audit log is operational evidence for the covered entity's own use. The accounting is patient-facing. Both can be generated from the same underlying record set if the record format captures the data each requires.

How do we audit AI usage we cannot see, like embedded AI in SaaS tools?

Embedded AI in SaaS tools is the case where the covered entity has the lowest visibility and the highest residual risk. The audit trail starts with the SaaS vendor's logs. The covered entity should require, in the BAA, that the vendor produce per-disclosure audit records on request. Without that contractual right, the audit obligation becomes structurally unmeetable. Procurement contracts with AI-using SaaS vendors need to specify the record format, the retention, and the response time for record requests during an incident.

HIPAA AI Audit Trail: What Records OCR Asks For After an AI Incident

The HIPAA Security Rule at 45 CFR § 164.312(b) requires covered entities and business associates to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." For AI deployments, the activity that matters is the prompt submission and the response. The application logs that most teams point to as their HIPAA audit trail rarely contain prompt content, identity context, or PHI classification. HHS Office for Civil Rights audits ask for the operational records that prove the safeguard was running at the moment of disclosure.

I want to walk through what OCR actually asks for after an AI-related incident, where the typical evidence falls short, and what an audit-grade record looks like at the prompt layer.

What OCR asks for after an incident

The HIPAA Audit Program and the post-incident investigation process focus on documentation of safeguards in operation. An incident triggers an OCR request for the records that demonstrate the covered entity's controls were running and effective during the relevant period.

For AI incidents, the typical request covers four items. First, the access controls that authorized the workforce member or agent to interact with the AI system, mapped to the workforce member's role. Second, the audit controls that recorded the activity at the prompt and response layer. Third, the integrity controls that prevented post-hoc modification of the records. Fourth, the transmission security controls that protected the prompt and response in transit to the AI service.

OCR's 2016-17 audit findings reported that 86% of audited covered entities failed to provide complete documentation of risk analysis under 45 CFR § 164.308(a)(1)(ii)(A) and 67% failed to provide complete documentation of risk management under 45 CFR § 164.308(a)(1)(ii)(B). The same documentation failures appear in AI incidents because the underlying controls are absent.

Where application logs fall short

Most enterprise AI deployments rely on the calling application to write audit records. The application records a request was processed, the duration of the inference, the response status code, and sometimes the prompt length. Four common failure modes hit this pattern.

The application logs lack identity context at the workforce-member level. The credential used to call the AI service is a service principal or an API key issued to the application. The natural person who initiated the workflow does not appear in the log. OCR cannot trace which workforce member disclosed PHI.

The application logs lack data classification. The application records that a prompt was submitted. The application does not record whether the prompt contained PHI, what categories of PHI appeared, or what redaction was applied. OCR cannot determine whether the disclosure was within the authorized scope.

The application logs are mutable. The application that records the disclosure also operates the database where the log lives. Modification, rotation, or deletion happens through the same access path the application uses. OCR cannot rely on the record as an immutable witness.

The application logs miss the response. PHI sometimes appears in model responses through inference or context-window leakage. An application log that captures the request but not the response misses half the disclosure.

What the audit-grade record looks like

The records that survive OCR review have a consistent format. Per AI request, the record contains: the timestamp at sub-second precision, the workforce member identity verified through the covered entity's identity provider, the workforce role and authorization scope at the moment of the request, the patient identifier if disclosure was authorized, the PHI classification of the prompt content, the AI vendor and model selected, the policy version that governed the decision, the decision outcome (allow, redact, block), and a tamper-evident hash of the prompt and response.

The record is committed to storage independent of the application that made the request. The storage layer enforces append-only semantics with a write-once retention policy. Retrieval is by identity, time range, patient identifier, or policy version. The record is signed at the moment of creation, which lets a reviewer detect later modification.

The HHS audit protocol checks for the existence of these audit controls under 45 CFR § 164.312(b) and for the procedures that govern review of the records under 45 CFR § 164.308(a)(1)(ii)(D). The covered entity must demonstrate both the recording and the periodic review.

Retention and what the law requires

The HIPAA Security Rule does not specify a fixed retention period for audit logs. The Privacy Rule at 45 CFR § 164.530(j)(2) requires the covered entity to retain documentation of its required actions, activities, or assessments for six years from the date of creation or the date when it was last in effect, whichever is later.

For AI usage records, the operational standard most covered entities adopt is six years of retention to align with the accounting-of-disclosures retention. State law sometimes extends the period. Texas requires medical records retention of seven years past the last patient encounter. New York requires six years from the date of discharge. The applicable retention period is the longer of the federal floor and the state requirement.

The retention applies to the records, not just to their availability for routine queries. The storage layer should support efficient retrieval across the full retention window without requiring restore from cold storage for routine OCR responses.

The incident response timeline

The HIPAA Breach Notification Rule at 45 CFR § 164.404 requires notification of affected individuals within 60 days of discovery of a breach of unsecured PHI. The covered entity must also notify HHS through the breach reporting portal. Breaches affecting 500 or more individuals require notification to HHS without unreasonable delay and to prominent media outlets in the affected state or jurisdiction.

The 60-day clock runs from discovery. For AI incidents, discovery is often delayed because the covered entity has no operational signal that the disclosure occurred. A workforce member pastes PHI into ChatGPT consumer. The application has no record. The IT team has no alert. Months later, a vendor publishes a blog post about how they detected and contained leaked PHI from a customer's prompts. Discovery is the day of the blog post, not the day of the disclosure.

A working audit trail at the AI request boundary shortens the discovery interval to seconds. The record exists from the moment the disclosure happens. The detection runs against the record stream in near real time.

Connecting the audit trail to the rest of the safeguards

The audit trail is one of nine technical safeguards required under the HIPAA Security Rule's administrative simplification structure. The trail interacts with access controls under § 164.312(a), integrity under § 164.312(c), person or entity authentication under § 164.312(d), and transmission security under § 164.312(e).

A defensible AI deployment ties the safeguards together at the request layer. Authentication verifies the workforce member. Access control evaluates the role against the policy for the data category. The audit trail records the decision. Integrity controls sign the record. Transmission security covers the channel to the AI vendor.

Implementing these safeguards across nine separately-owned applications produces nine partial implementations. Implementing them at a single enforcement layer produces one consistent control surface that operates per request.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated workforce members or agents and any LLM endpoint. Authentication, role evaluation, PHI classification, vendor selection, and decision enforcement happen inline for every request. Every decision produces a signed audit record containing identity, role, classification, vendor selected, policy version, decision outcome, and timestamp.

The records are committed to append-only storage before the response returns to the application. The storage layer supports retention configurable up to the seven-year operational standard. Retrieval by identity, time range, patient identifier, policy version, or vendor takes seconds, which is what OCR expects when it sends the request after an incident.

If you are operating AI in a HIPAA-regulated environment and your audit trail depends on application logs that the application controls, the trail collapses under OCR review. Book a demo today.