HIPAA Integrity Controls for AI-Generated EHR Content

What the Security Rule requires at the write-back step

Two technical safeguards apply directly. The integrity standard, 45 CFR 164.312(c)(1), requires policies and procedures to protect ePHI from improper alteration or destruction. The audit controls standard, 164.312(b), requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit controls are a required specification. The integrity standard includes an addressable specification, a mechanism to authenticate ePHI, and the rule also contains an addressable transmission-security specification: measures to ensure that transmitted ePHI is not improperly modified without detection until disposed of.

Both standards are technology-neutral, and neither mentions AI. As of November 2026, eCFR shows no changes to 164.312 after January 3, 2017. A January 2025 HHS proposed rule would clarify that ePHI in AI training data, prediction models, and algorithm data held by a regulated entity for covered functions is protected by the HIPAA Rules. It is a signal of direction, so the control mapping in this guide is anchored to the current 164.312 text.

The practical consequence is that every AI write-back creates or alters ePHI. The word "improper" in the integrity standard means you must define, in advance, what a proper AI write looks like: which record types, which fields, which content, and under whose approval. Without that definition, there is nothing to enforce and nothing to examine later.

Allow, redact, block, escalate: defining a proper write

Each outcome needs an explicit rule, or engineers will improvise it per integration.

Allow applies to writes that match a permitted pattern, for example a draft that stays within its permitted record type and contains only the PHI that record legitimately holds. Redact applies when content is mostly acceptable but includes PHI that does not belong in the target field or note; the redacted version is written and the original is not. Block applies to writes outside scope, such as an unpermitted record type or an attempt to overwrite or delete existing entries. Escalate applies to writes you have classified as high risk, where a human must review the content before it is committed.

Which write types need approval is a policy decision, not a technical default. ONC SAFER guidance supports the principle: AI-generated recommendations should be reviewed and approved by humans who take responsibility for them. Orders and coded data are natural candidates for escalation, and low-risk drafts may be allowed with attribution. The tradeoff is clinician workload against exposure, so tune the escalation criteria by write type and risk, and revisit them as you see real decisions.

Runtime enforcement versus after-the-fact review

Review after the fact can show that an improper write occurred. It cannot prevent it. The integrity standard is framed around protecting ePHI from improper alteration, and a policy that is only checked afterward leaves a window in which the record is already wrong and possibly already relied upon. Enforcement at runtime closes that window, because the policy decision happens before the write and the evidence is a by-product of enforcement rather than a separate reconstruction effort.

Trussed enforces policy in the execution path for individual interactions and tool calls, with outcomes of allow, redact, block, rate limit, and escalate for human approval. That enforcement generates audit-ready evidence mapped to HIPAA. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, and it runs in production with healthcare and pharma organizations. It does not replace the surrounding program, and it is scoped to interactions and tool calls, not whole workflows.

Governance work still sits around the control. Name the accountable human for AI-generated content. Under SAFER Guide 5, organizations should have policies so that patients and clinicians are aware, when possible, that AI is in use. Test write-back controls before go-live and in production for data integrity. Document your rationale for the addressable specifications, and keep security documentation current as write-back capabilities change, consistent with the maintenance provision at 164.306(e). Components that handle drafts, prompts, or outputs containing PHI belong in your Security Rule analysis.