Answer · Healthcare
What happens when an AI tool causes a HIPAA breach?
The practice notifies, not the vendor. What you can bound decides how large the notification turns out to be.
The practice notifies its patients, the regulator and sometimes the press. The vendor's duty is to report to the practice. Whether the exposure is bounded or presumed to cover everyone depends on logs nobody thought to keep.
The direction of the obligations is the first thing to get right, because it is counter-intuitive. A vendor that mishandles information is required to report the incident to the practice. It is the practice — the covered entity — that owes notification to the affected individuals, to the Department of Health and Human Services, and, above a threshold, to prominent media in the state or jurisdiction. The vendor's failure becomes the practice's notification, and no contract redistributes that, though a contract can allocate who pays for it.
The clock is the second thing. Individual notification runs without unreasonable delay and no later than sixty days from discovery, and discovery includes what the practice should have known through reasonable diligence. In an AI arrangement the practical consequence is that a vendor's own reporting timetable eats part of the practice's window before the practice has heard anything, which is why the reporting deadline the vendor owes you is one of the more consequential lines in an agreement people sign without reading.
The part that actually determines the size is the scope question, and it is decided long before an incident. An acquisition, access, use or disclosure not permitted by the rules is presumed to be a breach unless the practice can demonstrate a low probability that the information was compromised, through a risk assessment that considers the nature of the information, who received it, whether it was actually acquired or viewed, and the extent to which the risk has been mitigated. Every one of those is an evidence question. A practice that can show which records that account could reach, and which it opened, has a bounded incident. A practice that cannot must treat the reachable set as the affected set.
This is why access scoping is a notification control rather than a security preference. A connection with broad read access to the whole record system is not merely more dangerous; it is more expensive when nothing bad happens, because the absence of a bound turns an incident into a mass notification. The narrow connection with a query log is cheaper in exactly the scenario nobody budgets for.
There is a second class of incident specific to these tools and no less real: the exposure that happens with no security failure at all. Staff pasting patient material into a personal account, a note drafted with one patient's history and sent to another, a shared workspace where a colleague on an unrelated matter can retrieve what was entered. None of these involves a vendor being compromised, and all of them are impermissible disclosures on the same analysis. They are also the ones a practice will find only if somebody is looking, which is an argument for knowing what accounts staff actually use.
Finally, the notification itself is a document that will be read closely by people deciding whether to be angry. Practices that describe what was reachable, what was confirmed accessed, what has changed, and what the patient should do tend to get a proportionate reaction. Practices that describe an incident involving a third-party vendor and reassure the reader that they take privacy seriously get the other one, and the difference is entirely in whether the practice did the scoping work described above.
The size of a breach is not what happened; it is what you can prove did not happen, and that is decided long before the incident.
Siddharth Sharma, Context Theory
Related questions
Can the contract make the vendor notify the patients?
A covered entity may delegate the mechanics, and some do, but the obligation and the accountability remain with the practice. Delegating it also means handing the vendor a list of patients and letting them speak to them at the worst possible moment, which is rarely what a practice wants on reflection. The more useful contractual terms are the reporting deadline, the cooperation duty, and who bears the cost.
Does an incident have to be reported if the information was encrypted?
Information rendered unusable, unreadable or indecipherable through a specified method falls outside the breach definition, which is the practical value of encryption at rest. It rarely helps in an AI incident, because the tool had to be able to read the information in order to do anything with it, and the failures that occur are usually about who could reach it rather than about bytes at rest.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Dentists & dental services CPC | $8.00 | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
LocaliQ / WordStream Search Advertising Benchmarks 2026 · Google + Microsoft Ads, 20 industries · Apr 2025–Mar 2026 · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Regulation | Notification to affected individuals, to the federal regulator and, above a threshold, to prominent media is owed by the covered entity rather than by the vendor whose failure caused the incident, with the vendor's own duty running only to the covered entity. | The breach notification rules at 45 CFR 164.400 through 45 CFR 164.414, and the business associate reporting clause in the practice's own agreement. |
| Constraint | An impermissible acquisition, access, use or disclosure is presumed to be a breach unless the entity demonstrates a low probability of compromise through an assessment covering the nature of the information, the recipient, whether it was actually viewed and the extent of mitigation. | The risk assessment factors set out in the breach definition, applied to a specific incident's access records. |
| Software | Whether an incident is bounded or presumed to cover every reachable record is decided by access scoping and query logging established before the incident, which makes a narrow connection a notification control rather than only a security preference. | Whether the practice can produce, for a given integration, the list of records that connection could reach and the subset it actually retrieved. |
| Workflow | A substantial class of incidents involves no vendor compromise at all — material entered into a personal account, a draft carrying one patient's history sent to another, a shared workspace retrievable by colleagues on unrelated matters — and each is an impermissible disclosure on the same analysis. | An inventory of which accounts and tools staff actually use for patient material, compared against the accounts covered by executed agreements. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one