CBUAE Guidance Note on AI/ML — Clause-by-Clause Breakdown

If you run AI or machine learning anywhere inside a UAE-supervised financial institution — credit decisioning, fraud screening, transaction monitoring, a customer-facing chatbot, even an internal model that prices risk — this page is written for you. It is aimed at the people who actually carry the burden of proof when a supervisor asks how the model is governed: the Data Protection Officers, Chief Compliance Officers, and Heads of Risk at DIFC-, ADGM-, and CBUAE-supervised entities in the 25-to-500-employee range, where there is no twenty-person model-risk function to absorb the work.

The instrument in question is the CBUAE's "Guidance Note on the Consumer Protection and Responsible Adoption and Use of AI and ML by LFIs in the U.A.E.", issued on 23 February 2026. Read the title carefully, because the form matters. It is non-binding, principles-based guidance. It does not replace existing law — it supplements it, and it applies to all CBUAE-supervised Licensed Financial Institutions proportionate to their size, nature, and complexity. "Non-binding" is not the same as "optional", though. The CBUAE supervises against its expectations, and a principle you cannot evidence is a finding waiting to happen. Treat the Note as the lens through which an examiner will read your existing obligations, not as a document you can file and forget.

What follows is a practitioner's clause-by-clause reading. I have organised it around the five principles that the Tier-1 firms use to summarise the Note — governance and accountability, fairness and non-discrimination, transparency and explainability, effective human oversight, and data management and privacy — together with the granular obligations that law firms have drawn out of it and the three-tier human-oversight model the Note sets out. Where it helps, I cross-reference DIFC Data Protection Regulation 10 and ISO/IEC 42001, because for most readers the real compliance picture is the overlap of several instruments, not one.

A caution on what this is not. It is not legal advice, and nothing here substitutes for UAE-licensed counsel. Stoneset is a deterministic governance workspace, not a law firm — where I map a clause to how we'd structure the evidence, that is a product opinion, offered as opinion, not a statement of what the regulator requires.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Applies to all Licensed Financial Institutions (LFIs) within the CBUAE supervisory ecosystem: banks, insurance companies, exchange houses, finance companies, and payment service providers. Includes a proportionality clause: frameworks must be “proportionate to [the institution's] size, nature and complexity”.

Required

Every CBUAE-supervised entity using AI or ML for any decision-making, monitoring, or consumer-facing function must build an AI governance framework. Smaller entities can scale the framework down — but the five core principles apply at all sizes.

Ambiguous

• What exactly counts as “AI” for scope purposes? The Guidance Note does not define AI in the rulebook. Brief 4 §3 notes the parent Federal Decree-Law 6/2025 is technology-neutral.
• Where does the threshold of “proportionate” land for a 50-employee payment service provider vs a 5,000-employee bank?
• Does scope extend to vendor AI used by an LFI? Brief 4 §1 confirms: yes, vendor AI is in scope, and the LFI retains regulatory accountability irrespective of vendor use.

Stoneset implication

The proportionality clause is exactly why Stoneset is tiered by entity size — a lighter governance toolkit for a smaller institution, the full audit-evidence vault and board-pack generator for a larger one.

Vendor accountability flow-through is the core wedge for the Third-Party AI Vendor Contract Clause Library module.

Scope is where a careless reading of the Note does the most damage, so it is worth being precise. The Note applies to all CBUAE-supervised Licensed Financial Institutions — banks, insurers, exchange houses, finance companies, payment service providers — and it applies proportionately. A fifty-person payment institution is not held to the same governance apparatus as a five-thousand-person bank, but proportionality scales the depth of the framework, not the existence of it: the five principles bind at every size. If you use AI in any decision-making, monitoring, or consumer-facing function, you are in scope. The Note does not publish a formal definition of "AI" for scoping purposes, and the parent Central Bank Law is deliberately technology-neutral, so the safer reading is functional — if a model materially shapes an outcome a customer experiences, treat it as in scope rather than litigating the label.

Then there are the entities that are not formally caught but should still pay attention. A DIFC or ADGM fintech that has not yet taken a CBUAE licence sits outside the Note's direct reach today, but it will be examined against materially the same expectations by its own regulator once licensed, and credit-line and partnership banks increasingly ask for this posture in diligence. Building the framework early is cheaper than retrofitting it under a licensing clock.

Vendor AI flows straight through. If a consumer-lending platform buys its underwriting model from a third party, or a wallet provider plugs in an off-the-shelf fraud engine, the licensed institution retains accountability for the outcome regardless of who built the model. Outsourcing the model does not outsource the obligation — which is precisely why the vendor due-diligence and contractual provisions, examined later, matter as much as the in-house controls.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“Boards and senior management bear direct accountability for AI outcomes, model deployment, and ongoing monitoring.”

Required

Named board-level accountability. Documented governance framework. Senior management cannot delegate AI accountability downward.

Ambiguous

• Does this require a dedicated board AI committee, or can existing risk committee absorb the function?
• Frequency of board-level review — quarterly, semi-annually, or only on material incident?
• Does it extend to non-executive directors? Brief 4 doesn't resolve this.

Stoneset implication

Maps directly to the DIFC Regulation 10 Board Pack Template module — personal accountability tracking, AI risk summary, quarterly cadence. The CBUAE Guidance Note doesn't mandate the board pack format, but DIFC Reg 10 effectively does for DIFC-licensed entities.

Governance and accountability is the principle the rest of the Note hangs from, and it is also the one a supervisor can test most quickly. The Guidance Note — issued 23 February 2026, non-binding and principles-based, but the standard CBUAE examiners will read your house against — places direct accountability for AI outcomes with the board and senior management. That accountability cannot be delegated downward into the data-science team. What that means in practice is evidentiary, not rhetorical. Three artefacts do most of the work. The first is a board minute that actually approves the AI governance policy by name, dated, with the policy version attached — not a passing reference in 'any other business'. The second is a risk-register entry that names a single accountable owner for AI risk, with a real job title, not a committee. The third is a quarterly board pack that surfaces the things a board is supposed to be governing: incidents, model changes, and bias-testing results, in a form a non-executive can interrogate.

The mechanism that turns this board-level accountability into daily practice is the three-tier human-oversight model the Note sets out — in-the-loop, on-the-loop, out-of-the-loop (covered in full at §4). Classifying each system into a tier is how 'the board is accountable' becomes 'here is who reviews what, and when'. Stoneset's reading is that the board pack is the load-bearing artefact here; the DIFC's Regulation 10 effectively forces that cadence for DIFC-domiciled entities even though the CBUAE Note does not prescribe a format.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“AI and ML systems must not result in discriminatory, manipulative or unfair outcomes.”

Required

Active fairness testing — not just a policy statement that says “we don't discriminate.” Bias testing at least annually or after any model upgrade. Representative training data.

Ambiguous

• The Guidance Note does not define “discriminatory” — does it import the UAE PDPL definition? UAE federal anti-discrimination law?
• “Representative training data” — representative of what population? UAE-resident customers? GCC customers? Global customers?
• “Manipulative” is new language not in most comparable frameworks. What does the CBUAE mean by it?

Stoneset implication

Direct mapping to the Bias Testing Register module — quarterly cadence, representative-sample tracking, regulator-facing export. The “manipulative” framing is novel enough to deserve its own monitoring lane.

Fairness is where principles-based drafting bites hardest, because the principle, as the firms read it, fixes the outcome it wants — that AI and ML must not produce discriminatory, unfair, or manipulative results — but it does not hand you a methodology. There is no prescribed fairness metric, no defined protected-characteristic list, no statistical threshold. As Pinsent Masons reads the Note, the operational expectation is bias testing on representative data at least annually, or after any material upgrade, with the outcome documented; that is a law-firm reading of what the principle implies, not verbatim rulebook text, and it is worth being precise about which is which when you brief your board.

So what does a 100-person fintech actually do? The defensible minimum is a written test plan, run on a schedule, against a sample that genuinely reflects your UAE customer base rather than your easiest-to-extract data, with the results — pass, fail, or remediate — held in a register a supervisor can read. Stoneset's product opinion is to run this quarterly rather than annually: it is easier to defend 'we test every quarter' than to be caught having tested once, eleven months ago, before three model changes. Pick a method and stick to it; disparate-impact analysis is the method of least regret because it is explainable to a non-technical examiner. Crucially, the Note does not define a methodology, so document why you chose yours.

The genuinely novel word is 'manipulative'. Most comparable frameworks police discrimination; far fewer police manipulation. Read sensibly, this reaches behavioural design — dark patterns, default-nudged upsells, friction engineered to push a consumer toward the firm's preferred outcome rather than the consumer's. That belongs in your testing scope as its own lane, not folded into demographic bias, because it is a different failure mode and a regulator who wrote the word down will expect to see you have thought about it. Whether the CBUAE intends 'manipulative' to track a specific external instrument; the primary text was not extracted this run.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“Clear and understandable disclosures must be provided in both Arabic and English, with adequate customer support.”

LFIs must explain AI system functionality and the logic behind AI-assisted decisions.

Required

Bilingual disclosures (Arabic + English). Explanation of AI logic at the level a non-technical customer can understand. Adequate complaints / escalation route.

Ambiguous

• What constitutes “the logic behind” a decision? Counterfactual explanation? Feature importance? A high-level “this decision used machine learning to evaluate X factors” statement?
• Does the bilingual requirement apply to the AI documentation itself or only to customer-facing notices?
• “Adequate customer support” — staffed in Arabic? 24/7?

Stoneset implication

Less directly tooled in V1. The disclosure layer is a content/template problem more than a workflow problem. Could appear in a future module (Consumer Disclosure Library) but not V1.

Transparency and explainability is two obligations wearing one name. The first is disclosure: telling a customer, in language they can follow, that AI was involved and broadly how. As the law-firm readings of the Note describe it, this disclosure is expected in both Arabic and English, with a usable route to human review, challenge, correction, and escalation. The bilingual expectation is reported by firms such as Pinsent Masons rather than quoted here as verbatim CBUAE primary text, and it is operationally awkward for a London-built workspace to pretend otherwise: Stoneset V1 is English-first, and Arabic-language disclosure is a translation-and-review layer the LFI owns, not something a governance tool should fake.

The second obligation is explaining the logic behind an AI-assisted decision, and the honest framing is that this is policy and process before it is technology. You very rarely need to expose model internals; you need to show, on demand, that you can articulate which factors drove a decision and that a human can re-examine it. The evidence a supervisor wants is unglamorous: a written explanation standard, a record that the customer-facing notice was actually served, and a log of human-review requests and how they were handled. DIFC Regulation 10 — in force since 1 September 2023 — carries a closely related expectation for autonomous and semi-autonomous systems, so a DIFC-domiciled CBUAE-supervised entity is meeting the same shape of obligation twice, expressed in two registers.

This principle is significant enough that the Guidance Note breaks it into its own three-tier model. Covered in detail in §4 below.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Three-tier model: Human in the Loop / Human on the Loop / Human out of the Loop.

Required

Every deployed AI system must be classified into one of the three tiers, with controls proportionate to the tier. See §4 for the full breakdown.

Effective human oversight is significant enough that the Note frames it as its own operating model rather than a single principle, so the full breakdown — human-in-the-loop, human-on-the-loop, and human-out-of-the-loop, and how to classify and evidence each — sits at §4 below.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Alignment with UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021).

Required

AI systems processing personal data must satisfy PDPL legitimacy, proportionality, accuracy, retention, and subject-rights obligations. The Guidance Note treats this as the floor, not the ceiling.

Ambiguous

• What additional AI-specific data obligations exist beyond PDPL baseline? The Guidance Note is unspecific.
• DIFC Regulation 10 (Brief 4 §4) is the more specific instrument for DIFC-domiciled entities — does the CBUAE Guidance Note absorb its requirements for DIFC-licensed CBUAE-supervised entities (dual licence)?
• Cross-border data flow obligations for cloud-hosted AI processing UAE personal data?

Stoneset implication

Out of direct V1 scope (PDPL DPIA templates are a later-stage, V1.1 addition). The cross-reference to DIFC Reg 10 is significant — that regulation defines the Autonomous Systems Officer (ASO) role, which is mirrored from the DPO.

Data management and privacy is the principle where most readers quietly apply the wrong law, because the UAE runs two parallel regimes and your domicile decides which one binds you. For an onshore, CBUAE-supervised entity the operative federal instrument is the UAE Personal Data Protection Law, Federal Decree-Law 45/2021. For a DIFC-domiciled entity the federal PDPL does not apply in the same way — DIFC entities sit under the DIFC Data Protection Law 5/2020 instead. The Note treats whichever applies as the floor for AI systems processing personal data, not the ceiling, so satisfying lawful-basis, proportionality, accuracy, retention, and data-subject-rights obligations is the starting position rather than the finish line. (These specific instrument references are drawn from the repo brief and EY rather than re-verified against primary text this run; treat the legal split as well-established but the citations as medium-confidence.)

Two practical points. First, PDPL-specific tooling — DPIA templates and the like — is deliberately later-stage for Stoneset; V1 captures the governance evidence around data, not the DPIA workflow itself, and it would be overselling to claim otherwise. Second, DIFC Regulation 10 introduces an Autonomous Systems Officer for high-risk processing, a role that mirrors the data-protection officer; if you already understand the DPO function, the ASO is the same instinct pointed at autonomous systems.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“LFIs are expected to establish documented AI governance frameworks that are proportionate to their size, nature and complexity.”

Required

A written, board-approved framework that integrates AI risks across conduct, credit, operational, and cybersecurity risk dimensions. Not a policy statement — a framework with named owners, processes, and review cadence.

Ambiguous

• What does “documented” mean — Word document? Living policy in a GRC tool? Both?
• Is there a CBUAE-prescribed structure, or fully open?

Stoneset implication

The umbrella module. The governance framework lives in the Stoneset workspace; specific obligations (model inventory, bias testing, vendor clauses, board pack) hang off it as sub-modules.

The granular list of six obligations that circulates in the market is, to be precise about provenance, a law-firm reading of the Guidance Note rather than verbatim CBUAE rulebook wording. Pinsent Masons and other Tier-1 firms have distilled the principles-based text into operational expectations, and the first of those is the one everything else hangs off: a documented AI governance framework, proportionate to your size, nature and complexity. Treat it as the umbrella. The model inventory, the bias-testing cadence, the vendor due diligence, the board reporting — none of them are free-standing obligations. They are chapters of the framework, and a supervisor who asks to see your governance will expect a single coherent document that names them all and shows how they connect.

If you want the most operationally crisp shape available, start from ISO/IEC 42001, the AI management-system standard. It is not UAE law and the Guidance Note does not mandate it, but it gives you a defensible table of contents that maps cleanly onto what the CBUAE is examining for. A workable structure: (1) scope and AI policy, board-approved; (2) roles, responsibilities and named accountability, including the senior owner who cannot delegate the outcome downward; (3) the AI model inventory and risk-classification method; (4) the human-oversight model and how each system is tiered; (5) fairness and bias-testing procedure and cadence; (6) data management and privacy, cross-referenced to your PDPL or DIFC obligations; (7) security and resilience controls; (8) third-party and vendor management; (9) transparency and consumer-disclosure handling; (10) monitoring, internal audit and management review.

The defensible minimum is not length. It is that the framework is written down, has a board approval date, names owners against each section, and states a review cadence the supervisor can hold you to. A glossy fifty-page policy with no named owner is weaker evidence than a tight ten-page framework with a signature and a quarterly review log. Stoneset's reading is that the framework should live as a workspace, not a static Word file — that is opinion, not requirement.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Maintain an inventory capturing name, purpose, risk rating, and metadata.

Cross-referenced to CBUAE Model Management Standards 2022 (Brief 4 §2): “the 2022 framework predates the AI-specific February 2026 guidance and ‘contains no explicit AI or machine learning-specific provisions’ (Lux Actuaries) — coverage is generic to all models. The 2026 AI Guidance Note layers AI-specific requirements on top of this 2022 baseline.”

Required

A living register. Every AI/ML model named, classified by risk, mapped to a business purpose, and tied to an owner. The 2022 Standards provide the underlying schema (six-component framework: governance / data governance / development / implementation / usage / monitoring); the 2026 Note layers AI-specific fields on top.

Ambiguous

• Granularity — is a different LLM prompt a different “model”? Same model deployed with two RAG configurations?
• Update cadence — real-time, monthly, on change?

Stoneset implication

Direct mapping to the AI Model Inventory module — the entry point of the V1 workspace. Aligned to the 2022 Model Management Standards' schema for compatibility.

A model inventory is the most-asked-about and least-tooled artefact in the UAE AI compliance market right now, and it is the one place where a supervisor can tell in thirty seconds whether your governance is real. As the law firms read the Note, the expectation is a living register rather than a one-off audit, and you should align its schema to the CBUAE Model Management Standards of December 2022 — a generic, six-component model framework (governance, data governance, development, implementation, usage, monitoring) onto which the 2026 AI guidance layers. Building on that existing baseline means you are not asking the business to maintain two competing registers.

A minimum viable entry runs to eight to twelve fields: a unique model identifier and name; business purpose; model type and version; the data sources it consumes; a risk classification; the human-oversight tier (in-the-loop, on-the-loop, or out-of-the-loop); a named accountable owner; whether it is built in-house or supplied by a third party; the date it went live; the date and result of its last bias test; and a next-review date. Those last two fields are what make the inventory load-bearing: bias-test scheduling falls out of the register automatically, and the vendor-supplied flag is what drives your third-party due-diligence and contract tracking. The inventory is the spine the rest of the framework attaches to — which is why, in Stoneset, it is the entry point of the workspace. That is the product's reading, not a regulatory instruction.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Safeguards required against unauthorised access, misuse, cyber-attack, and system-failure.

Cross-referenced to FSRA Cyber Risk Management Framework (Brief 4 §5c): “effective 31 January 2026, banks/insurers/investment firms must adopt written cyber risk frameworks. 24-hour reporting obligation for material cyber incidents. Not AI-specific but applicable to AI systems as a subset of technology risk.”

Required

Threat modelling per system, encryption, access controls, monitoring, incident response. Where AI is involved, additional risks around prompt injection, training data poisoning, model extraction.

Ambiguous

• AI-specific threat categories — the Guidance Note doesn't enumerate them. Implicit reliance on NIST AI RMF / MITRE ATLAS?
• How does this interact with the FSRA 24-hour cyber reporting obligation when an AI failure has a cyber root cause?

Stoneset implication

Indirect — Stoneset doesn't build the security controls; it captures evidence of them as part of the governance framework. Module: ISO 42001 Evidence Vault — Annex A controls A.5 (information security) cover this.

Security-by-design and privacy-by-design is where the principles framing leaves the most operational work to you, because the Note does not enumerate AI-specific threat categories. The defensible move is to treat AI as a subset of your existing technology-risk programme and then add the controls that are specific to models. A minimum cyber-AI control set, in plain terms: prompt-injection prevention and input/output filtering for any system exposed to untrusted text; training-data lineage, so you can show where the data that shaped a model came from and that it was permitted to be used; model versioning, so every deployed version is identifiable and you can roll back; and access logging, so you have an immutable record of who queried, retrained, or reconfigured a model and when. Layer the conventional disciplines over the top — encryption, role-based access, monitoring, and an incident-response path that connects to your wider cyber reporting obligations.

Stoneset does not build these controls and does not pretend to be your security tooling. Where it earns its place is evidence: the governance workspace is where you record that the control exists, who owns it, when it was last reviewed, and where the underlying artefact (the pen-test report, the access-log export, the data-lineage record) lives. A supervisor examining you will rarely ask to run your controls; they will ask you to demonstrate they are designed, owned and operating. Capturing that evidence in one place, tied back to the relevant model in the inventory, is the point. That is the product's reading of the obligation, offered as opinion rather than as a regulatory requirement.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“Test AI models for bias at least annually — or after any upgrade — using representative training data; document non-discriminatory outcomes.”

Required

Formal bias-test cadence. Test methodology documented. Representative sample maintained. Outcomes documented in a regulator-facing format.

Ambiguous

• “After any upgrade” — does a prompt tweak count as an upgrade? A fine-tune? A new RAG document set?
• What test methodology is acceptable? Demographic parity, equalised odds, calibration — the Guidance Note is silent.
• “Representative” — see §2.2 ambiguity.

Stoneset implication

Direct mapping to the Bias Testing Register module. Quarterly cadence (more frequent than annual) chosen deliberately — easier to defend “we test quarterly” than to defend “we test annually” when the regulator examines.

The Note, as the Tier-1 firms read it, asks you to test models for bias at least annually or after any material upgrade, on representative data, and to document the outcome. That is the floor. My position — and this is Stoneset's reading, not a regulatory requirement — is that an annual cadence is the wrong thing to commit to in writing. If you tell a supervisor you test once a year, you are also telling them that for up to eleven months a known fairness defect can sit live in production with your name on it. A quarterly cadence is cheaper to defend, because the question "when did you last check?" never has an embarrassing answer. Commit to the cadence you can actually sustain, then beat it.

Treat representative-sample maintenance as a separate discipline from scheduling. The schedule answers "when"; the sample answers "against whom". A test run quarterly against a stale or skewed sample is worse than useless — it manufactures evidence of fairness you do not have. So the sample needs its own owner, its own refresh trigger, and its own provenance record showing which population it reflects. The Note (per the firm readings) does not define "representative", and it is silent on methodology — no demographic-parity-versus-equalised-odds steer at all. That silence is yours to fill defensibly, not to exploit.

Disparate-impact testing is the method of least regret here: it is the most widely recognised approach across financial-services supervision, it produces a number a non-specialist examiner can interpret, and it does not require you to have solved the contested question of which fairness metric is canonical. Whatever you choose, the report shape is what converts effort into a supervisory artefact — model identifier, sample and its provenance, the metric and threshold applied, the result, and the remediation decision with a named owner and date. That is the object a regulator can read in two minutes, and it is exactly what the Bias Testing Register is built to emit.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Provide disclosures in Arabic and English. Honour rights to human review, to challenge decisions, to correct inaccurate data, and to escalate complaints.

Required

Customer-facing notice that AI is in use, in both languages. Operational channel for human review on request. Process for challenge, correction, escalation.

Ambiguous

• Where does the disclosure live — terms & conditions, in-product notice, account opening flow?
• Is the bilingual requirement met by translation, or does the original drafting need to be in both?

Stoneset implication

Out of V1 module scope. Future consideration: Consumer Disclosure Library — pre-drafted bilingual notices the LFI can lift.

The consumer-facing obligations the firms draw out of the Note — a right to human review, to challenge a decision, to correct inaccurate data, and to escalate — are the closest thing in the document to the data-subject rights you already know from GDPR and the UAE PDPL. That is the useful insight: this is the same shape of obligation, sitting on the same operational layer, just answering to a different supervisor. If you have already built a request-handling workflow for access and correction under a data-protection regime, you do not need a second one for AI; you need to extend the existing intake, routing, SLA and audit trail to cover "a human looked at this decision" as a logged event. The specifics that get quoted around this clause — that disclosures must be in Arabic and English, that the vendor relationship must allow immediate cessation — come from law-firm readings such as Pinsent Masons rather than verbatim CBUAE primary text, so treat the bilingual obligation as a strong directional steer to confirm against counsel, not a clause I can hand you word-for-word. Stoneset V1 is English-only; the bilingual layer is honestly a later build.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

Apply governance, data protection, cybersecurity assessments and annual independent cybersecurity reviews. Contractual terms must include audit rights, cybersecurity guarantees, and immediate cessation capabilities. “LFI retains full regulatory accountability irrespective of vendor use.”

Required

Pre-contract due diligence, ongoing monitoring, contractual rights. The “immediate cessation” clause is unusually strong — the LFI must be able to switch off the vendor instantly if a regulatory issue surfaces.

Ambiguous

• “Immediate cessation” — defined in technical terms (kill switch), commercial terms (termination right), or both?
• Does “annual independent cybersecurity review” mean a SOC 2 attestation, an ISO 27001 audit, a bespoke pen test?
• Sub-processor flow-down — implied but not explicit. Brief 4 §1 lists “sub-processor flow-down” as a vendor obligation; the Guidance Note itself is less explicit.

Stoneset implication

Third-Party AI Vendor Contract Clause Library — the most differentiated and hardest-to-build V1 module. This is the largest single piece of V1 work.

This is the obligation I get asked about more than any other, for a simple reason: every regulated entity of this size runs on third-party AI, and almost no contract signed before this year was drafted to survive a supervisor's questions about it. As Pinsent Masons reads the Note, the LFI must apply governance, data-protection and cybersecurity diligence to its AI vendors, secure contractual audit rights, cybersecurity guarantees and an "immediate cessation" capability, and — this is the part people miss — retains full regulatory accountability irrespective of vendor use. You cannot outsource the liability. You can only contract for the rights you need to discharge it. I attribute the "immediate cessation" framing to the firm readings rather than presenting it as verbatim CBUAE text, but the direction of travel is unambiguous.

In practical terms there are four clauses every AI-vendor contract should now contain. First, audit rights — a contractual right to inspect, or to receive independent assurance over, the vendor's controls, not merely an annual marketing deck. Second, a cybersecurity guarantee with teeth: defined standards, breach-notification timelines that let you meet your own supervisory reporting duties, and consequences for failure. Third, an immediate-cessation right — the ability to suspend or terminate the vendor's processing quickly when a regulatory or security problem surfaces, drafted as an operational reality rather than a 90-day notice buried in a termination clause. Fourth, sub-processor flow-down, so that the obligations you have just negotiated do not evaporate the moment your vendor routes your data through its own downstream providers.

Most existing AI-vendor SaaS terms fail all four. They cap audit to a SOC 2 report you cannot question, disclaim security warranties, reserve broad rights to swap sub-processors at will, and treat termination as a billing event rather than a kill switch. Closing that gap is contract-by-contract work, and it is precisely why Stoneset maintains a vendor clause library: a defensible default set of clauses, a record of which vendor accepted or red-lined which, and the evidence trail a supervisor expects to see. That is the product's opinion on the clause, offered as a starting point — not legal advice, and no substitute for your own counsel.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“Humans retain full authority to approve/reject AI recommendations.”

Required

AI surfaces a recommendation; a human reviews and approves before action is taken. Highest oversight, slowest cycle.

Stoneset implication

Captured in the Model Inventory as a classification field. Drives downstream evidence: every HITL decision must show the human review event.

The Guidance Note confirms the human-in-the-loop tier as one where a person retains full authority to approve or reject the AI's recommendation before anything happens to a customer. It does not, however, tell you which of your use cases belong here — that judgement is yours, and it is the judgement a supervisor will second-guess first. My reading is that the obvious candidates are credit and lending decisions, third-party vendor onboarding, the disposition of a flagged fraud case, and the triage of a consumer complaint. Each carries a material, individualised consequence for a customer, and each is exactly the kind of decision the Note's fairness and consumer-protection expectations are written to reach.

The honest objection is that human-in-the-loop is slow and expensive — you are paying a person to sit between the model and the action. That friction is the cost. The benefit is that it is the most defensible posture you can hold in an examination: when a supervisor asks how you prevent a discriminatory or unfair outcome on a credit decision, "a named officer reviewed and signed it" is an answer that survives scrutiny. The defensible minimum is not the review itself but the evidence of it — a logged review event, the reviewer's identity, and the recommendation they accepted or overrode. That record is what a supervisor wants to see, and the Stoneset model inventory treats the tier as a classification field precisely so the downstream evidence is captured by default rather than reconstructed after the fact.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“AI operates autonomously for routine tasks with human monitoring and intervention capability.”

Required

AI acts unsupervised in the routine case; a human monitors outputs and can intervene. Middle ground.

Stoneset implication

The largest practical bucket. Most production AI fits here. Evidence: monitoring dashboards, intervention logs, escalation thresholds.

Human-on-the-loop is, in the Note's confirmed wording, the tier where the AI runs autonomously for routine tasks while a human monitors and retains the ability to intervene. This is where most production machine learning in a fintech actually lives, and assigning a system here rather than to in-the-loop is a legitimate, proportionate choice — not a way of dodging oversight. My reading of the natural fits: payment-fraud screening, customer-segment scoring, churn modelling, and transaction monitoring. These run at a volume no human could approve case by case, but each produces outputs a human can sample, threshold and escalate.

The trick — and the place firms quietly fail — is proving you are genuinely on the loop rather than merely asserting it. "We monitor it" is not evidence; a monitoring layer is. What a supervisor will want to see is the live dashboard, the alert thresholds that were set in advance, the intervention log showing humans actually stepped in when those thresholds tripped, and the cadence of review. The defensible minimum is an intervention you can point to: a date, a trigger, a person, an action. If your transaction-monitoring model has run for a year with no logged human intervention and no recorded review, you do not have human-on-the-loop — you have human-out-of-the-loop with a comforting label, and that gap is exactly what an examination is built to expose.

Source — Brief 4 §1, CBUAE Guidance Note (Feb 2026)

“AI operates independently, restricted to low-risk, non-material processes with appropriate controls.”

Required

Fully autonomous AI. Permitted only for low-risk, non-material processes. Material processes are explicitly excluded.

Stoneset implication

Smallest bucket but the riskiest if mis-classified. Evidence: explicit risk classification, named owner who approved the HOOTL deployment, regular review that the use case remains low-risk.

Human-out-of-the-loop is the tier the Note restricts to low-risk, non-material processes with appropriate controls — fully autonomous AI with no human in the decision path. It is the smallest bucket and the most dangerous to assign wrongly, because the entire safeguard is the up-front classification. And here is the live problem for almost every LFI I speak to: the generative AI you have actually deployed — the support chatbot, the document summariser, the internal knowledge-base Q&A tool — does not announce which tier it belongs to. The Guidance Note gives the three tiers but, on the evidence available, lists no worked examples, so the line is yours to draw and yours to defend.

My reading of where the line sits: human-out-of-the-loop is defensible when the process is genuinely internal, advisory, and severable from any customer outcome. An internal tool that drafts a summary a human then reads, edits and acts on is not autonomous decision-making — the human is the loop, downstream. It tips out of defensibility the moment the output reaches a customer unreviewed or feeds a material decision: a chatbot that quotes binding terms, refuses a claim, or states an account balance is consumer-facing and material, and parking it in the lowest tier is the classification error a supervisor will find first.

The practical test I use has three questions. Does the output reach a customer or alter their position without a human seeing it? Could a wrong output cause financial, contractual or regulatory harm? Is the process severable — could you switch it off tomorrow with no material effect? Only a clear no, no, yes earns the out-of-the-loop label. Whatever you decide, the defensible minimum is the same: an explicit risk classification, a named owner who approved the autonomous deployment, and a periodic review confirming the use case is still low-risk. The classification is the control.

Source — Brief 4 §2

The 2022 Standards are mandatory and apply to all banks and branches in the UAE. They define the six-component model governance framework: governance / data governance / development / implementation / usage / performance monitoring. The 2026 AI Guidance Note layers AI-specific requirements on top of this baseline.

If you run a CBUAE-supervised bank, you almost certainly already comply with most of what the 2026 Note now asks of your model register — you just comply with it for credit-scoring, capital, risk-rating and pricing models rather than for anything badged 'AI'. The CBUAE Model Management Standards, dated 23 December 2022, set out a six-component model-governance framework (governance, data governance, development, implementation, usage and monitoring). On the repo's reading, those standards are generic to all models and carry no AI-specific provisions; the 2026 Note does not supersede them, it layers AI-specific expectations on top of an inventory discipline most institutions have run for years.

The practical consequence is that you should not be standing up a second, parallel register for 'the AI stuff'. That is how reconciliations drift and how a supervisor finds two inconsistent sources of truth. Stoneset's reading — and this is product opinion, not a regulatory requirement — is to keep one inventory whose schema is shaped to the 2022 six-component framework, then extend each entry with the AI-specific fields (oversight tier, bias-test cadence, vendor dependency) the Note implies. You extend the register you have rather than migrating to a new one.

Source — Brief 4 §3

Article 184 sets the reconciliation deadline: 16 September 2026. Article 62 makes licensing requirements technology-neutral — any person who “by any medium or technology, issues, carries out, offers, or facilitates a licensed financial activity” is in scope. AI vendors facilitating regulated activity are therefore licensable in principle.

The phrase that trips people up is 'non-binding'. The Guidance Note is principles-based guidance that supplements — does not replace — existing law, and it is non-binding in form. It does not follow that it is optional in substance. A CBUAE-supervised institution will be examined against the Note, and 'we read it as guidance and chose not to act' is not a position you want to defend in an inspection. Treat it as a statement of supervisory expectation: the standard the CBUAE will hold you to, expressed as principle rather than rule.

The harder instrument sits above it. Federal Decree-Law No. 6 of 2025 — the new Central Bank Law — repealed and replaced FDL 14/2018 and 48/2023; it was gazetted on 15 September 2025 and came into force on 16 September 2025. Two articles matter here. Article 184 opens a one-year reconciliation window to 16 September 2026 for bringing licensed activity into line with the new law. Read this precisely: it is a general licensing and reconciliation deadline, not an AI-specific one, and the CBUAE Board may extend it (Stoneset's own monitoring puts the window holding at roughly 55%, with the balance across micro, formal and binding-as-is outcomes). Plan for it to hold; do not market it as an immovable AI cut-off. Article 62 makes licensing technology-neutral — it reaches anyone who, by any medium or technology, carries out or facilitates a licensed financial activity, which is why a third-party AI vendor sitting inside a regulated flow cannot assume it is outside the perimeter. On sanctions, White & Case describes a materially broader and more stringent framework of administrative and criminal penalties under the new law; that broadening is clear. The specific ceiling sometimes quoted is not something I can stand behind, and I have flagged it as unconfirmed.

Source — Brief 4 §4

For DIFC-domiciled entities, Regulation 10 is binding and more specific than the CBUAE Guidance Note. Key concepts: defines “System” (autonomous/semi-autonomous), “Deployer” (controller-equivalent), “Operator” (processor-equivalent), and the Autonomous Systems Officer (ASO) role for high-risk processing. Full enforcement from January 2026.

If you are DIFC-domiciled and CBUAE-supervised, you are not choosing between two regimes — both apply, and the DIFC instrument is the more demanding of the two. DIFC Data Protection Regulation 10, which governs personal data processed through autonomous and semi-autonomous systems, has been in force since 1 September 2023. (The 'January 2026' date that circulates refers to an enforcement or transition milestone, not commencement — the obligations are already live.) Where it overlaps with the CBUAE Note, it overlaps on the familiar ground: governance and accountability, transparency toward the data subject, and fairness in automated outcomes. The point for a compliance officer is that meeting these once, with evidence, can largely satisfy both.

Where Regulation 10 goes further is in its machinery, and this is where Guidance-Note compliance alone leaves you exposed. Reg 10 defines a 'System', a 'Deployer' (the controller-equivalent that determines purpose) and an 'Operator' (the processor-equivalent that runs it) — a vocabulary the CBUAE Note does not impose, and one you should map your own arrangements onto early, because it dictates who carries which obligation. It also introduces a gating concept the Note has no equivalent for: High Risk Processing, which on one of three qualifying routes triggers the appointment of an Autonomous Systems Officer (ASO), a named, accountable role analogous to but distinct from the DPO. A DIFC-domiciled LFI that has built a clean Guidance-Note framework but has not assessed whether its processing is High Risk, has not assigned Deployer/Operator roles, and has not appointed an ASO where required, has met the lower bar and missed the binding one. Reg 10 is the higher bar; design to it, and the CBUAE expectations come along for free.

Source — Brief 4 §8

Foundational baseline issued by CBUAE + SCA + DFSA + FSRA. Establishes governance, senior management accountability, model reliability, ongoing monitoring, risk assessment, and customer transparency for AI + APIs + biometrics + cloud + DLT. The 2026 AI Guidance Note expressly builds on these guidelines.

The 2026 Note did not arrive on a blank page. The 'Guidelines for Financial Institutions Adopting Enabling Technologies' were issued on 15 November 2021 jointly by four regulators — the CBUAE, the SCA, the DFSA and the FSRA — and the new Note expressly builds on that foundation rather than displacing it. For most institutions this is background; for one group it is the main event. ADGM does not appear to have issued a standalone AI rulebook, which means for an ADGM-FSRA-licensed firm the 2021 Joint Guidelines are effectively the only AI-relevant guidance with direct application. If you are FSRA-regulated, do not wait for an ADGM equivalent of the CBUAE Note before acting: treat the 2021 Guidelines as your operative baseline and read the 2026 Note as persuasive context for where supervisory thinking across the UAE is heading. Because the DFSA and FSRA co-signed the 2021 text, the direction of travel is shared even where the binding instruments differ.

Source — Brief 4 §1 (cross-reference), Brief 4 §4 (DIFC overlay)

UAE federal personal data protection law. The CBUAE Guidance Note states explicit alignment with PDPL. For DIFC-domiciled entities, DIFC DP Law 5/2020 is the operative instrument instead.

One distinction is worth getting right because almost everyone conflates it: which data-protection law actually applies to you. The federal regime is the UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, and the CBUAE Note points to alignment with it. But a DIFC-domiciled entity is not governed by the federal PDPL — it sits under the DIFC Data Protection Law No. 5 of 2020 (with Regulation 10 as the autonomous-systems overlay discussed above). So 'are you PDPL-compliant?' is the wrong opening question; the right one is 'which protection law is your operative instrument, federal or free-zone?', and the answer follows your domicile. Stoneset's PDPL-aligned DPIA tooling is deliberately later-stage work, not part of the V1 spec, so I will not overstate it here — the point for now is simply that you confirm the right regime before you start building DPIAs against the wrong one.

Source — Brief 4 §3

Federal Decree-Law 6/2025 came into force on 16 September 2025. Article 184 sets a one-year reconciliation window. The CBUAE Board can extend the window — but as of Brief 12 monitoring (internal extension-probability monitoring), the probability distribution is: 55% hold / 25% micro-extension / 12% formal extension / 8% binding-as-is. Plan for the deadline to hold.

The whole page builds to one date, so it is worth being precise about what that date is and what it is not. On 16 September 2025, Federal Decree-Law No. 6 of 2025 — the new Central Bank Law that repeals and replaces the 2018 and 2023 instruments — came into force. Article 184 of that law opens a one-year window, closing on 16 September 2026, within which licensed activities must be brought into line with the new regime. That is a general licensing-and-reconciliation deadline, not an AI-specific one. The February 2026 Guidance Note is not switched on by Article 184; it is non-binding, principles-based guidance that supplements existing law. But it is the instrument a supervisor will reach for when it asks how you govern the AI and ML you have deployed, and Article 62 makes the licensing perimeter technology-neutral — anyone who, by any medium or technology, carries out or facilitates a licensed financial activity is captured. So the deadline and the Note arrive at the same desk at roughly the same time.

Can the deadline move? Yes. The CBUAE Board may extend the Article 184 window, and our own monitoring puts the distribution at roughly 55% hold, 25% micro-extension, 12% formal extension, 8% binding-as-is. The honest planning assumption is that it holds, because an extension carries a FATF-context cost the regulator would rather not pay. Plan for September; treat any extension as found time, not as the baseline.

What does being "examined against the Guidance Note" mean in practice? It does not mean a tick-box certification. It means ordinary supervisory engagement — inspections, thematic reviews, evidence-of-compliance requests — in which the burden of proof sits with you. A supervisor will not ask whether you believe you are compliant; it will ask to see the artefact. The defensible position is documentary. You want, ready to hand: a board-approved AI governance framework with named owners and a review cadence; an AI model inventory that classifies each system by risk and oversight tier; a bias-testing schedule with dated results on representative data (the law-firm readings, Pinsent Masons among them, put the floor at least annually or after any material change — we recommend quarterly because a quarterly cadence is easier to defend); a third-party AI vendor clause library evidencing audit rights, security guarantees and a cessation right; a recurring board-pack pattern that surfaces AI risk to the people who are accountable for it; and, if you are DIFC-domiciled, an appointed Autonomous Systems Officer where Regulation 10's High Risk Processing gate bites. An evidence vault that ties these together — dated, versioned, attributable — is what turns a claim into a record.

The honest close: this is principles-based guidance, and principles-based guidance does not grade you on perfection. No methodology is mandated; no single "right" framework exists. What a regulator can see, and will judge, is whether you built the framework at all and whether you can show evidence of operating it month to month. Note also that FDL 6/2025 materially broadened the administrative and criminal sanctions regime — the exact ceiling circulating in the market is unconfirmed and we do not publish a figure here. The point stands regardless: the cost of having nothing to show has gone up. Build the framework, run it, keep the evidence. That is the work the next four months are for.

This breakdown was written by Bora Acıkan, founder of Stoneset. Stoneset is built in London and operated through Prospy Limited, a UK holding company, and is a deterministic governance workspace — not a law firm, and not an AI model dressed up as advice. The reason this page exists is that it is the document I wanted to read myself while pointing a governance product at UAE-supervised financial entities: a clause-by-clause, practitioner's reading of what the Guidance Note actually asks you to do. I have deliberately kept specific professional credentials out of this note rather than assert anything I cannot here verify.

This is not legal advice and must not be relied on as such. It is commentary, and it is no substitute for engagement with UAE-licensed counsel on your own facts — particularly on the statutory text of Federal Decree-Law 6/2025 and on the DIFC/onshore data-protection split. Where I have relied on law-firm readings of the Guidance Note rather than the CBUAE primary text, I have said so in line.

This page was researched and drafted with AI assistance and then fact-checked against primary instruments and Tier-1 firm analyses; some points remain flagged as unverified where the primary text was not directly extracted. Last updated late May 2026, and it will be re-versioned as the regulatory picture shifts. If you are preparing for September and want to compare notes, there is a 30-minute discovery call you can book from the site — no pitch, just the spreadsheet you are using right now and where it breaks.