Frequently Asked Questions
The Veil FAQ
How The Veil separates identity from AI processing, and what that means for compliance.
Last updated: April 2026
Overview
What is The Veil?
A split-knowledge platform where identity data (WHO) and AI processing (WHAT) live in separate, network-isolated sandboxes. They communicate only through opaque pseudonymous tokens via an ID Bridge. The AI model never knows who the data belongs to.
How does The Veil differ from data redaction?
Redaction is a software promise — a single bug leaks PII. The Veil enforces separation at the infrastructure level using Kubernetes NetworkPolicies and Docker network segmentation. The AI sandbox is physically unable to reach identity data, regardless of application-level errors.
Architecture
How does the ID Bridge work?
The ID Bridge generates opaque pseudonymous tokens that have no derivable relationship to real identities. It manages token-to-identity mappings, enforces rotation policies, and requires audited four-eyes approval for any re-linkage operation.
Can The Veil work with any AI model?
Yes. The Veil is AI-provider agnostic. Sandbox B supports pluggable adapters for Anthropic Claude, OpenAI, Mistral, and local models via Ollama. The architecture separates privacy guarantees from AI capabilities — swap models without changing the privacy posture.
How is re-linkage governed?
Re-linkage requires a legitimate legal basis, four-eyes approval (two authorized individuals), scoped attribute access, jurisdiction controls, and mandatory post-access review. A break-glass mechanism exists for emergencies, with full audit trail.
What happens during a data breach?
An attacker compromising Sandbox B gets AI outputs and pseudonymous tokens — but no names, emails, or account numbers. Compromising Sandbox A reveals identity data but no AI-derived insights or behavioural profiles. Neither sandbox alone produces a linked, identifiable profile.
What is the audit trail?
Decision records are appended to a cryptographic hash chain. The application role has INSERT and SELECT only. Deletion is permitted only for GDPR Article 17 erasure requests and retention expiry, executed through audited security-definer functions that write a signed erasure event to a separate append-only log alongside every deletion.
Does The Veil integrate with our existing identity provider?
Yes. Sandbox A includes a full OIDC-compliant identity provider supporting PKCE, authorization code grants, refresh tokens, and client credentials. It integrates with existing enterprise identity infrastructure — Azure AD, Okta, Keycloak, or any OIDC-compatible provider.
Compliance
Which regulations does The Veil address?
GDPR Article 25 (data protection by design), Article 32 (security of processing), EU AI Act Article 10 (data governance for high-risk AI), and EU AI Act Article 14 (human oversight, via TraceVault decision records). These are architectural and evidence mappings — not held certifications, and not sector-specific attestations.
How does The Veil handle GDPR data subject access requests (DSARs)?
DSARs are scoped to Sandbox A (identity data) and the audit trail. Sandbox B only holds pseudonymous tokens, so there is no identity data to search. This dramatically reduces DSAR response scope and engineering complexity.
How does The Veil satisfy GDPR Article 25?
Article 25 requires data protection by design and by default. The Veil implements this architecturally: pseudonymisation is the default processing mode, identity isolation is enforced at the network layer, and data minimisation is structural — Sandbox B literally cannot access more data than needed.
How does right to erasure (GDPR Article 17) work?
Sandbox A provides a dedicated erasure endpoint. When invoked, it performs a hard delete of the identity record with cascading cleanup and full audit logging. Once the identity is erased, all tokens associated with that identity become permanently non-resolvable — the data in Sandbox B becomes truly anonymous, with no path back to the individual. This is architectural erasure, not soft-delete.
How does The Veil reduce DSAR response time?
Sandbox A provides a dedicated DSAR endpoint that exports the identity record as structured JSON — name, email, sensitive fields, vertical-specific data. Because Sandbox B only holds pseudonymous tokens, DSARs are scoped entirely to Sandbox A and the audit trail. This reduces DSAR engineering cost and response time by 80-90% compared to systems where personal data is scattered across AI processing logs.
Deployment
What industries can use The Veil?
The architecture is applicable to any regulated industry processing sensitive data with AI, but the current launch focus is a single vertical: ITSM / ServiceNow-style internal workflows (privacy-first Now Assist, internal ticket triage). Broader verticals such as finance, healthcare, and government are follow-on work, not current launch offerings.
Where does The Veil deploy?
On your infrastructure. The Veil deploys via Helm charts to any Kubernetes cluster — cloud, on-premise, or air-gapped. Raw identity data never leaves your environment. In split deployment, only sanitized text, opaque pseudonymous tokens, and content hashes cross infrastructure boundaries — your sensitive data stays where it belongs. Fully local / air-gapped deployment is the recommended default for healthcare and government. No vendor lock-in. Uses PostgreSQL, Redis, and standard Kubernetes primitives your team already knows.
Does The Veil require special hardware (SGX, SEV, confidential computing)?
No. The Veil runs on any standard Kubernetes cluster or Docker environment. Unlike confidential computing approaches that require Intel SGX or AMD SEV enclaves, The Veil enforces isolation at the network and infrastructure layer using standard Kubernetes NetworkPolicies and Docker network segmentation. No specialised hardware, no vendor-specific silicon, no performance overhead from enclave transitions.
Can we use our own key management system?
Yes. The ID Bridge master key can be sourced from HashiCorp Vault, AWS KMS, or Azure Key Vault. Your encryption keys stay in your existing KMS infrastructure. No migration required.