HIPAA retention requirements for AI prompt and tool-call logs in health systems

What the Security Rule states, and what it leaves open

Several provisions bear on AI records, and each does a different job. Section 164.308 includes a required implementation specification, information system activity review. It requires procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports. Section 164.312(b) is the technical safeguard for audit controls. Section 164.308(a)(1) defines the parameters of the security risk analysis. Section 164.308(a)(8) requires a periodic technical and nontechnical evaluation, performed initially against the implemented standards and afterward in response to environmental or operational changes affecting ePHI security.

Section 164.316(a) requires reasonable and appropriate policies and procedures, taking into account the factors in 164.306(b)(2)(i) to (iv). Section 164.316(b) governs documentation retention. The six-year period is stated expressly in 164.105(c)(2) and 164.530(j)(2): documentation must be kept for six years from creation or from the date it was last in effect, whichever is later.

That is the explicit text. What it does not do is assign a retention period to current system activity logs, or say whether AI prompt, response and tool-call records fall within the activity review specification. Those are interpretive decisions for the covered entity, supported by risk analysis and written policy. HHS has stated, in the preamble to its January 2025 proposed Security Rule, that ePHI in AI training data, prediction models and algorithm data maintained for covered functions is protected by the HIPAA Rules. Prompts and responses that contain PHI warrant the same safeguards as other ePHI.

The 2025 proposal: relevant, but not in force

The proposed rule, published January 6, 2025, would add a requirement at proposed 164.308(a)(7)(ii)(D) to retain records of activity in relevant electronic information systems. It lists audit trails, event logs, firewall logs, system logs, data backup logs, access reports, anti-malware logs and security incident tracking reports as examples. It also states that documentation must be retained for the later of six years from creation or the date last effective, and that review frequency may vary with the record type and the information it contains.

As of November 2026 this is proposed text only. Do not describe it as a current obligation. It is still useful as a planning signal. It points toward differentiated treatment by record type, and a six-year reference point is a reasonable starting position for evidence records if your policy documents why.

Classify AI records by purpose before assigning a period

A single retention number for everything an AI system produces will usually be wrong in one direction. Too short, and you cannot support activity review or show what happened. Too long, and you hold PHI-bearing prompts beyond any need. Classifying by purpose lets each category carry its own period and rationale.

• Audit-control evidence: Identity, timestamp, action, target system and policy decision. Supports activity review under 164.308 and audit controls under 164.312(b). The period is a policy decision informed by risk analysis; six years is a defensible reference point but not a stated rule for activity logs today.
• Policy documentation: AI use policies, retention rationale, risk analysis outputs, evaluation records and records of policy rule versions. The six-year documentation measure applies where the record qualifies as required documentation.
• PHI-bearing content: Prompt text, model responses and tool-call arguments containing PHI. This is ePHI. Minimize it, protect it, and keep it only as long as a documented purpose requires.
• Clinical record content: AI output that is filed into the medical record. Retention follows state medical record law and organizational policy for that record, independent of any log.

Setting and documenting retention periods

Start with an inventory of every record an AI deployment creates: prompts, responses, tool-call requests and results, policy decisions, approvals and errors. Map each to a purpose from the table above. Where a record serves more than one purpose, split it. The common case is an interaction record that holds both an evidence trail and PHI-bearing text. Separating who, what, when and decision from the content lets the evidence outlive the content.

Then set a period for each category and write down the reasoning. Record the factors you weighed under 164.316(a): the risk analysis findings, how often the records are reviewed, state medical record law, organizational policy, and the exposure created by holding PHI. State why a record is treated as documentation rather than as an activity log, because no rule settles that question for you.

The tradeoff is real. Longer retention of PHI-bearing content widens the set of data exposed in a breach and increases what must be protected and, in some cases, produced. Shorter retention can weaken your ability to reconstruct events. Redacting PHI before storage reduces that tension, because the evidence record can be kept longer while the sensitive content is kept shorter or not at all. Whether a given redaction approach is sufficient is a risk analysis question you should answer for your own data.

Finally, assign an owner for regular review of AI activity records, define review frequency by record type, and revisit the retention decisions through the 164.308(a)(8) evaluation whenever models, tools or workflows change. Document deletion at expiry as well, so you can show that the policy was applied. This is operational guidance and not legal advice; have counsel confirm state law obligations.

Applying the periods with runtime enforcement

Retention periods are easier to apply when the evidence is produced at the point of the interaction instead of reconstructed later. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and human-approval outcomes for individual interactions and tool calls. Because enforcement happens at runtime, PHI can be redacted before content is stored, and each decision generates audit-ready evidence mapped to HIPAA.

Trussed deploys self-managed in the customer's cloud, with configurable retention and data residency, so the periods your policy sets are applied inside your own environment. Trussed runs in production with healthcare and pharma organizations. It does not decide your classification or your retention periods. Those remain your documented decisions.