Cross-border scope and responsibilities
EU AI Act Relevance for Saudi Companies
Assess EU connections, provider and deployer roles, amended dates and practical evidence for Saudi AI activities involving European markets.
A Saudi company can fall within the EU AI Act's scope because of how it supplies or uses an AI system in relation to the European Union. Its Saudi incorporation or hosting location does not settle the question. The assessment must identify the activity, the parties' roles, where the system or its output is used, and the rules and dates relevant to that activity.
This guide is for Saudi software exporters, group legal teams, product owners and procurement leaders. It provides a practical scoping method and an illustrative recruitment-software case. It reflects official materials checked on 24 October 2026, including the amended implementation timetable. Use qualified EU and Saudi legal review for an actual market-entry or deployment decision.
Test the connection to the EU before classifying risk
Article 2 includes providers supplying AI systems into the Union regardless of establishment, EU deployers, and certain third-country providers or deployers where outputs are used in the Union. The full provision includes exclusions and qualifications. Assess the actual connection rather than treating every Saudi AI use as subject to the Act.
Prepare a factual map. Identify the legal entities, buyer, intended users, markets, product delivery and downstream use of outputs. Include group arrangements: an assessment produced by a Saudi shared-service team may be used by an EU subsidiary even when the technical service remains outside Europe.
A website accessible from Europe is not a complete analysis of market activity. Conversely, describing a contract as offshore does not resolve where the AI is supplied or its output used. Preserve evidence such as contractual scope, deployment plans and intended-use statements for the legal assessment.
Complete this jurisdiction step before assigning a risk label. A high-impact internal use and an activity within the Act's legal scope are different questions, although both can deserve strong governance.
Identify the role from the activity, not the job title
The Act's definitions distinguish providers, deployers, importers, distributors and authorised representatives. A company developing or having a system developed and supplying it under its own name can have a different role from a company using it under its authority. Map each entity's actual activity to the definitions.
A Saudi software company and its EU customer should not assume that a contract label allocates every statutory responsibility. The distribution arrangement may introduce other parties, but an importer should not be invented simply because the transaction crosses a border. Determine whether a party performs the defined role.
Distinguish the AI system from an underlying general-purpose model. Integrating a model into an application does not make every downstream business the original model provider. Equally, using a third-party model does not remove the application provider's own responsibilities for the system it supplies.
| Evidence field | Question for the review |
|---|---|
| Entity and location | Which legal person performs the activity? |
| System and intended purpose | What is supplied or used, and for which decision? |
| Name and commercial arrangement | Under whose identity is the system placed or made available? |
| Operational authority | Who determines use, configures it and relies on outputs? |
| Supply chain | Do any parties perform importer, distributor or representative roles? |
| Changes | Who can alter purpose, branding or functionality? |
Record the legal conclusion, its author and the facts it depends on. A role assessment should be revisited when those facts change.
Use the amended timetable as at October 2026
The official implementation timeline incorporates the Digital Omnibus on AI. The general application date remains 2 August 2026, with earlier and later phases. The timetable is therefore not accurately described as either “nothing applies yet” or “every high-risk duty applied in August 2026”.
| Milestone | Date |
|---|---|
| Initial general provisions, AI literacy and prohibitions | 2 February 2025, subject to later-added provisions |
| General-purpose AI and governance phase | 2 August 2025 |
| General application, including transparency phase | 2 August 2026, with relevant transitions |
| Relevant Annex III high-risk provisions | 2 December 2027 |
| Relevant Annex I high-risk provisions | 2 August 2028 |
Amended Article 113 specifies the phased application of the high-risk sections. Check additional transitions, existing-system provisions and activity-specific obligations separately. A future high-risk date does not suspend already applicable rules or other legislation.
Assign a legal owner to maintain the timetable in the programme. Use a dated source and a named review trigger when official guidance or legislation changes. Sales teams should not reuse an old slide that presents an obsolete deadline.
Worked example: Saudi recruitment software supplied to an EU employer
Consider an illustrative Saudi software supplier offering an application that evaluates job applications and ranks candidates for an EU employer. The employer uses the ranking to decide whom recruiters review first. A third-party language model supports parts of the application, but the supplier markets the recruitment product under its own name.
The first assessment maps the supplier's and employer's roles and the EU market connection. It then examines the intended purpose and actual influence on recruitment. The employment category in Annex III expressly addresses recruitment and candidate evaluation. The applicable classification must be assessed with Article 6 and the facts of the service.
The supplier cannot resolve the question merely by adding “human reviewed” to the product description. If recruiters only see the highest-ranked candidates, the ranking influences who receives meaningful attention. The review should inspect the entire process, including excluded candidates and the practical ability to challenge the output.
For this example, the programme treats the recruitment purpose as requiring a serious high-risk classification review and prepares for the relevant obligations under the amended dates. It does not claim that a generic assistant licence, an ISO certificate or a human sign-off automatically changes the classification.
A separate feature that only arranges interview calendar slots may require a different analysis. Do not bundle its conclusion with candidate evaluation simply because both features appear in the same product. Describe the intended purpose and functional connection of each.
Examine classification exceptions with evidence
Article 6 contains conditions under which certain Annex III systems are not treated as high-risk, alongside an important rule concerning profiling of natural persons. The conditions require a factual assessment; “preparatory” or “administrative” is not a self-executing exemption label.
Document what the system does and how its output affects the outcome. Show which information a human sees, what choices remain available and whether an incorrect output could materially influence the decision. A process diagram should include the people who never reach the reviewer because of an earlier automated filter.
Where a legal conclusion relies on a limited task, control that limitation in the product and customer instructions. A sales promise that encourages broader use can undermine the factual premise of the classification. Maintain consistency among technical documentation, instructions and commercial material.
Keep the internal AI use-case risk classification separate from the legal classification. An organisation may impose strong controls on a use even where a particular statutory category does not apply. The internal label should not be presented as the regulator's conclusion.
Build an obligation register by role and date
After scope and classification, record each relevant obligation with its legal source, responsible entity, application date and evidence owner. Distinguish an obligation already in force from a future requirement being prepared for. Add the dependencies needed to deliver the evidence.
For the recruitment example, the team should identify which system information the provider must produce, what the employer needs to operate the service appropriately and which responsibilities require coordination. Legal specialists determine the applicable duties; the operating team turns them into owned work.
Do not give a supplier questionnaire the status of a conformity assessment. It can collect useful information while leaving important issues unresolved. The third-party AI questionnaire should feed the obligation register and evidence review rather than become an automatic approval.
Include evidence that crosses company boundaries. If the employer must understand limitations or monitor a particular outcome, the provider's delivery should make that practical. A contractual statement without usable information can leave both parties unable to operate their responsibilities.
Control changes that can alter responsibilities
The Act's value-chain provisions address circumstances in which rebranding, substantial modification or changed intended purpose can change provider responsibilities for high-risk systems. Review the actual conditions and application dates; not every minor configuration change has the same legal effect.
Set commercial and technical change triggers. Examples include a customer asking to use a general assistant for candidate scoring, adding a ranking feature, changing the branded supplier or expanding the product's intended population. Route the change before it is sold or enabled.
Maintain a baseline of the assessed configuration and purpose. Record what changed, who requested it, the effect on evidence and the resulting decision. The AI change-trigger design should connect product, sales, legal and deployment teams so each sees the same change.
Supplier terms should support the information and assistance needed for the applicable responsibilities. Do not assume a generic model contract supplies every document or access right required for a downstream regulated system.
Keep AI Act, privacy and Saudi obligations distinct
An EU AI Act assessment does not replace a privacy assessment. Candidate data, customer records and cross-border transfers may engage separate data-protection rules. The legal team should map the parties' privacy roles and relevant processing arrangements independently of their AI Act roles.
The same organisation may have obligations in Saudi Arabia as well as in Europe. Use the PDPL and AI governance workflow to connect Saudi privacy review to the processing facts. Avoid assuming that satisfying one jurisdiction's conditions automatically satisfies the other.
A shared evidence package can support both reviews. Data-flow maps, intended-use descriptions, access tests and supplier commitments may be reusable, but each conclusion should identify the rule and facts it addresses. Shared evidence is not the same as interchangeable legal tests.
Where obligations create a design constraint, resolve it before promising a deployment. A hosting or support arrangement that is commercially convenient may need adjustment after the full processing and responsibility review.
Prepare customer evidence without overpromising compliance
Give prospective customers a precise description of intended use, supported configuration, known limitations and review responsibilities. Identify which claims are demonstrated, contractually committed, planned or unresolved. A broad “EU AI Act ready” badge is less useful than evidence tied to the customer's use.
For the recruitment application, prepare documentation showing the inputs, outputs, ranking effect, evaluation approach and human operating process. Explain how the customer should report unexpected behaviour and how changes are communicated. The model-documentation guide supports the technical portion of that package.
Keep sensitive information protected during due diligence. Provide controlled access or appropriately prepared examples where necessary. The need for evidence does not justify distributing personal candidate records to every prospect or reviewer.
Use ISO 42001 and NIST AI RMF as supporting governance references where appropriate, while keeping their claims separate from the legal assessment and any required conformity process.
Make cross-border oversight operational
Assign an owner for regulatory changes, a product owner for assessed purpose, and a service owner for deployed configuration. Establish how those people coordinate when an EU customer requests a new use or reports an incident. A policy statement without that route leaves the practical response uncertain.
Test the process with a realistic scenario: an employer changes ranking criteria and reports that a candidate group is being excluded. Determine who preserves evidence, assesses scope and impact, decides a temporary restriction and communicates with the relevant parties. Applicable reporting duties require their own legal assessment.
Maintain a record of customer-specific configurations and allowed uses. The supplier should be able to identify which customers are affected by a model or feature change, without assuming every installation is identical.
Review the programme as the application dates approach and as official materials change. Preparation should produce usable controls and evidence, rather than a timetable that postpones all work until the final month.
Test the market-entry conclusion against real commercial variations
Before relying on the recruitment example's analysis, vary the proposed arrangement and record what changes. One customer may use a standard hosted application under the supplier's name; another may request a rebranded service; a third may modify the intended purpose or integrate the output into a different decision process. These variations do not necessarily produce the same role or obligation analysis.
Use a commercial change sheet that records the parties, establishment locations, intended purpose, branding, model and application responsibilities, output users and proposed modifications. Have the qualified reviewer identify which legal conclusions remain supported and which need further analysis. Do not resolve a role question merely by putting a preferred label in a contract when the actual activities differ.
For the candidate-evaluation service, compare a draft-writing feature with a ranking feature using the intended workflow and actual output influence. Record who sees the output, whether it determines a shortlist and what meaningful review occurs. The exercise is not a shortcut to an exemption; it is a way to expose facts the classification and obligation review must address.
Connect the legal conclusion to the release record. A sales team should not describe the approved market, role or deployment arrangement more broadly than the assessment supports. If a customer asks for a materially different integration, make the unresolved review visible before promising a delivery scope. A contract deadline is not evidence that the new configuration has been assessed.
Keep a dated statement of assumptions with the evidence pack. Identify the text and timetable used, the application characteristics reviewed and any transition provision requiring separate confirmation. When an amendment, implementing measure or official interpretation changes a relevant premise, the owner can reopen the specific conclusion rather than asking every team to reconstruct the entire analysis.
Finally, rehearse a handover from legal review to product operation. Ask the product owner which features are permitted, procurement what evidence must be obtained from upstream providers, and the customer team which statements it may make. If these answers diverge, a correct legal memorandum has not yet become a controlled market-entry decision.
Use a clear market-entry decision pack
A useful decision pack contains the EU connection, entity roles, system and purpose, classification rationale, applicable dates, obligation owners, evidence gaps and launch conditions. It should distinguish the legal conclusion from the commercial decision and identify which unresolved facts could change either.
For AI governance setup, bring the product description, intended customers, deployment flow, supplier arrangements and existing legal analysis. Discuss governance for AI activities involving EU markets with Open for AI to build the operating records and review routes around that analysis. The resulting system should help the organisation keep its assessed purpose, evidence and customer commitments aligned as the product evolves.
FAQ
Your questions, answered.
Can the EU AI Act apply to an AI supplier established in Saudi Arabia?
Potentially, depending on the activity and connection to the Union. Assess the supply of the system, the parties’ roles and where outputs are used, alongside the full scope provisions and exclusions. Saudi incorporation or hosting is not a complete answer. Prepare a factual map for qualified legal review rather than assuming that every Saudi use is covered or that none can be.
What are the current high-risk AI Act dates relevant to Saudi exporters?
As checked on 24 October 2026, the amended timetable places the relevant Annex III high-risk provisions at 2 December 2027 and the relevant Annex I provisions at 2 August 2028. Other parts already apply, and specific transitions must be checked. Maintain a dated obligation register for the actual system and role; do not use these later dates to postpone already applicable duties.
Does a human recruiter reviewing AI rankings remove high-risk classification?
Human involvement does not by itself settle classification. Examine the intended recruitment purpose and whether the ranking materially influences who receives consideration. A reviewer may never see candidates filtered out earlier. Assess the full workflow under the applicable classification rules and document the rationale. A human-review label on a sales page is not evidence that the relevant legal conditions are satisfied.
Is every EU customer an importer of Saudi AI software?
No role should be assumed solely because the transaction is cross-border. Identify which entity develops, brands, places, makes available or uses the system, then apply the relevant definitions. The customer may act as a deployer, while other distribution arrangements can introduce different roles. Preserve the actual contractual and operational facts and obtain legal review of the role allocation.
Can using a third-party language model remove the application supplier’s responsibilities?
It does not automatically remove responsibilities for the system supplied under the application provider’s name. Distinguish the underlying model from the application, its intended purpose and its effect on users. Identify which evidence and assistance the upstream supplier provides and what remains with the downstream organisation. A generic model contract should not be assumed to cover all needs of the finished system.
When should a Saudi software company reassess its EU AI Act role?
Reassess when branding, intended purpose, functionality, distribution or the customer’s use changes materially. A request to turn a general assistant into candidate scoring is different from a minor cosmetic setting. Record the assessed baseline and route the proposed change through product, legal and deployment owners. The actual role consequence depends on the law’s conditions and the relevant application dates.
Does AI Act preparation also establish PDPL or GDPR compliance?
No automatic conclusion follows. Privacy roles, processing purposes and transfer arrangements need their own analysis under the applicable rules. Evidence such as a data-flow map can support several reviews, but the legal tests remain distinct. Maintain separate conclusions and coordinate the resulting controls so the product and supplier commitments can satisfy the relevant requirements together.
What should a Saudi AI exporter put in an EU market-entry decision pack?
Include the EU connection, legal entities and roles, system purpose, classification rationale, relevant dates, obligation owners, evidence gaps and launch conditions. Link the analysis to actual product documentation and customer commitments. Identify facts that could change the conclusion and assign an update owner. The pack should support a concrete legal and commercial decision rather than a broad claim of being AI Act ready.