Chakali / Deployment

One control model.
Three places to run it.

Deployment is a strategy decision, not a technical detail. It follows your risk position — and whichever pattern you choose, identity, policy, approval and evidence behave the same way.

Discuss your deployment Review the controls

01The three patterns

Pick the boundary.
Chakali enforces it.

Controlled

On-premises / air-gapped

You operate it

Chakali and the models it uses run entirely inside infrastructure you own, with or without an internet connection. Nothing crosses the boundary in either direction.

Open-weight models on your own hardware
Full capability with the cable pulled
Your identity provider, your keys, your monitoring
Enclave-per-programme where compartments must be physical

Typical fitClassified and protected workloads, defense, national security, critical infrastructure, central-bank supervisory material.

Dedicated

Private cloud

Shared operating model

A dedicated deployment inside your own cloud tenant, aligned to the networking, residency and key-management controls your organization already runs.

Models served from inside your tenant
No traffic to a public model endpoint
Residency follows your existing cloud policy
Integrates with the controls your cloud team already operates

Typical fitRegulated enterprises and public bodies that have an approved cloud and a mature cloud control plane.

Managed

SaaS

RabitaNoor operates it

Managed application operation with your organizational identity, data and integration boundaries — the fastest way to put a governed workflow in front of real users.

No infrastructure for your team to stand up
Organizational identity and workspace separation from day one
Upgrades and operations handled by RabitaNoor
A path to move on-premises later without rebuilding the workflows

Typical fitTeams proving a first governed use case, and organizations whose risk position allows a managed boundary.

02What never changes

The control model is not
a deployment option.

These apply identically in all three patterns. Moving between them changes where the boundary sits, not how authority is decided.

Identity and workspace separation

Every request carries who is asking, from where, with which entitlements.

Deterministic policy

Rules evaluated before consequential work proceeds — never adjudicated by the model.

Permission-aware retrieval

An Agent reads only what the person behind the request is entitled to read.

Bounded tools

Typed capabilities with exact scopes, so an action cannot reach past what was approved.

Named human approval

Consequential actions stop for a person, and the approval binds to that exact action.

Evidence record

Identity, purpose, model, knowledge, tools, policy results and outcome, retained together.

03What does change

Read this before
you choose.

The honest differences, including the one most vendors leave out: what stays your responsibility.

	On-prem / air-gapped	Private cloud	Managed SaaS
Where models execute	Your hardware	Your cloud tenant	RabitaNoor-operated
Internet connectivity	Optional or none	Your egress policy	Managed
Frontier models available	No — by construction	By policy	By policy
Key custody	Yours	Yours	Shared, defined in contract
Host hardening and patching	Your team	Your team	RabitaNoor
Time to first governed workflow	Longest	Medium	Shortest

In every pattern, host hardening, identity lifecycle, key custody, monitoring, backup and regulatory compliance remain the operator's responsibility for whatever that operator runs. We would rather you hear that from us early than from an auditor late.

Choosing between them

Bring your boundary, data classes, identity model and integrations — we will tell you which pattern fits.

Start a conversation Read the FAQ

One control model.Three places to run it.

Pick the boundary.Chakali enforces it.