Skip to content
SparQ

Sovereignty

Sovereign by design, not by setting.

Your customers ask where their data is processed and which models may see it. SparQ answers with the architecture: data stays in its geo, every model call is filtered by each client's compliance profile, and a call with no compliant model is refused, never rerouted.

geo: eustamp eu-1stamp eu-2one lane per client, sealed by RLS

Sovereignty

Your data stays where your contracts say it must.

Residency is not a setting you hope every agent respects. It is enforced where every model call is made, and the architecture keeps content inside its geo.

Data stays inside its geoThree geos, each with its own control plane and data stamps. A global directory holds only placement ids. A request that would send an India client's data to a model outside its allowed regions is refused.global directoryplacement ids onlygeo: us · controlstamp us-1stamp us-2content, ledger, tracesgeo: eu · controlstamp eu-1stamp eu-2content, ledger, tracesgeo: in · controlstamp in-1stamp in-2content, ledger, tracesrefused: no_compliant_model
Fig. 1  A control plane and its stamps in each geo. The directory above them holds only ids.

  • Residency per client, enforced at routing

    Early access

    Each client's compliance profile lists the regions and providers it allows. The gateway filters on it before every call, and a request with no compliant model is refused, not rerouted.

  • Data stays in its geo

    Next release

    A control plane per jurisdiction and complete data planes, called stamps, inside it. Conversations, files, knowledge and the ledger never leave the geo. Disaster recovery goes to a paired region inside the same geo, never across a border.

  • Control is separate from content

    Next release

    The control plane holds configuration, credentials (as hashes) and policy. It never reads conversation, run or knowledge content. The global directory holds only opaque ids and region codes.

  • Your keys, your stores

    Roadmap

    Encryption with a key per client and customer-managed keys. Files and vectors in stores you own: Azure Blob, Amazon S3, Google Cloud Storage, pgvector, Qdrant and others.

Three ways to deploy, one code base

The deployment model decides where SparQ runs. Each client's compliance profile decides where its data may be processed. SparQ applies both, and refuses a setting where they conflict.

Frontier Cloud

Early access

SparQ runs everything, in the geo you choose.

Where it runs
Control plane and data plane hosted by SparQ
Models
Any model in the registry that your allowlist and each client's profile permit

Hybrid Sovereign

Roadmap

SparQ runs the control plane. Your cloud holds the data plane.

Where it runs
Database, vector store, files and model gateway in your cloud
Models
Your own provider accounts or self-hosted models

Full Sovereign

Roadmap

Everything runs in your environment.

Where it runs
Control plane and data plane in your environment
Models
Open-weight models only. Proprietary frontier models cannot be shipped as weights.

jade = run by SparQ  ·  amber = runs in your cloud or data centre

What never crosses a boundary

  • No query, foreign key or shared cache crosses from one stamp to another.
  • Stamps report only aggregated usage counters upward: no content, no per-user detail.
  • Embeddings, reranking and traces are processed in the same geo as the data.
  • No per-customer hostnames, so a customer's name never lands in global DNS.

Compliance

Controls you can trace, evidence you can export.

Each control maps to the frameworks your auditors use, to the safeguard that implements it, and to the evidence that shows it operating.

Designed to map to

  • ISO/IEC 27001Information security management (Annex A controls)
  • ISO/IEC 42001AI management systems
  • SOC 2Trust Services Criteria
  • NIST AI RMFAI risk management
  • OWASP Agentic Top 10Threats specific to agentic applications
  • GDPREU data protection
  • India DPDPDigital Personal Data Protection Act

These are frameworks of controls, not certificates. SparQ makes no certification claim today: certification needs operating evidence from the live platform, and we will publish each one when it is earned.

Evidence the platform produces

  • Early access

    Hash-chained audit

    Append-only records per workspace, verifiable end to end.

  • Early access

    Policy decision records

    Every allow and every refusal, with the policy version that decided it.

  • Early access

    Data-location record

    The provider, deployment and region of every model call, per client.

  • Next release

    Evidence export

    Residency policy, model deployments, approvals, grants and evaluation results in one export per workspace.

See the control mapping

Give your next AI feature a contract that outlives the model.

Tell us what you are building. We will show you SparQ on your use case and your residency rules.

Book a demoExplore the API

Early access: Built and tested. Available to early-access workspaces.