Compliance decisions
PHI sent to AI: assess the HIPAA breach
An impermissible PHI disclosure is presumed to be a breach unless the required assessment demonstrates a low probability of compromise or an applicable exception applies. After an AI submission, preserve the facts, assess the recipient and exposure, and involve the privacy and incident owners promptly.
For Healthcare incident responders and privacy officers
A deleted chat or a provider reassurance does not by itself close the assessment.
Synthetic incident only. No real patients, provider response, notice or completed investigation is represented.01
Contain the route and preserve the facts
Ask the employee to stop further submissions and contact the incident team. Record the service, account, feature, time and information involved without spreading the PHI into ordinary chat or support tickets. Preserve appropriate evidence in the approved incident system and follow the organisation’s response procedures.
Identify whether the submission actually left the device, reached a provider or was stopped by a control. Distinguish an intended block from an observed block. A policy event can help establish facts, but it should be reconciled with the application, employee account and other available evidence.
Source context: HHS: Breach Notification Rule
02
Establish whether the disclosure was impermissible
Review the purpose, recipient, applicable agreement and permitted scope. An unfamiliar tool is a reason to investigate, not a substitute for the legal analysis. Conversely, a familiar product name does not prove that the employee used an approved account or a covered feature.
HHS describes exceptions to the definition of breach as well as the four-factor assessment. The responsible privacy team should evaluate those conditions against the facts. Do not assume that deleting the visible conversation reverses the disclosure or that a setting about model training settles whether information was compromised.
Source context: HHS: Breach Notification Rule · HHS: Guidance on HIPAA and cloud computing
03
Work through all four risk factors
HHS identifies at least four factors: the nature and extent of the PHI, including identifiers and identification likelihood; the unauthorised person who used or received it; whether the PHI was actually acquired or viewed; and the extent of mitigation. Address each factor rather than substituting a single risk score.
For an AI service, useful evidence can include the actual payload, provider identity, account terms, relevant processing or access facts, and a documented mitigation response. Clearly distinguish verified facts, employee recollection and unanswered questions. Missing evidence does not become a favourable finding merely because no harm has been reported.
Source context: HHS: Breach Notification Rule
04
Assign notification decisions and deadlines
If notification is required, HHS describes different responsibilities for covered entities and business associates. Individual notices must be provided without unreasonable delay and no later than 60 days after discovery of the breach. Notification to HHS and, in some circumstances, the media follows additional requirements.
Do not treat 60 days as a waiting period or apply one deadline to every recipient. A business associate must notify the covered entity, and the organisation’s agreements or other applicable laws may add duties. Record the discovery date, responsible decision-maker, affected scope and next action in the incident record.
Source context: HHS: Breach Notification Rule
05
Close with evidence and a control change
The synthetic assessment below cannot support a low-probability conclusion because several material facts remain unknown. That is a useful outcome: it identifies what the incident owner must obtain and prevents an unsupported “no breach” label from entering the record.
After the assessment, address the route that allowed the submission. Clarify staff instructions, review account access and test the intended input policy with invented data. Preserve the assessment and notification decision separately from the technical remediation. Blocking future submissions neither removes existing provider copies nor performs breach notification.
Source context: HHS: Breach Notification Rule
Put it into practice
Worked four-factor assessment
A fictional employee submits two identifiable patient summaries to an unapproved AI account. The assessment identifies evidence needs without inventing a final legal conclusion.
Synthetic incident only. No real patients, provider response, notice or completed investigation is represented.
Data
What PHI and identifiers were involved?
Recipient
Who received or could access it?
Exposure
Was it acquired or viewed?
Mitigation
What was actually done and evidenced?
| Factor | Invented case fact | Assessment and next step |
|---|---|---|
| Nature and extent | Two invented records include names and diagnoses. | Direct identifiers and health details require careful assessment; verify the actual payload. |
| Unauthorised recipient | An external AI account was used; its applicable terms are not established. | Identify the service, account and any other recipients before assessing their obligations. |
| Acquired or viewed | Employee saw an answer; provider access and retention facts are unknown. | Do not infer no acquisition from the absence of a human viewer; obtain relevant evidence. |
| Mitigation | A deletion request is proposed but not sent in this exercise. | Record any actual action and response; do not treat a draft request as completed mitigation. |
| Illustrative disposition | Material recipient and exposure facts remain unresolved. | No low-probability conclusion is demonstrated by this example; escalate the assessment. |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
phi-ai-breach-assessment.mdInspect
# Worked four-factor assessment
Synthetic incident only. No real patients, provider response, notice or completed investigation is represented.
A fictional employee submits two identifiable patient summaries to an unapproved AI account. The assessment identifies evidence needs without inventing a final legal conclusion.
| Factor | Invented case fact | Assessment and next step |
| --- | --- | --- |
| Nature and extent | Two invented records include names and diagnoses. | Direct identifiers and health details require careful assessment; verify the actual payload. |
| Unauthorised recipient | An external AI account was used; its applicable terms are not established. | Identify the service, account and any other recipients before assessing their obligations. |
| Acquired or viewed | Employee saw an answer; provider access and retention facts are unknown. | Do not infer no acquisition from the absence of a human viewer; obtain relevant evidence. |
| Mitigation | A deletion request is proposed but not sent in this exercise. | Record any actual action and response; do not treat a draft request as completed mitigation. |
| Illustrative disposition | Material recipient and exposure facts remain unresolved. | No low-probability conclusion is demonstrated by this example; escalate the assessment. |
## Review steps
- Secure the factual record: Capture the exact service, account, time, data categories and source evidence without copying PHI unnecessarily.
- Address each HHS factor: Separate established facts from unknown acquisition, recipient and mitigation details.
- Assign the legal decision: Record the responsible privacy owner and applicable notification steps and dates; this worksheet does not send notices.
## Synthetic evidence request list
- What exact information was submitted, through which account and feature?
- Was the input stopped locally or received by the service?
- Which entity and other recipients could process or access it?
- What retention, access and deletion facts can the provider substantiate?
- What mitigation was actually completed, and when?
## Example decision record
Assessment status: facts incomplete.
Low-probability conclusion: not demonstrated by this fictional evidence.
Notification determination: for the authorised privacy/legal owner.
Notices sent: none; this is a teaching exercise.
## Source and scope
Guide: https://aona.ai/resources/guides/phi-uploaded-ai-hipaa-breach-assessment/
Source check: 21 September 2026. General information; no professional approval or installed-product result is represented.
- HHS: Breach Notification Rule: https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
- HHS: Guidance on HIPAA and cloud computing: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
phi-ai-breach-assessment.csvInspect
Factor,Invented case fact,Assessment and next step
Nature and extent,Two invented records include names and diagnoses.,Direct identifiers and health details require careful assessment; verify the actual payload.
Unauthorised recipient,An external AI account was used; its applicable terms are not established.,"Identify the service, account and any other recipients before assessing their obligations."
Acquired or viewed,Employee saw an answer; provider access and retention facts are unknown.,Do not infer no acquisition from the absence of a human viewer; obtain relevant evidence.
Mitigation,A deletion request is proposed but not sent in this exercise.,Record any actual action and response; do not treat a draft request as completed mitigation.
Illustrative disposition,Material recipient and exposure facts remain unresolved.,No low-probability conclusion is demonstrated by this example; escalate the assessment.
Before you proceed
Keep these distinctions clear
- No reported harm is not the whole test
- Use the required compromise-risk factors and relevant evidence.
- Deletion is not retrospective permission
- A visible deletion or future block does not settle the original disclosure or every retained copy.
Apply it to employee AI use
Bring your actual data path.
Supported Aona activity and policy events may help establish what happened on a covered employee input path.
Aona does not determine reportability, erase third-party copies or submit HIPAA breach notifications.
After containment, reproduce only the input pattern with invented data and verify the intended protection on the selected path.
Review your use caseFAQ
Questions for this decision
Is every unapproved AI upload automatically a reportable breach?
Can we close the incident when the employee deletes the chat?
Can we wait 60 days to start investigating?
Should we test with the same patient record?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- HHS: Breach Notification Rule
The presumption of breach, four risk factors, exceptions and notification responsibilities and time limits.
regulator · checked 2026-09-21 - HHS: Guidance on HIPAA and cloud computing
Business-associate roles, BAAs, risk analysis and cloud-service safeguards, including providers without decryption keys.
regulator · checked 2026-09-21