PDPL Breach Response for AI Systems

An AI-related personal-data incident needs a prompt decision about exposure, containment and the applicable PDPL notification duties. The team should establish what happened to actual personal information, who may be affected and what remains uncertain, while preserving the evidence needed to make those decisions.

SDAIA's breach notification service describes notification within seventy-two hours of awareness where the incident could harm personal data or its subject, or conflict with the person's rights or interests. This is a conditional requirement, not a rule that every unusual model output must be reported.

This guide follows an illustrative training-service incident: an assistant displays one learner's accommodation note in another learner's answer. It explains the PDPL decisions that need reliable facts, rather than offering a generic catalogue of every possible AI failure.

Establish whether the answer exposed real personal information

Start with the reported output and the authorised context. What was shown, to whom, and what was that person entitled to see? Preserve the relevant evidence through a controlled process rather than asking multiple staff members to reproduce the sensitive answer.

Compare the output with the source material. An assistant may reveal a real note, combine information from several people or invent a statement. Those possibilities need different factual investigation, even where each creates a serious concern.

Do not dismiss an incident as a hallucination simply because the system generated the sentence. Generation describes how the answer was produced; it does not establish whether the information came from a real record or whether an unauthorised person received it.

Conversely, do not assume that every inaccurate answer proves disclosure from a source system. Investigate the actual processing and consequences. An unsupported personal claim may require correction and other action even when the investigation does not establish the suspected exposure.

A learner's accommodation note appears in another account

Consider a hypothetical training provider whose assistant answers questions about course arrangements. A learner reports that the answer includes another participant's accommodation note. The organisation confirms that the wording corresponds to a real restricted record.

The first confirmed event establishes a problem, but it does not establish the total scope. The team needs to determine whether the source was available too broadly, whether the retrieval decision crossed an account boundary and whether the answer was stored or sent elsewhere.

Suppose the investigation also identifies replies to two other accounts that may have used the same source collection. That finding is a lead to investigate, not proof that every reply disclosed the same note or that only those accounts were affected.

Illustrative distinctions in the training-service investigation

Evidence	What it establishes	What it does not yet establish
Reported answer matches a restricted note	A real source is implicated in the confirmed event	The full exposure period or all affected people
Source collection was accessible to the assistant	A possible path existed	Every item was retrieved or displayed
Two further accounts used that collection	Additional interactions need review	Each answer contained personal information
Access is now disabled	The identified path has been restricted	All prior copies or alternative paths are resolved

Keep these distinctions visible. Under pressure, teams often convert a possible exposure into a confirmed count, or a confirmed example into an assumption that the incident is isolated. Both errors can distort the notification decision and the response to affected people.

Separate event time, detection and awareness

Create a chronology that distinguishes when the relevant processing occurred, when a signal was received and when the organisation became aware of the incident. Record the facts and responsible assessment rather than using a convenient timestamp to postpone the response.

The first technical alert may be ambiguous. A later review may establish that a real note was exposed. The team should document what each event showed and how it informed the awareness assessment. The legal owner needs that evidence to apply the relevant requirement.

Do not wait for a complete root-cause report before involving the privacy lead. Exposure and notification decisions can be urgent while some technical details remain unresolved. The response should distinguish known facts, reasonable investigation leads and unanswered questions.

Use one coordinated chronology across the incident team. If the supplier and organisation record different times or time zones, reconcile them explicitly. A clear sequence is more useful than several independent documents that describe the same event inconsistently.

Contain the identified path without spreading the note

Choose containment that addresses the known exposure path. In the example, that may involve restricting the implicated source collection or suspending the affected assistant function while the team verifies the boundary. The exact action should follow the system design and evidence.

Consider service continuity separately. If learners still need timetable information, an approved source or staffed channel may provide it while the problematic function is paused. A useful fallback should avoid creating another route for the same restricted information.

Preserve necessary evidence before making changes that could erase the explanation of what happened. Coordinate that preservation with authorised technical and privacy owners. Evidence handling should itself minimise access and avoid uncontrolled copies.

Do not paste the accommodation note into broad incident chats, slide decks or status emails. Describe the information category and use a controlled reference where appropriate. A response process should not expand the audience for the very information it is trying to protect.

Determine scope through actual access and outputs

Investigate the relevant period, sources and accounts using approved methods. The question is not only what the assistant could access, but what was retrieved, generated, displayed, stored or exported in the interactions under review.

Differentiate people, records and outputs. Several answers can concern one person, and one answer can contain information about more than one person. A count of requests is not automatically a count of affected individuals.

Record limitations in the evidence. Missing logs or short retention can make the exact scope uncertain. State that uncertainty and identify what other evidence can narrow it, rather than presenting an unverified number as a complete incident total.

Review whether a recipient actually viewed or could access the material, and whether it was copied or acted upon where that can be established. Avoid unsupported certainty in either direction. The response needs a defensible account of exposure, not a reassuring narrative chosen before investigation.

Assess harm in the context of the information

Consider what the note reveals, who received it and what consequences are reasonably plausible. An accommodation note may contain information that the learner expected to remain restricted. Its significance depends on its actual content and context, not merely the fact that it is a short text field.

Separate the information category from assumptions about the person. The incident team should not invent a diagnosis, personal circumstance or likely consequence that the record does not establish. It should assess realistic risks using the facts available.

Consider persistence and reach. A displayed answer, a saved conversation and a downloaded report can create different opportunities for further use. The team should determine which occurred rather than assume that an answer disappeared when the browser closed.

Document the notification decision with its rationale and evidence. Where the assessment changes as facts emerge, preserve the reason for the change. A later conclusion should not overwrite the earlier record as though the team always knew the final facts.

Keep authority and individual notification decisions distinct

Article 24 of the Implementing Regulation requires individual notice without undue delay when its harm or rights-and-interests condition applies.

For the training provider, decide what the learner needs to know to understand the incident and any practical action available. The communication should distinguish confirmed facts from ongoing investigation without hiding the nature of the exposure behind technical language.

Use an appropriate communication channel and verify the recipient. A poorly addressed notification can create another disclosure. The organisation should also prepare a way for the learner to ask questions and receive consistent, authorised information.

Check whether other applicable reporting obligations need their own action. A supplier report, customer contract notice and regulator notification may serve different purposes. The incident owner should coordinate them without assuming that sending one message completes every requirement.

Prepare a notification that states what is known

Build a concise factual account with the responsible legal owner, using the current official process and required information. Separate established facts, preliminary estimates and matters still under investigation. Avoid presenting guesses with the certainty of verified evidence.

For the example, the organisation can describe the affected assistant function, the type of restricted information, the known exposure and actions already taken. It should not claim that the issue was fully contained merely because one data source was disabled.

Maintain a controlled update process. As the investigation clarifies scope or consequences, the team should know who approves revised information and how it reaches the relevant recipient. Versions should make changes understandable rather than silently replacing earlier statements.

Check operational readiness for the official channel before an incident. SDAIA's notification service lists a valid registration certificate as a prerequisite. The organisation should know who can access the service and how an unavailable account or responsible person will be escalated.

Coordinate the supplier without surrendering the decision

The supplier may hold evidence about retrieval, access or retained outputs that the organisation cannot see directly. Give it a precise request tied to the incident, including the relevant service and period, and preserve the response through the controlled record.

Ask the supplier to distinguish observed events from product capability. “The platform supports tenant isolation” does not answer whether the particular configuration enforced the intended boundary during the incident. The response should address the actual environment.

Keep responsibility clear. A supplier's statement that the incident is low risk is evidence to assess, not a substitute for the organisation's own decision about its information and affected people. Equally, a supplier should not be asked to make a legal conclusion outside the facts it can establish.

If an overseas arrangement is implicated, connect the investigation with the relevant transfer and recipient records. The team needs to understand whether the exposure occurred within the approved processing arrangement or reveals a change that had not been assessed.

Distinguish containment from correction and recovery

Containment limits further exposure through the identified path. Correction addresses the defect that caused it. Recovery returns the service to an approved operating state. These are related tasks, but evidence for one does not automatically prove the others.

In the example, restricting the source collection can reduce immediate exposure. The team must still understand why the assistant reached the note, correct the relevant boundary and verify that other routes do not reproduce the problem.

Use controlled test cases for recovery checks. The test should demonstrate that one learner's authorised context cannot retrieve another learner's restricted material, including relevant variations in how the question is asked. Avoid using the affected person's actual note unnecessarily in repeated tests.

Define who approves restoration and what evidence they need. A service owner under pressure to resume should not have to infer the release condition from an informal conversation. Record the scope that is restored and any continuing restriction.

Keep AI assistance out of the factual record unless it is checked

The response team may be tempted to ask another AI tool to summarise the incident or draft a notification. Before doing so, assess the information that would be supplied and the approved use of that tool. An urgent response does not make a new disclosure arrangement self-explanatory.

If an approved assistant helps with drafting, use a controlled factual brief and require a responsible reviewer to check every substantive statement. The draft must not invent the number of affected people, the awareness time, the cause or the effectiveness of containment.

Keep the source evidence separate from generated prose. A polished summary can make an uncertain conclusion sound settled, particularly when it combines notes from different stages of the investigation. The reviewer should be able to trace important statements to the current approved facts.

Also review the Arabic and English versions together where both are used. A translation that changes “potentially affected” into “affected” changes the factual claim. The communication owner should preserve uncertainty and scope consistently, rather than judge quality only by fluency.

Close the incident with unresolved issues visible

A closure decision should explain the established cause, exposure assessment, communications, corrective actions and remaining uncertainty. If some evidence cannot be recovered, state the limitation and its effect on the conclusion.

Track longer-term changes separately from immediate closure. A wider review of source permissions or supplier contracts may continue after the affected function is safely restored. Each action needs an owner and a reason, rather than becoming an unprioritised list of every desirable improvement.

Review whether the incident reveals a broader class of failure. An incorrectly shared source collection may affect other assistants or learner services. Investigate the relevant connection without assuming that every system has the same defect.

Keep the post-incident record proportionate and controlled. The organisation needs evidence of decisions and actions, but it should not retain unnecessary copies of the learner's private note merely because they were created during the response.

Make the next incident easier to understand

Before the next release, test whether the team can identify a disputed output, connect it to the relevant source and access decision, restrict the affected function and communicate reliable facts. Those capabilities make the PDPL assessment more timely and defensible.

The Saudi PDPL and AI guide explains the wider obligations. Data subject rights addresses correction and individual requests, while cross-border transfer review clarifies supplier arrangements. Impact assessment can reveal exposure paths before launch, and AI incident scenarios supports exercises that test the organisation's decision process.

The Saudi AI authority guide collection connects incident learning with governance and delivery. AI integration and delivery support can help build traceable access and recovery checks. The aim is an accurate, timely response grounded in the real information and people affected.