Private & Sovereign AI Platforms Run AI where your data is allowed to be, on a platform you control

Control, not location alone. Hosting in a data centre inside the Kingdom gives you residency; a platform is sovereign only when encryption keys, administration and change control are held by your organisation or a party you approve inside the Kingdom, and every dependency that could move data or control outside is removed or documented as an exception you accept in writing. In practice we check four things: who holds the keys and who can rotate them, which accounts administer the platform and from where, who approves and who applies changes and updates, and what still connects outside, such as licence checks, telemetry, remote support and update services. The design records the answer to each, so calling the platform sovereign rests on evidence you can inspect.

It depends on the deployment option. With private hosting or Saudi data residency, outside services can remain, such as a commercial model through its enterprise API, licence checks, telemetry or remote support; on a sovereign platform only those you approve in writing remain; in an air-gapped design none remain at run time. Each one has an entry in the dependency register: its purpose, the data or metadata it receives, where that goes, who approved it and how it could be removed or replaced. Where a dependency would send personal data outside the Kingdom, the entry flags it as a transfer question under the Regulation on Personal Data Transfer outside the Kingdom for your data protection officer to review. Anything not needed is switched off where the software allows it, and recorded where it does not.

Open-weight models whose licence allows your intended use, chosen by evaluation rather than reputation. We shortlist candidates by licence terms, size, language coverage and the hardware they need, then test them on your tasks before recommending one. We name no model before the evaluation, because the choice depends on your tasks, languages and hardware, and the models available change often. Licences differ: some restrict commercial use, user numbers or modification, so your legal team reviews the licence of the selected model, and we do not accept licences on your behalf unless the contract says so.

Mainly how many people use the platform at the same time and what they ask of it. The main factors are the number of users and concurrent requests, model size, context length (how much text each request carries, which grows with long documents and retrieved passages), the latency targets you set, and whether several models or use cases share the same hardware. Indexing documents and running evaluations also take capacity. We size from load measured on a test environment, or from your pilot where there is one, so you buy only for a need that testing has shown.

It varies by model and by task, so we measure it rather than assume it. Summarising formal Modern Standard Arabic, answering questions written in Saudi dialect, extracting fields from scanned forms and handling text that mixes Arabic and English are different tests, and the same model can do well in some and poorly in others. Your reviewers help build the evaluation set from your own material and agree the pass threshold for each task. If no model that fits your hardware and licence constraints reaches that threshold for a task, we say so, and you decide whether to change the task, the hardware or the deployment option.

Yes, if the platform is designed for it from the start, and we design it that way: applications and the gateway call a standard interface rather than a specific model, and the environment can be rebuilt elsewhere from the code that defines it. A change still takes work: the new model is re-evaluated on the same evaluation set, its prompts may need adjusting, and if the embedding model changes, the document indexes must be rebuilt. Moving to new hosting means re-testing capacity and isolation there. The portability note in the handover states what moves as it is, what must be rebuilt and what is tied to a specific provider.

Yes, with open-weight models that run locally and no network path to the internet or outside services. The trade-offs are real: model and security updates arrive on controlled media after they are checked, so they come later; the choice is limited to models your hardware can run; vendor support happens on site or through diagnostic data you review before it leaves; and patching, monitoring and capacity management take more operational effort. We design the import process for models, updates and software packages, including integrity checks and malware scanning, and the backup and recovery path inside the isolated environment. Air-gapping removes the network path to outside services; it does not remove insider threats or the risk carried in content imported on media, which need other controls.

Your data stays yours, and so does the hardware you buy; configurations, documentation and deliverables are handed over as set in the contract. The hosting contract can be in your name, and model licences are between you and the licensor unless the contract states otherwise. On a sovereign platform the encryption keys are yours from the start, and the administrative accounts we used during the build have their credentials changed or are removed at handover. The handover pack includes the configuration as code, runbooks, the dependency register and the portability note, so your own team or another provider can take over operation.