03 · What You Need to Know
Respond to the Incident Before Trying to Explain It Away
First, Stop Further Unauthorized Processing
If the AI workflow is still active, stop sending additional participant information. Disable automated uploads, integrations, scheduled processing, shared prompts, or other pathways that could continue the disclosure.
This does not necessarily mean destroying evidence of what happened. Containment and documentation need to occur together.
If a research assistant or collaborator is using the same workflow, ensure that the instruction to stop reaches everyone involved.
Do Not Delete the Evidence Before You Know What Must Be Preserved
Your first instinct may be to delete the chat, erase browser history, remove the file, and hope the incident has been undone.
Deletion from the provider may indeed be an important containment step. But the institution may also need evidence showing what was uploaded, when it happened, which account was used, which service received the data, what settings applied, and whether the material was shared further.
Preserve the facts necessary to investigate the incident while avoiding unnecessary duplication of the participant data. Follow institutional instructions about evidence preservation and provider deletion rather than improvising.
Establish Exactly What Was Sent
“I uploaded some research data” is not enough for meaningful risk assessment.
Determine, as accurately as possible:
- which files, prompts, images, recordings, or text were submitted;
- whether direct identifiers were included;
- whether indirect identifiers could reveal participants;
- whether sensitive personal information was involved;
- how many participants were affected;
- whether information about non-participants was included;
- when and how often the processing occurred; and
- whether AI-generated outputs containing participant information were downloaded or shared elsewhere.
The sensitivity and volume of information are central to determining the seriousness of the incident.
Identify the Exact AI Service and Account
The consequences can differ materially depending on whether the upload occurred through a personal consumer account, an institutionally contracted service, an API, an enterprise workspace, or another environment.
Determine the provider, product, account type, relevant settings, applicable terms at the time of the incident, retention conditions, model-training or service-improvement settings where relevant, and any available deletion controls.
Do not rely solely on what you remember the provider's privacy policy saying. The institutional incident team may need current and historical documentation applicable to the specific account.
Unauthorized Does Not Automatically Mean the Same Thing as a Reportable Breach
An AI upload can be unauthorized under an ethics protocol or institutional policy without necessarily meeting the legal definition or notification threshold for a personal-data breach.
Conversely, unauthorized disclosure or access to personal data may constitute a personal-data breach under applicable privacy law.
For example, the UK ICO defines a personal-data breach as a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Whether notification to the regulator is required depends on the resulting risk to individuals.
Under Philippine NPC Circular No. 16-03, breach management includes prevention, incident response, mitigation, and notification requirements. Mandatory notification applies when the conditions specified by the Data Privacy Act and Circular are met, rather than to every security incident automatically.
Researchers should therefore report the incident internally and allow the institution's responsible privacy or legal function to determine the applicable classification and reporting obligations.
Some Notification Deadlines Can Be Short
This is one reason prompt escalation matters.
For personal-data breaches meeting the relevant threshold, the Philippine National Privacy Commission states that required Personal Data Breach Notification Forms should be submitted within 72 hours upon knowledge of or reasonable belief that a breach occurred. The NPC also states that incidents not meeting mandatory-reporting requirements should still be documented and included in the applicable Annual Security Incident Report.
UK data-protection rules likewise impose a 72-hour regulatory notification period for reportable personal-data breaches.
Those rules do not mean the researcher personally should rush to file a regulator report. The appropriate organizational authority normally needs to assess the incident. They do mean that waiting a week because the researcher is embarrassed can create an additional compliance problem.
Watch Out
Do not delay internal reporting while you investigate the entire incident yourself. Some legal and institutional notification clocks begin when the organization becomes aware of a breach or has reasonable grounds to believe one occurred. Promptly provide the known facts and update them as the investigation develops.
Containment May Include Provider-Side Deletion
If the provider offers a mechanism to delete the conversation, file, account content, or stored data, that may form part of containment. An institution may also contact the provider to request deletion, determine retention status, or clarify whether submitted content entered another processing pathway.
Deletion should not be treated as magic. The effect of deletion depends on the provider's architecture and applicable retention terms. Some information may remain temporarily in logs or backups, while different account types may have different retention arrangements.
Document what deletion action was taken, when it was taken, and what the provider says that action accomplishes.
Containment Can Reduce Risk Even When the Incident Cannot Be Undone
Privacy regulators commonly treat containment as part of breach response. ICO guidance, for example, asks whether data were recovered, whether an unintended recipient securely disposed of them, and whether steps confirmed that the information was returned or destroyed when assessing whether risk has been mitigated.
With an AI provider, equivalent questions may include whether submitted content was deleted, whether the provider confirms deletion or restricted use, whether the account has been secured, and whether downstream copies or outputs remain.
The objective is not to pretend the upload never happened. It is to prevent the incident from becoming larger than it already is.
Assess Potential Harm, Not Merely Whether Names Were Present
A transcript without a participant's name can still contain intimate narratives. A survey may contain a rare combination of demographics. A photograph may reveal a face or location. A clinical record may expose highly sensitive health information.
Risk assessment should therefore consider identifiability, sensitivity, volume, affected populations, realistic re-identification, potential misuse, and consequences for participants.
If the data had been de-identified, assess whether participants could nevertheless be re-identified rather than assuming that deletion of direct identifiers makes the incident inconsequential.
Participant Notification Should Be Coordinated, Not Improvised
Researchers may feel an ethical impulse to email participants immediately. In some circumstances, prompt participant notification may indeed be required.
But notification requirements differ among laws and institutional procedures. Premature communication can also provide incomplete or inaccurate information before the scope of the incident is understood.
Coordinate with the responsible privacy, ethics, security, or legal authority. If participants must be notified, they should receive accurate information about what happened, what data were affected, the likely consequences, mitigation steps, and any actions they should take.
The Ethics Committee May Need to Know Even When Privacy-Breach Notification Is Not Required
A privacy regulator and a research ethics committee answer different questions.
An unauthorized AI upload may represent noncompliance with an approved protocol even if the incident does not reach the legal threshold for regulatory breach notification. The ethics authority may need to assess participant welfare, protocol deviation, corrective actions, consent implications, and whether research activities should continue.
This is particularly relevant if AI was introduced without obtaining the prospective determination described in the process for adding AI to an ongoing study.
Do Not Alter Research Records to Hide the Incident
Research integrity requires an accurate record of what happened. Do not retrospectively edit logs, protocol records, data-management documentation, or methodological notes to make it appear that the AI processing had been authorized from the beginning.
Correct the record transparently through the appropriate institutional process.
An uncomfortable protocol deviation is manageable. Falsifying the research record creates a different and potentially more serious problem.
Corrective Action Should Address Why the Incident Happened
Once the immediate incident has been contained, ask why the unauthorized processing occurred.
Possible causes include unclear AI policy, inadequate researcher training, ambiguous data classification, a research assistant using a personal account, insufficient technical controls, poor onboarding, or a protocol that did not anticipate emerging tools.
Corrective action might therefore involve technical restrictions, revised procedures, approved alternatives, training, clearer consent language, or a formal protocol amendment. The objective is to reduce the probability of recurrence rather than merely identify someone to blame.
