SDAIA’s National AI Risk Management Framework: A Practical Guide for Saudi Organisations
SDAIA launched its National AI Risk Management Framework in July 2026. Here is what it contains, how it relates to PDPL and earlier guidance, and how to turn it into a risk register and controls for an AI assistant.
In July 2026 the Saudi Data and Artificial Intelligence Authority released the National Artificial Intelligence Risk Management Framework, which the Saudi Press Agency described as a guidance reference giving government and private entities a single national method for identifying, assessing, treating and monitoring AI risks. For an organisation that has put an AI assistant in front of customers or staff, or is about to, it is the most practical document SDAIA has issued on AI so far, because it moves from principles to procedure.
This article sets out what was actually published, where it sits among SDAIA’s earlier instruments, and how to turn it into working controls for a real deployment. It is a practical reading for people who have to run these systems. It is not legal advice.
What SDAIA published, and when
The dates need care, because three of them appear in coverage. Legal commentary from the law firm Gowling WLG, and the documentation of at least one governance-software vendor, date the framework document itself to April 2026. The public launch, carried by the Saudi Press Agency and republished across Saudi newspapers, came on 14 July 2026. On 30 July 2026 SDAIA held an introductory session at the AI Oasis in Riyadh, attended by more than 150 specialists in risk, governance, compliance and technology from 45 government and private entities.
We found no further SDAIA publication of the framework in September 2026; the announcement and briefing were both in July. What follows describes the framework as reported in those July accounts and in legal commentary on the document, read as of the end of September 2026.
SDAIA’s own justification for a separate method is the most useful sentence in the coverage. AI risks, it says, differ from conventional software risks: they can appear unexpectedly during operation, change over time, and be hard to explain or reproduce. That is the whole case for the framework. A risk register written once at go-live does not describe a system whose behaviour can drift after it.
What is inside the framework
The framework rests on seven principles, listed in the Saudi Press Agency report as integrity and fairness; privacy and security; humanity; reliability and safety; transparency and explainability; accountability and responsibility; and social and environmental benefit. They are the same seven SDAIA set out in its AI Ethics Principles, which is deliberate: the risk framework is the operational layer beneath them.
Gowling’s summary describes the framework’s reference base as general principles grounded in Islamic values — justice, transparency, protection of rights, human dignity and avoiding harm — alongside three regulatory pillars: AI regulations, data regulations and sector-specific regulations. In plain terms, a risk you identify is judged against ethics, against data law and against whatever your own regulator expects.
It names three audiences — developers, who are expected to build risk management into design, training and testing; operators, who run and monitor systems day to day; and policymakers, who judge whether existing rules are enough. Its stated scope is government and private organisations regardless of sector or digital maturity, with a focus on high-impact systems: predictive models, natural language processing, image and video analysis, intelligent automation and general-purpose models such as large language models.
It sorts AI risks into seven categories, which Gowling lists as bias, discrimination and harm; privacy and security; misinformation; harmful use; human–machine interaction; socioeconomic and environmental impacts; and safety and limitations. And it includes a worked example — a government entity using a model to prepare internal reports — walked through identification, assessment, treatment and monitoring.
An AI assistant that answers customers in natural language sits squarely inside that scope. If you operate one, you are the “operator” the framework is written for, even if someone else built the model.
Where it sits among SDAIA’s earlier instruments
The framework is the latest step in a sequence that has moved, over three years, from principles towards methods an organisation can execute.
- Sep 2023PDPL in forceThe Personal Data Protection Law took effect on 14 September 2023 with its Implementing Regulations and Personal Data Transfer Regulations, published a week earlier, and a one-year grace period.
- Sep 2023AI Ethics PrinciplesSeven principles and a risk typology running in four tiers from little or no risk to unacceptable risk.
- Jan 2024Generative AI guidelinesTwo documents: one for government entities handling government data, one for the public and developers.
- Sep 2024AI Adoption FrameworkUnveiled at the Global AI Summit in Riyadh; the PDPL grace period ended on 14 September the same month.
- Apr 2026Risk framework documentThe National AI Risk Management Framework, dated April 2026 in legal commentary.
- Jul 2026Public launch and briefingAnnounced on 14 July; introduced to 45 government and private entities on 30 July.
Read in order, the pattern is clear. The ethics principles said what good looks like. The generative AI guidelines said what to be careful of with one class of tool. The adoption framework said how to organise for AI. The risk framework says how to find, score, fix and keep watching the specific things that can go wrong with a specific system — which is the question an operator is actually left holding.
Guidance, not law, and the parts that are law
The Saudi Press Agency calls the framework a guidance reference, and Gowling describes it as a governance and risk management tool rather than a technical standard. We found nothing in the coverage that attaches penalties to it. That is not the same as saying it can be ignored.
The Personal Data Protection Law does carry obligations, and they apply to an AI assistant that touches personal data. Its Implementing Regulations require a data protection impact assessment for processing that involves, among other things, sensitive data, new technologies, automated decision-making or continuous monitoring of data subjects — a list an AI assistant can hit on several counts at once. Breaches that may harm data subjects must be notified to SDAIA within 72 hours, and the Transfer Regulations restrict sending personal data outside the Kingdom, with a risk assessment required in several cases. We cover those in more depth in our guide to PDPL and AI chatbots and our piece on data residency.
The practical consequence is that the two fit together. A PDPL impact assessment asks what could go wrong with personal data. The risk framework asks the same of the whole system — including misinformation, misuse and the human–machine relationship, which data law does not cover. One well-kept risk register can feed both, and it is easier to defend a register built on the national method than one invented in-house, because it uses the vocabulary SDAIA itself published.
The cycle, stage by stage
Press reports describe four linked stages; Gowling and the vendor summaries describe five. The difference is grouping, not substance: the press version folds identification, assessment and treatment into one stage. We use the five-stage form because it maps more cleanly onto controls.
Context and scope. Describe the system, its data flows and its lifecycle, and decide where human checks are required. This is where most deployments are weakest, because nobody has written down where a customer’s message actually goes.
Risk identification. Walk the seven categories against your system. For an assistant, the categories that usually produce the most entries are misinformation, privacy and security, and human–machine interaction.
Risk assessment. Score each risk by likelihood and impact on the national matrix, described in the next section.
Risk treatment. Choose one of four responses: avoid (change the design, limit use or stop), mitigate (add technical, organisational or operational safeguards), transfer (contracts, insurance or supplier agreements) or accept (keep residual risk within agreed limits and review it). Gowling notes two details worth keeping: every safeguard should have an owner, a timeline and success measures, and transferring a risk to a supplier does not remove the organisation’s own governance duties.
Monitoring and review. Run scheduled reviews, update the register when something changes, report incidents and record lessons learned. For a system that SDAIA itself says can drift, this is the stage that keeps the first four honest.
Scoring a risk on the national matrix
According to the legal and vendor summaries of the document, likelihood is rated on four levels — rare (under 1% a year), unlikely (1–10%), likely (10–50%) and almost certain (50% or more) — and impact on four levels: low, medium, high and catastrophic. The risk level is likelihood multiplied by impact, giving a score from 1 to 16, grouped into four bands.
Each bar runs to the highest score in its band on the 1–16 scale, as reported in legal commentary on the framework.
One detail is easy to miss. Multiplying two numbers from one to four can only produce nine values — 1, 2, 3, 4, 6, 8, 9, 12 and 16 — which is why the bands appear to skip numbers. It also means “catastrophic” is reached only when both likelihood and impact sit at the top of their scales. Most real assistant risks will land in medium or high, and the useful work is deciding which.
The second detail is discipline. Write down why you chose each likelihood. “Unlikely” supported by a month of logs and a test set is evidence. “Unlikely” because the vendor said so is a guess, and the monitoring stage exists precisely to catch guesses that turn out wrong.
Mapping the stages to controls for an AI assistant
The framework sets a method; it does not tell you which controls to install. The table below is our translation of each stage into controls and evidence for an organisation deploying an AI assistant.
| What the framework asks | Control for an AI assistant | Evidence to keep | |
|---|---|---|---|
| Context and scope | Describe the system, its data flows and where humans check | A diagram of every hop a message, upload or transcript makes, including any external model call | Dated system description, signed by an owner |
| Risk identification | Walk the seven risk categories | Test questions outside your material, personal data in prompts and uploads, and whether users know it is automated | Register entries, each with a named owner |
| Risk assessment | Likelihood × impact, scored 1–16 | Score every entry; base likelihood on logs and tests, not instinct | Scored register with reasoning notes |
| Risk treatment | Avoid, mitigate, transfer or accept | Answer only from approved material, redact personal data before storage, hand over to a person on sensitive topics, write supplier duties into the contract | Control list with owner, timeline and success measure |
| Monitoring and review | Scheduled reviews, incidents, lessons learned | Log questions, answers and handovers with retention limits; sample-review monthly; re-score after any model or content change | Review minutes, incident log, updated register |
Our mapping, not SDAIA’s text. The framework defines the stages; these controls are one reasonable way to meet them for a conversational assistant.
Two rows deserve emphasis. The data-flow diagram is the most useful artefact in the exercise, because every later stage depends on it. And the treatment row is where architecture matters most: a risk you can avoid by design never needs to be mitigated, monitored or explained.
A starter risk register for an AI assistant
Applying the seven categories to a customer- or staff-facing assistant produces a fairly predictable first draft. It is a starting point, not a finished register, and your scores will depend on what the assistant is allowed to do.
| Typical assistant risk | First control to consider | |
|---|---|---|
| Bias, discrimination and harm | Weaker answers for users writing in dialect or mixing Arabic and English | Test in Gulf dialect and mixed-language input before launch |
| Privacy and security | National ID numbers, health details or account data typed into chat or uploaded | Redact before storage and restrict who can read transcripts |
| Misinformation | A confident answer your documents do not support | Answer only from approved sources and decline otherwise |
| Harmful use | Prompts crafted to extract internal data or bypass rules | Limit retrieval to content safe to disclose; test adversarially |
| Human–machine interaction | Users do not realise it is automated, or cannot reach a person | Disclose it plainly and keep a visible route to a human |
| Socioeconomic and environmental | Staff roles change with no plan for the people in them | Plan redeployment and measure workload before and after |
| Safety and limitations | Answering on medical, legal or financial matters beyond its remit | Set topic boundaries with a mandatory handover |
Illustrative entries, not scores. Likelihood and impact depend on your deployment, your users and what the assistant can see.
Several of these risks are cheapest to treat at the design stage rather than afterwards. It is the shape we built Elbi around: answers drawn only from an organisation’s approved material through retrieval, PII redaction in the core, and human handover as a module rather than an afterthought. Whatever you choose, the register should record which risks your design removes and which it merely reduces.
Data flows, logging and the questions to ask a vendor
Data flows. If answering a question involves a call to a model hosted outside your environment, that hop belongs in the context stage, the privacy category and, potentially, a cross-border transfer analysis under the PDPL regulations. Many organisations discover the hop only when they draw the diagram. We set out the architectural difference in sovereign AI versus cloud AI.
Logging. The monitoring stage needs logs, and logs of conversations are themselves personal data. The answer is not to stop logging but to decide in advance what is logged, where, for how long, who may read it and whether identifiers are redacted first. Write that decision into the register as a control in its own right.
Human oversight. The framework’s humanity principle centres on keeping people in control of choices, and its context stage asks where human checks are required. For an assistant, that means named triggers for handover — low confidence, sensitive topics, complaints, requests the assistant is not authorised to fulfil — and someone accountable for reviewing what happened afterwards.
Each answer slots directly into one of the framework’s stages. A vendor who answers in writing has drafted part of your register for you.
The honest limits of this article
We were not able to retrieve the full text of the framework from SDAIA directly. The launch details, principles, audience and worked example come from the Saudi Press Agency reports of July 2026; the matrix, the seven risk categories, the reference pillars and the treatment options come from published legal commentary on the document, and one vendor summary states that the Arabic text is the authoritative version. Coverage differs on whether the cycle has four stages or five. If precision matters, read the framework itself.
We also found no separate publication of the framework in late September 2026; the events we could verify took place in April and July. The mapping tables are our interpretation, not SDAIA’s, and sector regulators may expect more than the national framework does. We build an AI assistant, so we have an interest in the subject — which is why we have kept the product to two sentences and the questions to ones you should ask us too. Nothing here is legal advice.
Sources
- سدايا تطلق الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي ليكون مرجعاً إرشادياً للجهات الحكومية والخاصة — Saudi Press Agency, via Al-Madina, Jul 14, 2026
- SDAIA Introduces National Framework for Managing AI Risks — Saudi Press Agency, via Riyadh Daily, Jul 14, 2026
- سدايا تطلق الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي — Al-Watan, Jul 14, 2026
- سدايا تستعرض الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي بمشاركة 45 جهة حكومية وخاصة — Saudi Press Agency, via Al-Madina, Jul 30, 2026
- What Saudi Arabia's AI Risk Management Framework means for organisations — Gowling WLG, Jul 22, 2026
- Saudi Arabia issues Implementing Regulations to the Personal Data Protection Law — Clyde & Co, Sep 8, 2023
- Saudi Arabia: SDAIA publishes AI Ethics Principles — DataGuidance, Sep 14, 2023
- SDAIA unveils guidelines on generative AI safe use — Argaam / Mubasher, Jan 14, 2024
- SDAIA Launches AI Framework to Promote Ethical, Responsible Use of Advanced Technologies in Saudi Arabia — Riyadh Daily, Dec 1, 2024
- Published: SDAIA AI Adoption Framework — Digital Policy Alert, Sep 12, 2024
Common questions
It is a guidance reference from the Saudi Data and Artificial Intelligence Authority that gives government and private entities a single national method for identifying, assessing, treating and monitoring AI risks. It rests on seven principles, sorts risks into seven categories and scores them on a likelihood-by-impact matrix.
Legal commentary dates the document to April 2026. SDAIA launched it publicly on 14 July 2026, according to the Saudi Press Agency, and held an introductory session for 45 government and private entities in Riyadh on 30 July 2026.
The Saudi Press Agency describes it as a guidance reference, and we found no penalties attached to it. The Personal Data Protection Law and its regulations, and any sector regulator’s rules, remain binding on their own terms. This is not legal advice; confirm your obligations with qualified counsel.
Government and private organisations in the Kingdom regardless of sector or digital maturity, with a focus on high-impact systems such as natural language processing and large language models. It addresses developers, operators and policymakers. An organisation running an AI assistant is an operator even if it did not build the model.
Draw the data flow first: every hop a message, upload or transcript makes, including any external model call. Then walk the seven risk categories, score each risk on the 1–16 matrix with written reasoning, assign each control an owner and timeline, and schedule reviews that re-score after any model or content change.
Keep reading
AI Ethics in Saudi Arabia: What the UNESCO Global Forum in Riyadh Means for Organisations
Riyadh hosted UNESCO’s fourth Global Forum on the Ethics of AI in September 2026. Here is what was verifiably launched, what UNESCO’s and SDAIA’s frameworks ask, and how to turn each principle into a concrete design control for an AI assistant.
Read Article
PDPL and AI Chatbots: What Saudi Companies Must Get Right
An assistant that talks to customers is a personal data processing activity whether anyone described it that way in the project plan or not. Most of the work is design decisions taken early, cheaply, before anything is built.
Read Article
Microsoft Azure Saudi Arabia Region: What the November Launch Means for Local AI and Data Residency
Microsoft says its Saudi Arabia East cloud region opens to customers in November 2026. Here is what was actually announced, what an in-Kingdom region changes for data residency, and what it does not settle about where AI models run.
Read Article