It can be, and the rule starts from the assumption that it is. Under the HIPAA Breach Notification Rule, a use or disclosure of protected health information that the Privacy Rule does not permit is presumed to be a breach unless the covered entity demonstrates a low probability that the information has been compromised, based on a risk assessment of at least four factors. Whether a particular paste into an AI tool is an impermissible disclosure depends on where it went and what agreement, if any, sits behind that tool. If it is a breach of unsecured information, the notification clock runs from the day the health system knew or should have known, and the burden of showing what happened is on the health system.
What turns an impermissible disclosure into a breach?
The definition sits at 45 CFR 164.402. A breach is “the acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E of this part which compromises the security or privacy of the protected health information.” Three exclusions follow. One covers unintentional access or use by a workforce member acting in good faith and within the scope of their authority. One covers an inadvertent disclosure between people who are both authorized to access the information at the same entity. One covers a disclosure where the entity has a good faith belief that the person who received it could not reasonably have retained it.
Set each of those against a prompt sent to an outside service. They describe an unintentional access or use, an inadvertent disclosure between authorized colleagues, and a disclosure to someone who could not have kept the information. A prompt to an outside AI service is a deliberate act by the clinician, sent to a recipient that may retain it, so it is not obviously any of the three. Whether one fits a given case is a question for your counsel, not for a blog post. Outside the exclusions, the presumption applies.
Is a paste into an AI tool a disclosure at all?
HIPAA’s own definition, at 45 CFR 160.103, is broad: “the release, transfer, provision of access to, or divulging in any manner of information outside the entity holding the information.” Sending text to an outside company’s service is, on a plain reading, a transfer outside the entity. That is our reading, and it is not a ruling.
Whether the disclosure is permitted is the next question. Under 164.502(e), a covered entity may allow a business associate to create, receive, maintain, or transmit protected health information on its behalf if it obtains satisfactory assurance that the business associate will appropriately safeguard it, which 164.504(e) carries out through a written contract. A prompt sent under a signed agreement that covers that service is one situation. A prompt sent to a consumer account nobody at the health system agreed anything about is another. We walk through how the agreement works, and what it does not do, in is ChatGPT HIPAA compliant. Here, the point is narrower: the same act, typing patient details into an AI tool, can be permitted in one account and impermissible in another, and a health system that does not know which account was used cannot tell which one it is dealing with.
We found no OCR guidance that applies the breach rule to an AI prompt specifically, and we are not citing commentary as if it were authority. The analysis above uses the regulation’s own text.
How does the four-factor risk assessment apply to a prompt?
The presumption of breach can be rebutted only through a documented assessment that considers, at a minimum, the four factors in 164.402: the nature and extent of the information involved, including the types of identifiers and the likelihood of re-identification; who used the information or received the disclosure; whether the information was actually acquired or viewed; and the extent to which the risk has been mitigated. Applied to a prompt, each factor turns on facts that someone has to have written down:
| Factor | What you would need to know about the paste |
|---|---|
| Nature and extent of the PHI | What was in the prompt: a name and a diagnosis, or a de-identified summary with no direct identifiers |
| Who received it | Which service and which account, and what terms bind the recipient |
| Acquired or viewed | Whether the service kept the prompt, and whether anyone at the provider could read it, which a health system often cannot see from its side |
| Mitigation | Whether the provider confirmed deletion, and what written assurance exists |
Two of the four, what was pasted and where it went, are facts about your own staff and devices. The other two depend partly on the provider. That split matters, because the first two are the ones you can have on record before anything goes wrong.
What is the notification clock, and who has to be told?
If the event is a breach of unsecured protected health information, the covered entity must notify each affected individual without unreasonable delay and in no case later than 60 calendar days after discovery. A breach is treated as discovered on the first day it is known, or would have been known with reasonable diligence, and the entity is deemed to know if any workforce member or agent other than the person who committed the breach knows. So the clock can start when a colleague notices, not when compliance is told. Under 164.408, the Secretary of HHS is notified at the same time as individuals when 500 or more people are involved, and otherwise through a log reported within 60 days after the end of the calendar year in which the breach was discovered.
Text pasted into a prompt is readable by the service that receives it, so in our reading it is unsecured protected health information, which is the term the rule uses. Two further duties bear on the records. Section 164.414(b) puts the burden on the covered entity to show that all notifications were made or that the event was not a breach, 164.414(a) applies the administrative requirements of 164.530, including (j), to this part of the rule, and 164.530(j) requires documentation sufficient to meet that burden, retained for six years.
What should a health system have in place?
- A written policy that names which AI tools and accounts may take patient information, and says plainly that a personal or free account is not one of them.
- An incident procedure that treats a paste as a possible breach to be assessed on the four factors, with a named owner, rather than a private mistake to be corrected.
- A way for staff to report it that does not depend on getting it wrong to be believed. The clock can start with any workforce member other than the person who did it.
- A risk assessment template that asks for the four factors in the order above and is filled in for every event, including the ones that turn out to be low probability.
- Training that says what to do after a paste, not only before it.
- A record of AI use on managed devices, so the first two factors can be answered from evidence and not from memory.
- Counsel on call, because whether an exclusion applies and whether an event is a reportable breach are legal determinations.
Where Verillian fits
Verillian governs AI use on the devices you enroll. A checkpoint on each device sits between your people’s AI tools and agents and the AI providers it supports. For Claude and Claude Code traffic (the Anthropic API format), a tool call your policy bans is removed before your machine can run it; for the other supported providers, it screens and records the usage, and the Claude desktop app and Cursor are recorded only, with no redaction. Each record is signed on the device it came from and hash-chained to the one before it, so a change to its signed fields is detectable, and it stays on your own infrastructure. It cannot show that nothing was omitted. Redaction is best-effort, not a guarantee that every value is caught. The admin server runs where you choose: on-prem or in a private cloud you run. macOS is the supported install today; Windows has an interim scripted installer and Linux builds from source. For a health system, that record can help show which AI service was used from which enrolled device, attributed to the user the checkpoint reports, and when, which speaks to the second factor and to the date the clock may have started. On a fresh install the checkpoint detects and flags values such as a Social Security number or a credit card number without changing traffic; an administrator has to set redaction on, and a redacted Social Security number leaves the device as [US_SSN_REDACTED]. A flag is a signal when a detector fires, not an inventory of everything a prompt contained, so it does not settle the first factor, and redaction does not make a prompt de-identified under HIPAA. Verillian is built for HIPAA-regulated environments, and no HIPAA certification of a product exists.
Verillian sees only the devices it is installed on. A paste from a personal phone or an unmanaged computer never reaches it, and it does not see what a provider did with a prompt after receiving it, which is why the third and fourth factors still depend on the provider’s own records and terms.
For what a record has to contain to be worth keeping, see what an AI audit trail is. The related question of what a health system’s staff policy must cover is in what a clinician AI use policy has to cover, and the platform page covers how policy is applied.
Sources
- 45 CFR 164.402, definitions (breach, unsecured protected health information); 164.404, notification to individuals; 164.408, notification to the Secretary; 164.414, administrative requirements and burden of proof.
- 45 CFR 160.103, definition of disclosure.
- 45 CFR 164.502(e), disclosures to business associates, and 164.530(j), documentation and its six-year retention.