SDAIA AI Ethics Principles: Turning Principles Into Engineering Controls

This is for CIOs and heads of automation running agents in the Kingdom who have been handed the principles by a customer, a board or internal audit and asked to demonstrate compliance. The document is short and readable, and it does not tell an architect what to build, which is why most responses to it are a slide deck. This piece converts each principle into something an architecture review can pass or fail.

What the document is, and what it is not

The AI Ethics Principles published by SDAIA, Version 1.0 dated September 2023, state that they apply to all AI stakeholders designing, developing, deploying, implementing, using or being affected by AI systems within the Kingdom, naming public entities, private entities, non-profits, researchers and individuals. That is a statement of intended reach, not a legal obligation. The Principles are not a royal decree, and carry no penalty schedule and no enforcement process of their own.

They matter anyway, for two reasons. They are the vocabulary of Saudi procurement: buyers now draw AI ethics questions straight from this list, and an answer that restates the principle back is scored as no answer. And several principles restate things that are binding under the Personal Data Protection Law (Royal Decree M/19, as amended by Royal Decree M/148) and its Executive Regulations. The privacy principle has legal teeth the document itself does not describe.

The seven principles are Fairness; Privacy and Security; Humanity; Social and Environmental Benefits; Reliability and Safety; Transparency and Explainability; and Accountability and Responsibility.

It also sets four risk levels: little or no risk, where compliance is recommended without restriction; limited risk, where the principles apply; high risk, which attracts pre- and post-conformity assessments; and unacceptable risk, covering systems that threaten safety, livelihood and rights, which are prohibited. Reliability and Safety carries an explicit prohibition on social scoring and mass surveillance.

[NEEDS SOURCE: whether SDAIA has published a Version 2.0 of the AI Ethics Principles, and what changed. The sdaia.gov.sa host was not reachable during research.]

The translation table

The middle two columns are the point: a principle without an evidence artefact is a slide, and an evidence artefact without a named signatory is an orphan.

Principle	Engineering control	Evidence artefact	Who signs it
Fairness	A held-out evaluation set stratified by the attributes that could produce disparate treatment, with a disparity metric and a numeric threshold that fails the build	Evaluation set specification, per-cohort results, threshold, last three runs	Head of data science, countersigned by the business owner
Privacy and Security	NDMO classification before ingestion, a documented residency decision per store, tokenisation of direct identifiers before the prompt, retention set per store	Classification register, residency decision record, transfer risk assessment where data leaves the Kingdom	Data protection officer, residency decision countersigned by the CIO
Humanity	Prohibited-use list enforced in the orchestration layer, not in policy: blocked tool combinations, blocked intents, a refusal path with a logged reason	Prohibited-use register, refusal logs sampled quarterly	Head of automation, reviewed by legal
Social and Environmental Benefits	A benefit hypothesis per deployment with the measure that would falsify it, plus recorded inference cost	Business case with the falsifying measure and its post-deployment reading	Sponsoring executive
Reliability and Safety	An eval suite covering task success, refusal correctness, tool-call accuracy and injection resistance, wired to a gate that blocks promotion on breach	Eval suite in version control, gate configuration, promotion log per release	Engineering lead
Transparency and Explainability	A model card per system, a decision trace per run linking input, tools called, sources retrieved and output, and an interface disclosure that the counterparty is a machine	Model card, retained traces, screenshot of the live disclosure with its version	Product owner
Accountability and Responsibility	A single named owner per agent, an escalation path with response times, and a kill switch a named on-call person can operate without a deployment	System register entry with owner and deputy, escalation runbook, kill switch test record	The named owner, ratified by the AI governance committee

Two deserve expanding, because they are where the paperwork usually diverges from the system.

Fairness: a threshold, not an intention

The principle asks for training data cleansed of bias, inclusive representation and fairness metrics applied across the lifecycle. In an agent system the model is usually a third-party endpoint whose training data you cannot inspect, so cleansing training data is not a control you can implement. Measurement at the boundary you control is.

Build the evaluation set from your own decisions, not a public benchmark. For a credit or eligibility agent, a stratified sample of historic cases with known outcomes; for a service agent, paired prompts differing only in the attribute of concern. Fix the disparity metric in advance and write down the threshold, because a metric chosen after seeing results is not a control. Re-run on every model version change, including silent provider-side updates, which is why it must be automated rather than annual.

A fairness evaluation for a Saudi deployment that only tests English prompts has not tested the population. Paired Arabic and English prompts, including dialect forms where your users write that way, are the minimum. Refusal rate by language is the metric most teams have never measured and the one most likely to show a gap.

Privacy: where NDMO classification meets the residency decision

This is the principle with binding law behind it. The Executive Regulations of the PDPL require, at Article 25, a written and documented assessment of potential harms to data subjects, triggered by circumstances including sensitive data processing, combining multiple datasets, large-scale monitoring, emerging technologies and automated decisions. An agent deployment normally trips several at once. Article 33 requires records of processing kept during processing and for five years afterwards, including purposes, data categories, retention periods, recipients and the technical, administrative and organisational measures protecting the data. Article 32 governs the appointment of a data protection officer, and Article 11 requires consent documented separately per purpose, with explicit consent for sensitive data, credit data and automated decision-making.

That last clause is the one agent teams miss. If your agent decides about a person without a human in the loop, the Regulations point at explicit consent, not the general consent captured at account opening.

Classification comes first in sequence. SDAIA's Data Sharing Policy applies classification-dependent controls: a sharing agreement for secret or top secret data signed by the entity's first officer, restricted data signed by the director of the data management office, public data exempt. Authority to release depends on classification, so an agent retrieving across a mixed corpus needs classification carried in chunk metadata and enforced at retrieval, not at the answer. [NEEDS SOURCE: the NDMO Data Classification Policy itself, its exact level names and definitions, and whether it binds private-sector entities or only government entities. The sdaia.gov.sa host was not reachable during research.]

The residency decision follows. The Regulation on Transferring Personal Data Outside the Kingdom sets, at Article 3, criteria for assessing whether a destination provides an appropriate level of protection, reviewed every four years. Article 4 lists exemption cases, including centralised operational processes within a multinational group and direct service provision to the data subject, generally excluding sensitive data. Article 7 requires a risk assessment before transfer where you rely on an Article 4 case, or where sensitive data moves continuously or at large scale, covering purpose, nature and scope of processing, adequacy of safeguards, minimisation, potential harms and preventive controls.

For an agent stack, a transfer happens the moment a prompt containing personal data reaches a model endpoint outside the Kingdom. That is the transfer to assess, and it belongs in the design record before the endpoint is chosen, not in a retrospective register.

A pre-deployment review procedure

Run this as a gate before an agent touches production data. Each step ends in an artefact, and the review fails if the artefact does not exist.

1. Write the system description. Purpose in one sentence, the decisions it makes or influences, the tools it can call, the data classes each tool sees, and the oversight mode per decision type. If the purpose needs two sentences, the scope is wrong.
2. Classify the risk level against the four levels in the Principles, and record the reasoning. A high-risk determination pulls in the conformity assessments; an unacceptable-risk determination stops the project.
3. Classify the data every tool and retrieval source can reach, under NDMO rules, before ingestion. Record the classification against each source and each index; this is what later governs who may authorise a release.
4. Complete the PDPL impact assessment under Article 25 of the Executive Regulations, in writing, naming the triggering circumstances rather than asserting a general risk rating.
5. Take the residency decision explicitly. For each model endpoint, vector store, observability vendor and transcription service, record where processing occurs. Where data leaves the Kingdom, complete the Article 7 risk assessment and record which Article 4 basis or adequacy finding you rely on.
6. Fix the consent position. Identify decisions taken without a human in the loop and confirm whether explicit consent is required and how it is captured, separately per purpose, with withdrawal readable mid-run rather than only at session start.
7. Build and freeze the evaluation set. Stratified, bilingual, with the disparity metric and threshold written down before the first run, in version control alongside the code.
8. Wire the regression gate. Task success, refusal correctness, tool-call accuracy and prompt-injection resistance, with promotion blocked on breach. A gate that can be overridden without a recorded approver is not a gate.
9. Publish the model card. Intended use, out-of-scope uses, models and versions, retrieval sources with their classifications, known limitations, evaluation results and the date. One page, versioned, updated when the tool set changes.
10. Instrument the decision trace. Input, tools called, arguments, sources retrieved with document identifiers, model and prompt version, output and the human action taken. Redact at the SDK boundary before traces leave your network.
11. Put the disclosure in the interface, at first contact, in Arabic and English. Version the wording and store the version identifier against the interaction.
12. Name the owner and test the kill switch. One accountable individual and a deputy, an escalation runbook with response times, and a recorded test showing the on-call person can stop the system without a deployment. Keep these twelve artefacts together: assembling them after a tender lands takes three weeks, and as a by-product of the gate it takes an afternoon.

What else is moving in the Kingdom

SDAIA published Generative AI guidelines in January 2024, one set directed at government entities and one at a general audience. [NEEDS SOURCE: the exact titles, version numbers and substantive content of SDAIA's Generative AI guidelines and of the AI Adoption Framework. The sdaia.gov.sa host returned an access rejection throughout research.]

The National Cybersecurity Authority ran a public consultation on AI Cybersecurity Guidelines, posted 5 July 2026 and closing 5 August 2026, organised around cybersecurity governance, defence, resilience and third-party cybersecurity. Given how the NCA has treated its other control sets, plan for these to become an expectation in regulated sectors. [NEEDS SOURCE: whether the NCA AI Cybersecurity Guidelines have been published in final form, and whether they are mandatory controls or guidance.]

A draft Global AI Hub Law, providing for data embassies and hosted foreign jurisdictional arrangements, went to public consultation in 2025. [NEEDS SOURCE: the current status of the Global AI Hub Law, the consulting authority and whether it has been enacted.] If enacted it changes the residency conversation, which is a reason to record residency decisions in a form you can revisit rather than burying them in an architecture diagram.

Where teams get this wrong

Answering the principle with the principle. A tender response saying "our systems are designed to be fair and transparent" scores nothing. The response that scores names the evaluation set, the metric, the threshold, the last result and the person who signs it.

Classifying after ingestion. Data is loaded into a vector store and classification is attempted afterwards by inspecting chunks. It cannot be done reliably at that point, and the store then cannot enforce retrieval by classification. Classify at the source, carry the label into chunk metadata, filter at retrieval.

One consent flag per customer. The Executive Regulations want consent documented separately per purpose, with explicit consent for automated decision-making. A boolean on the customer record cannot express that, nor withdrawal for one purpose while another continues.

Evaluation sets built from production transcripts. They contain personal data, get version-pinned, get copied into three repositories, and are the copy every erasure process misses. Build from synthetic or pseudonymised data and write down the rule.

Treating the model provider as out of scope. Prompts leaving the Kingdom are a transfer. Retention of prompts and completions, training use, abuse-monitoring log handling and sub-processors belong in the data processing agreement, and the answers change by endpoint and contract tier.

No owner. The most common finding. The system has a project manager, a vendor and a steering committee, and no individual accountable for its behaviour on a Thursday afternoon.

What to automate, and what not to

Automate the evidence. The classification register, the residency decision record, per-run decision traces, model card generation from the deployment manifest, and the promotion log with eval results per release are mechanical and impossible to reconstruct honestly after the fact. Automate the evaluation runs too, because a fairness threshold checked only when someone remembers is not a threshold.

Do not automate the determinations. The risk-level classification, whether a use is prohibited, whether a disparity result is acceptable in context, and whether a transfer basis holds are judgements a named person signs and defends. A tool should assemble the evidence and get that person to a decision quickly. It should never generate the impact assessment text, because the assessment is the record of somebody having thought about it.

Where a system helps

The recurring failure is a missing record rather than a missing control: nobody can show which classification a retrieval source carried, which model version answered in March, what the disparity metric read at the last release, or who approved the run. CohortaOS records data classification per source, model and prompt version per run and eval results per promotion, and keeps an action ledger of every downstream write, so a principle-by-principle evidence request is a query rather than a project.

Related reading: What Is the DPDP Act? (KB-005); Dubai's Agentic AI Direction: What It Means Operationally for Private Companies (KB-047).

FAQ

Are the SDAIA AI Ethics Principles legally binding on a private company? They are principles, not a decree, and carry no penalty schedule of their own, though the document states a broad intended scope covering public and private entities in the Kingdom. What binds is the PDPL and its Executive Regulations, which sit behind the privacy principle. In practice the Principles bind commercially, through procurement questions and contractual assurance clauses.

How do the Principles relate to the Saudi PDPL? The Privacy and Security principle overlaps directly with law. The Executive Regulations require a documented impact assessment under Article 25 for circumstances including automated decisions and emerging technologies, records of processing under Article 33 kept for five years afterwards, and consent documented separately per purpose under Article 11, with explicit consent for automated decision-making.

What counts as high risk under the classification? High risk attracts pre- and post-conformity assessments and statutory requirements; unacceptable risk covers systems threatening safety, livelihood and rights, which are prohibited, with social scoring and mass surveillance named. [NEEDS SOURCE: SDAIA's detailed criteria for assigning a system to the high-risk level, and the form the conformity assessment takes.]

Do we have to keep personal data inside the Kingdom? Not automatically. The Regulation on Transferring Personal Data Outside the Kingdom permits transfer where the destination provides an appropriate level of protection under Article 3, or where an Article 4 exemption applies with appropriate safeguards. Article 7 requires a documented risk assessment for Article 4 transfers and for continuous or large-scale sensitive data transfers. Sector rules may impose stricter residency.

Sources

• SDAIA, AI Ethics Principles, Version 1.0, September 2023 (PDF)
• SDAIA, Personal Data Protection Law (Royal Decree M/19)
• SDAIA, Executive Regulations of the Personal Data Protection Law
• SDAIA, Regulation on Transferring Personal Data Outside the Kingdom
• SDAIA / NDMO, Data Sharing Policy (PDF)
• National Cybersecurity Authority, AI Cybersecurity Guidelines (public consultation)