You didn't download this because your AI programme is failing. You downloaded it because you're responsible for one that has to keep working — under regulators who are no longer waiting, with data pipelines that were never built with compliance in mind, and with a board that wants one answer covering three different domains.
What follows isn't a product catalogue. It's the kind of information that tends to surface in post-audit reviews, when everyone is asking why nobody said it before the regulator asked.
Five things. All of them real. All of them fixable. Plus one that almost no AI or security vendor will tell you about — because it requires someone who sits across both.
This guide is published jointly by Paringa AI and Databorn. Databorn has spent 20 years building AI and data systems for financial services, telecoms, and government organisations across the UAE, KSA, and MENA. Paringa provides the governance, data privacy, and cyber security layer that makes those implementations regulator-ready. We wrote this together because the problems are connected, and separate answers are part of the problem.
Your AI Model Inventory Doesn't Include the Models Your Employees Built Without Telling You
The CBUAE's February 2026 AI Governance Guidance Note requires every UAE-licensed financial institution to maintain a comprehensive AI model inventory. In Saudi Arabia, SDAIA expects the same. Both regulators want to know: what AI tools are in use, who is using them, and what data are they touching.
Most organisations can answer this for the AI they sanctioned. Fraud detection models. Credit decisioning engines. Customer analytics platforms. The ones that went through procurement and were deployed by IT.
They cannot answer it for the AI their employees are using alongside. ChatGPT to summarise credit analysis documents. Copilot to draft correspondence containing customer references. Gemini to analyse complaint data. Specialist AI tools adopted department by department, none of which went through IT, none of which are in anyone's model inventory.
This is not a policy failure. It is a structural gap. The tools appeared faster than the governance process could track them. The people using them are not doing anything they believe to be wrong. But the data they are feeding into these tools is regulated data — and the regulator's inventory requirement makes no distinction between sanctioned and unsanctioned tools.
Separate your sanctioned AI audit from your shadow AI discovery. The sanctioned audit — reviewing every model, pipeline, and data source you approved — is something your internal team or an AI specialist can conduct. The shadow discovery requires dedicated tooling: CASB, browser-level visibility, endpoint telemetry. One without the other produces an incomplete inventory.
Classify every tool by data type handled. The CBUAE and SDAIA are not asking whether you use AI. They are asking whether your AI use is controlled. Classification — approved, conditional, prohibited — is the governance action the inventory enables.
Run the inventory before you write the policy. Most organisations draft an AI use policy and then try to enforce it without knowing what tools are in use. Run the inventory first. Write the policy to match what you find.
The Personal Data Flowing Through Your AI Pipeline Is Unprotected at the Data Layer
Most organisations deploying AI in regulated environments have perimeter security: firewalls, endpoint protection, access controls. What most do not have is protection at the point where personal data actually enters an AI model.
Customer names, national IDs, transaction records, health data — they enter the AI pipeline as plaintext. The model processes them as plaintext. If the pipeline is compromised, if a third-party model vendor has a breach, if an employee exports an AI-generated output containing real customer identifiers — the data was never protected at the layer where it matters most.
UAE PDPL (Federal Decree-Law No. 45 of 2021): Processing personal data outside its permitted scope or without the required legal basis creates a notification obligation and exposes the organisation to fines of AED 100,000 to AED 1,000,000 per violation. The data does not need to be stolen. It needs to be processed incorrectly.
Saudi Arabia PDPL (enforced from September 2024): SDAIA issued 48 enforcement decisions in 2025 — for insufficient technical and organisational security controls over personal data. Fines reach SAR 5 million per violation, with criminal penalties available. Processing personal data of Saudi residents through AI systems that lack adequate controls is within scope.
CBUAE AI Governance Guidance (February 2026): Explicitly requires privacy-by-design embedded in AI systems. Not as a policy statement. As a technical control. This is the architectural requirement most organisations do not currently satisfy.
The technical answer is tokenisation. Sensitive data is pseudonymised before it enters any AI pipeline. Customer names become tokens. National IDs become references. The model receives statistical utility — the patterns and relationships it needs to produce useful outputs. The individual identity never reaches the model.
This approach was applied for a government-backed healthcare organisation aggregating patient data from multiple hospitals for AI-driven drug discovery. Tokenisation made the programme legally possible while ensuring individual patient identity was never exposed to the research pipeline. No other vendor in the room could offer this answer.
Map every point at which personal data enters your AI pipelines. For each entry point, establish: what is the legal basis for this processing, what data types are involved, and what technical control ensures the data cannot be individually identified if the pipeline is compromised. Where no adequate technical control exists — tokenisation is the architecturally correct answer, and it does not require restructuring your AI system to implement it.
Your AI Governance Documentation Won't Survive a Regulatory Examination
Most organisations interpret "AI governance" as a policy document. An acceptable use policy. A statement of principles. A set of guidelines that were approved by the Board and filed with the risk function.
That is not what the CBUAE is looking for. It is not what SDAIA is looking for. ISO 42001 — the international standard for AI Management Systems, which both regulators reference as the implementation framework — requires continuous, documented evidence that governance controls are actually operating, not merely stated.
The gap most organisations have is not that they lack governance intent. It is that intent is not evidence. A policy document is not a risk register. A board presentation is not an audit trail. What regulators will ask for — on demand, without advance notice — is the documented record of what AI tools are in use, how they are classified, what controls are operating, and what the last review found.
Distinguish between governance intent and governance evidence. Your policy document establishes intent. Your risk register, classification log, and control monitoring generate evidence. You need both. Most organisations only have the first.
Map your governance documentation against ISO 42001 control requirements. The standard specifies what evidence is required for each control area. Work backwards from the requirements, not forwards from what you have.
Automate evidence generation where possible. Manual governance documentation has a half-life. A month after your last review, it is already out of date. The AI inventory you produced is already incomplete. The organisations that pass regulatory examinations maintain living evidence, not point-in-time reports.
Your AI Models Are Making Decisions That Nobody Can Fully Explain
Most AI models deployed in financial services and government are not black boxes. They are grey boxes. The teams that built them understand the general logic. Nobody can explain every individual output in the precise terms a regulator, an auditor, or a customer disputing a decision will demand.
This was an acceptable operational reality before CBUAE AI governance requirements and ISO 42001 made model explainability and bias testing mandatory. It is no longer acceptable now.
Annual bias testing. AI models used in credit decisioning, risk assessment, fraud detection, and customer management must be tested annually for bias — and the testing must be documented and available to examiners.
Board-level accountability. The Board must be able to demonstrate that it understands the AI models in use and the risk they represent. A board pack that says "our AI models perform well" is not accountability. A board pack that says "here are the models, here is their risk classification, here is the last bias test result, and here are the controls operating around them" is.
Explainability for outsourced AI. If you are using third-party AI models — including cloud-based AI services — the CBUAE requires audit rights and the ability to immediately cease the use of any model that fails to meet governance standards. Most third-party contracts do not currently provide this.
The model you built two years ago and have been running successfully may be the model that creates your governance problem today. Not because it is performing badly — but because you cannot produce the documentation a regulator will ask for.
Conduct a model governance review for every AI system touching regulated decisions. Credit, fraud, AML, customer segmentation. For each: document the model's purpose, the data it uses, the last performance review, and the controls operating around it.
Run a bias test now — before the regulator asks. Bias testing is not a statement that your model is unbiased. It is a documented assessment of whether your model produces systematically different outcomes for different population groups, and what the organisation's response to any disparity is.
Review your third-party AI contracts against CBUAE outsourcing requirements. Audit rights and cessation capability are now regulatory requirements, not negotiating positions. If your current contracts don't provide them, they need to be renegotiated.
Your AI Programme Was Designed for the Business Case, Not the Regulatory Environment
Most enterprise AI programmes were built with one primary question: does it work? Does the fraud model catch more fraud? Does the credit model reduce defaults? Does the customer analytics platform increase retention? These are the right questions for a business case. They are not the only questions a regulator will ask.
Data residency. Where does the personal data processed by your AI systems actually reside? The TDRA in the UAE mandates that personal data remain within UAE-compliant data centres. Most cloud-hosted AI services process data in regions that do not automatically satisfy this requirement.
Consent scope. The personal data your AI models use was collected with a specific consent. Does the AI processing of that data fall within the original consent scope? PDPL in both the UAE and Saudi Arabia treats processing outside consent scope as a violation — regardless of whether the original data collection was lawful.
Cross-border transfers. Many AI organisations in the UAE and KSA process data through European, US, or Asian AI platforms. Each cross-border transfer is a regulatory event under PDPL. Most AI procurement processes do not assess this at the point of tool adoption.
Regulatory divergence. Operating across UAE, KSA, and any EU footprint means PDPL (UAE), PDPL (KSA), CBUAE guidance, and GDPR simultaneously. What satisfies one framework may not satisfy another. The operational burden of managing them separately is substantial and largely invisible until an audit surfaces it.
Run a regulatory compliance review across your existing AI estate — not just new deployments. For each system, map the data residency, consent basis, cross-border transfer position, and regulatory framework applicability. The review will almost certainly surface issues. Better to surface them internally than in a CBUAE examination or an SDAIA investigation.
If your organisation operates across UAE and KSA simultaneously, appoint a single point of accountability for cross-jurisdictional AI governance. The frameworks are similar enough to confuse and different enough to create gaps if managed separately.
Nobody Asked Whether the People Who Built the AI Can Also Govern It
Everything in the previous five sections can be addressed. The technology exists. The frameworks are documented. The regulatory requirements, while demanding, are achievable. None of this is the hard part.
The hard part is structural. The team that built your AI programme was optimised to build it. They made excellent choices about data architecture, model selection, infrastructure, and performance. They were not optimised — and in many cases, were not positioned — to simultaneously address data privacy at the pipeline level, cyber security at the perimeter and data layer, and governance documentation at the standard a regulator will accept.
A data exfiltration event through an AI tool is simultaneously an AI governance failure, a PDPL breach, and a cyber security incident. The notifications required under each regulatory framework differ. The remediation involves functions that don't normally talk to each other. The board wants one answer.
Most organisations in the UAE and KSA market currently manage this as three separate problems with three separate partners: an AI implementation partner, a cyber security provider, and a compliance consultant. None of them has full visibility of what the others are doing. None of them can give the board the single answer it needs.
The organisations that handle AI governance well have one thing in common: a single partnership that sits across implementation, data privacy, cyber security, and compliance evidence simultaneously — and can translate between technical reality, regulatory obligation, and the board conversation. That is what Paringa and Databorn built together.
What Happens Next
The honest version.
There are three things worth doing before 16 September 2026:
If you'd like an independent AI governance assessment, we're happy to have that conversation — no commitment required.