Skip to content

Data residency & subprocessors

Venturi's deployment model — an in-VPC data plane and an outbound-only control plane — keeps your data in your own cloud account and keeps the subprocessor surface intentionally minimal. This page describes where data lives, how region pinning works, the provider-connector model, and the subprocessors involved.

Where your data lives

Your data stays in your VPC

Per-tenant data — AI-invocation events, the attribution graph, source-system reads — lives entirely within your VPC, in your own cloud account. It does not leave that boundary regardless of Venturi's residency stance, because the control plane is outbound-only and there is no cross-account replication of customer data. See Security architecture.

The published customer-side onboarding modules target AWS, Azure, and GCP — they are real IaC modules your own security team reviews before deployment. (Venturi's own internal development footprint is a single, env-separated account, distinct from the customer-deployable artifact.) See the onboarding guides for each cloud.

Control-plane and aggregation residency

The Venturi control plane runs region-pinned. EU-origin data — including opt-in anonymized telemetry — is processed in-region or under GDPR Chapter V safeguards (Standard Contractual Clauses), never silently routed cross-region. Venturi's residency stance is single region plus SCCs.

Cross-tenant aggregation residency

The cross-tenant Aggregation environment is a separate, Venturi-managed VPC that no tenant data plane can read, and it is region-pinned from day one — region pinning of aggregation is a present architectural property, not a deferred milestone.

  • De-identification before egress. All tenant-identifying attributes are anonymized before any data leaves your VPC; the training pipeline reads only from the Aggregation VPC, never from tenant data planes.
  • Per-jurisdiction residency filtering. EU tenants do not contribute to non-EU aggregations, and vice versa.
  • Consent-gated. Aggregation is off by default for general-availability customers and requires explicit, scoped, revocable permission.

See Tenant isolation for the full aggregation model.

Region-aware processing

The canonical event schema carries a region field, and deployment carries a data-center-region configuration, enabling region-aware processing and residency filtering. A full, discrete customer-facing residency-control surface (inference_geo) is on the roadmap, built atop these region-aware fields and the per-jurisdiction filters. See Compliance.

Provider connectors

Venturi enriches attribution from provider-account reporting where you supply the credentials. Every connector is read-only.

Connector Read-only Notes
GitHub / Okta / cloud billing Yes Read-only org/team/billing metadata polling.
Anthropic admin-key usage/cost Yes (by API contract) Requires your admin key; not available on Claude-on-AWS / Amazon Bedrock.
OpenAI admin-key / audit logs Yes (by API contract) Requires your organization-owner access and audit logging enabled in OpenAI Data Controls.
Workspace opt-in router n/a Default state: nothing is ingested until an organization owner explicitly opts a workspace in.

Your admin key never leaves your trust boundary

Provider admin keys are stored per-tenant, KMS-encrypted, inside your trust boundary; the Venturi control plane never observes one in plaintext. Connectors use the keys only for documented read endpoints, and nothing is ingested until you explicitly opt a workspace in. Within an opted-in workspace, your provider's own RBAC still governs visibility — Venturi does not collect data your admin is not already entitled to see in the provider console.

Subprocessors

Because the data plane runs in your own VPC and the control plane is outbound-only, Venturi's subprocessor surface is intentionally minimal.

Subprocessor Role
Your own cloud provider Hosts the in-VPC data plane — i.e., your own account, under your own agreement with that provider.
Venturi control-plane endpoints The signed pricing-catalog sync, the software-release check, and (opt-in) anonymized telemetry.
Research / training tooling Used only for the consent-gated Aggregation VPC, for customers who opt in to de-identified aggregation.

The subprocessor inventory is published and versioned. Every new subprocessor or vendor is risk-assessed before onboarding — a security questionnaire plus a review of SOC 2 or ISO 27001 evidence, with a DPA (and SCCs where Chapter V applies) executed before any data flows. The assessment is recorded, the versioned inventory is updated, and affected customers receive the Art. 28(2) subprocessor change notice with an objection window.

Roadmap

The published, versioned subprocessor list and the formal DPA template are produced as part of the enterprise-readiness program. The minimal-by-architecture subprocessor surface and the processor framing described here are properties of the deployment today. The exact published inventory contents and the SCC selection are leadership and EU-counsel determinations. See Compliance.