HIPAA Four-Factor Breach Risk Assessment for an AI Prompt Incident: Evidence to Pull

Treat the assessment as an evidentiary exercise

Under 45 CFR 164.402, a breach is the acquisition, access, use or disclosure of PHI in a manner not permitted under subpart E that compromises the security or privacy of the PHI. An impermissible acquisition, access, use or disclosure is presumed to be a breach unless the covered entity or business associate demonstrates a low probability that the PHI has been compromised, based on a risk assessment of at least the listed factors. As of November 2026, the current regulation text contains that presumption.

The burden sits with the entity. Subpart D says that when a use or disclosure violates subpart E, the covered entity or business associate must demonstrate that all required notifications were made or that the event was not a breach. For an AI prompt incident, this means a missing artifact is not neutral. It leaves the presumption standing, and the practical choices become reporting without a basis for doing so or holding a determination you cannot support.

HHS has described breach analysis as fact-specific, for example in its Change Healthcare guidance on ransomware. The same applies here. No blanket rule says every AI prompt incident is a breach or that none is. Each determination depends on what the records show about that event.

Factors one and two: what was exposed, and to whom

Factor one concerns the nature and extent of the PHI. The core artifacts are the prompt content and the response content, because the response can echo or expand on what was submitted. Alongside them, pull an identifier inventory: which of the individual's identifiers appeared, how many individuals are affected, and whether clinical or financial detail accompanied them. Attachments and pasted documents count as part of the prompt. In practice, this content typically lives in application logs, an AI gateway or proxy store, browser or endpoint telemetry, or the vendor's conversation history. If none of these holds the prompt text, you cannot size the exposure, and the assessment has to assume the broader case.

Factor two concerns the unauthorized person who used the PHI or to whom it was disclosed. For an AI incident, that translates into the destination model or tool, the operator behind it, and the terms that govern the data. Collect the contract or business associate agreement, if one exists, and the recipient's documented data-use, retention and training terms. Also collect the identity of the workforce member or application that sent the prompt, tied to an authenticated account rather than a shared credential. An unattributed user and an unclear vendor retention term are the two gaps that most directly weaken this factor, because you cannot describe the recipient or what it may do with the data.

Factors three and four: was it acquired, and what was done

Factor three asks whether the PHI was actually acquired or viewed. The evidence here is a factual record of what left your boundary. Pull the transmission record showing whether the prompt reached the external model, the policy decision applied to it (allowed, redacted, blocked or escalated), and any record of the recipient's side, such as whether a human could access the conversation. This factor is where the distinction between a prompt that never left and one that reached an external model becomes concrete. It should be answered from records, not from recollection.

Factor four is the extent to which the risk to the PHI has been mitigated. Collect remediation evidence in a form that can be dated and attributed: deletion requests submitted to the recipient, written confirmations or attestations of deletion, account or access changes, and workforce follow-up. A deletion request with no response is weaker than a signed confirmation, and an undated note is weaker than a ticket with a timestamp and an owner. Finally, record the assessment itself: the facts relied on, the conclusion, and who signed off.

How the record differs by incident type

The facts you can establish depend on where the prompt stopped. The table below summarizes how the record typically changes. The effect on any determination is analysis for your privacy officer and counsel, not a regulatory rule.

• Blocked before leaving the boundary: Evidence needed: the block decision, the rule applied, the user and the original content as held internally. Factor three turns on showing nothing was transmitted.
• Redacted before leaving the boundary: Evidence needed: the redaction record and what the outbound prompt contained. Factors one and three depend on showing which identifiers were removed and which, if any, remained.
• Allowed to an external model: Evidence needed: full prompt and response, recipient terms, user identity and mitigation record. All four factors rely on this evidence, and factor four carries more weight.
• Escalated for human approval: Evidence needed: the approver, the decision, the timestamp and the content reviewed. The record shows who allowed or stopped the transmission.

Where runtime enforcement changes the record

Reviewing AI activity after the fact means reconstructing events from whatever logs happen to exist. Enforcing policy at runtime, in the execution path, changes that. Each interaction passes through a decision point, and each decision (allow, redact, block, or escalate for human approval) can generate a record as part of the action itself. That record speaks directly to factors one through three: what the content was, who sent it, where it was going, and whether it was transmitted. This is a design principle, and the quality of the evidence depends on how the enforcement is configured.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. The audit-ready evidence generated by enforcement is mapped to HIPAA, including 164.312(b) audit controls. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, so organizations can decide where evidence is held and for how long. As a recommendation, set retention so that evidence remains available for the full period during which you may need to support a determination. Trussed runs in production with healthcare and pharma organizations.

Enforcement does not replace the assessment. Factor two terms, factor four mitigation and the final sign-off still need human work. What it provides is a dependable factual record for the first three factors.