Skip to content
العربية Book a Consultation

Data sovereignty. A deployment choice, not a promise.

Local LLMs, approved Zero Data Retention (ZDR) APIs, or a hybrid of both: the right architecture starts with what your data is allowed to do.

We assess processing location, data access, retention and operating cost together. ZDR can limit provider retention for eligible API requests, but it does not keep those requests inside your environment.

Discuss your deployment

Three routes. Different boundaries.

On smaller screens, scroll the comparison horizontally.

DecisionLocal / private LLMApproved ZDR APIHybrid routing
Model processingInside your approved infrastructure. Confirm location and every dependency.At an external provider, in an agreed processing region. Approved context leaves your environment.Local or external, according to explicit data-classification rules.
Content retentionYour policies govern documents, prompts, logs, history and backups. Local does not automatically mean zero retention.Provider retention is limited within the approved ZDR scope. Your application storage and metadata need separate controls.Apply retention controls separately to each route and to shared application storage.
Best fitIn-boundary processing, offline use, or workloads that justify dedicated capacity.Eligible low-volume assistants and pilots where external processing is permitted.Mixed sensitivity or capacity needs, with external requests blocked unless policy permits them.
Cost profileHardware or private hosting, capacity planning, power and model operations.Usage-based inference plus application, retrieval, storage, security and integration costs.A balance of local capacity and API spend; more routing and governance complexity.

Where local LLMs belong

When processing must stay inside an approved boundary, a local or privately hosted model is the starting point. Keep retrieval, embeddings, source documents and query execution in that boundary too; check model telemetry, monitoring and backup destinations.

Select and evaluate models against Arabic and English task quality, latency and capacity. Define permissions, content logging and deletion policies. Running a model locally is not, by itself, proof of sovereignty or zero retention.

How an approved ZDR route works

Only authorized, minimal context crosses the external boundary. The gateway checks identity and classification; the application retrieves permitted knowledge and validates the response. This diagram illustrates a proposed design, not a certification of an existing deployment.

Swipe the diagram horizontally to see the complete data flow.

ZDR API architectureRequests pass through customer policy controls and private retrieval to an approved external model provider; responses are validated locally and operational logs exclude prompt and response content. CUSTOMER-CONTROLLED ENVIRONMENTEXTERNAL MODEL PROVIDER TLSContent processed externallyVerified retention scopeMetadata subject to contract User requestUser or application Policy gatewayIdentity · classification AI orchestratorMinimal, transient context Approved ZDR LLM APIEligible workloads only Validated outputChecked · returned Usage & securityMetadata only Private knowledgeDocuments · authorized RAG
Request pathResponse pathIllustrative architecture, not a verified deployment

A smaller solution need not start with a GPU server.

For a low-volume support chatbot, document assistant or pilot, a usage-priced API may cost less than maintaining dedicated model capacity. It avoids upfront GPU purchases, idle capacity and model-server maintenance—but application, retrieval, storage and security costs remain.

Compare total monthly cost at expected and peak usage. Right-size models, limit context and output tokens, set request quotas and monitor spend. Sustained high-volume use may favor local inference. We do not assume a fixed savings percentage.

What we verify before enabling ZDR

  • Provider approval, contract, supported endpoints and features—not just a “no training” setting.
  • Processing region, subprocessors and permitted data classes; residency is a separate decision from retention.
  • Prompt and response content excluded from logs, traces, analytics and backups for the ZDR route.
  • Separate lifecycle rules for documents, embeddings, saved conversations and operational metadata.
  • Access checks, outbound policy enforcement and validated outputs, with external routing disabled when a request is not eligible.

ZDR scope and exceptions vary by provider, endpoint and feature. Operational metadata may remain. Regional processing and legal requirements must be assessed separately.

Provider data-controls reference · Usage-based pricing reference

Deployment guidance for RennixBayan

Discuss your deployment