Operationalizing UAE Consumer AI in Modulos

This is the rollout playbook for the CBUAE Consumer AI guidance in Modulos. It assumes you are already oriented on the framework — scope, the governance foundation, the principle families, and the operational backbone (see the framework overview) — and walks through the OFF-21 and MFF-21 templates, the recommended project structure, how the 26 requirements map to the four coverage domains, the two-band control library, a rollout sequence, and the readiness-plus-attestation evidence model.

The CBUAE guidance note is a supervisory instrument for CBUAE-supervised LFIs. In the Modulos catalogue the templates carry the Guidance label, which reflects the instrument type (a guidance note) — not a statement that compliance is optional. The note supplements, and does not replace, applicable UAE law and CBUAE directives, and the institution retains full legal responsibility.

Recommended project structure

Most rollouts use the following structure:

• One organisation project with the OFF-21 framework template attached. This holds the institution-wide governance set once and reused across every AI use: scope and accountability, the AI/ML inventory and risk rating, consumer-impact governance, the fairness/transparency/oversight policies, data/model/monitoring/incident/recordkeeping governance, third-party governance, consumer redress, proactive fraud detection, and industry collaboration.
• One AI-application project per in-scope AI use case with the MFF-21 framework template attached. Each application project holds the per-use-case execution evidence: deployment validation and the use-case risk rating, data handling, fairness testing, explainability artefacts, oversight and override, logging, monitoring, incident response, third-party assurance, and consumer communication support.

OFF-21 carries 16 requirements (ORF-423–ORF-438); MFF-21 carries 10 requirements (MRF-397–MRF-406) — 26 in total. The framework adds 22 UAE-exclusive controls (MCF-637–MCF-642, OCF-340–OCF-355) and reuses shared controls. The two templates operate together — several application requirements reference an organisation-side companion rather than restating it (see How org-locus and app-locus obligations connect).

Primary source

CBUAE, Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., 23 February 2026, anchored to CBUAE's Model Management Standards (MMS). Official text: rulebook.centralbank.ae.

The 26 requirements mapped to coverage domains

Coverage domain	Org requirements (OFF-21)	App requirements (MFF-21)
Scope and governance	ORF-423 (scope and applicability), ORF-424 (governance and accountability), ORF-425 (inventory and risk rating), ORF-426 (consumer-protection impact), ORF-431 (model governance and independent challenge), ORF-438 (industry collaboration)	MRF-397 (deployment validation, update testing, risk rating)
Fairness, transparency, and oversight	ORF-427 (fairness and non-discrimination), ORF-428 (transparency and explainability), ORF-429 (human oversight and escalation)	MRF-399 (fairness testing), MRF-400 (explainability and decision disclosure), MRF-401 (human oversight, override, contestation)
Data, models, monitoring, and remediation	ORF-430 (data quality, privacy, security), ORF-433 (continuous monitoring), ORF-434 (incident, resilience, remediation), ORF-436 (recordkeeping and supervisory readiness), ORF-437 (proactive fraud and financial-crime detection)	MRF-398 (data governance and lineage), MRF-402 (logging and audit trails), MRF-403 (monitoring, drift, outcome review), MRF-404 (incident containment and cease-use)
Consumer redress and third-party AI (conditional)	ORF-432 (third-party AI governance), ORF-435 (consumer human review, complaints, redress)	MRF-405 (third-party model/service assurance), MRF-406 (consumer communication support)

ORF-431 and MRF-397 appear in both scope-and-governance and the operational backbone — the org anchor is governance, the app counterpart is the deployment boundary — which is why the two topic pages cross-reference each other on model governance.

Where in Modulos (requirements, controls, evidence, comments)

Surface	Use
Project dashboard Add Framework	Attach OFF-21 to the organisation project; attach MFF-21 to each in-scope AI-use-case project
Project → Settings → Frameworks	Manage attached frameworks — list, freeze, and update
Project → Requirements	Track the OFF-21 / MFF-21 requirements; status Not fulfilled → Fulfilled, with Out of scope for conditional duties that do not apply (for example MRF-405 where there is no external dependency)
Project → Controls	Document implemented measures — scope and inventory records, consumer-impact assessments, fairness tests, oversight and override design, monitoring, incident response — and map them to requirements; control status changes are routed through review requests
Project → Evidence	Store supporting artefacts (scope and applicability decisions, the AI/ML inventory, risk ratings, consumer-impact assessments, fairness-test results, monitoring and drift reports, incident and remediation records, complaint analysis, disclosure copy, third-party due-diligence and audit-rights evidence) and link them to controls
Comments and logs on each requirement	Capture the rationale for fulfilment attestation, conditional-scoping (in-scope / out-of-scope) decisions, and residual-risk acceptance

Rollout sequence

Organisation groundwork first, then per-use-case execution, then the conditional families:

1. Set scope (org). Confirm the CBUAE onshore perimeter and in-scope AI uses (ORF-423).
2. Establish governance (org). Fulfil governance and accountability, the AI/ML inventory and risk-rating process, and consumer-impact governance (ORF-424 to ORF-426).
3. Set the principle families and data/model governance (org). Fulfil fairness, transparency, oversight, and data governance (ORF-427 to ORF-430), plus the model-governance and independent-challenge anchor (ORF-431).
4. Set monitoring, incident, and recordkeeping governance (org). Fulfil ORF-433, ORF-434, and ORF-436.
5. Assess proactive fraud detection (org). Fulfil ORF-437 — assess where AI can feasibly strengthen fraud and financial-crime detection, adopt it where feasible, and connect material findings to reporting duties.
6. Set the industry-engagement posture (org). Fulfil ORF-438 — the encouraged collaboration and case-study duty; a light-touch step, evidenced by participation or published case studies where the institution chooses to engage.
7. Activate use-case execution (app). For each AI use case, fulfil deployment validation and risk rating, data handling, fairness testing, explainability, oversight, and logging (MRF-397 to MRF-402).
8. Complete monitoring and remediation (app). Fulfil live monitoring and outcome review (MRF-403) and incident containment, cease-use, and remediation (MRF-404).
9. Apply the conditional families where relevant. Third-party governance and assurance (ORF-432, MRF-405) where there is a material external AI dependency; consumer redress and communication (ORF-435, MRF-406) where the use materially affects consumers. Mark out of scope with rationale where the condition is not met.

Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfilment.

How the control library is organised (baseline vs UAE-specific)

The templates pair two bands of controls, and the split is what keeps evidence reusable across frameworks without leaking UAE-specific wording into shared controls.

Baseline shared library. Control objects reused by other Modulos framework templates, carrying no UAE-specific text. Representative reuse: deployment and testing (MCF-61/MCF-63/MCF-55), data (MCF-26/MCF-66/MCF-243/MCF-443), fairness (MCF-42/MCF-43/MCF-44/MCF-58/MCF-32), explainability (MCF-40/MCF-420), oversight (MCF-178/MCF-179/MCF-419), logging (MCF-184/MCF-435), monitoring (MCF-65/MCF-67/MCF-68/MCF-72), security incidents (MCF-260), third-party (MCF-243/MCF-253/MCF-254/MCF-256), and transparency (MCF-47); on the org side, governance (OCF-1/OCF-52), transparency-general (OCF-9), human-oversight-general (OCF-45), privacy policy (OCF-234), processor management (OCF-189/OCF-213), org performance monitoring (OCF-67), deployer monitoring and incidents (OCF-49), and records and traceability (OCF-47/OCF-141).

UAE-specific block. The 22 controls that carry the binding CBUAE language:

Control	Name	Anchored requirement
MCF-637	Assure material third-party AI dependencies affecting consumer interactions or outcomes	MRF-405
MCF-638	Support consumer-facing notices and challenge routes for AI-assisted interactions	MRF-406
MCF-639	Risk rating of the AI use case	MRF-397
MCF-640	Execute AI data handling and privacy controls for UAE consumer uses	MRF-398
MCF-641	Review deployed AI outcomes against consumer-protection expectations	MRF-403
MCF-642	Execute AI incident containment, remediation, and cease-use response	MRF-404
OCF-340	Determine UAE Consumer AI scope and in-scope AI uses	ORF-423
OCF-341	Govern UAE Consumer AI accountability and management oversight	ORF-424
OCF-342	Maintain and risk-rate the AI and ML inventory	ORF-425
OCF-343	Assess and govern consumer-protection impacts of AI uses	ORF-426
OCF-344	Govern fairness and non-discrimination for AI uses	ORF-427
OCF-345	Govern transparency and explainability for UAE consumer-facing AI uses	ORF-428
OCF-346	Govern human oversight and escalation for UAE AI uses	ORF-429
OCF-347	Govern AI data handling, privacy, confidentiality, and security in the UAE context	ORF-430
OCF-348	Govern model validation and independent challenge for AI uses	ORF-431
OCF-349	Govern third-party AI dependencies in the UAE consumer context	ORF-432
OCF-350	Govern ongoing monitoring and outcome review for AI uses	ORF-433
OCF-351	Govern AI incident response, resilience, and remediation	ORF-434
OCF-352	Govern consumer human review, complaints, and redress for AI decisions	ORF-435
OCF-353	Maintain UAE AI recordkeeping and supervisory-readiness evidence	ORF-436
OCF-354	Assess and use AI for fraud and financial-crime detection	ORF-437
OCF-355	Collaborate on trustworthy AI and publish responsible-AI case studies	ORF-438

The 16 org UAE-exclusive controls map one-to-one to the 16 org requirements. On the app side, the fairness (MRF-399), explainability (MRF-400), oversight (MRF-401), and logging (MRF-402) requirements run on shared controls only. Scoping is not tag-driven and there is no dedicated questionnaire — there is no UAE Consumer AI scope-tag family to filter on.

How org-locus and app-locus obligations connect

The org/app split is deliberate, and obligations are documented on one side only:

• Inventory and risk-rating process. MRF-397 (app) records the use-case risk rating, but the institution-wide risk-rating process and the AI/ML inventory live on the org side at ORF-425. The application requirement consumes the process; the organisation requirement maintains it.
• Model governance. MRF-397 draws the per-use-case deployment boundary; the MMS-aligned validation, periodic review, and independent-challenge policy lives on the org side at ORF-431.
• Consumer redress. MRF-406 (app) provides the consumer-facing communication surface for a use case; the institution-wide redress rights and Article 8 alignment live on the org side at ORF-435.

The rule is that institution-wide governance set once belongs on OFF-21, while per-use-case execution belongs on MFF-21. Do not duplicate an obligation on both sides; the application requirement points to its organisation-side companion.

Evidencing requirements: readiness signal + owner-attested fulfilment

Requirements in Modulos use a two-step pattern, not a review:

• when all linked controls are in a final state, the requirement becomes ready for review — a signal to the requirement owner;
• the requirement owner attests fulfilment by marking the requirement Fulfilled, with rationale captured in the requirement's comments and logs.

Review requests in Modulos apply to control status changes (and other reviewable objects), not to the requirements themselves. A conditional requirement can be marked Out of scope with rationale — ORF-432 or MRF-405 where there is no material external AI dependency is the canonical example.

A defensible UAE Consumer AI evidence package usually includes:

• the scope and applicability decision for the institution and its in-scope AI uses;
• the AI/ML inventory with each model's name, purpose, and risk rating, including third-party-hosted models;
• consumer-impact assessments and related approvals;
• fairness, transparency, and oversight evidence at both the org and use-case levels;
• data-handling, privacy, and residency evidence for the live use case;
• model-validation and deployment-readiness records;
• monitoring, drift, incident, remediation, and complaint-handling evidence;
• the proactive fraud and financial-crime detection assessment and how material findings feed reporting duties (ORF-437);
• industry-collaboration or published-case-study records where the institution engages (ORF-438);
• records showing how consumer-facing notices and challenge routes are supported, where applicable;
• third-party due-diligence, contractual audit-rights, and annual independent cybersecurity-review evidence for material dependencies.

Common pitfalls

• Treating the Guidance label as "optional". The note is a CBUAE supervisory instrument for supervised entities; the label reflects the instrument type, not that compliance can be skipped.
• Undercounting the org requirements. OFF-21 has 16 requirements (ORF-423–ORF-438), not 14 — ORF-437 (proactive fraud detection) and ORF-438 (industry collaboration) are easy to miss because they have no app-side counterpart.
• Looking for a UAE scoping tag or questionnaire. There is none. Set the perimeter with ORF-423 and record conditional-family scoping as rationale on ORF-432/ORF-435/MRF-405/MRF-406.
• Modelling ORF-437 as conditional. Proactive fraud detection is an assess-and-use-where-feasible duty that applies broadly; it is not switched on and off by an applicability condition.
• Treating third-party AI as procurement-only. ORF-432/MRF-405 reach consumer treatment, data handling, explainability, and fallback — accountability is retained by the LFI, not transferred to the provider.
• Duplicating the inventory, model policy, or redress rights on the app side. They live on ORF-425, ORF-431, and ORF-435; the app requirements reference them.
• Using reviews to sign off requirements. Requirements are evidenced by readiness plus owner attestation; reviews are for control status changes.

Related pages

UAE Consumer AI overview

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

Scope and governance

Perimeter, accountability, inventory, consumer-impact and model governance — ORF-423–426, ORF-431, ORF-438

Fairness, transparency, and oversight

The three principle families — ORF-427–429 / MRF-399–401

Data, models, monitoring, and remediation

Data, validation, logging, monitoring, incidents, and fraud detection — ORF-430/431/433/434/436/437

Consumer redress and third-party AI

The conditional families — ORF-432/435, MRF-405/406

Governance operating model

How projects, requirements, controls, and evidence fit together

Source attribution

The authoritative source is the CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., published 23 February 2026 by the Central Bank of the United Arab Emirates, anchored to CBUAE's Model Management Standards (MMS). This page describes how Modulos maps the note's obligations to platform surfaces through the OFF-21 and MFF-21 framework templates; the obligations themselves are in the CBUAE publication. Requirement and control codes are Modulos template identifiers, not CBUAE references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the Guidance label on the Modulos templates reflects the instrument type and is not a statement that compliance is optional. The institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers.