On 6 October 2026, the Saudi Data and Artificial Intelligence Authority (SDAIA) published a revised set of draft amendments to the Implementing Regulation of the Personal Data Protection Law (PDPL) for public consultation, open until 5 November 2026. The proposals follow an earlier consultation in 2025 and remain, for now, draft.

The proposed amendments are not primarily focused on AI or technology. Instead they would amend the Personal Data Protection Law framework more broadly. But several proposals raise practical questions for businesses developing or deploying AI, cloud and other data-driven technologies in the Kingdom. Some of those questions arise not from entirely new obligations, but from how existing data protection concepts would apply to increasingly complex technology architectures.

Three questions stand out: when is AI an ‘emerging technology’? What does it mean to ‘store’ Personal Data in the Kingdom where an AI service uses a distributed technology stack? And when might the use of an international technology provider bring the proposed registration requirements into play? We look at each of these questions below. 

When is AI an ‘emerging technology’?

Under the proposed amendments, processing Personal Data using ‘any emerging technologies’ would be a standalone trigger for an impact assessment under Article 25 of the Implementing Regulation. The draft does not, however, define what constitutes an ‘emerging technology’.

This differs from the structure of the current Article 25. The existing provision already refers to processing based on ‘newly adopted technologies’, but does so within a paragraph that also addresses large-scale and repetitive processing of data of individuals lacking full or partial legal capacity, processing that by its nature requires constant monitoring, and automated decision-making. The proposed amendment would separate these circumstances into distinct cases, including processing of Sensitive Data or data relating to minors or individuals lacking legal capacity, large-scale processing or regular or systematic monitoring, the use of emerging technologies, and certain solely automated decisions. The draft would also remove the current trigger for products or services likely to cause serious harm to Data Subjects’ privacy.

The proposed change is therefore partly a restructuring and clarification of the Article 25 triggers, but in some respects it is also an expansion: separating the triggers appears to remove the ‘large scale and repetitive’ qualifier from processing of data relating to individuals lacking legal capacity and from the use of new technologies. Other triggers are more specifically qualified. For example, the current text refers to decisions based on automated processing, whereas the proposed trigger would apply only where decisions are based solely on automated processing and affect the rights or interests of Data Subjects. The same qualifier would also be added to the explicit consent requirement for automated decisions in Article 11.

For AI businesses, however, the reference to ‘emerging technologies’ raises a more fundamental question: when should AI actually be considered an emerging technology for these purposes? It may be tempting to assume that any use of AI falls within the term, but the draft does not actually say that. As AI capabilities increasingly become embedded in established enterprise software and ordinary business processes, the distinction may not always be straightforward. 

This could have an important consequence for AI deployments. If ‘emerging technologies’ is interpreted broadly to include AI as a category, making it a standalone trigger could mean that an impact assessment is required for a much wider range of AI deployments, regardless of their scale or whether they involve systematic monitoring or consequential automated decision-making. As AI becomes embedded in increasingly routine business tools, that could produce a surprisingly broad result: the use of AI itself may, in some circumstances, be enough to bring Article 25 into play. Whether that is the intended effect will turn significantly on how ‘emerging technologies’ is interpreted.

Separately, the existing Article 4(5), which the draft does not appear to amend, already requires Controllers whose activities involve the adoption of new technologies or automated decision-making to give Data Subjects additional information, including whether decisions will be made based solely on automated processing. AI deployments may therefore engage transparency obligations as well as the impact-assessment question.

Where is AI data actually ‘stored’?

Determining where Personal Data is "stored" may be more complicated in AI and cloud environments than it first appears, particularly where storage, processing and transfers occur across multiple locations or service providers. 

The proposed new Article 23(2) would require a Controller to store Personal Data within the Kingdom, while transfers and disclosures outside the Kingdom would remain possible in accordance with the Personal Data Protection Law and its regulations. The proposal is easy to state. Applying it to a modern AI or cloud architecture may be less straightforward.

Personal Data associated with an AI service may appear at several points in the technology stack. Depending on the use case, that can include training or fine-tuning datasets, prompts and inputs submitted to a model, generated outputs, logs and telemetry, conversation histories, retrieval indexes or vector databases, and backups.

That means selecting an in-Kingdom hosting region for the principal application may be the beginning of the analysis rather than the end of it. Businesses may need to understand which components store Personal Data, where that storage takes place and which data flows involve transfers outside the Kingdom.

The draft also leaves an important element unresolved: what does ‘store’ mean where Personal Data is transmitted offshore for computation but is not persistently retained there? That distinction may be particularly relevant where organisations access models through APIs or use cloud services whose processing and storage locations differ. It is an area where further regulatory clarity would be valuable. As the obligation would sit with the Controller, it would also need to be reflected in arrangements with processors and other service providers.

Can an overseas technology provider bring registration into play?

The proposed amendments to Article 34 would bring registration criteria into the Implementing Regulation itself and repeal the 'Rules Governing the National Register of Controllers Within the Kingdom'. The proposed criteria would cover public entities, Controllers whose core activity requires the processing of Personal Data, Controllers processing Sensitive Data or data relating to individuals lacking legal capacity, and Controllers that transfer Personal Data outside the Kingdom or disclose it to entities outside the Kingdom. The requirement would also extend to natural persons processing Personal Data beyond personal or family use.

For organisations using international cloud, SaaS or AI providers, the relevant question is therefore not simply whether a provider is based overseas or whether an API endpoint is offshore. The legal question is whether Personal Data is in fact transferred or disclosed outside the Kingdom as part of the service.

That makes data-flow mapping increasingly important. A technology deployment that appears local at the application layer may still involve other service components or providers outside the Kingdom. The registration question therefore cannot necessarily be answered simply by asking where the application is hosted or where the technology provider is based. A service hosted in the Kingdom may still involve Personal Data being sent to an overseas model or service provider; conversely, an international provider may offer an architecture in which the relevant Personal Data remains in the Kingdom. For Article 34, the key question is what happens to the Personal Data in practice: does it leave Saudi Arabia or is it disclosed to an entity outside the Kingdom? In that sense, an apparently technical question about the architecture of an AI or cloud service could determine whether the Controller falls within the proposed registration requirement. That said, other proposed criteria, such as where a Controller’s core activity requires the processing of Personal Data or where it processes Sensitive Data, may independently require registration for many data-driven businesses, whatever their architecture.

What else is changing?

Several of the other proposals could have significant practical consequences beyond the AI-specific issues discussed above. Most notably:

Breach notification

The draft would remove the current harm-based threshold for notifying SDAIA. The 72-hour deadline would remain, but notification of a Personal Data Breach, damage or unauthorised access would no longer expressly depend on the incident potentially causing harm or conflicting with the Data Subject’s rights or interests. This means more incidents may become reportable to SDAIA, while notification to Data Subjects would still depend on whether the breach may cause damage to their data or conflict with their rights or interests. The draft would also delete the definition of ‘Personal Data Breach’ while continuing to use the term, although the consultation table notes that consequential edits to affected provisions will be required.

Marketing

Under the current Article 28, consent to receive advertising or awareness material is expressly required only where there has been no prior interaction between the Controller and the recipient. The draft would require consent in all cases. Where a prior relationship exists, Controllers would also need to verify that consent was obtained in accordance with the Personal Data Protection Law and its Regulations. Separately, the draft would delete the definition of ‘Direct Marketing’, with Article 29 referring instead to processing for marketing purposes; where consent to such processing is withdrawn, the Controller would need not only to stop the processing but also to destroy the data resulting from it without undue delay.

Responding to SDAIA

A new 20-business-day period would apply to responses to requests from SDAIA concerning implementation of the Personal Data Protection Law and its Regulations. An entity unable to meet the deadline would need to request an extension with sufficient justification, which SDAIA may approve at its discretion.

Data Subject requests and complaints

A request not fulfilled within the applicable response period would be deemed rejected, and the Data Subject could then complain to SDAIA. The existing 90-day period for submitting a complaint to SDAIA would be removed.

DPO requirements

The draft would remove the existing large-scale qualification for public entities providing services involving Personal Data, while adding a large-scale qualification to the regular and systematic monitoring trigger. 

Other changes

The draft would also add a requirement for privacy policies to use clear, simplified language consistent with the language used to provide the relevant services, including language to accommodate the diverse levels of understanding among the various categories of Data Subjects. Article 23 would also require Controllers not subject to the National Cybersecurity Authority’s controls to comply with recognised cybersecurity standards and best practices.

Commencement

The amended Regulation would enter into force 60 days after its publication in the Official Gazette.

What does this mean in practice?

The draft does not create a standalone AI regulatory regime, and not every technology deployment will engage each of these provisions. What it does illustrate is that how seemingly familiar data protection concepts can become less straightforward when applied to modern AI and cloud architectures.

For businesses deploying technology in the Kingdom, three issues are worth building into the design and procurement process: what Personal Data the system processes; where that data is stored, processed and transferred across the technology stack; and whether the characteristics of the particular use case bring it within one of the proposed Article 25 impact-assessment triggers.

Those questions also have a contractual dimension. Where third-party AI or cloud providers are involved, organisations need to test whether their contractual terms provide enough visibility over data location, sub-processors, use of customer data, incident notification and regulatory co-operation to support their own Personal Data Protection Law obligations.

Answering those questions early during procurement, implementation and contract negotiations may help organisations identify potential compliance obligations and reduce implementation risks if the proposals are adopted in their current form.

Why does the detail matter?

The consultation is worth watching because several of its apparently simple concepts become more challenging at the point where law meets technical architecture. How SDAIA ultimately frames concepts such as ‘emerging technologies’ and in-Kingdom storage may therefore be as important for technology businesses as the headline amendments themselves.

Businesses developing or deploying AI, cloud and other data-driven technologies in the Kingdom should understand what Personal Data their systems process and where that data is stored and processed, and whether it is transferred across the technology stack. While the proposals remain subject to consultation, organisations should start assessing how their technology architecture, data flows and arrangements with third-party providers could be affected if the amendments are adopted in their current form. If you would like to discuss the implications of the proposed amendments for your organisation, please contact Christine Khoury or Noor Al Wari. To stay up to date with legal and regulatory developments affecting technology businesses in the Middle East, subscribe to our newsletter.