User Guide

An operational product guide for customers, evaluators, and regulators reviewing what DataSitr does, how it routes data, and what claims it does not make.

Important regulatory note. This guide describes the product and operating controls as currently built. It is not legal advice and it is not an SDAIA-issued approval, accreditation, or license. Controller/processor allocation, contractual commitments, and any applicable licensing obligations should be reviewed by qualified Saudi counsel.

1. What DataSitr is

DataSitr is a Saudi-hosted privacy gateway for AI requests. It receives text requests, detects personal data and sensitive signals, and then routes each request through the appropriate privacy lane before any model call is made. The purpose is to support AI enablement while reducing the risk of uncontrolled transfers of personal data outside the Kingdom.

2. Intended users

Customer application or end user — submits requests to /v1/process or /v1/batch.
Tenant admin — reviews history, compliance surfaces, and subject-rights actions within tenant scope.
Operator — manages health, keys, alerts, billing, and runtime configuration.
Reviewer or regulator — uses this guide plus the status, privacy, and legal pages to understand the product’s operating model.

3. Core operating flow

DataSitr receives request text, a request ID, task type, and routing policy inputs.
The detector scans for PII using English recognizers, Saudi-specific patterns, and a configurable local Arabic semantic backend.
The policy engine assigns one of four outcomes: green, amber, red, or block.
If the request is green, the current public pilot default is typed-placeholder anonymization before any external model call. If fpe is explicitly enabled, supported Saudi structural identifiers can use FF1 structural surrogates, but that remains reversible pseudonymization rather than the default public anonymization claim. If the request is amber or red, processing is routed to operator-configured in-Kingdom paths according to the configured provider set and policy.
The service returns the response with compliance metadata and writes request-linked operational records.

4. Privacy lanes

Green — text is anonymized before any external processing. This lane is not intended to send raw personal data outside the Kingdom.
Amber — text is pseudonymized or tokenized and routed to operator-configured in-Kingdom paths when linkable context is still needed or confidence is mixed.
Red — raw text is routed to the strictest in-Kingdom path available for the highest-sensitivity or lowest-confidence cases.
Block — the request is rejected if policy forbids the processing or no suitable safe route is available.

5. What stays in-Kingdom

Raw personal data, vault mappings, operational logs, compliance logs, and API keys.
Processing records, transfer register entries, subject-rights audit entries, and request-correlation data.
Amber- and red-lane model processing when operator-configured in-Kingdom providers are configured.

Customers can also force all processing onto configured in-Kingdom paths by using force_in_kingdom where their internal policy requires it. If no such path is available, the request is rejected. DataSitr does not independently verify provider data residency for amber/red paths.

6. User-facing controls and records

Dashboard — overview of health, usage, providers, compliance, and request history.
Keys and roles — tenant, tenant_admin, and super_admin scope what each user can view or change, with a separate read-only regulator role when explicitly provisioned.
Compliance artifacts — the product maintains processing records, transfer history, and supporting audit evidence tied to request IDs.
Subject rights — export, rectification, and deletion workflows are available within tenant scope.
Traceability — X-Request-ID is propagated through requests, responses, and logs to support investigation and review.

7. Customer and operator responsibilities

DataSitr operator is responsible for operating the deployment, configuring public identity, retention, backup, and security contacts.
The customer is responsible for the lawfulness of submitted data, the appropriate legal basis and notices, and human review of outputs before operational or legal reliance.
Controller/processor allocation, data-processing commitments, and customer-specific obligations should be defined in the signed legal documents, not inferred from the product interface alone.

8. What this product does not claim

It does not claim to grant automatic legal compliance or remove the need for legal review, approvals, or customer governance.
Its outputs should not be represented as an official regulatory decision, accreditation, certification, or legal opinion.
Any regulated audit, accreditation, or advisory activity should be assessed separately under the applicable legal and regulatory framework.

9. Relevant official references

Questions about this guide should be routed through your DataSitr operator or administrator.