01Deployment

Deployment.

Choose where DataSitr runs. The components stay the same, so your evidence and review exports stay consistent.

02What you deploy

One layer. Three products.

Deploy one, two, or all three — reduce the risk you can, contain the risk you can't. Each part runs in a different place; the architecture, runtime, and infrastructure detailed below describe the Gateway.

Live

AI Privacy Gateway

Runs server-side, on the wire.

Self-host it in your own cloud or run it DataSitr-hosted in-Kingdom. The detector, policy engine, router, and three-lane routing detailed below are this path.

Pilot

Data Sitr Shield

Runs device-side, through your MDM.

A browser and endpoint layer pushed through your own MDM. Local-first fingerprint matching runs on-device at the DOM layer; raw files, fingerprint lists, and your tenant key never leave the device (keys provisioned via MDM). Warn-first today, covering the browser / GenAI channel — not every exfiltration path.

In development

Adversarial Prompt Protection

Will run at the Gateway's outcome layer.

The outcome layer will scan egress to reduce leak risk and gate tool-use independently of the model, so protected actions still require policy or approval. In development — not yet available to deploy.

// The Gateway and Shield provide controls you can verify today. Adversarial Prompt Protection is in development. We'll never blur that line.

03Deployment models

Three paths, same components.

Pick the one that fits your operating model — we keep the runtime identical so evidence and exports look the same to a reviewer regardless of who hosts.

01 · Hosted pilot DataSitr-hosted pilot We provision and manage a Saudi-hosted environment with shared-state services where required. Fastest path to a working pilot. 1–2 days
02 · Customer cloud Your Saudi-hosted cloud Your team deploys on your Saudi-hosted infrastructure. Two paths supported: ACK guided Kubernetes, or single-VPS Docker Compose. 1–3 days
03 · On-premises Your datacenter Same components on your hardware. No cloud dependency. Operator owns network egress, backup target, and identity provider. 1–3 days

04Architecture

One path. Every request.

Every request follows the same path: TLS edge, then the API runtime that detects personal data, applies your policy, and chooses the allowed route. State, audit, and signed evidence live alongside the API on Saudi infrastructure.

DataSitr request flow architecture Vertical flow from client through TLS edge, the API runtime with detector, policy, and router blocks, the state stores beneath, and the lane-based provider routing at the bottom. Client app / SDK REST · API key OR OIDC session TLS edge · nginx + Let's Encrypt HSTS · request size cap · health probes DataSitr API · FastAPI · 2× replicas Python 3.12 · Uvicorn · Saudi region Detector Arabic NER · heuristics finds PII · sensitive ctx Policy engine tenant policy · scope lawful basis · purpose Router lane decision · audit log provider selection PostgreSQL sessions · attempts · audit hash-chained records Redis shared state · rate limits cross-replica coordination Object storage encrypted backups signed evidence outbox Lane decision → AI provider GREEN — tokenized external AI AMBER — pseudonymized in-Kingdom AI RED — raw in-Kingdom only / blocked

Request flow · Saudi-hosted runtime · 2026 baseline

The runtime is identical across hosted-pilot, customer-cloud, and on-premises models. Helm guards 2× replicas with shared Postgres + Redis when high-availability mode is on; a single-VPS Docker Compose path is supported for early pilots that don't need it.

05Three-lane routing in detail

Each lane has explicit rules.

The router's lane decision determines what the downstream AI provider sees. Each lane has explicit rules, an explicit destination, and an explicit audit trail.

GREEN Tokenized · external AI PII is replaced with typed placeholders before the request leaves the gateway. The external model never sees real identifiers, dates, or location names — only shape-preserving tokens. rehydration on response · placeholder map kept in-Kingdom
AMBER Pseudonymized · in-Kingdom AI Linkable pseudonyms substitute identifiers but the prompt stays inside Saudi infrastructure. Use this when the workload needs internal context the green lane would strip. tenant policy controls when this overrides green
RED Raw · in-Kingdom only or blocked Sensitive categories (health, national ID combinations, financial accounts) stay raw and route only to operator-configured in-Kingdom paths. If no in-Kingdom path is configured, the request is blocked. default sovereignty posture · operator opts in to paths

06What gets deployed

The same components, every model.

The same five components run in every deployment model. Sizes scale with traffic; the topology stays the same.

datasitr-api FastAPI · Python 3.12 · 2× replicas with shared state. Hosts the detector, policy engine, router, and audit writer.
dashboard SPA React + Vite · pre-built static bundle served by the API container. Operator UI, regulator portal, academy.
postgres Operational data store · sessions, attempts, audit, hash-chained compliance records. Daily backup with restore drill.
redis Coordination layer · shared cache for rate-limits, OIDC sessions, and cross-replica state. Stateless after restart.
object storage Encrypted backups + signed evidence outbox. Saudi-hosted bucket; off-host copy for regulator-readable export packages.
nginx (TLS) Edge layer · TLS termination, HSTS, request size cap, health probes. Let's Encrypt or operator-supplied certificate.

07Runtime options

Pick the runtime that fits the host.

Runtime
When to choose
Notes
Alibaba ACK
Kubernetes · production

Production deployments needing horizontal scaling, rolling updates, and managed control plane.

Guided deploy script · helm chart · 2× replicas with shared Postgres + Redis · health probes and recovery gates.

Docker + Compose
single VPS · pilot

Early pilots and on-premises installs that don't need horizontal scaling yet.

Single command, dashboard build, health checks. SQLite-backed sessions when Postgres is not yet provisioned.

systemd
bare host · constrained

Environments where Docker is not available (regulated estates, air-gapped reviewers).

Requires Python 3.12+ and Node.js 20+ on the host. Operator owns process supervision and log rotation.

08Authentication

Keys for machines. SSO for people.

Method
Detail
API key
default · machine actors

Bearer token in the Authorization header. Keys carry the sv_ prefix and are role-scoped (tenant / tenant_admin / super_admin / regulator).

OIDC SSO
optional · human actors

Authorization Code + PKCE flow against the operator's corporate IdP. Person-bound identity for every action — required for individual training records and per-user audit attribution.

09Infrastructure requirements

Small for a pilot. Scales for production.

Minimum (pilot)
Recommended (production)

2 vCPU

4 GB RAM

20 GB SSD

Ubuntu 22.04+

Saudi region

single-VPS Docker Compose path

4+ vCPU per node · 2 nodes

8+ GB RAM per node

50+ GB SSD per node

Shared Postgres + Redis

Off-host backup + scheduled restore drill

Active alert delivery to operator on-call

10What gets verified

The runtime emits dated, hash-chained, regulator-readable evidence.

Operator-refreshed controls — not timeless freshness guarantees.

  • Signed export packages Time-bounded, scope-bounded JSON manifests with key fingerprint and hash-chain verification — what a regulator opens first.
  • Audit trail Every lane decision, every rights-request action, every key invocation — recorded once with a route reason, time, and actor identity.
  • Training records The dashboard's built-in academy emits dated, exportable training records by named actor (when OIDC) or by shared key — distinguished and attributable.
  • RoPA + transfer register Article 31 / Article 29 anchor surfaces with dated entries that link each transfer to its lawful basis and TRA reference.
  • Subject-rights queue Verification, fulfilment, and dated closure evidence linked to a single workflow — auditable end-to-end without leaving the platform.
  • Breach register PDPL Implementing Regulation Article 24 fields — detection time, awareness time, affected categories, supervisory-authority notification timestamp — with a 72-hour clock from awareness, per PDPL Article 20.

11Shield deployment

Deploying Data Sitr Shield.

Shield runs on the device, not on a server. Nothing from DataSitr sits in the request path — you push it through your own MDM and it checks locally, in the browser, before anything reaches an AI tool. Warn-first today; zero-knowledge by design.

  1. 1
    Push the extension through your MDM

    Deploy the Data Sitr Shield browser extension to managed devices with your existing MDM — Microsoft Intune, Jamf, Google Workspace, or any Chromium-policy manager. Force-installed, no per-employee setup.

  2. 2
    Provision the tenant key via managed storage

    Your tenant key is delivered through chrome.storage.managed, set by your MDM policy — never typed by a user, never sent to DataSitr. All fingerprint matching is keyed on the device.

  3. 3
    Load your protected-content fingerprints

    Shield matches against fingerprints of your sensitive files — computed locally with HMAC-keyed shingling and winnowing, so partial copies are caught, not just exact files. DataSitr never receives your raw files, your fingerprint lists, or your key; they stay inside your boundary.

  4. 4
    Roll out warn-first

    Shield runs warn-only today: when protected content is about to be pasted or submitted into a GenAI tool, the employee gets a warning at the DOM layer, before submission. Start in monitor/warn mode, tune against your own corpus, then widen coverage. Hard blocking is on the roadmap — we won't claim it before it ships.

Scope, honestly: Shield covers the browser / GenAI channel — it is not a full-DLP across every exfiltration path (email, USB, native apps), and it is warn-first, not hard-block, today. The scoped claim is that matching, keys, and protected-content fingerprints stay on the device for the Shield browser / GenAI-channel workflow.

12What this is — and isn't

What this is — and isn't.

Current pilot runtime uses a Saudi-hosted shared-state layout. Dated proof covers scaling beyond a single-process setup, and dated alert-delivery and backup-plus-restore evidence is operator-refreshed. Treat those as controls the operator maintains, not as timeless freshness guarantees.

Optional immutable-evidence retention can strengthen audit evidence when configured. That is a software-level control — it should not be read as hardware-backed immutability or as a high-availability claim.

DataSitr is registered with NDGP as a data services / products provider (LR-25-000018, status Complete) — not licensed. SDAIA denied AI Service Provider Accreditation application AE-26-000237 on 2026-06-14; remediation/resubmission work is not an accreditation award. References to PDPL articles describe operational alignment; they do not imply regulator approval.

Contact us to start a pilot →

See it work on your data.

Same components, hosted in the Kingdom — pick where they run and the evidence travels with you.

Evaluate → Request a pilot →