Skip to Content
RSEEN technical documentation for authorised evaluators and operators.

Data residency architecture

RSEEN is designed around one governing question: when a regulated Saudi institution processes a private document with an AI system, where does the data live at every hop? This page describes the control model without naming private provider choices.

The three data planes

Any document-generation run crosses three planes:

  1. Model inference plane - the model gateway or endpoint that reads prompts and returns generated text.
  2. Embedding plane - the service or endpoint that turns chunks of text into vectors for retrieval.
  3. Storage plane - where uploaded source files, generated drafts, and exported DOCX artefacts sit at rest.

RSEEN’s position is that inference and embedding should be sovereign or operator-controlled by default, and storage should remain under the deployment operator’s control. A fourth implicit plane, credentials, stays encrypted at the application layer regardless of which runtime option is selected.

Model inference

RSEEN supports two deployment postures:

  • Sovereign hosted gateway - model calls route through a contracted Saudi-hosted gateway selected by the operator.
  • Operator-controlled endpoint - model calls route to an OpenAI-compatible endpoint operated by the customer or by an approved infrastructure partner.

Those postures are not interchangeable. A Saudi-hosted gateway can satisfy many in-Kingdom residency requirements, but it is still an external service relationship. An endpoint running inside the customer’s own perimeter gives the strictest inference-control posture. The right choice depends on the institution’s policy, contract model, and supervisory interpretation.

Embeddings

Retrieval-augmented generation requires embedding both the knowledge base and incoming queries. RSEEN keeps those embeddings residency-aware through an embedder factory and sensitivity tiers.

For sensitive knowledge-base segments, the configured embedding path must remain sovereign or operator-controlled. For non-sensitive public regulatory material, an operator may choose a different provider if their governance process allows it. Switching embedding providers requires a full re-index so vector dimensions and retrieval quality remain coherent.

Storage

Source files, generated drafts, and exported DOCX artefacts live on infrastructure chosen by the operator. The supported pattern is local filesystem storage or S3-compatible object storage in a region and account the operator controls. RSEEN does not require a foreign object store for application data.

Credentials

Provider keys and endpoint credentials are entered through the admin settings surface and stored encrypted in the database. Infrastructure secrets stay in environment variables. This split keeps runtime configuration out of the frontend bundle and avoids baking provider keys into images, logs, or deploy metadata.

What the Operator Owns

RSEEN provides the architectural controls: swappable inference endpoints, sensitivity-aware retrieval, operator-controlled storage, encrypted credentials, and auditable pipeline events.

The operator still owns the final residency determination: provider due diligence, network egress controls, backup policy, key rotation, contractual review, and the classification of which knowledge-base segments are sensitive.