Sizing and design
Workload analysis first, then a hardware, network and storage design sized to it. We would rather tell you that you need less than oversell you a rack.
NXAARA Platform service
The same platform, inside your boundary
Some workloads cannot run on shared infrastructure — because of a regulator, a contract, or a classification. Private AI puts the same platform on single-tenant hardware, in your data centre, or fully disconnected.
Three boundaries, one platform
The question is never really about the cloud. It is about where the boundary sits and who is inside it. For most teams shared multi-tenant infrastructure is fine. For some, a contract or a regulator says otherwise, and no amount of encryption discussion changes the answer.
Private AI covers three positions. Dedicated single-tenant, where the hardware is exclusively yours but we operate it in our Dubai facility. On-premises, where the platform is installed in your data centre and you control physical access. Air-gapped, where there is no external connectivity at all and updates arrive as signed, verified media.
The important property is that the platform is the same in all three. Same console, same APIs, same Model Foundry, same evaluation harness, same audit log. Teams move between deployment models without rewriting anything, and a workload developed on shared cloud can be lifted into an air-gapped installation without a port.
This is the pattern EADPAG already runs for regulated clinical work, where the standard is that a system must be able to demonstrate what it did, not merely assert that it was careful.
- Dedicated single-tenant — hardware exclusively yours, operated by us in Dubai
- On-premises — installed in your facility, under your physical control
- Air-gapped — no external connectivity, updates by signed offline media
- Identical platform — same console, APIs and workflows across all three
- Your identity provider — SAML or OIDC against your existing directory
- Full audit trail — who did what, to which model, on what evidence, exportable
Capabilities
What a private deployment includes
A private installation is a delivery project, not a licence key. This is what is in scope.
Installation and commissioning
Deployment with documented entry and exit criteria per phase, so acceptance is a verifiable event rather than an opinion.
Identity integration
SAML or OIDC against your directory, with role mapping so platform permissions follow your existing group structure.
Model catalogue control
You decide which base models exist in the installation. Nothing is downloaded or updated without an approved change.
Audit and evidence
Every provisioning action, tuning job, evaluation and promotion is logged with actor, timestamp and justification, exportable for review.
Update path
Signed, versioned releases you schedule and can roll back. For air-gapped sites, delivered as verified offline media.
How it works
How a private deployment runs
This is a delivery sequence with defined gates — later stages do not begin until the earlier one is signed off.
Requirements and boundary
Establish what the actual constraint is: regulator, contract, classification or policy. The boundary determines the design.
Sizing and design
Model the workload, size compute, storage and network, and produce a design document you can review before anything is bought.
Build and commission
Install and configure with per-phase entry and exit criteria. Each phase is verified before the next begins.
Integrate and validate
Connect identity, networking and monitoring. Validate against agreed acceptance tests with recorded results.
Operate and update
Hand over with documented runbooks, or we operate it. Updates are signed, scheduled and reversible.
Choosing honestly between the three
Dedicated single-tenant is right when the requirement is isolation rather than physical custody — you need to know no other tenant shares your hardware, but you do not need the machines in your building. It is the fastest to stand up and the cheapest of the three to operate.
On-premises is right when physical custody genuinely is the requirement, or when data volumes make moving data to the compute more expensive than moving compute to the data. It carries real operational weight: power, cooling, hands on site, spares.
Air-gapped is right when connectivity itself is the prohibited thing. It is the most demanding option by a distance — every update becomes a logistics exercise — and it should be chosen because a rule requires it, not because it sounds safest. We will say so during scoping if we think you are over-specifying.
| Deployment models | Dedicated single-tenant, customer on-premises, air-gapped |
|---|---|
| Platform parity | GPU Cloud, Model Foundry, Synthetic Data, Inference and Knowledge Cloud |
| Identity | SAML 2.0 or OIDC against your directory, with role mapping |
| Network | Private connectivity, no external egress required for operation |
| Model catalogue | Customer-controlled; models added only by approved change |
| Audit | Full action log with actor, timestamp and justification, exportable |
| Updates | Signed versioned releases, scheduled by you, with rollback |
| Operations | Customer-operated with runbooks, or managed by NXAARA under agreement |
Where it is used
Who deploys this way
Healthcare and clinical
Patient data that cannot leave the institution, with an audit trail a clinical governance committee can actually review.
Government and defence
Classification rules that make shared infrastructure a non-starter regardless of the technical controls applied to it.
Banking and financial services
Regulatory residency and isolation requirements, plus supervisory expectations about demonstrable model governance.
FAQ
Common questions
Is the on-premises platform a cut-down version?
No. It is the same platform. Same console, same APIs, same Model Foundry and evaluation harness, same audit log. A workload built on shared cloud runs in an air-gapped installation without modification — that parity is the point of the architecture.
How do updates work without internet connectivity?
Signed, versioned release bundles delivered on verified media, applied on a schedule you control, with a documented rollback path. Nothing updates itself, and nothing reaches out to a network that is supposed to be closed.
Who operates the system after installation?
Your choice. We hand over with documented runbooks and train your team, or we operate it under a managed agreement. Air-gapped sites usually run on a hybrid: your staff day to day, our engineers on scheduled maintenance windows.
What does a realistic timeline look like?
Dedicated single-tenant is the quickest because we are not waiting on your facility. On-premises depends on your procurement, power and network readiness far more than on us. Air-gapped adds validation and logistics time. We give a phased schedule during scoping rather than a single number up front.
Can we start on shared cloud and move later?
Yes, and it is usually the sensible path. Build and validate on shared infrastructure where iteration is cheap, then move the proven workload into a private deployment. Platform parity is what makes that migration a deployment change rather than a rebuild.
Scope a private deployment
Tell us what the boundary is and why it exists. We will tell you which of the three options actually fits, including when the answer is that you do not need one.