When the Central Bank of the UAE published its Guidance Note on Consumer Protection and the Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions, most of the institutions it applies to had a familiar reaction: a careful read, a gap assessment, a steering-committee slide. All necessary. But in close to two decades of breach investigation and security-assessment work, I have learned that the gap between a regulation being understood and a regulation being operationalized is where the real risk lives. This Note is no exception.

The whole document rests on a single, uncomfortable premise that runs through all ten sections: you cannot govern what you cannot see. Before any institution can evidence fairness, explainability, oversight, or third-party control, it has to know — completely and currently — every AI and ML system running in its environment. Most cannot. That is the problem worth solving first, and everything below is an argument for why.

The AI is already here — and most of it is invisible

AI inside a financial institution is no longer a single project with an owner and a budget line. It arrives in three forms, and each carries a different risk profile. There is classical machine learning — the models quietly scoring credit, flagging fraud, screening for AML and predicting churn. There are large language models — the chatbots, copilots and document-analysis tools that generate and reason over language. And there are AI agents — goal-driven systems that plan and act, calling tools, APIs and MCP connectors to execute on their own. The arc from prediction to autonomous action is exactly where the risk curve bends sharply upward.

Worse, this AI is already distributed across four distinct layers. Team use public LLMs through browsers, extensions and desktop copilots — sometimes uploading sensitive data without thinking twice. Your own applications call LLMs for user tasks, some of them now wired to tools to act rather than merely answer. Personal and embedded agents reach into corporate mail, Slack, files and SaaS to read and execute. And beneath all of it, third-party apps and SaaS-native AI — the model baked into your CRM, for instance — run automation and scoring you never explicitly switched on. Almost none of this appears in a traditional asset inventory. That absence is not a side issue; it is the heart of the compliance problem.

Not all AI carries the same risk

If everything is AI, then nothing is prioritised — so the first discipline is to rate systems honestly. I find two axes do most of the work. The first is deployment proximity: how close the system sits to your data and how far its reach extends. A vendor securing its own SaaS-native AI is one thing; an in-house application with autonomous agents touching organisational data is another entirely — that is peak risk. The second axis is output and autonomy: does the system simply inform, support a decision a human then makes, act with a human in the loop, or decide and execute with no human gate at all? The distance between “recommends” and “executes” is the distance regulators care about most.

On top of those axes sit three severity multipliers: access to customer data, the business-criticality of the process, and the authority to take irreversible or financial action. The point lands cleanly with one example. The same chatbot that books an appointment is a medium-risk system. Give it the authority to approve a refund, and it becomes high-risk overnight. The technology did not change — the authority did. Risk-rating each system on deployment × output × severity is precisely the documented, per-system rating the Note expects you to produce.

Every obligation points back to visibility

Section 1 of the CB UAE Guidance Note defines AI systems; Sections 2 through 10 set the obligations. Read them together and a single dependency keeps surfacing. Governance and accountability (Section 2) put the board directly on the hook for model selection and oversight — but you cannot assign an accountable owner to a system you have not catalogued. Fairness and ethics (Section 3) demand bias testing at least annually and on every material change, with training data representative of the customers you serve — but you cannot target that testing without knowing which datasets sit behind which decision-making models.

It continues. Transparency (Section 4) requires you to disclose AI use and explain how decisions are reached, in Arabic and English — which means first flagging every customer-facing and decisioning system. Data quality, privacy and security (Section 5) call for clear provenance, privacy- and security-by-design, and red-teaming of AI systems and agents. Continuous monitoring (Section 6) asks for independent challenge, tested vendor updates, and an immediate kill switch for any deployed model. Human oversight (Section 7) insists the level of human involvement scale with consumer risk, with a non-AI path always available. Integration (Section 8) and third-party risk (Section 9) extend the same expectations to vendors, requiring per-system risk ratings, independent audits and a full inventory of hosted and third-party models held to the same standard as your own.

Strip away the section numbers and the obligations collapse into one precondition: you must be able to point at the system, name its owner, identify its training data, and see its inputs and outputs. Without that, every requirement becomes an assertion you cannot evidence — and an assertion you cannot evidence is, to a supervisor, no control at all.

The foundational first move: build your AI estate

So before a single section can be met, build a complete, current inventory of every AI and ML system, wherever it runs. In practice that means looking in five places and consolidating what you find:

• Source code repositories, production servers and workloads

• User endpoints and desktops, where shadow AI tends to accumulate

• Cloud environments and third-party or hosted services

Run AI-discovery tooling across both code and runtime, then consolidate everything into an AI Bill of Materials — AI-BOM, ML-BOM and SBOM, aligned to OWASP. For third parties, request their BOM in CycloneDX, the accepted interchange format, and hold those models to the same bar as your own. The output is the AI register: the single source of truth every section of the Note quietly depends on.

The two roadblocks every programme hits

In my experience, compliance programmes stall on two problems, and both are prerequisites rather than nice-to-haves. The first is AI discovery — simply getting a complete, current view of the estate. Most organisations cannot see all of it, and as we have seen, every obligation leans on that visibility. The second is AI observability. Today’s SIEM and monitoring stacks work at the log level. AI needs the token level. Without code-level instrumentation capturing input, reasoning and output tokens, you cannot measure performance, catch a security incident as it happens, or detect the model drift the Note explicitly wants you to monitor. These two gaps are foundational for any AI standard — CBUAE today, ISO 42001 next, and whatever follows.

Stand up the loop: Discover → Test → Observe

The CB UAE Guidance Note never names a control loop, but it implies one throughout. Discover the estate and surface the shadow AI. Test it continuously — penetration-test the AI applications and agents, because attack methods evolve daily and an annual assessment is already stale. Observe it at the token level, so drift, explainability gaps, security signals and kill-switch triggers are visible in real time rather than reconstructed after an incident. Discover, Test, Observe — run as a loop, not a one-off project — is the operational shape the guidance is reaching for.

Where to start  

The institutions that will navigate this guidance comfortably are not the ones with the thickest policy binder. They are the ones that can answer a deceptively simple question on demand: where does the AI in our environment actually live, and who is accountable for it? Build the estate first, clear the discovery and observability roadblocks, and the rest of the Note becomes a series of controls you can apply system by system, scaled to risk — rather than principles you hope you are honouring.

At SISA, this is precisely the problem we built our Prism platform to address — discovery, testing and observability mapped directly to the obligations above. But whichever tooling you choose, the sequence is what matters. Start with what is running. You cannot govern what you cannot see.