Guide for AI Practitioners in the GCC

Verification required. Regional claims on this page were compiled from secondary sources on 7 October 2026. No primary legal text was read, and each claim is tagged [Reported], [Conflict] or [Unverified] as explained on the section home page. Check the primary text before relying on any of them. This is not legal advice.

For data scientists, ML and AI engineers, MLOps and security engineers. Regional claims carry the tags used in the GCC AI Regulatory Hub.

1. What changes when you build in the GCC

1. Personal data law applies first. Every GCC state has a data protection law [Reported]. Training, fine-tuning, prompts, logs and embeddings can all be personal data.
2. There is no single AI law, but buyers behave as if there is one. Government and regulated-sector customers ask for ethics self-assessments, inventories, human oversight and vendor evidence [Reported].
3. Decide residency at design time. Where inference, logs, vector stores and backups sit must be known before the architecture is fixed.
4. Arabic needs the same testing as English. Cover quality, dialect handling, right-to-left output and bilingual notices.

2. Lifecycle checklist

CHG and RET are control themes from the Framework Adoption Guide.

3. Design points by topic

3.1 Residency and transfers

• Draw the data flow: user device, API gateway, model host, retrieval store, logs, telemetry, backup, support access.
• Mark each hop with country and legal entity. Third-country model APIs are a transfer.
• Prefer in-region hosting for personal and regulated data. In-region availability of your preferred model may be limited; record the trade-off in T04.
• Transfer rules differ by country and free zone. No article-level rules were verified for this guide; check each PDPL.

3.2 Prompts, logs and training reuse

• Decide whether prompts and outputs are used for training. Default to no for customer data.
• Redact before logging where possible. Set a retention period for prompt logs.
• Customers in regulated sectors often forbid provider training on their data; contract for it.

3.3 Human oversight

• For decisions with legal or similarly significant effect (credit, insurance, employment, eligibility), design a human review step and an objection route (TC-L03-008). A kill switch must be tested, not just present (AI-CTRL-025).
• Record who can override, how fast, and what is logged.

3.4 Fairness and explainability

• Define the protected or sensitive groups relevant to the country and use case with legal input. Nationality, gender, age, disability and religion are typical candidates; confirm locally.
• Test before release, annually and on material change (CBUAE expectation, reported). Use T10.
• Keep a human-readable explanation per high-impact decision.

3.5 Generative and agentic AI

• Treat tool-calling agents as privileged identities. Least privilege, per-tool approval, spend and action limits.
• Prompt injection and data exfiltration tests belong in release gates. NCA and NCSA AI guidance are reported to target generative and agentic AI; final text status differs, verify.
• Content safety: test culturally and legally sensitive outputs for the target country (religion, politics, public order). Define blocked categories with legal input.

3.6 Security baseline

• Map to ISO/IEC 27001-style controls first; then to the national baseline your customer uses (NCA, Dubai AI Security Policy, NCSA) [Reported].

4. Arabic and bilingual testing

5. Evidence to keep

Use case record, data-flow diagram, hosting attestation, model card, test results (security, safety, bias), approval record, kill-switch test log, incident log, change log. See the Evidence Register.

6. Common mistakes

• Treating "internal tool" as exempt from data protection.
• Sending personal data to an out-of-region API during testing.
• Testing only English.
• No named owner for model changes.
• Bias test run once and never repeated.
• Claiming ISO/IEC 42001 or a national seal without a certificate in hand.