Skip to content

Data privacy & retention

Venturi is built around data minimization: it collects the metadata it needs to attribute AI consumption and nothing more. This page describes exactly what Venturi does and does not process, how it classifies data, how long it retains it, and how erasure works: by crypto-shredding the encryption keys rather than scrubbing append-only stores.

What Venturi does not collect

No prompt or completion content is ever persisted

Content capture is structural, not configurable: no setting turns it on. The default cloud read grants can reach content-bearing logs that a provider writes, so Venturi applies a field allowlist before materialization and discards request and response bodies and content-shaped keys in memory. Raw provider responses are never written to application logs, audit logs, retry queues, or dead-letter storage. The canonical InvocationEvent schema has no field for message content, and the attribution graph is derived state built from invocation metadata (identity, service, project, cost, tokens, timing), not from prompts or completions. This no-persistence boundary is a frozen decision.

Content reaches Venturi-operated code by two paths, and neither persists it:

  • Provider log sources that Venturi reads with the cloud grants can carry content; the content-bearing log boundary below covers them.
  • The drop-in proxy. When you route calls through the drop-in proxy, request and response content passes through Venturi’s proxy in memory only while it is forwarded, and is never written to access logs, error logs, traces, queues, or exception payloads, including on error and timeout paths. The proxy emits a metadata-only InvocationEvent.

Content-bearing logs

Read access to a log source is not storage of its content. Some provider log sources can contain prompts and completions. Most carry them only after you enable the provider feature that writes them; Vertex AI container logging is on by default for models deployed through the v1 service endpoint, so those logs carry whatever your serving containers write:

  • AWS: CloudWatch Logs read access can reach Amazon Bedrock model-invocation logs, which contain prompts and completions when invocation logging is enabled.
  • Google Cloud: roles/logging.viewer can read Vertex AI (now Gemini Enterprise Agent Platform) container logs, which contain whatever your serving containers write to standard output and standard error. Container logging is enabled by default on the v1 service endpoint and disabled by default on v1beta1. Vertex AI request-response logging writes a sample of requests and responses to a BigQuery table, so a project-wide BigQuery read grant can reach that table when you enable that logging.
  • Azure: Reader and Monitoring Reader can query Log Analytics workspace tables in the subscription at the default (General) protection level. When API Management language-model message logging is enabled, the ApiManagementGatewayLlmLog table in that workspace contains prompts and completions. Event Hubs diagnostic streams can also carry request or response detail when that diagnostic category is enabled; for example, the API Management Logs related to generative AI gateway category carries prompts and completions when an API’s Log LLM messages setting is enabled with Log prompts or Log completions selected.

Scope the grant to the named log group, log view, BigQuery dataset, Log Analytics workspace, or Event Hubs namespace that supplies metadata. On Azure, where Reader and Monitoring Reader apply to the whole subscription, set a content-bearing table such as ApiManagementGatewayLlmLog to the Protected level (an Azure Monitor preview feature) so those roles cannot query it. For any record that still contains content, the collector applies a field allowlist in memory, discards prompt and completion fields before a record is materialized, and never persists, logs, retries, or exports them. The normalized InvocationEvent schema has no field for prompt or completion text.

Keys and classification

In addition to the content boundary:

  • Provider API keys on proxied calls are never stored. Venturi keeps only a one-way keyed fingerprint and a truncated display prefix of each key (see Tenant admission).
  • Provider admin keys never reach the control plane in plaintext. Where you supply a provider admin key for usage/cost ingestion, it is KMS-encrypted inside your trust boundary, and a log-guard rejects any line that would emit it.

A field-level PII classification of the InvocationEvent schema is maintained and verified in CI, so that the personal-data footprint is auditable and minimized by design (GDPR Art. 5(1)(c) data minimization).

Cohort-only adoption intelligence

Venturi’s adoption-intelligence reporting is aggregate and cohort-level by construction; it does not profile, score, or infer the state of any individual worker. The minimum cohort size is a structural invariant of the customer-onboarding baseline:

  • Every cohort read path enforces it. Adoption views, dashboards, filters, drill-downs, shares, exports, API responses, board packs, and webhooks apply a server-side minimum cohort size of 5.
  • Sub-cohort suppression and roll-up: cohorts below 5 are suppressed and rolled into the parent unit; they are never displayed or returned.
  • Anti-differencing: a suppressed cohort cannot be reconstructed by differencing overlapping cohorts.
  • Raise-only threshold. An Admin can raise the threshold above 5; no role can lower it below 5.
  • Individual-level views do not exist.

A documented non-doing

Venturi performs no emotion recognition and no behavioral- or affective-state inference about individual workers. Adoption signals are aggregate usage-pattern metrics over cohorts of 5 or more, never affective-state inference. This is enforced as a frozen product invariant and is the foundation of Venturi’s non-high-risk posture under the EU AI Act (see Compliance).

Data classification

Venturi classifies every data class it handles in a four-tier scheme (Public, Internal, Confidential, and Restricted) plus an orthogonal personal-data flag (none, personal data, or sensitive personal data). The tier and flag drive the encryption, access, retention, and egress rules for each class. The table lists the data classes Venturi handles for your deployment, which fall in the Restricted, Confidential, and Internal tiers.

Data class Tier Handling
Provider admin keys Restricted KMS-encrypted in your boundary; control plane never sees plaintext; never egresses; rotated by you.
Invocation metadata (InvocationEvent fields) Confidential Stored in the dedicated tenant data plane, AES-256 with your KMS key, tenant-isolated; provider API keys kept only as a one-way keyed fingerprint and a truncated display prefix.
AttributionRecords Confidential Per-tenant store and key; cross-tenant access rejected; operational retention then archive.
Audit log Confidential Append-only; S3 Object Lock with 5-year retention; PII pseudonymized.
Aggregation contributions (post-anonymization) Internal Anonymized (cohort ≥ 5) before egress; region-pinned; non-personal once anonymized.
Model artifacts Internal Hash- and signature-verified at load; not customer personal data.

Retention

Operational retention defaults to 13 months

The operational-retention default is 13 months, chosen to cover a full annual audit cycle plus one reconciliation margin. Retention is configurable per data class within a bounded range of 30 days to 5 years.

Per-class lifecycle:

  • Billing data: 90 days in standard storage, then cold archive.
  • Attribution data: operational-retention default (13 months), then archive.
  • Audit log: retained for 5 years under S3 Object Lock (see below).
  • Override records: retained on an append-only topic so that manual overrides persist across graph rebuilds.
  • Application, security, and metric logs: metadata only, with no prompt or completion field; retained for the 13-month operational default, and within the 30-day crypto-shred erasure SLA: an erasure request crypto-shreds the tokenization key for that subject, so every historical log reference to the subject becomes unresolvable.

The audit trail

Audit-relevant events are written to a separate, append-only audit log, distinct from operational logs. Audited events include every dispute action, every model promotion, every threshold change, every aggregation enrollment or opt-out, every break-glass support access, and every administrative action against a tenant.

The audit trail has three distinct protections:

  1. Append-only application behavior. No product surface or API edits or deletes an audit entry.
  2. Governance-mode storage lock (default). The audit log is shipped to a per-tenant audit bucket in customer object storage, write-only from Venturi, under S3 Object Lock in Governance mode with a 5-year retention period. In Governance mode, a principal holding the explicit s3:BypassGovernanceRetention permission can shorten or remove a lock before it expires. Venturi’s writer and audit-retrieval roles never hold that permission; the administrators of the account that holds the bucket withhold it from routine roles and record its use with AWS CloudTrail data events on the bucket. See Who holds the audit bucket.
  3. Compliance mode (root-resistant). For deployments that require it, Compliance mode is configured at onboarding. In Compliance mode, no user, including the AWS account root user, can overwrite or delete a locked audit object or shorten its retention before it expires.

Only a Compliance-mode audit log is protected against deletion by every user, including the root user, for the full retention period. The chosen mode and retention date are visible in the activation evidence. See Audit logs.

  • The audit log carries a write-only policy at write time and read-only access via a separate retrieval role.
  • An append-only policy-event writer records every policy decision and override, providing the tamper-evident control history that the SOC 2 readiness program is built on.

Audit PII is pseudonymized

So that retaining the audit trail does not itself become a personal-data liability, PII in the audit log is pseudonymized: actor and subject references are opaque pseudonymous identifiers that can be linked to a person only through a mapping held under the per-subject key, rather than raw personal data. Until that key is destroyed, they remain personal data. After a subject’s per-subject data-encryption key is crypto-shredded (below), the corresponding audit entries are non-personal, and the audit trail is retained under a named lawful basis: the establishment, exercise, or defense of legal claims and Venturi’s legitimate interest in a tamper-evident security record (GDPR Art. 6(1)(f), Art. 17(3) exemptions).

Crypto-shred erasure

Erasure is implemented by destroying encryption keys, not by scrubbing append-only stores.

  • Erasure crypto-shreds the per-subject data-encryption key (and, on full offboarding, the per-tenant data-encryption keys). Once the key is destroyed, the data encrypted under it is permanently unrecoverable, which is how Venturi fulfills erasure without a record-by-record physical scrub.
  • Venturi destroys these keys without deleting your KMS key. Per-subject and per-tenant data-encryption keys are generated under your customer-managed KMS key and stored only in wrapped (encrypted) form. Crypto-shred erasure destroys the wrapped data-encryption keys, so it needs no KMS key deletion, and Venturi workloads never hold ScheduleKeyDeletion on your key. Your deletion evidence lists the data-encryption key versions destroyed.
  • The erasure SLA is 30 days. Complete, verified erasure of in-scope data finishes within 30 days of a valid erasure request, and on contract termination within 30 days after the post-termination retrieval window closes (see Offboarding & data return), with a deletion certificate as evidence.
  • Key destruction is the named exception to deterministic reconstruction. Venturi’s attribution graph is normally rebuildable by replaying the event stream, but replayed events whose key has been crypto-shredded cannot be re-materialized into personal data. This is the explicit, permitted exception that lets an append-only architecture honor a right-to-erasure request.

The carve-out is precise: operational and attribution data are crypto-shred-erased within 30 days; the append-only audit log and override topic are retained for their 5-year compliance period (pseudonymized, named lawful basis) and deleted on expiry; anonymized aggregation contributions are non-personal and not individually reversible. See Data-subject rights for the full request mechanics.

Offboarding & data return

On contract termination, Venturi runs a defined sequence that returns your data before it destroys any keys, so a departing customer never loses access to its own attribution record.

  1. Final full export before deletion. You receive a final full export in the standard tenant-export format within 5 business days of the termination effective date, covering your AttributionRecords, your customer-readable audit trail, and the reconciliation and billing artifacts you need to operate afterward.
  2. Post-termination retrieval window. A retrieval window (default 30 days, contract-configurable) runs after the export is delivered and before key destruction, so you can re-retrieve or validate the export on your own schedule.
  3. Certified crypto-shred deletion. After the window closes, the per-tenant (and per-subject) data-encryption keys are crypto-shredded under the 30-day SLA, and a deletion certificate is issued.

The offboarding runbook fixes the export-then-delete order (export and retrieval window first, key destruction second, never the reverse), names the owner, and enumerates the evidence artifacts (export manifest and checksums, retrieval-window record, deletion certificate) written to your audit trail.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Data privacy & retention
Page: https://docs.venturi.systems/security/data-privacy-and-retention/