Reference Pillars and Context Scoping

This page covers the footing the rest of the framework stands on: the four reference pillars and the context and scope stage of the risk cycle. It maps the org requirements ORF-449, ORF-450, ORF-451, and ORF-452 (the organization's side of each pillar), the per-system pillar alignment MRF-414, and the four context activities MRF-415 through MRF-418.

The order matters. The pillars tell an entity what governs its AI systems; the context activities establish what each system actually is: its purpose, data, autonomy, and lifecycle stage. Risk identification, assessment, and treatment all consume this record.

Primary source

SDAIA, National Artificial Intelligence Risk Management Framework, SDAIA-P145, version 1.0, April 2026. This page draws on the section «الركائز المرجعية لإطار إدارة مخاطر الذكاء الاصطناعي» (the reference pillars) and the stage «تحديد السياق والنطاق» (context and scope determination). The Arabic text is authoritative; English renderings are unofficial translations.

The four pillars at a glance

Pillar	Org requirement	What the organization maintains	Per-system evidence
General principles	ORF-449	The general principles and Islamic values and the seven AI ethics principles as a governing reference for AI decisions	MRF-414
AI regulations	ORF-450	A register of the policies, legislation, and regulatory frameworks governing AI that apply to the organization, with tracking of new issuances	MRF-414
Data regulations	ORF-451	The register of data-governance requirements for AI (purpose definition, access control, quality and integrity, source traceability, retention) and the organization-wide data practices they require	MRF-414 (data practices under MRF-416)
Sector regulations	ORF-452	The sector-specific instruments that govern AI in the organization's contexts of use, and the specialized controls each sector's particularity requires	MRF-414

The division of labor is deliberate: the organization builds and maintains the pillar registers once (ORF-449–ORF-452), and each AI system records which of those criteria apply to it and how it aligns, including documented gaps (MRF-414). A sector regulation that does not apply to a given system is recorded as such, with the reason.

Pillar one: general principles and AI ethics (ORF-449)

The first pillar anchors AI development and use in the general principles and Islamic values the framework names — justice, transparency, preservation of rights, safeguarding human dignity, and not harming others — and in their practical embodiment, the seven AI ethics principles:

Principle	Operative content
Fairness and integrity	Measures across design, build, and operation that limit bias and discrimination arising from unfair representation in data or algorithms; systems that represent target groups without discrimination on grounds such as race, religion, gender, or age
Privacy and security	Development in line with the relevant privacy and cybersecurity requirements, protecting personal data and preventing unlawful access, with controls that keep the system manageable and monitorable across its lifecycle
Humanity	An ethical, fair approach grounded in human rights and cultural values; no deception or manipulation; strengthening rather than diminishing the human role in choice and decision-making
Social and environmental benefits	Maximizing positive impact for individuals, society, and sustainability goals, contributing to technical, social, and environmental progress without harm
Reliability and safety	Conformity to approved specifications; reliable, predictable operation for the designed purpose, with risk management mechanisms that minimize potential and unintended harm
Transparency and explainability	Clear, interpretable design that lets automated decisions be traced and understood, especially where individuals may be affected; transparency of data, algorithms, purposes, and processes proportionate to context and risk
Accountability and responsibility	Designers, developers, operators, and evaluators answer for the effects of system decisions; governance and human supervision across the lifecycle, with clear roles and preventive risk measures

The principles correspond to SDAIA's separately published AI Ethics Principles, so organizations already evidencing those map that work directly onto this pillar. The framework's suggested risk taxonomy mirrors the principles (bias risks against fairness, privacy-and-security risks against that principle, human-machine interaction risks against humanity and accountability), so principle alignment feeds risk identification downstream.

Pillars two to four: the regulatory alignments (ORF-450–ORF-452)

ORF-450 — alignment with AI regulations. The organization maintains a register of the policies, legislation, and regulatory frameworks governing AI development and operation that apply to it, treats them as the legal reference for conformity with national requirements, tracks new issuances, and sets the alignment criteria and compliance processes that keep compliance continuous across the system lifecycle.

ORF-451 — alignment with data regulations. The register of controls and requirements governing the collection, processing, storage, and use of data within AI systems, and the organization-wide data practices that alignment requires: lawful, secure practices including defining the purpose of data use, controlling access, and ensuring quality and integrity, with source traceability, retention control, and treatment of bias, security, and output-integrity risks. The framework singles data out because AI systems depend on it directly across their lifecycle.

ORF-452 — alignment with sector regulations. The sector-specific requirements, policies, and guidance that govern AI in the organization's contexts of use — health, finance, and education are the framework's illustrative examples — and the specialized controls each sector's particularity requires. The pillar's premise is that AI risks differ with the nature of the sector, the sensitivity of the data, the scope of potential impact, and the nature of the decisions the systems support or take. These sector factors feed impact estimation later in the cycle (MRF-422).

Per-system pillar alignment (MRF-414)

Each AI system identifies which pillar criteria apply to it and documents how its design, development, and operation align with them, recording any gaps. All four pillars are considered individually; the framework's own worked scenario applies them as the first per-system step. Pillar alignment is revisited when the system's context, scope, or lifecycle stage changes (see MRF-418).

The context-and-scope stage (MRF-415–MRF-418)

The stage establishes a precise, shared understanding of each AI system before any risk is inventoried. Four activities, one requirement each:

MRF-415 — system description and use boundaries. The system's type, the purpose of its use, the functions or outputs it provides, and how those outputs are employed in the operational context. Intended uses are stated explicitly against unauthorized or out-of-scope uses, to limit misuse and uncontrolled expansion. The description also records the direct user categories and the indirectly affected groups, with the limits of the target population, its degree of reliance on the system, and its ability to interpret the results.

MRF-416 — data, input/output points, and value-chain parties. A comprehensive inventory of the data used to train and operate the system, classified by nature, sensitivity, and quality, with sources and collection mechanisms identified. Data flows are documented along with the input points through which the system receives data and the output points through which results are issued. Every party in the value chain — internal systems, other entities, external partners, data providers — is identified with roles and responsibilities.

MRF-417 — automation level and the human role in decisions. Whether the system is limited to supporting recommendations, takes decisions, or executes actions automatically; the human role in the decision cycle, including approval, review, objection, and stop points; the cases in which human intervention is mandatory; and clear allocation of responsibilities among developers, operators, and the decision owner, with formal approval paths and escalation mechanisms for when risks or unexpected results are detected.

MRF-418 — lifecycle stage and change plan. The system's current lifecycle stage — development, testing, operation, or update — and its change management mechanism: the nature and frequency of expected updates, who executes them, and which authority approves them. The record defines when material changes trigger risk reassessment and how users or affected groups are informed of changes that may affect performance or risk.

Worked example: the framework's own scenario

The framework's appendix applies the pillars and context activities to a concrete case: a government entity adopting a large language model to help staff draft internal reports. The scenario's context record is a useful calibration point:

• Use boundaries: drafting support only — the model produces draft text, improves phrasing, or summarizes user-provided content. Binding legal analysis, official regulatory interpretation, final administrative decisions, external correspondence, and classified documents are out of scope, and entering highly confidential data is prohibited.
• Data and I/O: an internally hosted model under the entity's supervision; inputs are texts staff enter manually, classed as low-to-medium sensitivity; outputs display directly to the user without automatic storage or transfer to other systems.
• Automation level: low, human-supportive. All outputs are unapproved until a competent employee reviews and adopts them; human intervention is mandatory in every use case.
• Lifecycle: monitored operation, with material updates subject to change management, prior risk assessment, and formal approval.

Cross-framework mapping (preview)

Preview

• ISO/IEC 42001 — the context activities align with the management system's context-of-organisation and impact-assessment clauses; the pillar registers align with the interested-parties and legal-requirements machinery.
• NIST AI RMF — the context-and-scope stage corresponds closely to the Map function; the pillars play the role of the Govern function's policy layer.
• EU AI Act — the automation-level and human-role record (MRF-417) covers ground the Act regulates as human oversight (Article 14), though the SDAIA framework sets no statutory oversight design duties.

These are framework-level adjacencies; cross-framework reuse is realised at the control layer, not as clause-by-clause equivalence.

Related pages

Saudi AI Risk Management overview

Framework structure, scope, and the OFF-23 / MFF-23 split

Risk identification and assessment

The next stage: the taxonomy, characterization, scales, and the 4×4 matrix — MRF-419–423

Operationalizing in Modulos

The OFF-23 / MFF-23 rollout sequence, control split, and evidence model

Source attribution

The authoritative source is the National Artificial Intelligence Risk Management Framework (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the reference-pillars section, the context-and-scope stage, and the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations; the laws and regulations its pillars point to remain binding on their own terms. Verify against the current published edition and consult qualified advisers.