An AI system register that answers QCB, CBUAE and DoH at once

The QCB calls it a register, the CBUAE an inventory and Abu Dhabi’s Department of Health a risk register. They are not the same document, and a firm that answers to more than one of them can end up with three spreadsheets that disagree about how many AI systems it runs. They are close enough, though, that one well-designed record can answer all three.

The QCB’s Artificial Intelligence Guideline applies to every entity the QCB regulates, whether it builds AI itself, buys AI systems or outsources processes that rely directly on AI, and it entered into force on 4 September 2024 [1]. Section 10 is the register. An entity must keep an updated register of information on all its AI system arrangements, highlight high-risk systems and the provider of each, disclose to the QCB the criteria it uses to decide what is high-risk along with a high-level risk and impact assessment, and disclose the full register once a year and whenever the QCB asks [1]. It is the only one of the three texts that names a yearly disclosure of the whole list.

The CBUAE’s guidance note on AI, issued on 11 February 2026, applies to licensed financial institutions, insurers included [2]. Section 2(f) asks for an inventory of all AI models, systems or technologies developed or deployed, holding all material metadata and at least the model name, purpose and risk rating, and section 9(c) adds models developed or hosted by third parties [2]. The note sends the inventory to the CBUAE’s Model Management Standards [2], which require models to be grouped by model risk, or at least by materiality, and managed through a defined life cycle with documentation at each step [3]. The note is guidance, but for a bank it points at a standard written in “must”.

Abu Dhabi’s Responsible AI Standard, version 1, published and in effect since October 2025, covers the DoH and every licensed healthcare entity in the emirate that develops, buys or deploys AI, for clinical, financial and administrative work alike [4]. It requires a risk assessment of all AI systems and related assets, with risks documented and tracked in a risk register and an owner assigned to each risk [4]. It defines a risk register as a log of identified risks with their severity, likelihood, mitigation measures and monitoring status [4], so its unit is the risk rather than the system. Its definition of an AI system includes the training, validation and testing data, and it wants dataset metadata kept in centralised governance registries [4].

The first design decision is what a row is, and the three texts count different things. The QCB counts AI system arrangements, and treats a substantially modified system as a new one [1]. The CBUAE counts models, systems or technologies [2]. The DoH counts AI systems and related assets, data included, and tracks risks [4]. Make the model the unit and a customer assistant that calls two models and a retrieval index becomes three rows, with one owner, one contract and one oversight protocol copied between them. Make the risk the unit and the QCB’s supplier fields have nowhere to live.

I would make the AI system the record: one thing a named person owns, with a purpose, a risk classification and a human oversight protocol. Models, datasets, contracts and risks are child records linked to it, each with its own history. A model shared by several systems then appears once and is linked to each of them, which is what you need when a regulator asks where else a given model is used.

A second decision follows from the QCB’s definition of the life cycle. If a substantially modified system counts as a new system, and a provider needs the QCB’s approval before any material modification [1], the register has to record every change, whether it was judged material, by whom and why. That record is what turns a list into a register.

The table is the union of the three texts, one row per field. The second column says who asks for it, by section number. The third is where I would fill it from, because a field nobody can populate from a system of record is a field that will be wrong within a quarter.

The second column is from the three texts [1, 2, 4]. The third is my reading, and this page is not legal advice.

Two things stand out once the fields sit side by side. Most of the QCB’s fields for bought or outsourced systems are procurement and contract data, which an AI team does not hold and should not retype. And only the CBUAE sets a minimum (name, purpose and risk rating) while asking for “all material metadata” beyond it [2], so an inventory built to that minimum will not survive a QCB disclosure or a DoH audit.

The usual first register is a spreadsheet filled in by asking each team what AI it uses. It is out of date the week it is finished, and it misses the AI nobody thinks of as AI: the summariser switched on inside a CRM, the transcription feature in the meeting tool, the vendor model behind a fraud score. The QCB’s scope covers AI systems an entity buys and processes it outsources that rely directly on AI [1], and the CBUAE’s inventory covers AI deployed as well as AI developed [2], so bought features count.

I would build the first version by discovery and then have owners confirm it. These five sources are where I would look.

Each source becomes a feed rather than a one-off search. Anything discovered with no register entry goes to a queue with a named person to confirm or reject it, and the length of that queue is the number I would put in front of the board. For the first classification of each confirmed system, a first-pass risk score for each use case is a reasonable start before it is aligned with the firm’s own tiers.

A register stays right when the systems cannot run without it. Four controls do most of that work.

The QCB’s yearly disclosure then becomes a query rather than a project: filter to the fields section 10.7 lists, attach the high-risk criteria and the high-level assessment the QCB also asks for [1], and review it. The same data produces the CBUAE inventory and the risk reports the DoH expects to see [4]. Where each store sits is a question of its own, and the guide to the Gulf rules on where AI data may sit covers what to ask a cloud or model vendor about regions.

This is the order I would work in for a regulated firm with some AI live and no register. It is a plan built from the three texts, not a timetable any of the regulators sets.

Six weeks fits a firm that can name its AI owners and runs one deployment pipeline. A group with several licensed entities, or with AI bought separately by each business unit, should expect discovery to take longer, and in that case discovery is the project.

Building this is what we sell as AI governance implementation: the register, the discovery feeds, the registration gate and the logging built into the systems they describe, so the answer to a regulator comes out of the estate rather than out of a spreadsheet kept beside it. Where a system has to change to carry those controls, such as a model gateway that can refuse unregistered calls, we build that too. We work with clients across the UK, the US and the Gulf, and clients in the UAE can contract locally through our UAE entity. We have built Arabic-language AI, including bilingual Arabic and English search and Arabic document OCR.

Our closest published work in the region is the production estate of a government-accredited EdTech in the Middle East, whose database we replatformed into Google Cloud’s Doha region, me-central1, to meet Gulf data-residency requirements. It is education rather than banking or health, and I mention it for the method: every store in a named region, and the evidence written down. Once a scope is signed, a fixed-scope build can start within a day, and if you already have a scoped job, we can resource it on contract from the collective of associates who work with us, held to the same standard. Whether the result satisfies the QCB, the CBUAE or the DoH stays with your compliance function and your counsel. The call is booked from the end of this page.