Governance Paper · 9 August 2026
Multi-Jurisdiction
AI Governance Framework
Singapore · Saudi Arabia · Oman
Organisations deploying artificial intelligence systems across Singapore, Saudi Arabia, and Oman face a compound governance problem. Each jurisdiction has developed its own regulatory architecture: Singapore's IMDA Model AI Governance Framework, Saudi Arabia's NDMO standards and SDAIA guidelines, and Oman's TRA cloud computing regulations, each with different enforcement mechanisms, evidence requirements, and compliance timelines.
This paper sets out a unified governance architecture derived from production deployment experience across all three jurisdictions. The architecture is structured around six governance dimensions: accountability, data integrity, deployment transparency, incident management, audit and traceability, and human oversight. Each carries a group-level control statement and jurisdiction-specific annexes that handle regulatory variation without duplicating compliance overhead.
The unified framework has been deployed in production across a private-cloud engineering AI platform (KELIX) and the NEOM Bay Airport AI strategy. Both deployments are described as production evidence in Section 6.
Terence Kok
Enterprise AI Strategist | terencekok.com
Introduction
1.1 The Multi-Jurisdiction Problem
The growth of AI deployment across public sector and critical infrastructure programmes in Asia and the Middle East has produced a regulatory landscape that is simultaneously maturing and diverging, with each jurisdiction reflecting its own regulatory philosophy:
- Singapore has published three generations of AI governance guidance since 2019, culminating in the Model AI Governance Framework for Generative AI (2024) and, most recently, the Agentic AI Framework (January 2026). The approach is principles-based and voluntary in form, but increasingly embedded in public-sector procurement standards and referenced in private-sector assurance assessments through ISAGO 2.0 and AI Verify.
- Saudi Arabia has enacted the Personal Data Protection Law as binding legislation and layered NDMO data management standards across 77 controls and 191 compliance specifications. The framework combines binding data protection legislation with institutionally-referenced voluntary guidelines, with data sovereignty as an operationally consequential constraint.
- Oman has issued TRA cloud computing regulations with a four-level data classification scheme and is executing a three-pillar national AI programme through MTCIT. It is at an earlier stage of framework maturity but has enacted binding cloud and data regulations that directly affect AI infrastructure decisions.
For an organisation deploying AI systems across all three jurisdictions, compliance must be designed into the architecture before deployment, not appended after it. Separate governance stacks per jurisdiction multiply compliance overhead without proportional risk reduction.
1.2 Scope and Definitions
This paper addresses AI governance as applied to enterprise and government AI deployments: systems that process data from regulated sources, produce outputs that inform decisions, and operate within accountability structures requiring both technical and organisational evidence of responsible operation.
Excluded from scope:
- Purely experimental or research-stage AI deployments with no operational decision output
- Consumer-facing AI products not subject to government or critical infrastructure procurement obligations
- AI hardware and semiconductor supply chain regulation, which falls under separate national security frameworks
Key terms used throughout this paper:
- Unified governance standard: a single documented framework maintained at group or programme level, specifying control obligations applicable across all operating jurisdictions
- Jurisdiction annex: a supplementary document specifying jurisdiction-specific control variations, regulatory references, and compliance evidence formats required by a named regulatory body
- Accountability structure: the documented assignment of responsibility for AI system decisions, outputs, error handling, and oversight, including named roles, escalation paths, and review frequencies
- Audit trail: the complete, tamper-evident, machine-readable record of AI system inputs, processing decisions, outputs, human review actions, and model versioning events across the production lifecycle
Regulatory Landscape: Three Frameworks Compared
IMDA Model AI Governance Framework
Three framework generations since 2019. The 2024 Model AI Governance Framework for GenAI and the January 2026 Agentic AI Framework are the current operative standards. Formally voluntary but operationally embedded in government procurement through AI Verify and ISAGO 2.0. Aligns with OECD AI Principles and GPAI Code of Practice.
Voluntary + Procurement-Embedded
NDMO Standards & SDAIA Framework
Two overlapping layers. NDMO data management standards are legally binding: 77 controls across 191 compliance specifications. SDAIA GenAI guidelines are institutional-reference voluntary guidance. NCA Essential Cybersecurity Controls apply to AI systems on government infrastructure. Data sovereignty is operationally binding.
Binding Legislation + Voluntary Guidelines
TRA Regulations & MTCIT AI Programme
TRA Decision No. 1152 (September 2024) regulates cloud computing and data centres with a four-level data classification scheme. The PDPL (Royal Decree 6/2022) establishes data subject rights. The MTCIT National AI Programme (2024–2026) sets three national pillars. Earlier stage of framework maturity than SG or SA.
Binding Regulation + National Programme
Table 1: Three-Jurisdiction Governance Dimension Mapping
| Governance Dimension | Singapore IMDA | Saudi Arabia NDMO / PDPL | Oman TRA / PDPL |
|---|---|---|---|
| Accountability & Roles | AI System Owner, DPO, Ethics Reviewer (Agentic Framework) | CDPO (mandatory), AI System Sponsor, Data Controller | CSP Compliance Rep, Data Controller, Human Oversight Lead |
| Data Classification | No mandatory taxonomy; PDPA applies to personal data | 5-level NDMO taxonomy; binding data sovereignty rules | 4-level TRA taxonomy; cloud permit required for regulated data |
| Deployment Transparency | System card + AI Verify assessment for government contracts | PDPL lawful basis required; NDMO data classification documented | TRA permit number in system card; processing environment certified |
| Incident Response | 3 business days (PDPA breach notification) | 72 hours (PDPL); 72 hours (NCA cybersecurity incidents) | 72 hours (PDPL breach); TRA notification for cloud incidents |
| Audit Trail | AI Verify testing records; no explicit AI log retention period | NDMO audit requirements; PDPL retention as minimum necessary | TRA audit logs for cloud services; PDPL personal data retention |
| Human Oversight | 3-tier delegation model (Agentic AI Framework, 2026) | PDPL prohibits fully automated decisions on personal data | MTCIT AI Programme human oversight requirements |
Where a dimension is addressed by all three frameworks, the variation lies in the specificity of required evidence and the enforcement mechanism, not in the fundamental control objective. This is the design insight that makes a unified architecture viable.
Comparative Control Analysis
Three structural conflicts arise when attempting to satisfy all three frameworks simultaneously. Each requires a design decision at the architecture stage.
Conflict 1: Data Classification Incompatibility
Saudi Arabia's NDMO five-level classification taxonomy and Oman's TRA four-level taxonomy are not directly interoperable. A dataset classified as NDMO 'Restricted' in Saudi Arabia does not map deterministically to TRA Level 3 or Level 4 in Oman, because the classification criteria, whilst similar in intent, are defined against different data categories.
Adopt a superset classification taxonomy at group level with four tiers (Open, Internal, Regulated, and Sovereign) mapped to each jurisdiction's native taxonomy via a jurisdiction annex. AI training data pipelines label data with the group classification; the annex mapping determines the jurisdiction-level evidence requirement.
Conflict 2: Data Residency vs. Model Portability
Saudi Arabia and Oman both impose data residency requirements for government-classified and regulated private sector data. Under a strict reading of NDMO and TRA regulations, these requirements extend to the processing environment, including AI inference. A model deployed in a cross-border inference architecture risks non-compliance where the training data or input data carries jurisdiction-specific classification.
Separate the model artefact (which can be distributed) from the inference environment (which must be jurisdiction-resident for regulated data). Model weights are replicated to jurisdiction-resident inference endpoints; training data remains in the originating jurisdiction's approved processing environment.
Conflict 3: Agentic AI Oversight vs. Operational Autonomy
Singapore's Agentic AI Framework (January 2026) defines three delegation tiers and requires comprehensive action logs with defined human override mechanisms. Saudi Arabia's PDPL prohibits fully automated decision-making on personal data without data subject safeguards. Oman's MTCIT programme requires human oversight for AI systems on national infrastructure. The combination of all three creates overlapping constraints on autonomous operation.
Adopt Singapore IMDA's three-tier delegation model as the group standard. Map each delegated task against the tier classification. For Saudi Arabia, document tier classification as evidence of PDPL automated decision safeguards. For Oman, document tier classification as human oversight evidence for the MTCIT programme.
Unified Governance Architecture
4.1 Design Principles
Jurisdiction-Neutral Core
Group-level controls are derived from the intersection of all three frameworks, not from the most permissive
Annex Architecture
Jurisdiction-specific variations are isolated in annexes, not embedded in the core framework
Evidence-First Design
Control statements specify evidence requirements before implementation, not after audit
4.2 Six-Dimension Control Architecture
Accountability & Role Assignment
Every AI system in production has a named accountable officer, a defined oversight structure, and documented escalation paths. Accountability register maintained with named individuals, appointment dates, scope definitions, and review cadence. Updated within 5 business days of any personnel change.
Data Classification & Sovereignty
All data used in AI training, fine-tuning, retrieval, or inference is classified against the group four-tier taxonomy (Open, Internal, Regulated, Sovereign) before processing begins. Processing environments are assigned based on classification and jurisdiction.
Deployment Transparency & Documentation
Every AI system deployed to production is documented in a system card covering model purpose, training data provenance, known limitations, output types, human review requirements, and version history. Updated at each major model version release.
Incident Management & Breach Response
Documented incident response procedure for all production AI systems: detection triggers, severity classification, response timelines, regulatory notification obligations, and post-incident review. Response clocked from incident detection, not confirmation.
Audit Trail & Evidence Architecture
Tamper-evident, machine-readable audit trail for all AI system actions. Structured JSON log with mandatory fields: system_id, jurisdiction, data_classification, model_version, input_hash, output_hash, delegation_tier, human_review_flag, timestamp_UTC, processing_environment_id.
Human Oversight & Delegation Governance
Every task performed by an AI system is classified against one of three delegation tiers. Classification documented in the system card, enforced in deployment configuration, and reviewed at each major model version update.
Table 2: Group Classification Taxonomy and Jurisdiction Mapping
| Group Tier | Description | Singapore IMDA / PDPA | Saudi Arabia NDMO | Oman TRA |
|---|---|---|---|---|
| Open | Publicly available; no processing restriction | No classification required | NDMO Public | TRA Level 1: Public |
| Internal | Operational data; restricted to authorised staff | General data; PDPA applies if personal data present | NDMO Internal / General | TRA Level 2: Internal |
| Regulated | Subject to regulatory obligation; limited jurisdiction transfer | PDPA Personal Data / IMDA Sensitive; AI Verify required for govt | NDMO Restricted; PDPL personal data; NCA ECC controls apply | TRA Level 3: Restricted; PDPL obligations |
| Sovereign | National strategic data; must remain jurisdiction-resident | Critical government data; Singapore classified national systems | NDMO Confidential / National; local infrastructure mandatory | TRA Level 4: Confidential; on-premise or approved local cloud only |
Table 3: Incident Notification Requirements by Jurisdiction
| Jurisdiction | Trigger | Notification Deadline | Recipient |
|---|---|---|---|
| Singapore | PDPA personal data breach (notifiable) | 3 calendar days from assessment | PDPC; affected individuals (if significant harm) |
| Saudi Arabia | PDPL personal data breach | 72 hours from discovery | SDAIA / NDMO; data subjects where high risk |
| Saudi Arabia | NCA cybersecurity incident (government systems) | 24 hours from detection | National Cybersecurity Authority (NCA) |
| Oman | PDPL personal data breach | 72 hours from becoming aware | MTCIT / ITA; data subjects where high risk |
| Oman | TRA cloud service incident | Per TRA permit conditions | Telecommunications Regulatory Authority |
| All jurisdictions | Group-level AI system failure (production) | 4 hours (internal); then regulatory timelines above | Accountable Officer; Jurisdiction Compliance Lead |
Table 4: Delegation Tier Classification
| Tier | Delegation Level | AI System Behaviour | Human Oversight Requirement | Typical Task Category |
|---|---|---|---|---|
| Tier 1 Autonomous | AI acts without prior human approval | Output executed directly; full audit log mandatory | Post-hoc review; anomaly detection; periodic audit | Document retrieval, summarisation, classification of non-regulated data |
| Tier 2 Human-in-Loop | AI output requires human review before execution | Output queued; human reviews and approves or rejects | Named reviewer; documented approval step in audit trail | Design recommendations, compliance checking, client-facing content |
| Tier 3 Human-in-Command | AI cannot act without explicit human authorisation | Output presented as recommendation only; human initiates action | Named authority; two-step approval for Regulated/Sovereign data | Contract actions, regulatory submissions, infrastructure configuration |
Implementation Methodology
5.1 Sequencing and Prerequisites
A unified governance architecture cannot be implemented without establishing prerequisites in a defined sequence. Organisations that attempt to deploy the framework before completing the prerequisite stages produce documentation artefacts rather than operational governance.
- 1Data inventory before classification. The group classification taxonomy cannot be applied accurately without an inventory of data sources, data types, and data flows across all jurisdictions. This inventory is the prerequisite to classification, not a parallel activity.
- 2Accountability register before system card. The system card requires named accountable officers. Those roles cannot be documented accurately unless the accountability structure has been designed and populated. Role assignment precedes documentation.
- 3Delegation tier classification before deployment configuration. Every production task must be tier-classified before the system is deployed. Tier classification cannot be retrospectively applied to a running system without re-deploying with correct configuration and regenerating audit trail evidence.
- 4Incident response procedures before go-live. Regulatory notification timelines begin from the moment an incident is detected, not from when the response team is assembled. Procedures, roles, and notification templates must be in place before the first production inference.
5.2 Common Implementation Failures
Four failure patterns are observed consistently in multi-jurisdiction AI governance programmes:
Failure 1: Governance as Documentation
Producing governance documents without implementing the technical controls described in them. An audit trail specification document is not an audit trail. A system card template is not a system card.
Failure 2: Jurisdiction-by-Jurisdiction Stacking
Building separate governance stacks for each jurisdiction rather than a unified framework with annexes. Creates inconsistent evidence, gaps at jurisdictional interfaces, and multiplicative compliance cost.
Failure 3: Retrospective Classification
Attempting to apply data classification and delegation tier labelling after deployment. Audit trail records cannot be retroactively classified; historical inference records without classification labels cannot satisfy regulatory evidence requirements.
Failure 4: Underpowered Accountable Officers
Naming an accountable officer with insufficient seniority or decision-making authority. The accountable officer's authority must extend to stopping a production system; a nominal appointment without that authority is not governance.
Production Evidence: Applied Architecture
6.1 KELIX Enterprise AI Platform
The architecture described in this paper was developed and deployed across AI programmes spanning Singapore, Saudi Arabia, and Oman. The implementation addressed a specific constraint: the Group's engineering AI platform, KELIX, a private cloud RAG platform serving over 6,000 engineers, processed data across all three regulatory environments simultaneously.
The governance problem was as follows. KELIX processed engineering design standards, project documentation, and regulatory references, and the classification obligation differed by jurisdiction:
- Singapore: no mandatory classification under IMDA, but subject to PDPA where personal data was present
- Saudi Arabia: design documentation generated under government contracts carried NDMO classification obligations
- Oman: project data for Sultan Haitham City development fell within TRA regulated data categories and required local processing environment certification
The unified framework resolved this with a single governance standard at group level covering all six dimensions, with three jurisdiction annexes appended. The audit trail was implemented as structured JSON logs within KELIX's private cloud environment, with jurisdiction identifiers, classification tags, and delegation tier labels on every inference record.
Key Outcome
Single governance sign-off covered legal compliance across Singapore, Saudi Arabia, and Oman. The sustainability report citation ("responsible AI practice across the Group") was produced directly from the audit trail evidence; no separate evidence collection was required.
6.2 NEOM Bay Airport: Governance Before Operations
The NEOM Bay Airport AI strategy required governance design before the airport opened, a condition that is rare in infrastructure AI programmes but represents the architecturally correct approach. The Saudi regulatory environment applied: NDMO data classification governed all operational data generated from airport systems, and PDPL obligations applied to passenger data from day one of operations.
The governance design established three structural requirements before any system went live:
- A measurement framework for AI operational performance, establishing baselines prior to live data collection
- A data classification protocol for airport operational data categories: passenger flow, baggage handling, airside management, staff scheduling
- A delegation tier classification for every AI task in the operational intelligence system
Building the right measurement framework and governance architecture before you need the predictions is worth more than retrofitting AI onto data collected for other purposes. Design the data collection and governance first; the AI capabilities follow.
Recommendations for Programme Leads and Governance Officers
- 1Design for the strictest applicable constraint, not the average. Where requirements differ, the group framework must satisfy the most demanding requirement across all relevant dimensions. The annex architecture handles jurisdiction-specific variations; the core must pass the hardest test.
- 2Treat data classification as an infrastructure decision, not an administrative task. Classification must be embedded in data pipelines, not applied manually at the point of compliance review. Manual classification at scale is operationally unsustainable and produces inconsistent audit evidence.
- 3Commission the audit trail architecture in parallel with the model architecture. Audit trail design is not a post-deployment activity. The log schema, retention policy, access controls, and integrity mechanism must be specified before the first production inference. Retrofitting an audit trail is technically possible but produces incomplete historical records.
- 4Apply the four baseline questions before any agentic system acts on your behalf. What can it do without asking you? Who checks the output? What happens when it is wrong? Can your staff still do this manually? These questions are the same whether deploying across three jurisdictions or adding a single agent to a business process.
- 5Build the jurisdiction annexes before legal review, not during it. Presenting legal counsel with a completed unified standard plus draft annexes enables a focused review of jurisdiction-specific mapping decisions. Presenting an incomplete framework produces extended review cycles and late-stage rearchitecture.
- 6Monitor regulatory change as an operational input, not a compliance cycle. All three frameworks are actively evolving. Singapore's Agentic AI Framework was issued in January 2026; Saudi Arabia's PDPL implementing regulations were updated in 2024; Oman's TRA cloud regulations were issued in September 2024. The unified framework requires a scheduled review cadence aligned to regulatory publication cycles.
Conclusion
The case for a unified multi-jurisdiction AI governance architecture rests on a practical calculation, not a compliance philosophy. Separate governance stacks per jurisdiction are operationally expensive, produce inconsistent audit evidence, and create gaps at the interface between jurisdictions that are structurally difficult to close after deployment.
The three frameworks addressed in this paper are in different stages of maturity and have different enforcement mechanisms. Singapore's framework is operationally embedded through procurement standards without legislative mandate. Saudi Arabia's NDMO standards carry direct legal force through the PDPL and institutional force through SDAIA's embedded position in the Kingdom's AI programme. Oman's TRA regulations are binding on cloud infrastructure but the broader AI governance environment is at an earlier stage of development. Despite these differences, the common structural requirements identified in Section 3 (accountability, data classification, deployment transparency, incident response, audit traceability, and human oversight) are present in all three frameworks.
Organisations that treat governance as a deployment-stage activity will encounter the same compounding costs that the production programmes described in Section 6 were designed to avoid:
- Rearchitecture after data residency non-compliance is identified
- Audit trail reconstruction that cannot meet evidence standards
- Legal review cycles that delay deployment while governance documentation catches up to the technical implementation
The unified architecture approach eliminates this compounding cost at source.
Regulatory References and Sources
- •IMDA and AI Verify Foundation. Model AI Governance Framework for Generative AI. Singapore: IMDA, May 2024.
- •IMDA. Model AI Governance Framework for Agentic AI. Singapore: IMDA, January 2026.
- •SDAIA / NDMO. National Data Management and Personal Data Protection Standards. Kingdom of Saudi Arabia: SDAIA, 2021 (updated 2023).
- •Kingdom of Saudi Arabia. Personal Data Protection Law (PDPL), Royal Decree M/19 of 2024. Riyadh: SDAIA, 2024.
- •NCA. Essential Cybersecurity Controls (ECC). Kingdom of Saudi Arabia: National Cybersecurity Authority.
- •TRA Oman. Decision No. 1152/2/19/2024-20: Regulation of Cloud Computing Services and Data Centres. Muscat: TRA, September 2024.
- •Oman. Personal Data Protection Law, Royal Decree 6/2022, and Executive Regulation. Muscat: MTCIT, 2024.
- •OECD. OECD AI Principles (Revised 2024). Paris: Organisation for Economic Co-operation and Development, 2024.
- •ISO/IEC 42001:2023. Artificial Intelligence: Management System. Geneva: International Organisation for Standardisation, 2023.
Terence Kok is an Enterprise AI Strategist with twenty-five years leading AI and digital transformation programmes across Asia and the Middle East. He has designed and deployed AI governance frameworks for national infrastructure programmes, smart city developments, and enterprise AI platforms operating under regulatory obligations in Singapore, Saudi Arabia, and Oman.
The eight-dimension AI Readiness Assessment referenced in Section 5 is developed in full in AI at Scale: From Pilot to Production (Terence Kok, forthcoming Q4 2026).