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.
Open this only if you want the full reading order or the related public pages.
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.
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.
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.
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.
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.
Customers can also force all processing to remain in-Kingdom by using force_in_kingdom where their internal policy requires it.
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.
Responsible for operating the deployment, configuring public identity, retention, backup, and security contacts.
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.
It does not claim to grant automatic legal compliance or remove the need for legal review, approvals, or customer governance.
The following SDAIA resources are referenced for context. They do not constitute endorsement of DataSitr by SDAIA.