PDPL DPIA for AI Projects

A data protection impact assessment, often called a DPIA, should help a Saudi organisation decide whether an AI design is necessary, proportionate and workable before the design becomes difficult to change. Its useful output is a reasoned decision about a particular processing activity, supported by evidence and actions.

Check Article 25 of the Implementing Regulation for conditional assessment triggers, including sensitive data and certain large-scale or repeated activities.

This guide uses an illustrative visitor-centre project to show how an assessment can change the system itself. The centre wants to reduce crowding. Its first proposal tracks individual visitor journeys, but the business question may be answered with much less information.

Start with the decision the organisation needs to make

Write the operational decision in ordinary language. “Use AI to understand visitors” is an ambition, not a defined purpose. “Decide when to open an additional service point because a particular area is becoming crowded” gives the assessment a concrete question.

Then identify what information that decision needs. A manager deciding whether to add staff may need a count and waiting-time estimate. They may not need to know who each visitor is, how often the person attends or which route that individual took.

This distinction prevents a technical capability from becoming the purpose. A product may offer individual path reconstruction, but the existence of that feature does not establish that the organisation needs to use it. The assessment should ask what would be lost if the feature were removed.

Define the responsible decision-maker and the action the system supports. An alert shown to a duty manager has a different operating role from a system that automatically redirects people or changes access. The assessment should describe the proposed behaviour, not just the model.

Compare three ways to answer the crowding question

Consider a hypothetical visitor centre. Its team wants earlier warning that a service area is becoming congested. A supplier proposes cameras and an AI system that reconstructs individual journeys across areas. The team should compare that proposal with alternatives before accepting its information footprint.

One alternative uses doorway counts and short-period aggregate occupancy estimates. Another uses staff observations at defined intervals. Neither alternative should be assumed adequate in advance; each must be tested against the operational question and the circumstances of the site.

Illustrative alternatives for a visitor-centre assessment

Design	Question it could help answer	Main issue to investigate
Individual journey reconstruction	How does a particular visitor move between areas?	Is individual continuity necessary for the crowding decision?
Doorway counts and aggregate occupancy	Which area needs additional attention now?	Can counting errors be managed without retaining individual histories?
Structured staff observations	When do visible queues require intervention?	Is observation timely and consistent enough for the service?

The alternatives should be compared on decision usefulness, operational effort, reliability and privacy effects. A cheaper design may be too inaccurate, while a richer design may collect information that adds little to the actual decision. The assessment makes those tradeoffs explicit.

The example does not establish that aggregate outputs automatically make the entire process non-personal. The team must examine the inputs, intermediate processing and ability to identify people, not only the dashboard's final display.

Describe the processing before describing the model

Map what happens from observation to action. What is captured, where is it processed, what is retained and who sees the result? Does the design keep images, generate persistent identifiers or connect observations across time? These questions reveal the processing that the assessment needs to examine.

Distinguish transient computation from retained information. A system might process an image to produce a count, but that does not tell the team whether the image is also stored for troubleshooting or whether the provider can access it. The configuration and service arrangement matter.

Describe intermediate outputs in meaningful terms. “Anonymous analytics” is not enough if the service maintains a persistent identifier that follows an individual through the site. The organisation should establish what each representation can reveal and who can reconnect it to other information.

Include the operational response. If an alert changes staffing, signage or visitor routing, explain who interprets it and what information they use. Privacy effects can arise from how staff act on a result as well as from the data collection itself.

Test necessity through a counterfactual

Ask what happens if the organisation removes a particular data element or capability. If individual continuity is disabled, can the duty manager still identify congestion? If longer retention is removed, can the team still investigate a counting error sufficiently?

A counterfactual makes necessity testable. The project owner should explain which operational decision fails under the narrower design and provide evidence from a suitable trial. A general preference for richer analytics does not demonstrate that a specific feature is needed.

Test alternatives under realistic conditions. A doorway counter may struggle with people moving in both directions or groups entering together. The response could be a better counting method, a manual correction process or a different operational threshold, rather than immediate adoption of persistent individual tracking.

Record rejected alternatives fairly. State why they did not answer the decision, what evidence supports that conclusion and whether a modified version remains possible. This avoids turning the alternatives section into a ceremonial list written after the preferred product has already been purchased.

Identify people and consequences beyond the average visitor

The assessment should consider the different people who encounter the service. Visitors, staff, contractors and people accompanying someone else may experience the same system differently. The organisation should not assume that every person has the same understanding, ability to avoid the system or way to raise a concern.

For the visitor centre, investigate whether a proposed design could reveal a repeated pattern of attendance or link a person with a particular service area. The significance depends on the actual setting and information, so the assessment should describe plausible consequences rather than use a generic severity label.

Consider staff behaviour as well. A dashboard that encourages employees to single out a person may create a different concern from an occupancy count used to allocate staff. The distinction should be visible in both the design and operating instructions.

Do not infer sensitive characteristics merely to make the assessment look thorough. Identify what the system actually processes and what realistic inferences or actions could follow. Speculative profiling can create confusion and distract from the concrete risks that need a decision.

Write risk scenarios with a cause and an affected person

A useful scenario describes a condition, an event and a consequence. For example, a retained journey history could be viewed by someone without a business need and used to infer an individual's repeated visits. The assessment can then ask how the design prevents that access and whether the history is needed at all.

Another scenario might concern an inaccurate count that repeatedly triggers unnecessary redirection. The privacy assessment should distinguish that operational reliability issue from a disclosure issue, while recognising that an action involving identifiable people can connect the two.

Avoid merging all concerns into “AI risk: high.” Separate the mechanism that causes each concern. The remedy for excessive retention differs from the remedy for inaccurate counting, even if both appear in the same project.

Use risk scores only when their meaning is clear. A number should summarise a reasoned assessment, not replace it. State the uncertainty, the evidence available and the event that would lead the team to revise the judgement.

Choose measures that change the risk mechanism

Prioritise changes to the design before relying entirely on training or promises. If the business decision can use aggregate counts, avoiding persistent individual histories may remove a concern more directly than restricting access to a history that is not needed.

Where information is necessary, define access by actual responsibilities. The duty manager may need a current occupancy estimate, while a technical investigator may need limited diagnostic information under a separate process. Do not give both groups the widest available view simply because the product permits it.

Make retention a decision tied to the activity. Explain what an identified period enables and how the team will verify that the configured behaviour matches the decision. An unexplained default inherited from the supplier should not become the organisation's rationale.

Test the proposed measures. If a setting claims to disable retained images, identify what evidence confirms that behaviour in the actual environment. If staff should respond only to aggregate conditions, observe whether the workflow supports that instruction under pressure.

Consider how the people using the site understand the design

The assessment can benefit from an appropriate way to understand the concerns of people who use the visitor centre. This is a proposed design exercise, not a claim that every project has an identical consultation duty.

Ask questions about the actual options without collecting unnecessary personal histories. Can people distinguish an occupancy count from an individual journey record? What would they expect staff to do when the system signals crowding? Their answers can reveal an expectation that the project team had overlooked.

Keep feedback separate from proof that the processing is justified. A favourable reaction does not settle the legal assessment, and one concern does not automatically determine the design. Use the findings to sharpen the explanation, compare alternatives and identify a concrete issue for the responsible decision-maker.

Assess the remaining tradeoff honestly

After proposed measures, identify what concern remains and why. The assessment may conclude that a narrower design answers the operational question sufficiently, that further evidence is needed or that the proposed activity should not proceed in its current form.

A residual-risk statement should not say merely that management accepts the risk. Explain the remaining consequence, uncertainty, limits and responsible owner. The decision-maker needs enough information to understand what is being accepted and what would invalidate the decision.

In the visitor-centre example, a limited aggregate trial might be appropriate for testing decision usefulness. That trial still needs a defined data arrangement and operating boundary. Calling something a pilot does not remove the need to understand what it does.

Document any condition that must be completed before live use. Distinguish a required design change from a monitoring action after launch. A project should not treat an unresolved prerequisite as an ordinary future improvement.

Use the assessment tool without confusing it with approval

SDAIA provides a personal-data processing impact assessment service to support assessment of processing and its risks. Its availability can help structure the work, but the organisation still needs accurate inputs, evidence and a reasoned decision about its own design.

Assign contributors according to the question. The business owner explains the decision and alternatives, the technical owner explains actual processing, the privacy owner assesses applicable obligations and the operational owner explains how staff will act. Procurement should clarify supplier dependencies.

Resolve contradictions before completion. A form saying “no images retained” and a supplier document describing retained diagnostic clips cannot both be accepted without investigation. The assessment is useful precisely because it exposes that disagreement while the design can still change.

Keep the working record understandable. Attach enough evidence for the conclusion, but do not turn the assessment into an uncontrolled repository of personal information. Use appropriate descriptions and test material where they answer the assessment question.

Connect the assessment to implementation acceptance

Translate important conclusions into acceptance evidence. If the approved design excludes persistent journey histories, the delivery team should show how the configured service respects that boundary. If only designated staff may see a diagnostic view, access should be checked before launch.

Choose checks that test the decision, not just the existence of a document. A signed policy cannot demonstrate that an export function is disabled. A screenshot of a dashboard cannot establish what the provider retains behind it.

Link each unresolved issue to an owner and a consequence for release. The project manager should know whether a missing answer prevents live use, limits the trial or requires a defined follow-up. This makes the assessment part of delivery rather than a parallel paperwork exercise.

Preserve the approved version with the relevant configuration and scope. The team needs to know which system the assessment actually covered, especially when a later product update introduces new analytics or broader retention.

Reopen the assessment when the purpose or design changes

A crowding system can drift into a different business purpose without a new product purchase. A request to identify repeat visitors or analyse individual journeys may transform a current-capacity tool into a different processing activity.

Define change triggers in the operating process. New data sources, persistent identifiers, additional recipients, changed retention and automatic actions should prompt the responsible team to assess whether the existing decision still applies.

Review evidence from operation. If staff routinely bypass the aggregate view and request individual information, the approved design and actual behaviour may have diverged. Investigate the reason rather than assume the original assessment remains accurate.

The assessment should remain a record of a living decision. Updating its date without reconsidering changed facts provides little value. Conversely, a small change that does not affect the relevant assumptions should not require an entirely new document merely to create activity.

Bring the right question to the project team

For the visitor centre, the decisive question is whether the organisation can manage crowding without reconstructing individual journeys. That question creates a practical comparison, a narrower trial and evidence that management can use.

The Saudi PDPL and AI guide explains the wider processing framework. Rights handling tests whether people can challenge information, and cross-border transfer review addresses overseas recipients. Human oversight clarifies who can interpret and change an AI-supported action. Residency and localisation helps avoid treating location as a substitute for the assessment.

The Saudi AI authority guide collection connects these questions across the programme. AI integration and delivery can help implement the resulting design limits and acceptance checks. Start with the decision, compare genuine alternatives and require evidence for the design that proceeds.