
United States
Vision 2030 turned AI adoption into a board-level expectation, and that has produced a great deal of procurement with very little scoping. We work in Arabic and English from Riyadh, design against SDAIA's seven AI Ethics Principles and the PDPL from the first workshop rather than the final review, and architect for in-Kingdom data residency when the workload requires it.

In most markets you choose a model on accuracy, latency and cost, then work out the compliance position afterwards. For regulated workloads in the Kingdom that order is backwards, and reversing it late is the single most expensive mistake we are asked to unwind.
The framework is layered. The Personal Data Protection Law governs personal data, and it sits alongside SDAIA's AI Ethics Principles for the AI system itself, the National Cybersecurity Authority's Essential Cybersecurity Controls and Cloud Cybersecurity Controls for the platform underneath, and then sector rules from SAMA, the Ministry of Health, the Communications, Space and Technology Commission and others depending on who you answer to. Any one of those can rule out an architecture that was otherwise the obvious technical choice.
So we establish the constraints in scoping. Where the data may be processed, what lawful basis covers it, what has to be logged and for how long, and which decisions require a human in the loop. Once those are settled, model selection is a straightforward engineering question, and it is a question with several good answers rather than one that has to be argued past a regulator.
Fairness
Bias testing against the groups the system actually affects, with the evaluation set and the results documented rather than asserted. For screening and eligibility decisions this is the principle regulators and complainants both reach for first.
Privacy and Security
PDPL obligations made concrete: lawful basis recorded, data minimised to what the use case needs, encryption in transit and at rest, tenant isolation for multi-customer deployments, and a retention policy covering prompt logs and model artefacts as well as source records.
Humanity
Human oversight designed into the workflow rather than promised in a policy. Any decision affecting an individual's rights, entitlements or employment keeps a person with real authority to overrule the system, and that authority is written down.
Social and Environmental Benefit
The use case is stated in terms of the benefit it creates and who receives it, alongside the run cost. In practice this is the section that stops vanity deployments, because a use case with no articulable beneficiary rarely survives writing it down.
Reliability and Safety
Validation against a held-out set of real cases, defined accuracy thresholds tied to the current process baseline, behaviour specified for degraded and failure conditions, and a documented condition under which the system should be switched off.
Transparency, Explainability and Accountability
Data sources, model design and decision logic documented to the extent feasible for the technique used, every automated decision logged with its inputs and system version, and a named owner with an escalation route and an incident reporting path.
DATA RESIDENCY
Residency is the constraint that most often decides the architecture before anything else does, and the one most often discovered late by teams who scoped the model first.
Personal data, sensitive personal data, and sector-regulated data carry different obligations, and a single workflow often touches more than one class. We classify what the use case actually needs at the field level, because the classification of the narrow path is what matters rather than that of the whole dataset.
Whether the records may be processed outside the Kingdom, and under what conditions, determines which providers and regions are available. Establishing this after a model has been chosen is how teams end up rebuilding a working system for reasons that have nothing to do with its performance.
We architect for in-Kingdom cloud regions, or entirely inside your own tenancy, when residency demands it. That constrains model choice, and we would rather present you with the honest shortlist under the constraint than an ideal architecture you cannot deploy.
Prompt logs, embeddings, fine-tuning datasets and cached retrievals all contain the underlying records and are routinely omitted from retention policies written for databases. We treat them as in scope from the start, because discovering them during an audit is not the moment to start that conversation.
SECTOR OVERLAY
Beyond PDPL and SDAIA, the sector regulator usually adds requirements that change the design. These are the overlays we most often work under.
SAMA-regulated entities carry additional expectations around outsourcing, model risk, cybersecurity and customer data handling. Automated decisions affecting customers need an explainability position and a human review route established before build, not after a supervisory question.
Patient data raises both the classification and the oversight requirement, and Ministry of Health expectations apply alongside PDPL. Clinical or triage-adjacent use cases need the human-in-the-loop boundary drawn conservatively and documented in the deployment record.
Procurement here tends to require the governance artefacts as deliverables rather than as internal practice: the pre-deployment review, the logging design and the accountability record are part of what is handed over, and we scope them that way from the start.
CST rules interact with subscriber data handling and with any customer-facing automated interaction. Voice and chat automation in particular needs its disclosure and escalation behaviour specified rather than left to the model's discretion.
Usually lighter on personal data and heavier on operational technology boundaries. The design questions move to network segmentation, what may cross from the OT side, and what a model is permitted to actuate versus merely recommend.
High personal-data volume with marketing and profiling use cases attached, which is where consent, lawful basis and the individual's rights under PDPL become the practical constraint rather than a formality noted in a policy document.
HOW WE WORK HERE
Workshops, interviews with operators, the report and the runbook are delivered in Arabic where the team works in Arabic. Documentation your staff cannot read is documentation that does not transfer ownership, whatever the handover meeting concluded.
We run Sunday to Thursday, plan around Ramadan working hours and the Eid periods, and schedule stakeholder time in Riyadh rather than expecting your team to take calls at the end of their day for someone else's convenience.
The hub: how scoping, roadmap and build fit together across both the Saudi and US markets.
The two-week method that produces the baseline, the ranked opportunities and the governance blockers.
Five dimensions scored separately, with the governance dimension assessed against SDAIA and PDPL.
The build side: models, pipelines and integrations delivered for Saudi organisations.
Let's discuss how we can create a custom GPT-powered solution tailored to your specific needs and industry challenges.
GLOBAL PRESENCE
Three hubs, one mission, dedicated teams across time zones delivering seamless collaboration and round-the-clock coverage for every client.

United States

Pakistan

Saudi Arabia