AI Agent Audit Trail in Healthcare: What You Must Log and Keep

A patient calls in September and asks who texted her in March about a follow-up she never booked. Your front desk opens the chart, finds the message, and finds no name attached to it. The record says the system sent it. That is not an answer you can give a patient, an attorney, or a federal investigator.

The HIPAA Security Rule has no category for software that acts on its own. Its audit controls standard at 45 CFR 164.312(b) is Required, with no addressable escape hatch, and a separate Required implementation specification at 45 CFR 164.308(a)(1)(ii)(D) tells you to actually review what you recorded. In January 2025 a business associate settled with the Office for Civil Rights for $337,750 after a breach affecting 2,903 people, and one cited failure was not reviewing records of system activity.

This post covers what an AI agent action log has to contain, why the agent needs its own credential instead of borrowing a staff login, why a recording and a transcript and a summary are three separate problems, where patient details leak into tools never built to hold them, and what you should be able to hand over when someone asks.

Why "the AI did it" is not an answer you can give

HIPAA does not care that software took the action. It cares whether you can reconstruct it. The Security Rule requires audit controls that record and examine activity in systems holding electronic patient information, and it separately requires you to review those records. An unattributed action fails both tests at once.

Read the two provisions side by side. Audit controls at 45 CFR 164.312(b) is a standard, not an optional practice: implement mechanisms that record and examine activity in systems that contain or use electronic protected health information. Information system activity review at 45 CFR 164.308(a)(1)(ii)(D) is a Required implementation specification: review those records regularly. Recording without reviewing satisfies neither.

Regulators enforce the second half. The USR Holdings settlement in January 2025 cited a failure to implement procedures for reviewing system activity records alongside the more familiar risk-analysis findings. The logs were not the problem. Nobody looking at them was.

The question you face months later is never whether the agent gave good advice. A well-built agent gives no clinical advice at all and routes anything urgent to a person. The question is narrower: what happened, to whom, on whose authority, and can you show it. If you have not drawn that boundary yet, start with what an AI receptionist does and where it stops, because you cannot log a limit you never set.

What one agent action line has to contain

Six fields answer almost every question you will face later: what happened, when, where, what triggered it, how it ended, and who or what did it. For an agent, add two more no standard guidance anticipated: the instruction set it was running, and the permissions it held at that moment.

Six fields come from standard audit guidance. The last two exist only because the actor is software.

The first six come from NIST SP 800-53, control AU-3, which is specific in exactly the places HIPAA is deliberately vague. HIPAA tells you to have audit controls and leaves the contents to you. AU-3 tells you an audit record should establish the type of event, when it occurred, where it occurred, the source of the event, the outcome, and the identity of any individuals, subjects, or objects associated with it.

The two extra fields exist because an agent is not a person. A staff member's behavior changes when you retrain them, which is slow and visible. An agent's behavior changes when someone edits a prompt or a rule, which takes 30 seconds and leaves no deployment trace. If your log says the agent sent a recall text but not which version of its instructions produced that text, you can describe the outcome and not the cause.

Permissions are the same story. A receptionist's access comes from their role. An agent's access is configured field by field, and it drifts as people add capabilities. Recording the scope in force at the time of the action is the only way to answer whether the agent was allowed to do what it did.

"On whose behalf" deserves its own field. An agent texting a patient is acting for a provider or a location, and both the agent and the principal belong in the record. A log that names only one of them answers half the question.

Give every agent its own identity and its own credential

Unique user identification at 45 CFR 164.312(a)(2)(i) is a Required implementation specification: assign a unique name or number for identifying and tracking user identity. An agent operating through a staff member's login defeats that quietly, because the log looks complete. It names a real person. It just names the wrong one.

The difference shows up on the day you need to answer a question or cut off access.

Two things break, and both break on the day they matter most. Attribution breaks first: your activity report credits 400 overnight messages to a front desk coordinator who was asleep, and every review of that person's access is now noise. Revocation breaks second: cutting off the agent means disabling a login a working employee needs, so nobody does it, and the agent keeps its access through the incident you are trying to contain.

The scale of this is not theoretical. The 2026 Identity Security Landscape, a survey of 2,930 IT and security leaders, reports machine identities outnumbering human identities by 109 to 1. That is a vendor survey and a broad one, so treat it as direction rather than a benchmark for your practice. The direction is clear enough: non-human actors are multiplying faster than anyone's process for naming them.

Ask for three things: a credential that belongs to the agent, a scope limited to what the agent actually does, and the ability to revoke that one credential in under 5 minutes without touching anyone's account.

A recording, a transcript, and a summary are three different artifacts

One patient call produces three records with three risk profiles. Audio carries tone, distress, and whoever else was in the room. A transcript is searchable and easy to over-share. A summary is the agent's own reading, so it can be wrong where the source is not. One retention rule cannot serve three.

Retention is where practices get this backwards. The 6 year clock at 45 CFR 164.316(b)(2)(i) applies to the documentation the Security Rule requires you to keep, not to your call audio. How long you hold a recording comes from your state's medical record rules, your payer contracts, and your own written policy, so confirm that one with counsel rather than with a vendor.

The third artifact deserves extra care. Under 45 CFR 164.501, a designated record set includes anything used to make decisions about an individual. If an agent's summary is what a scheduler read before moving an appointment, it is not scratch data. Whether you may record the call at all is a separate question from how long you keep it, and it varies by state; we cover that in call recording consent laws.

Keep patient details out of systems never built to hold them

The leak is almost never the AI itself. It is the debugging scaffolding around it: a generic application log, an error tracker, a monitoring service, an analytics script. These tools will happily accept a phone number, a date of birth, and a reason for visit, because nobody told them not to.

Four published figures, each with a source. Verify before repeating any of them.

Vendor terms are more specific than most people expect. Datadog publishes exactly 2 HIPAA-eligible services, Cloud SIEM and Log Management, plus 31 further services it lists as extended eligible. Everything else may be used only if it does not process patient information. Signing their agreement also turns off conveniences engineers use daily, including live chat support and sharing logs from the explorer view.

Web tracking is its own trap with a real legal wrinkle. On 20 June 2024, a federal court in the Northern District of Texas vacated part of the Office for Civil Rights bulletin on tracking technologies in American Hospital Association v. Becerra, and HHS withdrew its appeal that August. What was struck applied to unauthenticated public pages. The rest of the bulletin stands, and anything behind a patient login was never in question.

The practical move is a written list of every system that can see a patient detail, checked against your signed agreements. Anything on the first list and missing from the second gets fixed or gets cut off. The wider vendor question is covered in what a signed agreement does not tell you.

What you should be able to produce on request

Two different requests get confused constantly. A records request under 45 CFR 164.524 covers the designated record set and must be acted on within 30 days. An accounting of disclosures under 45 CFR 164.528 looks back 6 years and must be answered within 60 days. They cover different ground.

Both allow one written extension of up to 30 days, which sounds generous until you try to assemble the answer. Here is the nuance that matters more: the accounting requirement excludes disclosures made to carry out treatment, payment, and health care operations. So a patient asking who texted her about her own appointment is usually not making a formal accounting request at all.

Declining to answer on that technicality is the wrong instinct. She is asking an operational question a competent practice should answer in minutes. Build for the plain question: for any single patient, produce every automated contact in a date range, showing which agent, acting for which provider, on which channel, at what time, why it fired, and what changed afterward.

Field note

Before an agent gets access to patient records

• The agent has its own credential and its own name in the log, separate from any staff account.
• Each action records the instruction version and the permissions in force at that moment.
• Recordings, transcripts, and summaries each have a written retention period and a named owner.
• Someone can reconstruct one patient's full contact history well inside the 30 day access window.

Run that as a drill, not a policy. Pick one real patient from last month and reconstruct every automated contact end to end. An afternoon is a reasonable budget. If it takes longer with your own records and your own staff helping, it will not go better under a subpoena.

Settle these questions before an agent touches a patient record

Four questions decide whether your agent is auditable, and all four are cheaper before go-live than after a complaint. Does the agent hold its own credential? Does every action record the actor, instructions, and permissions? Does each artifact have its own retention? Can you prove nothing leaks to an unsigned tool?

Four questions, asked before go-live. Every agent action ends with a name and a reason.

Put the export question to your vendor in writing before you sign. Can you export the full action log, in what format, how far back does it reach, and does the export name the agent separately from any staff user? A vendor who answers those four in a paragraph has been asked before.

None of this makes an agent riskier than the front desk it supports. A receptionist who takes a message on a sticky note leaves no audit trail at all. The difference is that software can be made to log properly, and once patients start asking who contacted them, "we do not know" stops being survivable. If you want the leak sized first, the free Growth Leak Audit works from your own numbers.