01Regulator review surface
User Guide.
Plain English first: what DataSitr does, where your data goes, and what a reviewer can inspect.
Use this guide for the operating model. Use the trust and evaluation pages for dated continuity, restore, and survivability proof.
Section index
Read in order
See also
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.
02What DataSitr is
What DataSitr is
Start here if you need the simplest description. DataSitr is not the model itself. It is the policy and privacy layer in front of model processing.
DataSitr is a Saudi-hosted privacy gateway for AI requests. It catches personal data before model calls, applies your policy, and uses automatic privacy routing to reduce uncontrolled personal-data transfers outside the Kingdom.
03Intended users
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.
04Core operating flow
Core operating flow
This is the shortest operational path a reviewer should understand: receive, inspect, route, process, and record.
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 Arabic NER.
The policy engine assigns one of four outcomes: green, amber, red, or block.
If the request is green, the text is tokenized before any external model call. If it is amber or red, processing remains in-Kingdom according to the configured provider set and policy.
The service returns the response with compliance metadata and writes request-linked operational records.
05Privacy lanes
Privacy lanes
The lane model is the core decision surface. Every request ends in one of these outcomes before any model processing is allowed.
Text is tokenized before any external processing. This lane is not intended to send raw personal data outside the Kingdom.
Text is pseudonymized or tokenized and processed in-Kingdom when linkable context is still needed or confidence is mixed.
Raw text stays in-Kingdom for the highest-sensitivity or lowest-confidence cases.
The request is rejected if policy forbids the processing or no suitable safe route is available.
06What stays in-Kingdom
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 in-Kingdom providers are configured.
Customers can also force all processing to remain in-Kingdom by using force_in_kingdom where their internal policy requires it.
07User-facing controls and records
User-facing controls and records
These are the surfaces a customer, evaluator, or regulator can expect to inspect rather than infer from marketing claims.
Dashboard
Overview of health, usage, providers, compliance, and request history.
Keys and roles
tenant, tenant_admin, super_admin, and the separate read-only regulator role scope what each user can view or change.
Compliance artifacts
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.
08Customer and operator responsibilities
Customer and operator responsibilities
DataSitr operator
Responsible for operating the deployment, configuring public identity, retention, backup, and security contacts.
The customer
Responsible for the lawfulness of submitted data, the appropriate legal basis and notices, and human review of outputs before operational or legal reliance.
Contractual allocation
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.
09What this product does not claim
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.
10Relevant official references
Relevant official references
The following SDAIA resources are referenced for context. They do not constitute endorsement of DataSitr by SDAIA.