There is a comforting reading of the Central Bank's February 2026 AI guidance, and a less comfortable one.

The comforting reading is that not much has changed. UAE licensed institutions have had Model Management Standards since 2022. Banks have model inventories, validation functions, risk ratings and a governance committee that signs models off. The Guidance Note ties AI back to the MMS repeatedly. So AI is just another model class, and the existing machinery absorbs it.

The less comfortable reading is that this is broadly true and entirely insufficient, because AI systems place pressure on almost every assumption the model risk framework was built on. Not one or two. Almost all of them.

Both readings matter. If you throw away your model risk framework and start again, you will have wasted the strongest asset you have. If you assume it transfers cleanly, you will find the gaps the way most institutions find gaps, which is during an examination.

What the Central Bank actually said

The 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. was issued on 11 February 2026 and announced publicly on 23 February. It applies to all licensed financial institutions, with insurance providers named expressly in its scope. That last point deserves emphasis, because insurers sometimes read banking-flavoured guidance as addressed to someone else. It is not.

On the relationship to model risk, the Guidance Note is unambiguous. Section 2 states that the governance, usage and validation of AI use in LFIs should follow the principles of the MMS. Section 6 opens with "In accordance with the MMS." Section 2's inventory requirement should follow the CBUAE Model Management Standards and Model Management Guidance. Section 9 refers institutions to section 4.7 of the MMS for third-party arrangements.

So the answer to the scoping question is settled. AI and machine learning models sit inside your model risk framework, not alongside it. If your MRM policy currently defines its scope in a way that excludes them, that is the first document to change.

The Guidance Note also uses "should" throughout rather than "shall", and states that it supplements rather than replaces existing law. It is supervisory expectation, not a rulebook obligation. Anyone who has sat through a CBUAE review will know how much practical distance there is between those two things.

Where existing MRM transfers well

Start with the good news, because there is more of it than institutions expect.

Risk-based tiering transfers. Your framework already sorts models by materiality and applies proportionate control. The Guidance Note asks institutions to create processes to rate the risk of each AI system they deploy, influenced by data quality and sensitivity, the capability of the AI, the controls in place, its impact, and dependence on it or on third parties. That is your existing tiering logic with AI-specific inputs.

The Guidance Note also gives you a materiality anchor that maps cleanly onto how banks and insurers already think. It defines a high-impact decision as any determination by an LFI using AI that materially affects a customer's access to financial products or services, offering loan applications and insurance claims as examples. Credit decisioning, underwriting, claims adjudication, pricing. You know how to tier these.

Three lines of defence transfers. Section 2 asks that AI-related risks be incorporated into the governance framework with specific adaptable roles for the Audit and Risk Committee, Risk Management, Internal Audit and IT. That is your existing structure, named.

The inventory discipline transfers. You already maintain a model inventory. The Guidance Note asks for an inventory of all AI models, systems or technologies developed or deployed, holding at minimum the model name, purpose and risk rating. Section 9 extends it to models developed or hosted by third parties, and asks that third-party models adhere to the same standards of fairness, explainability and robustness as in-house ones.

Board accountability transfers. Section 2 places responsibility on senior management and the board for AI systems and outcomes, model selection and development, deployment, resourcing, and oversight and monitoring on an ongoing basis.

If your institution has a functioning MRM capability, you are considerably further ahead than a mid-market firm starting cold. The framework is right. The strain is in the detail.

Where it strains

Here is the part that catches institutions with mature model risk functions, and the reason a lift-and-shift of existing MRM will not hold.

The volume assumption breaks. Model risk frameworks were designed around a manageable population. A mid-sized UAE bank might carry forty to eighty models under formal governance, each with a validation cycle, a documented owner and a periodic review. That works because the population is finite and grows slowly.

AI does not grow slowly. Generative capability arrives embedded in software the institution already licenses. A vendor adds an AI feature in a routine update. A business team builds something genuinely useful on a platform they already have. Within eighteen months an institution can be running several hundred things that meet the Guidance Note's definition of AI, which covers computer or machine-based systems that perform tasks normally requiring human intelligence, with varying levels of autonomy and the ability to learn from data and adapt.

Your validation function cannot process that volume at the depth it currently applies. The answer is not to validate everything more lightly. It is to be far more rigorous about tiering, so that deep validation goes where materiality actually sits, and lighter controls apply elsewhere by design rather than by omission.

The independent validation assumption strains. Independent validation assumes a validator who can genuinely challenge the model. For a logistic regression on credit data, an experienced validator can reconstruct the logic and interrogate it.

For a large language model supplied by a third party, they cannot. They cannot inspect the training data, reproduce the model, or explain a specific output from first principles. Validation shifts from examining the model to examining its behaviour: testing outputs across representative and adversarial cases, measuring consistency, checking for differential treatment across customer groups.

That is legitimate and it is what the Guidance Note contemplates when it asks for periodic testing to identify and remediate embedded biases or discriminatory outcomes. But it requires skills most validation teams were not hired for. This is a resourcing question that lands on the CRO, and it is usually the binding constraint rather than tooling.

The control assumption creates real tension. Section 2 contains a sentence that deserves more attention than it has received: LFIs should not employ AI models that they have no control over.

Read strictly, that sits awkwardly against the reality of buying generative AI from a global provider, where the institution controls neither the model weights, the training corpus, nor the update cycle. The Guidance Note does not resolve the tension directly, but section 6 points at how it expects institutions to manage it. Automatic updates to AI tools should be tested before implementation, institutions should be fully aware of such updates, and those updates should not result in bias in the model output.

In practice that is a procurement and contracting problem as much as a model risk one. It means contractual notice of material model changes, the right to test before an update reaches production, audit and information rights, and a defined exit. Section 9 asks for exactly this: due diligence on the provider's reputation, governance, security and data protection practices, and contracts that ensure access to relevant information, audit rights and compliance with CBUAE requirements.

If your vendor cannot commit to telling you before the model behind your product changes, that is a model risk finding, not a procurement inconvenience.

The validation cadence assumption breaks hardest. This is the most consequential strain, and it is where model risk management and AI governance genuinely diverge.

Traditional MRM is periodic. Validate at build, revalidate annually or on material change. That works when a model is stable between reviews.

AI systems are not reliably stable between reviews, because the world they operate in is not. Section 6 expects institutions to consistently monitor and review and, where appropriate, update or cease using AI models, taking into account changes in data, market conditions and customer behaviours. Section 3 states that no AI system should be deployed or used if it is discriminatory or manipulative or develops as such post-deployment.

That phrase, develops as such post-deployment, is the one an annual validation cycle cannot satisfy. You cannot demonstrate that a system has not developed a problem by pointing at a review conducted nine months ago.

Section 3 sets the testing floor at once a year or each time a model is upgraded, materially changed, or a new one is introduced. But section 6 asks for continuous monitoring alongside it. The two operate together: periodic deep testing, continuous shallow monitoring. Most institutions have the first and not the second.

Model boundaries blur. MRM assumes you can point at the model. With AI systems, the thing producing the decision is often a pipeline: a retrieval step, a prompt template, a base model, a post-processing rule, a threshold. Changing the prompt can change outcomes as much as changing the model. If your framework registers the base model and ignores the prompt layer, your inventory is describing something other than what is running.

A practical fix: define the governed unit as the decision, not the model. What is registered, tiered, validated and monitored is the system that produces a customer-affecting outcome, whatever its components.

The nine changes that follow

Translating this into work, for a mid-market bank or insurer:

1. Amend MRM policy scope to bring AI and ML systems expressly within it, referencing the Guidance Note's link to the MMS.

2. Redefine the governed unit as the decision-producing system rather than the model artefact, so prompts, retrieval layers and thresholds fall inside the perimeter.

3. Re-run discovery. Your inventory is almost certainly incomplete, because AI entered through procurement routes model risk never saw. Include vendor-embedded and third-party-hosted systems, as section 9 requires.

4. Rebuild tiering for volume, with deep validation reserved for high-impact decisions and a defensible lighter tier below it.

5. Add behavioural validation methods to the validation toolkit for models you cannot inspect, and be honest about the skills gap that creates.

6. Introduce continuous monitoring alongside periodic validation, with agreed thresholds, automated detection and named owners. Section 6 also requires that institutions retain at all times the clear and immediate ability, through human intervention, to cease using a deployed AI system. Test that you can.

7. Fix vendor contracts for notice of material model changes, pre-implementation testing rights, audit and information rights, and exit.

8. Upskill the second and third lines. Section 2 expects risk committees and control functions to understand AI-driven processes and be able to challenge outcomes where appropriate. That is a training obligation with a named audience.

9. Check your evidence trail. Section 5 asks for clear provenance and audit trails on the data feeding AI models. Section 4 requires disclosures in both Arabic and English, which is a documentation requirement as well as a customer-facing one.

On the sixth point, the tooling question follows the design rather than leading it. Once thresholds and owners are agreed, something has to watch continuously, because manual monitoring across a growing estate does not survive contact with a busy quarter. Platforms built for the purpose, IBM watsonx.governance among them, maintain the inventory, run continuous drift and fairness monitoring against defined thresholds, and produce the evidence trail as a by-product of running rather than as a reconstruction exercise before an examination. Scope your estate first, then choose.

The international frame

For institutions benchmarking against global practice, the direction of travel is consistent. The ongoing monitoring principle in US supervisory guidance on model risk management, SR 11-7, has been the reference point internationally for over a decade, and it has always held that validation is not complete at implementation. The CBUAE Guidance Note's insistence on continuous monitoring sits comfortably within that tradition rather than departing from it.

For institutions with European operations or customers, the EU AI Act reaches activity outside the Union where outputs are used within it, and credit scoring and life and health insurance pricing fall within its higher-risk categories. That is a separate compliance track, but the underlying controls overlap substantially. Build once, map to several.

The honest summary

Your model risk framework is the right foundation and it will not carry AI unmodified.

The parts that transfer are the structural ones: tiering, three lines of defence, board accountability, inventory discipline. The parts that strain are the operational ones: how many models you can realistically validate, how you validate something you cannot inspect, how you govern a system a vendor can change without telling you, and how often you look.

That last one is the real divide. Model risk management asks whether this model was sound when we checked. What the Central Bank is now asking is whether it is sound today.

Those are different questions, and answering the second requires something the first never needed.

Aligne AI works with banks and insurers across the UAE and GCC to extend existing model risk frameworks to cover AI, aligned to CBUAE Model Management Standards and supervisory expectations, ISO/IEC 42001 and the NIST AI Risk Management Framework. Contact us to discuss your model estate.

This article describes the regulatory landscape as understood at the date of publication and is provided for general information. It does not constitute legal advice. Organisations should obtain advice from qualified UAE counsel on their specific circumstances.

‍