All jurisdictions

Qatar / Banking and financial services

What AI rules apply to banks in Qatar?

BindingVerified September 1, 2026

Four separate QCB approval gates stand between a Qatari bank and a live high-risk AI system, which amounts to a pre-authorization regime.

The QCB's Artificial Intelligence Guideline states that it shall enter into force as of 04/09/2024. Read in full, it is not a principles document at all: it is a licensing-style regime. The regulator approves the training, validation and testing results of any new high-risk system before launch, approves high-risk AI procurement before the contract is signed, approves any fully autonomous system whatever its risk rating, and receives the entity's full AI register every year. The EU AI Act, by contrast, routes conformity assessment for Annex III points 2 through 8 to the provider's own internal control.

Primary source

Every requirement on this page was read in the issuing authority's own text.

Scope

Who this applies to

  • Any Entity regulated by the Qatar Central Bank (§2, definition of Entity)
  • Entities that develop and implement AI on their own, purchase AI Systems, or outsource processes or functions that rely directly on AI (§5)
  • Entities acting as User of a system and Entities acting as Provider, a distinction the register must record (§10.7.2)

What pulls a system into scope

  • Deployment of any AI System by a QCB-regulated Entity (§5)
  • A mandatory high-risk classification under §9.7 where there is potential harm to natural persons: interactions determining consumer access to financial services, internal decisions materially affecting employees, or processing of sensitive personal information
  • Signing a high-risk AI purchase, licensing or outsourcing agreement, which requires prior QCB approval (§11.2)
  • Launching a new AI System as a Provider, or materially modifying an existing one, which also requires prior QCB approval (§11.1)

Obligations

What is actually required

Board and senior management accountability

§7.1-§7.3

The Board and senior management remain accountable for the outcomes and decisions of the Entity's AI Systems, including systems that make decisions on behalf of the Entity. The Board approves the level of AI exposure tolerated in the overall risk framework, decides whether existing governance structures are fit for purpose, and ensures adequate human resourcing of all AI functions. Senior management must include one or more members with the knowledge to understand and manage technology risks.

Committee review of AI use cases before implementation

§7.5, §7.4

The function responsible for overseeing AI must utilize or create appropriate committees to assess AI use cases prior to implementation. An Entity should establish a function overseeing AI or delegate that responsibility to an existing function.

Mandatory high-risk classification floor

§2 (def. 10), §9.6, §9.7

High-Risk AI is defined at §2 as systems risk-assessed as having potential to cause significant negative impact to the Entity's operations or the financial system, judged by severity, intensity, probability, duration, and ability to affect individuals or limit access to financial resources or essential services. Notwithstanding the Entity's own determination under §9.6, it must classify a system as high-risk where there is potential harm to natural persons in three areas: interactions determining consumer access to financial services, internal decisions materially affecting employees, and processing of sensitive personal information.

QCB approval of training, validation and testing results

§14.1, §14.2

For any new high-risk AI System, an Entity must submit the full results of the system's training, validation and testing to the QCB for approval. A User must additionally submit the Provider's instructions for use and the Provider's technical and training results, plus the results of its own use testing, its data sources and its human oversight plan.

QCB approval before signing high-risk AI contracts

§11.2, §11.3, §11.1

An Entity must receive official QCB approval prior to signing any high-risk AI purchase, licensing or outsourcing agreement. Before granting approval the QCB may direct the system into a sandbox environment for further evaluation. Separately, approval is required before launching a new AI System as a Provider or materially modifying an existing one.

QCB approval for any fully autonomous system

§13.6.1, §13.5.1

A high-risk system with no human oversight of decision execution requires prior QCB approval before launch, and the Entity is expected to notify the QCB as soon as such a system is actively being considered or developed. Even where a fully autonomous system is viewed as low or no risk, the Entity must provide very detailed information to support its use for QCB approval.

Guard rails the AI cannot override

§13.6.2-§13.6.5

A fully autonomous high-risk system must have built-in guard rails or specific limits the AI cannot override, reviewed on a frequent set schedule or in response to external volatility spikes, with in-built limits linked to warning levels or auto-close routines. The Supervisor must be able to close the system down where outputs or surrounding data seem aberrant.

Named Supervisor and a stop button

§13.1-§13.4, §13.7.5

Any AI System must have a human oversight protocol. The User assigns oversight to a Supervisor with the competence, training and authority to operate or oversee the system, equipped to understand its capacities and limits, interpret its output, decide not to use or to disregard, override or reverse the output, and interrupt the system through a stop button or similar procedure. Systems must carry built-in operational constraints that the system itself cannot override.

Register of all AI systems

§10.1, §10.7

An Entity must develop and maintain an updated Register of all its AI System arrangements, recording per system the high-risk classification, whether the Entity is User or Provider, a category reflecting functional use, and the human oversight protocol used.

Annual disclosure of the full Register to the QCB

§10.6, §10.2, §10.3

The full Register goes to the QCB annually and on request. The Entity must separately disclose the criteria it uses to decide whether a contract for a specific system is high-risk, and a high-level risk and impact assessment.

Vendor substitutability and exit planning

§10.7.5.10, §10.7.5

For every high-risk purchased, licensed or outsourced system the register must rate the AI's substitutability as easy, difficult or impossible and identify an alternate service Provider where applicable, alongside governing law, contract start and renewal dates, and the provider's country of registration and LEI.

Provider data must be contractually secured and disclosable to the QCB

§15.1, §15.2

An Entity must be able to manage a system across its life cycle either directly or by contractual provision from the Provider, who is expected by contract to supply all data from development, testing, pre and post-market introduction, regular performance testing and system development. The Entity must make available to the QCB the full range of data the Provider is contractually obliged to provide to it.

Board approval and contract terms for AI outsourcing

§12.5, §12.10.6-§12.10.8, §12.11

Board approval is required to outsource any AI-related function, and must be documented. Service agreements must include the right to terminate for non-compliance or when the QCB so directs, exit clauses ensuring data is wiped on termination, and a QCB right to audit the provider's accounts. The Entity remains responsible as principal for all acts of its outsourcing providers.

Demographic bias testing

§15.7, §15.9

The Entity must ensure the model is checked for systematic bias by testing it on different demographic groups, to observe whether any group is being systematically advantaged or disadvantaged. Training, validation and testing data sets must be subject to documented design choices and data governance practices covering collection, preparation, assumptions, prior suitability assessment, bias examination and identified data gaps.

AI TRiSM program with named toolsets

§17.2, §17.3

An Entity must develop an AI Trust, Risk and Security Management program including toolsets for content anomaly detection, data protection from Providers and third parties, and third-party system security, plus an acceptable use policy and processes for assessing privacy, fairness and bias. The program must ensure AI Providers adhere to it.

Named security controls, including prompt injection

§17.4-§17.9

Examine an AI model's attack surface prior to deployment and address findings; protect against integrity attacks, against query attacks leading to manipulation or theft, and against prompt injections leading to data poisoning or drift; deploy a data loss prevention tool and content anomaly detection tools.

Monitoring, versioning and archived training data

§19.1-§19.3

An Entity must support monitoring systems and plans for high-risk systems, including accessing Provider information, and must ensure Provider compliance with evaluating conformance to predicted model outcomes across the life cycle. Records should be auditable: audit logs and traceability of decisions and outcomes, design documentation, robust model versioning including code, and archiving of the original data sets used to develop, re-train or calibrate models.

Customer notification, explanation and two-choice recourse

§20.1-§20.6, §20.10-§20.11, §21.1-§21.2

Customers must be notified when interacting with an AI System, given plain-language disclosure, told on request the data types and factors influencing the decision, and told how a decision affects them and whether it is reversible. A mechanism must exist to request review of decisions made with no human intervention, offering a two-choice process: supply data to alter the system and resubmit, or request human review by a qualified decision-maker. Intellectual property need not be disclosed, and fraud and identity-theft models are excluded from disclosure.

Formal exemptions, time-boxed

§23.1-§23.6

An Entity seeking exemption from any requirement must request it from the QCB, supported by a documented business case and linked to a specific requirement. All exemptions are subject to QCB approval, must be recorded in an exemptions Register with an expiration date by which the exemption will be mitigated or resolved, and the Entity remains accountable for the risks arising from them.

If you already built for the EU AI Act

An institution that has built to the EU AI Act for Annex III high-risk systems: risk management under Article 9, data governance under Article 10, technical documentation under Article 11, human oversight under Article 14, and deployer duties under Article 26.

DimensionEU AI ActQatarDelta
Who signs off before launchSelf-assessment through internal control for Annex III points 2 through 8, with biometric systems under point 1 requiring a notified body where harmonized standards are not applied. No regulator approves a high-risk system before it goes live.Four separate QCB approval gates: training, validation and testing results for any new high-risk system (§14.1); high-risk AI procurement before contract signature (§11.2); launch as Provider or material modification (§11.1); and any fully autonomous system whatever its risk rating (§13.5.1, §13.6.1).No EU equivalent
Risk tiers and who assigns themA closed statutory list at Annex III. Creditworthiness assessment of natural persons and employment decisions are both on it.A mandatory floor of three categories at §9.7. Two track Annex III closely enough that an EU mapping largely carries over.Already covered by EU work
Sensitive data as a risk triggerProcessing special-category data engages the GDPR but does not by itself make a system high-risk under the AI Act.§9.7.3 makes processing sensitive personal information a mandatory high-risk trigger in its own right, so systems an EU mapping leaves outside the perimeter fall inside it here.No EU equivalent
Provider and deployer rolesArticle 25: a deployer that puts its name or trademark on a high-risk system, or substantially modifies it, takes on provider obligations.§14.3 is a close analogue: a User that materially changes an AI Model with a view to placing it on the market under its own name or trademark is considered a Provider. §2 adds that a substantially modified system is a new system, ending the previous life cycle.Already covered by EU work
Recurring disclosure to the supervisorArticle 49 registration attaches to providers of Annex III systems and public-authority deployers, not to private-sector deployers generally. No recurring filing.The full Register goes to the QCB annually and on request, with the high-risk criteria used and a risk and impact assessment.No EU equivalent
Vendor diligence and contractsArticle 25 allocates responsibilities along the value chain, but a regulator does not obtain vendor development data through the deployer's contract.§15.1 expects the Provider to supply development, testing and performance data by contract, and §15.2 requires the Entity to make that full range of data available to the QCB.No EU equivalent
Concentration and exit planningNo equivalent. Concentration and exit risk sit in sectoral outsourcing rules, not the AI Act.The register must rate each high-risk vendor system's substitutability as easy, difficult or impossible and name an alternate provider, with contracts carrying data-wipe exit clauses and a QCB audit right over the provider.No EU equivalent
Limits on autonomous operationArticle 14 requires human oversight for high-risk systems but does not prescribe guard rails or auto-close behavior.Fully autonomous high-risk systems need built-in guard rails the AI cannot override, reviewed on schedule or on external volatility spikes, with limits linked to warning levels or auto-close routines. Drafted with algorithmic trading in view.Extends EU work
Bias testingArticle 10 requires examination for bias in data governance for high-risk systems, without prescribing a method.§15.7 prescribes the method: test the model on different demographic groups to see whether any group is systematically advantaged or disadvantaged.Extends EU work
Security controlsArticle 15 requires appropriate accuracy, robustness and cybersecurity without naming tooling.Named and testable: attack surface examination, protection against integrity attacks, query attacks and prompt injection, a data loss prevention tool, and content anomaly detection.Extends EU work
Contestability and recourseGDPR Article 22 gives a right to human intervention; AI Act Article 86 gives a right to explanation of individual decision-making for Annex III systems.§21.2 requires a two-choice process: supply data to alter the system and resubmit, or request human review. The resubmission limb has no EU analogue.Extends EU work
Waivers and exemptionsNo waiver mechanism. Obligations apply or they do not.§23 provides a formal route: request a waiver from a specific requirement with a documented business case, subject to QCB approval, recorded with an expiration date.No EU equivalent
When it bitesHigh-risk obligations for standalone Annex III systems apply from 2 December 2027; Annex I embedded systems from 2 August 2028.In force since 4 September 2024 under §1, roughly three years ahead of the EU timetable.

Instruments

What the requirements rest on

BindingTier 1 source· Issued 2024-09-04

Artificial Intelligence Guideline (2024)

Qatar Central Bank

Titled a guideline, drafted as instructions with a commencement clause, and operating as a pre-authorization regime. It distinguishes must from should deliberately: the approval gates, register, bias testing and security controls are must; customer consent, the opt-out and most documentation duties are should. This is why this entry is labeled binding where the UAE entry is not: the QCB instrument carries a commencement clause and mandatory drafting, and the CBUAE Guidance Note carries neither.

22 pages, 24 articles across six parts, read in full. The PDF carries no text layer: its text is outlined vectors. Pages were therefore rendered to images with pypdfium2 and read directly rather than extracted. §1 states: the instructions set forth herein are titled the Artificial Intelligence Guideline for 2024 and shall enter into force as of 04/09/2024.

BindingTier 1 source· Issued 2016

Law No. (13) of 2016 on Personal Data Privacy Protection

State of Qatar

The data protection floor beneath the AI Guideline. §15.15 permits processing personal data strictly as necessary for bias work, subject to this law, with pseudonymization or encryption where feasible.

Cited at §15.15 as the law governing processing of personal data by Providers of high-risk systems for bias monitoring, detection and correction. The statute itself was not separately reviewed for this entry.

BindingTier 1 source

Sector-Specific Security Regulation

Qatar Central Bank

AI security obligations sit on top of the existing sectoral security regime rather than replacing it.

Referenced at §17.1, which requires compliance in all deployment of AI solutions. Not separately reviewed for this entry.

BindingTier 1 source· Issued 2018-01

Technology Risks Circular (January 2018)

Qatar Central Bank

Part of the stack §24 wires the AI Guideline into, in the same way the CBUAE note routes into the Model Management Standards.

Named at §24.1.3 as a secondary regulation an Entity must comply with alongside the AI Guideline. Not separately reviewed for this entry.

BindingTier 1 source· Issued 2024

Cloud Computing Regulation (2024)

Qatar Central Bank

Applies to most production AI deployments in practice, since almost all of them are cloud-hosted.

Named at §24.1.4 as applying where an entity leverages cloud-based AI solutions. Not separately reviewed for this entry.

GuidanceTier 2 source· Issued 2025-08

FinTech and Digital Transformation Strategy (2025)

Qatar Central Bank

Context rather than obligation. Signals AI supervision is being institutionalized rather than left as a single publication.

Reported as expanding the 2024 guideline into a wider strategy making AI oversight a core pillar. Not reviewed in primary form.

Enforcement

How this is actually supervised

Supervisor
Qatar Central Bank
Mechanism
Direct supervision of regulated entities, with two structural advantages over examination-only regimes: the annual Register disclosure means shortfalls surface in a filing, and the approval gates at §11.1 and §11.2 mean the QCB sees high-risk systems before they are contracted rather than after.
Observed to date
No AI-specific enforcement action identified at the verification date. Note §19.5: in the event of a serious incident the Entity should report to the QCB immediately after a causal link between the AI System and the incident is established, or its reasonable likelihood.

Action

What to do Monday morning

  1. 1Establish whether any new high-risk AI system went live without submitting its training, validation and testing results to the QCB for approval under §14.1. This is a pre-launch gate, so a live system that never passed it is already in breach.
  2. 2List every fully autonomous system, at any risk rating. §13.5.1 and §13.6.1 both require QCB approval, and §13.6.1 expects notification as soon as such a system is actively being considered, earlier than most institutions think to involve a regulator.
  3. 3Check whether the annual Register disclosure under §10.6 has ever been filed. The instrument has been in force since 4 September 2024, so the exposure is missed filings rather than a future deadline.
  4. 4Run §9.7 as a mandatory floor separately from any internal rating. The third limb, processing of sensitive personal information, catches systems an EU Annex III mapping leaves out.
  5. 5Audit AI vendor contracts against §15.1-§15.2 and §12.10: do they actually oblige the provider to hand over development, testing and performance data, and can that data be passed to the QCB? Do they carry data-wipe exit clauses and a QCB audit right?
  6. 6Rate each high-risk vendor system's substitutability as easy, difficult or impossible and name an alternate provider, per §10.7.5.10.
  7. 7Confirm §15.7 demographic bias testing is actually run, and that §17 controls exist as deployed tools rather than policy language.

This page tells you what applies. It cannot tell you what you are running.

The Diagnostic maps your actual AI systems against these requirements and returns the gaps in priority order, with the evidence an examiner would ask for. Built once against the most demanding specification you face, it answers the questions in every other jurisdiction you operate in.

Request the Diagnostic

Watch list

What would change this verdict

  • How the §11.2 approval gate operates in practice: expected turnaround, required documentation, and how often systems are diverted into the sandbox under §11.3.
  • Whether the QCB publishes findings or expectations from the first cycles of annual Register disclosures.
  • Whether the 2025 FinTech and Digital Transformation Strategy adds obligations beyond the 2024 instrument or restates it.

Questions

Common questions

Is the QCB AI Guideline mandatory?

Substantially yes. §1 states the instructions shall enter into force as of 04/09/2024, and the operative duties are drafted as what an Entity must do, including four separate QCB approval gates. The document does distinguish must from should: customer consent to AI risks (§20.9), the customer opt-out (§22.1) and most of the documentation article (§18) are drafted as should.

Do we need QCB approval before buying an AI system?

For high-risk AI, yes, and in more than one way. §11.2 requires QCB approval before signing a high-risk AI purchase, licensing or outsourcing agreement. §14.1 separately requires submitting the system's full training, validation and testing results to the QCB for approval. §13.6.1 requires approval for any fully autonomous high-risk system, with notification as soon as one is actively being considered.

What counts as high-risk AI in Qatar?

The Entity determines it under §9.6, but §9.7 sets a mandatory floor wherever there is potential harm to natural persons: interactions determining consumer access to financial services, internal decisions materially affecting employees, and processing of sensitive personal information.

If we comply with the EU AI Act, are we covered in Qatar?

No. High-risk categories, human oversight and the deployer-becomes-provider rule carry over well. But Qatar runs a pre-authorization regime the EU does not: regulator approval of training and testing results, of high-risk procurement, and of autonomous systems, plus an annual register, vendor substitutability ratings, QCB reach into provider data, and sensitive-data processing as a standalone high-risk trigger.

Verification notes

  • The Guideline PDF carries no text layer, so all 22 pages were rendered to images and read directly rather than extracted. Clause numbers and wording were transcribed manually from those images.
  • All 22 pages were read. Instruments the Guideline cross-references were confirmed as cited within the text but not separately reviewed: Law No. (13) of 2016, the Sector-Specific Security Regulation, the Technology Risks Circular and the Cloud Computing Regulation.
  • One secondary source renders the issue date as September 2026. It is 2024: §1 gives 04/09/2024, and Qatar News Agency reported the issuance on 4 September 2024.
  • Two corrections to earlier versions of this entry, recorded rather than silently fixed: customer consent to AI risks (§20.9) is a should and not a must; and the entry previously described a single procurement approval gate, where the instrument in fact contains four distinct QCB approval requirements.

Last verified September 1, 2026 by Rabii Agoujgal.

This entry is provided for informational purposes and does not constitute legal advice. Applicability of any regulation, guidance, or standard discussed depends on the facts, deployment context, and relevant jurisdiction. Regulatory positions change; check the verification date before relying on this page.