Deployment Sovereignty: How BYOC Architecture Keeps Your AI Data Inside Your Perimeter

What Is the 'Sovereignty Gap' and Why Does It Block Enterprise AI Adoption?

In 2023, a major European bank's AI adoption roadmap was stalled for 11 months because no available observability vendor could satisfy the European Data Residency requirement. Their credit scoring models produced inference telemetry that included applicant identifiers — and the only compliant option was to either forego observability entirely or build it in-house at an estimated cost of €4M.

This is the Sovereignty Gap in practice.

Why it affects regulated sectors so acutely:

Financial services regulators — RBI in India, ECB in Europe, SAMA in Saudi Arabia — do not just recommend data localisation, they enforce it. Sending credit decision telemetry to a US-hosted SaaS platform constitutes a data transfer under GDPR Article 46, requiring either an adequacy decision (unavailable for the US post-Schrems II) or Standard Contractual Clauses — a compliance overhead most enterprises find prohibitive for operational data pipelines.

India's DPDPA creates a parallel obligation: financial data classified as "sensitive personal data" must be processed within Indian territory unless specific conditions are met. Model inference telemetry containing applicant features routinely qualifies as sensitive personal data.

The Three Failure Modes of Centralised Observability:

1. Legal blocker — The DPO/Legal team identifies the cross-border transfer risk and blocks deployment. No observability.

2. Compliance workaround — The team redacts PII before sending telemetry. This destroys the observability signal (you can't diagnose a bias problem if the protected attributes are stripped from the telemetry).

3. Shadow deployment — Teams deploy the tool without legal sign-off. This is the most common outcome — and the one that results in regulatory enforcement action 18–36 months later.

Claris's BYOC architecture exists specifically to close this gap, making enterprise-grade observability legally deployable in any jurisdiction.

How Does BYOC Architecture Keep Sensitive Data Within Your Secure Perimeter?

The BYOC Deployment Architecture:

Step 1 — VPC Orchestration: Claris's analysis containers are deployed via Helm chart (Kubernetes) or Docker Compose into your existing cloud environment. The containers are provisioned with no outbound internet permissions — they communicate only with your model serving infrastructure (inbound inference data) and the Claris Control Plane (outbound anonymised metrics).

Supported environments:

• AWS VPC (EKS, ECS, or standalone EC2)
• Azure Virtual Network (AKS or Azure Container Instances)
• GCP VPC (GKE or Compute Engine)
• On-premise Kubernetes clusters (air-gapped supported)

Step 2 — Local Encryption: All metadata produced by the analysis containers — SHAP value distributions, PSI scores, MSS readings — is encrypted using your organisation's KMS (Key Management Service) keys before any transmission. Claris's Control Plane receives only the cipher text; decryption occurs in your browser session using ephemeral session keys. Claris employees cannot access your raw telemetry.

Step 3 — Zero-Egress Telemetry Transmission: The outbound payload to the Claris Control Plane contains only:

• Aggregated drift metrics (PSI, MSS scores per feature)
• Alert flags (threshold breaches, Directional Conflicts)
• Model performance indicators (accuracy, AUC, KS statistic)
• Anonymised explanation summaries (feature importance distributions, not individual-level SHAP values)

What is explicitly excluded: individual inference inputs, individual prediction outputs, applicant identifiers, any data field that could be used to reconstruct a specific transaction.

Air-Gap Mode: For environments with no outbound internet access (defence, critical infrastructure, highest-security banking), Claris supports a fully air-gapped deployment. The dashboard runs as a local web application inside your VPC. Governance reports are exported via secure file transfer on a scheduled basis. This mode is used in two of India's largest public sector banks.

How Does Zero-Egress Telemetry Work Without Sacrificing Observability?

The Logic vs Content Distinction:

Traditional observability tools treat model monitoring as a data warehousing problem — they ingest all inference inputs and outputs, store them centrally, and run analytics on the full dataset. This creates the Sovereignty Gap because the stored data is indistinguishable from a copy of your customer records.

Claris's approach treats model monitoring as a statistical sampling problem — we compute distributional statistics over inference streams, producing summary metrics that contain no recoverable individual-level information.

What Zero-Egress Telemetry captures:

The 100-inference floor: To ensure that no individual-level data can be reverse-engineered from transmitted metrics, Claris enforces a minimum batch size of 100 inferences before any metric is computed and transmitted. Metrics computed over samples smaller than 100 are held locally until the batch fills. This provides k-anonymity protection for individual inferences.

Compliance mapping:

Zero Data Retention (ZDR) mode is Claris's strictest configuration: the analysis containers process inference streams in memory only, with no writes to disk. All telemetry is computed ephemerally and transmitted as aggregated metrics within 100ms of inference. No inference data persists in Claris's infrastructure at any point.