Why an EU AI Act file is not a Saudi file

The two regimes do not attach their obligations to the same object. Three consequences follow, and no crosswalk resolves them.

The first thing most teams do, when a system built for the European market is headed for Saudi Arabia, is to put the two regimes side by side and look for the matching row. AI Act in one column, the Saudi regime in the other. Article against article, requirement against requirement.

The exercise works for a while. Then it stops — and it stops in a way that a better table would not fix.

The difference is structural, not one of degree

Europe regulates the system. For high-risk AI, the Act attaches its obligations to the system itself: classed by risk, documented to a common standard, assessed before it reaches the market, watched afterwards. The obligations travel with the product.

The Kingdom has no general AI statute. There is no cross-sector Saudi instrument equivalent to the AI Act. What binds is the Personal Data Protection Law, the National Cybersecurity Authority's controls, and the sector regulators. Each was built for a different object — personal data, an information system, a medical device — and each reaches AI only insofar as the AI touches that object. The obligations attach to the data you hold, the entity you are, and the sector you work in.

This is not a gap waiting to be filled. It is a different architecture.

A note on timing, because it cuts against the intuition

The European obligations described below are not yet in force. The Digital Omnibus, adopted in the summer of 2026, deferred the high-risk regime: Annex III systems now from 2 December 2027, Annex I systems from 2 August 2028. What applies today is narrower — the Article 5 prohibitions since February 2025, the general-purpose model obligations since August 2025, and the Article 50 transparency duties since August 2026.

The requirements themselves did not change. Only the date did.

That deferral sharpens rather than softens the point of this piece. The European file is a future obligation that teams are preparing for. The Saudi obligations are present ones: the PDPL has been fully enforceable since September 2024, registration on the national register already binds a defined set of controllers, and the transfer regime applies now. A team that sequences its work by deadline will arrive in the Kingdom having built the file that is not yet due, and not the one that already is.

Where the two regimes do converge

On substance, they converge more than the contrast suggests. Data quality, human oversight, security, traceability, accountability: these appear on both sides, and anyone comparing the SDAIA AI Ethics Principles with Chapter III of the AI Act will find considerable overlap in what is expected of a responsible system.

That convergence is precisely why the crosswalk is tempting — and why it misleads. The requirements may meet. The instrument that carries them, and the evidence that discharges them, do not.

Consequence one: a gate and a scale do not convert

Under Article 43 of the AI Act, a high-risk system undergoes conformity assessment. The outcome is binary: the system meets the requirements for its class, or it does not. Article 47 then requires an EU declaration of conformity, drawn up by the provider and kept available to the national authorities. It is a gate to the market.

The Saudi instrument is a scale. SDAIA's National Data Management Office awards an AI service provider accreditation across five maturity levels — Conscious, Adoptive, Committed, Reliable, Pioneer — tiered according to the risk involved, assessed at the level of individual products and services, and valid for one year. More than forty entities have received certificates since the scheme opened.

The two do not convert into one another. "Reliable" is not a conformity assessment, and an Article 47 declaration places a provider nowhere on the SDAIA scale. A team that has cleared the European gate has not thereby earned a Saudi level; a team holding a Saudi level has not thereby satisfied Article 43.

Consequence two: supervision follows the object

Because Europe attaches obligations to the system, European supervision follows the system onto the market. Article 74(1) provides that Regulation (EU) 2019/1020 — the general market surveillance framework, written originally for physical goods — applies to AI systems, and that any reference to a product in that Regulation is to be understood as including all AI systems within the AI Act's scope. An AI system is supervised as a product placed on a market.

What that gives an authority is concrete. Access to the technical documentation. Access, where relevant and limited to what is necessary, to the training, validation and testing data, including through APIs. Access to source code only on a reasoned request, and only once assessment based on the provider's own data has been exhausted or proved insufficient. Which authority depends on the system: the sectoral authority for products under Annex I, the national financial supervisor for financial institutions, data protection authorities for law enforcement, biometrics, justice and democratic processes, the European Data Protection Supervisor for Union institutions.

Nor does the obligation stop at the gate. Article 72 requires the provider to collect and analyse performance data across the system's lifetime, according to a post-market monitoring plan — and that plan is part of the technical documentation referred to in Annex IV. The file is not an archive. It keeps running.

The Kingdom has no general AI market surveillance, because no instrument attaches to the system. What the authority sees is what the entity has declared. Registration on the national register of controllers is already mandatory under SDAIA's governing rules where a controller processes sensitive data, or where processing personal data is its core activity in the Kingdom; registration is made online, currently without fee, and the certificate expires, with notice before renewal.

The draft amendments to the PDPL Implementing Regulations, in public consultation on the Istitlaa platform from 6 October to 5 November 2026, would move that duty into the Regulations themselves and widen it to four categories: public entities; controllers whose core activities require processing personal data; controllers processing sensitive data or data concerning persons lacking legal capacity; and controllers that transfer or disclose personal data outside the Kingdom. That last trigger is the one to watch. It catches a great many foreign controllers who have so far considered themselves out of scope.

Consequence three: there is no Saudi Annex IV

Annex IV enumerates what the technical documentation of a high-risk system must contain: the same list for every such system, whatever the sector. Article 11(1) sets those elements as a minimum, and provides that SMEs, including start-ups, may supply them in a simplified form on a template the Commission establishes and notified bodies must accept — the form changes, the list does not.

What is striking is Article 11(2). Where the high-risk system relates to a product covered by the Union harmonisation legislation in Annex I, Section A — medical devices, machinery, and the rest — a single set of technical documentation is drawn up, containing both the sectoral information and the Annex IV content. Europe stays horizontal through the sector: the sectoral file absorbs the common core rather than displacing it.

The Kingdom's position is the mirror image, and it is worth being precise about where the file actually sits. The SFDA's Guidance on Digital Health Products, MDS-G027 of 11 August 2025, largely settles a prior question: whether a product is a regulated device at all. The technical documentation itself sits in the marketing authorisation requirements — MDS-REQ1, Annex 3, or Annex 4 for in-vitro diagnostics — to which the SFDA's AI and machine-learning device guidance, MDS-G010, points. That dossier covers device description, design information, essential principles, benefit-risk and risk management, verification and validation, and a post-market surveillance plan, with significant changes notified through GHAD.

Which makes the asymmetry sharper than a first reading suggests. The nearest Saudi equivalent of Annex IV is not an AI instrument at all. It is a device dossier, reached by a device route, and nothing takes a team there unless its product is a medical device in the first place.

That does not mean an AI system outside the device line generates no documentation. Article 25 of the PDPL Implementing Regulations requires a written impact assessment wherever health data is processed, or where large-scale processing involves automated decisions, covering the risks to data subjects and how they are mitigated. But note where that document sits: it is held by the controller, not by the vendor. A hospital buying an AI tool that never qualifies as a device inherits a file its supplier was never required to produce. In Europe the documentary burden falls on whoever builds the system; in the Kingdom it falls on whoever runs the data.

A note on an objection worth anticipating. The NDMO's national data governance framework, organised across fifteen domains and assessed periodically through a combination of self-assessment and evidence review, is sometimes offered as the Saudi horizontal referential. It is not an Annex IV equivalent. It evaluates the maturity of an organisation's data management; it does not describe a system's training data, architecture, performance metrics or human-oversight measures. It belongs to the other storey — the one this analysis identifies.

What this means in practice

The practical consequence is not that compliance work must be done twice. On substance, much of it is reusable.

What is not reusable is the evidence. What a European authority may demand is system-level and continuous: the technical documentation, the data behind it, the monitoring plan that keeps it current. What a Saudi authority may demand is entity-level and declarative: the registration, the records of processing, the impact assessments, the transfer assessments under Article 29 and the SDAIA standard contractual clauses. Same company, same AI, two sets of artefacts that do not substitute for one another.

There is a second, quieter consequence. Where the European question is whether a given change belongs to the system or to its use, the Saudi question presents itself in another vocabulary: whether whoever made that change was deciding a means of processing, and so carries the controller's obligations. The same facts, a different test, and a different set of documents at the end of it.

Teams that discover this late discover it in the worst way: holding a complete file that answers the wrong question.

Two caveats

Neither regime is stricter. Europe is more prescriptive about the file; the PDPL is more demanding about moving data out of the Kingdom and about declaring yourself to the authority. They constrain in different places, not to different degrees.

And three is not the list. These are three consequences of one structural difference. Once the difference is visible, the remaining divergences can be derived rather than catalogued — which is the only durable way to work across the two regimes.

Mapping is not alignment. Alignment is not evidence.

This is general commentary on two regulatory regimes, current at the date shown. It is not advice on any particular organisation's position, and both regimes are moving: the European dates were changed in 2026, and the Saudi consultation closes on 5 November 2026.

Sources. Regulation (EU) 2024/1689, Articles 11, 43, 47, 72 and 74, and Annex IV, as amended by the 2026 Digital Omnibus · Saudi Personal Data Protection Law and its Implementing Regulations; Rules Governing the National Register of Controllers; draft amendments in consultation, 6 October – 5 November 2026 · SDAIA AI service provider accreditation · NDMO national data governance framework · SFDA MDS-G027, Guidance on Digital Health Products, v1.0, 11 August 2025; MDS-G010, Guidance on AI and ML technologies based Medical Devices, v1.0, 29 November 2022; MDS-REQ1 marketing authorisation requirements.