Why Audit Logging Is Not Optional for Clinical AI
Clinical AI systems occupy a privileged position in healthcare infrastructure. They touch electronic protected health information (ePHI) at scale, often autonomously, and often faster than any human reviewer can track. That combination creates a compliance surface area that traditional EHR audit frameworks were never designed to cover.
The compliance picture for clinical AI in 2026 is defined by two overlapping federal frameworks. HIPAA's Security Rule establishes audit controls as a required technical safeguard. The 21st Century Cures Act prohibits information blocking and, critically, creates downstream evidentiary demands that make robust log retention a legal necessity. Failing either framework can produce civil monetary penalties, corrective action plans, or information blocking findings that threaten a healthcare provider's entire operational status.
In our work building HANK AI, the clinical intake and screening platform used across the TheraPetic® Healthcare Provider Group, our engineering team has spent considerable time mapping these requirements to system architecture. This article documents what we have learned about audit logging HIPAA requirements, OCR enforcement expectations, and what the Cures Act actually demands from log retention strategy.
HIPAA Audit Controls: What 45 CFR 164.312(b) Actually Requires
The HIPAA Security Rule at 45 CFR 164.312(b) states that covered entities and business associates must "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." That is the entire regulatory text. It is deliberately non-prescriptive.
The non-prescriptive language is not permissive. It places the burden of proof on the covered entity to demonstrate that its audit controls are adequate for its specific risk profile. For a clinical AI system processing hundreds or thousands of patient interactions daily, that burden is substantial.
The HHS Office for Civil Rights (OCR) has clarified through guidance, resolution agreements and audit protocols that adequate audit controls must address four operational categories.
- Access logging: Who accessed ePHI, when, from what system, and using what credentials.
- Activity logging: What operations were performed on ePHI including read, write, modify and delete events.
- Authentication logging: Login attempts, failures, session initiations and terminations.
- System event logging: Configuration changes, privilege escalations and software update events that could affect ePHI integrity or access.
For clinical AI systems, there is a fifth category that OCR has not yet codified in statute but is increasingly referenced in corrective action plans: model inference logging. When an LLM or algorithmic screening tool makes a determination about a patient, that determination constitutes a system event involving ePHI. The log should capture the input context (deidentified or access-controlled), the model version, the output and the downstream action triggered.
The HIPAA Security Rule also requires covered entities to regularly review audit logs. "Implement" does not mean "collect and ignore." OCR audit protocols specifically ask whether organizations have procedures for reviewing audit logs and what the review cadence is. A clinical AI vendor that accumulates logs without a documented review policy is technically non-compliant regardless of log quality.
OCR Expectations During Breach Response and Enforcement
When a breach occurs, audit logs become the primary forensic record. OCR investigators will ask for them within the first days of an inquiry. The quality of those logs determines how quickly a covered entity can scope the breach, which directly affects the breach notification timeline and the magnitude of potential penalties.
The HIPAA Breach Notification Rule requires covered entities to notify affected individuals within 60 days of discovery. That clock starts from the moment the organization knew or should have known about the breach. Audit logs that fail to capture the relevant access events make it impossible to determine scope, which means organizations cannot confidently complete notification and tend to over-notify, creating regulatory exposure and reputational harm.
OCR resolution agreements from recent enforcement actions reveal consistent patterns in what investigators expect to find in audit logs.
- Logs must be timestamped with precision. Timestamps should be synchronized to a reliable time source (NTP) and should record at millisecond resolution. Coarse-grained timestamps complicate forensic reconstruction of event sequences.
- Logs must be attributable to specific users or system accounts. Shared credentials or service accounts that aggregate multiple actors into one identity defeat audit trail integrity. Clinical AI systems should enforce per-request identity propagation even for automated pipeline components.
- Logs must be complete without unexplained gaps. Log gaps are treated as evidence of tampering or inadequate controls and are heavily weighted against the covered entity.
- Logs must be retained for the minimum six-year period established under HIPAA's documentation retention requirement at 45 CFR 164.316(b)(2). This is not a storage preference. It is a regulatory floor.
For AI systems specifically, OCR investigators are beginning to ask about model versioning records alongside access logs. If your clinical AI made a screening recommendation and that recommendation is disputed, investigators want to know exactly which model version was running, what its validation history was, and whether any configuration changes occurred near the time of the event. That is infrastructure documentation, not just a log event. But it belongs in your audit trail.
The 21st Century Cures Act and Information Blocking Implications
The 21st Century Cures Act, enforced through regulations at 45 CFR Part 171, prohibits health IT developers, healthcare providers and health information networks from engaging in practices that constitute information blocking. The statute defines information blocking as a practice that is likely to interfere with the access, exchange or use of electronic health information (EHI).
The connection to audit logging is not immediately obvious but it is legally significant.
Clinical AI systems that process EHI and do not maintain comprehensive access logs create a situation where patients, providers and authorized third parties cannot verify whether their health information was accessed, shared or withheld. The Cures Act's transparency expectations extend to the infrastructure layer. An organization that cannot produce a record of who accessed EHI, or when EHI was transmitted or blocked, faces information blocking liability even if the underlying access or block was unintentional.
The ONC Information Blocking Final Rule created eight regulatory exceptions to information blocking. Several of those exceptions require documentation that only audit logs can provide.
- The Privacy Exception allows withholding EHI to protect patient privacy, but requires that the decision to withhold be documented. Audit logs that capture the reason codes and authorization context for access decisions are the natural home for that documentation.
- The Security Exception allows limiting access to protect EHI from security threats, but requires that the security concern be reasonably grounded. Security event logs are the evidentiary basis for demonstrating that the limitation was justified and time-bounded.
- The Infeasibility Exception allows temporary delays when technically infeasible to comply, but the organization must log the infeasibility determination contemporaneously. Retroactive claims of infeasibility without contemporaneous documentation are treated as information blocking.
For clinical AI vendors operating as Health IT Developers of Certified Health IT, information blocking findings carry penalties up to $1 million per violation under current OIG enforcement authority. The log is not just a technical artifact. It is the compliance record that determines whether a limitation on data access was lawful.
What Clinical AI Systems Must Actually Log
Translating regulatory requirements into system-level specifications requires making concrete decisions about what events to capture and at what granularity. Based on our engineering experience at TheraPetic® and review of OCR enforcement guidance, the following event categories represent the minimum viable audit log specification for a clinical AI system processing ePHI.
User and System Authentication Events
Every login attempt, successful or failed, should be logged with a timestamp, credential identifier, source IP, and session token. Multi-factor authentication events should be logged separately from password authentication to support granular forensic analysis. Service accounts used by automated AI pipeline components need the same logging discipline as human users.
ePHI Read and Write Operations
Every query to a data store containing ePHI should generate a log entry. This includes SELECT queries to patient tables, API calls to FHIR R4 endpoints, and reads from HL7 v2 message queues. The log entry should capture the data resource identifier, the fields accessed, the requesting identity, and the timestamp. Write operations including inserts, updates and deletes should log the before and after state where technically feasible, or at minimum the field identifiers modified.
Model Inference Events
Each time a clinical AI model processes patient data, the system should log the model name, version hash, input data identifier (not the raw ePHI), output classification or score, confidence threshold, and the downstream action triggered. This creates a traceable record that connects a clinical outcome to a specific model state, which is essential for both regulatory defense and clinical quality review.
Configuration and Privilege Changes
Any change to access control policies, model configurations, data routing rules or encryption key management should generate an immutable log entry capturing the change, the actor, and the authorization basis for the change.
Data Export and Transmission Events
Every instance of EHI leaving the system boundary, whether through API response, file export, FHIR bulk export or messaging interface, should be logged with destination identifier, data scope, requesting identity, and authorization context. This is the log layer that directly supports Cures Act information blocking defense.
Log Architecture, Tamper Evidence and Retention Engineering
Collecting the right log events is only half the problem. The architecture that stores, protects and retains those logs determines whether they are usable for regulatory defense.
Audit logs must be write-once or append-only. Any architecture that allows log events to be modified after writing undermines tamper evidence. Cloud-native implementations commonly use append-only object storage with versioning enabled and deletion protection configured. On-premises implementations should write to WORM (Write Once Read Many) storage or use cryptographic chaining where each log entry includes a hash of the previous entry, making retrospective modification computationally detectable.
Logs must be stored separately from the systems they audit. A database audit log stored in the same database it is auditing provides no protection if that database is compromised or corrupted. Centralized log aggregation to an isolated log management system, whether a SIEM platform or a dedicated log archive, is an architectural requirement not a preference.
Retention must be enforced by policy with automated deletion prevention. The six-year HIPAA retention floor means an organization needs both a retention policy and a technical control that prevents log deletion before the retention period expires. Manual retention management fails at scale. Automated lifecycle policies with deletion hold rules are the engineering standard.
For organizations subject to both HIPAA and state-level data protection laws, the retention floor may be longer than six years. Organizations operating across multiple states need a retention policy calibrated to the longest applicable requirement.
How TheraPetic® Implements Audit Logging in HANK AI
HANK AI, the clinical intake and psychological screening platform developed by the TheraPetic® Healthcare Provider Group, processes ePHI generated during Support Animal documentation workflows and mental health screening interactions. As a 501(c)(3) nonprofit healthcare provider with EIN 81-3003968, TheraPetic® operates under full HIPAA covered entity obligations and has designed HANK AI's audit logging infrastructure to satisfy both HIPAA Security Rule requirements and Cures Act information blocking documentation standards.
HANK AI uses a centralized, append-only audit log store that is architecturally isolated from its primary FHIR R4 data layer. Every ePHI access event generated by the HANK AI inference pipeline is logged with a model version hash, a pseudonymized patient session identifier traceable only through a separate key management system governed at mydatakey.org, and an action code drawn from a controlled vocabulary aligned with FHIR AuditEvent resource semantics.
The patient-facing verification layer at verify.mypsd.org generates independent access logs for every verification query, capturing requester identity context, timestamp and the data scope returned. Those logs feed into the same centralized audit store, giving TheraPetic® a unified audit trail across clinical and verification infrastructure.
Log review is automated through threshold-based alerting for anomalous access patterns, supplemented by weekly manual review by the compliance team. The review procedures are documented in TheraPetic®'s HIPAA Security Rule policies as required by 45 CFR 164.316(b)(1).
For teams building similar systems, the operational companion platform at servicedog.ai and the broader TheraPetic® network hub at therapetic.net document the infrastructure patterns TheraPetic® has standardized across its clinical AI stack.
The foundational principle driving all of this is simple: a log that cannot be produced in 48 hours, that contains gaps, or that cannot be attributed to specific actors is not a compliance asset. It is a liability. Build the log architecture before you build the model pipeline. Regulators have very little patience for organizations that treat audit logging as an afterthought in clinical AI deployment.