Qatar Central Bank’s AI Guideline: what licensed entities must do before launching AI

The Qatar Central Bank (مصرف قطر المركزي) titled it the Artificial Intelligence Guideline for 2024, subtitled Regulating the use of Artificial Intelligence by QCB Licensed Entities, and it entered into force on 04/09/2024, which is 4 September 2024 [1]. It covers the use of AI by any entity the QCB regulates, and it applies whether the entity develops and implements AI on its own, purchases AI systems, or outsources processes or functions that rely directly on AI [1]. Buying a tool does not take a bank out of scope.

Generative AI is inside it. The introduction describes AI systems that produce self-generated outputs such as content, which it calls generative AI systems, alongside predictions, recommendations and decisions [1]. A chatbot in a banking app, a model that drafts a credit memo and an assistant that summarises a customer file are all AI systems for this purpose.

The word “guideline” undersells it. Most of its requirements are written in “must”, it closes by listing the secondary regulations an entity must also comply with, and an entity that wants to depart from any requirement has to ask the QCB for an exemption, tie the request to that requirement, support it with a documented business case and record it with an expiry date [1]. The UAE central bank’s AI guidance note, by contrast, is written in “should”, says it supplements rather than replaces other rules, and asks for no approval before launch [3]. For a bank working in both countries, I would treat Qatar’s text as the harder of the two on process, because it puts the regulator in front of the launch rather than behind it.

The approvals are what set this guideline apart. The table lists each point in the life of an AI system where the texts put the QCB ahead of the entity, with the clause each comes from.

Every row but the cloud one is from the AI Guideline [1], and the cloud row is from the Cloud Computing Regulation [2]. Section 11.3 adds that the QCB may send a system for further evaluation in a sandbox before it approves it [1]. The third column gives clause numbers as printed, and none of this is legal advice.

Read together, the rows turn an AI launch into a regulatory submission with a lead time, and nothing in the text says how long that lead time is. I would put the QCB dates on the project plan on the first day, beside the build milestones, because the approval sits on the critical path and a system that is ready and unapproved is still not live. The early notice in 13.6.1 points the same way: for autonomous high-risk AI, the QCB expects to hear about the system while it is still an idea.

The guideline gives an entity one of two roles for each system, and the register records which [1]. A Provider is a person or body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether paid or free. A User is the person or body under whose authority a system is operated [1].

The approval in 11.1 attaches to launching a new system as a Provider [1]. On those definitions, a bank that commissions a customer assistant from a supplier and puts it into service under its own name looks like a Provider, even though somebody else wrote the code. Section 14.3 closes the other door: a User that makes a material change to an AI model, with a view to putting it into service under its own name, is treated as a Provider [1]. My reading is that fine-tuning a vendor’s model and shipping it inside the bank’s app puts the bank on the Provider side. That reading is not legal advice, and it is the first question I would put to counsel and, through them, to the QCB.

Buying a finished high-risk product does not avoid approval either: it moves the approval to the contract, under 11.2 [1]. And 14.2, as written, applies to any User of an AI system, high-risk or not. The User submits to the QCB the Provider’s instructions for use and its technical and training results, with its own use testing, data sources and human oversight plan [1]. A vendor that will not share its training and test results is a vendor a Qatari bank may not be able to file for.

The guideline defines high-risk AI as a system risk-assessed as having the potential to cause significant negative impact to an entity’s operations or the financial system, including through its ability to affect a person or a group or limit their access to financial resources or essential services [1]. The entity makes that call with its own risk and criticality assessments of the process the system sits in, and it must disclose to the QCB the criteria it uses [1]. The text expects a system with no direct human oversight to score higher, and a vendor’s access to information and its reputation to count in the assessment [1].

Section 9.7 then takes part of the decision away. Whatever the entity’s own assessment says, a system must be classified as high-risk where there is potential harm to people in any of three areas [1].

The third area is the one I expect to catch people out. A general assistant that summarises customer files will meet health notes in hardship cases, marital details in joint accounts and children in savings products. On a literal reading it processes sensitive personal information, which makes it high-risk, with every high-risk row of the approvals table attached. Decide early whether each system can be kept away from those fields, because keeping it away is a design choice and reclassifying it later is an approval.

Section 7.5 expects the function that oversees AI to use committees to assess use cases before they are implemented [1]. A first-pass risk score for each use case gives that committee something concrete to argue with before the bank’s own method is agreed.

Every entity keeps an up-to-date register of all its AI system arrangements and discloses the full register to the QCB once a year and whenever the QCB asks [1]. Alongside it, the entity discloses a high-level risk and impact assessment, high-risk systems are highlighted and each system names its Provider [1].

Section 10.7 sets the fields. Each system carries its high-risk classification, the entity’s role as User or Provider, a category for its function and the human oversight protocol it runs under. A system that is bought, licensed or outsourced adds the Provider and any outsourcer, a third-party supplier assessment, the country of registration, local registration number and LEI where there is one, the registered address, the parent company, the governing law of the arrangement, the creation date and every upgrade, and the contract start and next renewal dates [1]. For a high-risk system the entity rates how easy the AI would be to replace, as easy, difficult or impossible, and names an alternative provider where one exists. High-risk systems also need a detailed life-cycle description, the date and main results of the latest risk assessment or audit, and the date of the next one [1].

Two of those fields cause trouble with generative AI. “All subsequent upgrades” means every model version a vendor ships, and on a hosted model that can happen without anybody at the bank deciding anything. “Impossible” to substitute is an answer a supervisor will read closely: a system built straight against one vendor’s API tends to earn it, while one built behind a gateway with a second provider already tested tends not to.

Every AI system must have a human oversight protocol, and the guideline names three: AI-assisted decision-making, where no decision is made without human approval for designated outputs; human exception oversight, where people monitor the system and can intervene or shut it down; and fully autonomous AI [1]. The protocol chosen goes in the register [1].

For high-risk systems, a Supervisor with the competence, training and authority to oversee the system must be able to understand its limits, interpret its output, decide not to use it or override it, and interrupt it through a “stop” button or a similar procedure [1]. Fully autonomous high-risk AI needs built-in guard rails or limits the AI cannot override, reviewed on a set schedule or in response to external volatility spikes and linked to warning levels or auto-close routines [1].

“Limits the AI cannot override” is an engineering requirement, and an instruction in a system prompt does not meet it, because a model can be talked out of its instructions. What meets it are limits enforced outside the model: code that checks each proposed action against hard rules before anything happens, and a switch a named person can throw.

Part E is where the guideline reaches the customer. An entity must tell customers when they are interacting with an AI system, and be transparent about its use of AI through accurate, understandable and accessible plain-language disclosure [1]. For non-high-risk systems, the guideline’s example being chatbots, customers are told before the service is first provided; for high-risk AI such as credit, insurance or employee issues, each time they interact with it [1]. The entity should also collect the customer’s consent to the risks of AI before providing the service [1].

One line changes how generative AI is run: each update of an AI system will be treated as a new version requiring customer notification [1]. Read literally, a bank whose chatbot moves to a new model version owes its customers a notice. That argues for pinned model versions and planned releases, because a vendor that changes the model under you also changes your notice obligations.

On request, customers get clear explanations of the types of data, variables and factors behind an AI decision, and the entity discloses how a decision may affect them and whether it can be reversed [1]. Customers can raise inquiries about AI decisions, and they get a two-choice process: supply data and resubmit to the AI system, or ask a qualified human decision-maker to review a negative decision [1]. An opt-out should be weighed against six factors, from the degree of harm to technical feasibility, and an entity that decides against one must offer another route of recourse [1]. Models used to detect fraud and identity theft are excluded from the disclosure requirements [1].

The guideline does not say which language a disclosure must be in. For customers who read Arabic first, plain language means plain Arabic, and I would test it with native speakers against the same scripts as the English.

Section 17 is more specific about attacks than most AI rules. An entity must run an AI Trust, Risk and Security Management (TRiSM) programme with tools for content anomaly detection, for protecting data from providers and other third parties and for third-party system security, an acceptable use policy and processes for assessing privacy, fairness and bias [1]. Before deployment it examines each model’s attack surface, and it must protect models against integrity attacks, query attacks that could lead to manipulation or theft, and prompt injections [1]. Any entity that uses AI must deploy a data loss prevention (DLP) tool and content anomaly detection [1].

The guideline also lists the rules that apply alongside it, among them Law No. (13) of 2016 on Personal Data Privacy Protection, the QCB’s Technology Risks Circular of January 2018 and the QCB’s Cloud Computing Regulation 2024 where an entity uses cloud-based AI [1]. That regulation, in force since 15 April 2024, requires an entity to ensure that personal and financial information is processed within Qatar only, and to get QCB approval before entering into a cloud arrangement [2]. Its definition of a cloud arrangement covers a third party that uses a cloud provider in the services it provides to the entity [2], which on my reading takes in most hosted AI services.

Processed is the word that matters. A cloud account in Doha can store the data while the model that reads the prompt runs on another continent. Before any architecture review, check whether a Doha region can run the model at all, provider by provider, because a region that stores the data may serve few of the models or none.

This is the order I would work in for one system at a QCB-regulated entity, from idea to launch. It is built from the texts, and the QCB sets no such sequence. The guideline also expects a defined AI strategy, board approval of the AI exposure the entity will tolerate and a function that oversees AI [1]. If those are not yet written, they come first, and a written AI governance policy with a control behind each clause is the quickest route I know to something a board can approve.

Fifteen lines look like a lot for one chatbot. Most are answered once, in the framework, and reused for every system after it. The lines that recur for each system are the role, the classification, the approvals and the register entry, which is why I would build those as a workflow the build pipeline can check, and keep the policy for the rest.

This is the work we sell as AI governance implementation, done for a QCB-regulated entity: the register kept as data and generated from the systems it describes, the approval packs assembled from evidence those systems already produce, and the oversight, stop and version controls built into the systems rather than written up beside them. Where the gap is a system rather than its controls, such as a customer assistant or a credit workflow, we build it with the approvals, an in-Qatar data path and the customer notices designed in from the start. We work with clients across the UK, the US and the Gulf, and Gulf clients can contract through 1AYM’s UAE entity. We have built Arabic-language AI, including bilingual Arabic and English search and Arabic document OCR, which matters when the plain-language disclosure has to be plain in Arabic too.

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, and I mention it for the method: the data placed in a named in-country region, in Qatar in that case. 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 stays with your compliance function and your counsel. The call is booked from the end of this page.