The evidence layer for regulated AI
VeilEngine sits between your operators and Claude, GPT, or Gemini. Sensitive data is secured before it ever crosses the provider boundary, and every request emits a cryptographic receipt your auditor can verify offline. The compliance officer receives evidence; the CFO, productivity — both from the same workflow.
Your most valuable AI workflows touch your most sensitive data — which is why they stall
Healthcare can’t put PHI in Claude. Finserv can’t put MNPI in GPT. Legal can’t put privileged communications in Gemini. Insurance can’t put claimant identifiers anywhere. The result: regulated organizations watch the productivity gap widen while their compliance officers correctly say no.
The category response — AI governance dashboards layered over an unprotected execution path — doesn’t change what data reaches the model. It just reports on what happened. VeilEngine changes what reaches the model.
One boundary, one receipt, any provider
VeilEngine introduces a single protection boundary between your operators and the LLM provider. Every workflow inherits four guarantees from the boundary; nothing in your stack downstream depends on which provider served the request.
Secured before the provider
Sensitive entities — patient identifiers, MNPI, privileged content, claimant data, student PII — are protected before any request leaves your environment. The provider receives a workflow-equivalent payload with the sensitive elements replaced by deterministic placeholders.
Receipt at every boundary
Each request emits a signed receipt: workflow ID, provider, tokenization summary, time-to-answer, and a signed attestation hash. Receipts are hash-linked into a tamper-evident per-session chain; your auditor verifies each receipt signature offline with our open verifier CLI — without trusting our infrastructure. Automated chain-walk verification, a per-request cryptographic proof bundle, and a cross-session transparency log are on the roadmap.
Provider-agnostic by design
Workflows are written against the VeilEngine execution layer, not the provider SDK. Route to Claude for one workflow, GPT for another, Gemini for a third — or all three with automatic fallback. Switching providers is a config change, not an engineering project.
Round-trip utility check
The output is checked back through the protection boundary so usable signal survives without leaking sensitive entities. Operators see a Semantic Preservation Score per request; cryptographic proof-bundle claims remain roadmap-gated until review clears the public wording.
Gateway protection live at launch — three tiers by design
Different workflows demand different trust boundaries. The launch path is Tier 1 gateway protection; Tier 0 client-side and Tier 2 provider-under-agreement paths are engagement-scoped options that require separate configuration and governance review.
Client-side
Tier 0 is designed so protection happens inside your perimeter — the raw data stays in your network, not even reaching us. It is scoped per engagement for sovereignty workloads, attorney-client privilege, and the most sensitive PHI / MNPI use cases; it is not the default gateway launch path.
Gateway
Protection happens in your region inside VeilEngine’s boundary. It is designed so the provider receives only protected / de-identified payloads, not raw entities; we do not persist them after the request closes. Tier 1 is the default for most regulated workflows — HIPAA, FERPA, NAIC, SEC Reg S-P all map cleanly here.
Provider under agreement
For workflows where a provider-side agreement is the right control, VeilEngine acts as the routing and evidence layer over that provider relationship, established per engagement on an eligible service tier. Tier 2 requires the provider relationship, DPA or BAA path, and workflow eligibility to be cleared before use; eligibility for a BAA is not the same as a signed BAA.
Eight primitives, one contract your auditor verifies offline
VeilEngine’s evidence fabric is organized around eight primitives that compose into a single auditor-verifiable artifact. Each is specified by a canonical schema; a per-session evidence bundle exports today for your auditor to verify offline, with a multi-session portable-ZIP package on the roadmap.
Gateway event spine
Every request becomes an append-only event — the system of record.
Receipt service
Signed receipt per request: workflow, provider, tokenization summary, signed attestation. (Per-request proof bundle: roadmap.)
Proof & verification layer
Offline verification of receipt signatures and the per-session hash chain. Per-request cryptographic proof that the provider never received the raw payload: roadmap.
Transparency log
Roadmap — designed for inclusion proofs against an append-only log. Today, receipts are hash-linked into a tamper-evident per-session chain.
RBAC / auditor boundary
Auditors see what they need. Operators see what they execute. Both see the same receipts.
Evidence package builder
Export a per-session evidence bundle; your auditor runs the open verifier offline, no call to our infra. Multi-session portable-ZIP packaging: roadmap.
Lineage store
Roadmap — designed so every output traces back to inputs, decisions, and policy version, with retention scoped to your framework.
Policy engine
Vertical-pack rules compiled to runtime decisions. Every gate logged. Every override attested.
Workflows survive provider switches — and the evidence survives with them
Provider lock-in is a real risk and an underdiscussed compliance liability: if your evidence depends on a provider’s logs, the day you switch providers is the day your audit trail breaks. VeilEngine inverts this. The evidence fabric is the system of record. The provider is interchangeable infrastructure.
- Claude (Anthropic) — Opus; default healthcare routing where a provider agreement is required, on an eligible service tier
- GPT (OpenAI / Azure OpenAI) — Tier-2 routing via Azure HIPAA-eligible services; cost-optimized for high-volume finserv workloads
- Gemini (Google Vertex AI) — DPA path; default for EU-residency and multimodal workflows
- On-premise / open-weight (roadmap) — designed for air-gapped Llama, Mistral, or your own model under the same evidence contract
Productivity gains, instrumented
Time-to-Useful-Answer (TUA)
Wall-clock from operator prompt to verified, compliance-cleared output. Healthcare discharge-summary baseline: ~18 seconds with VeilEngine versus ~22 minutes of manual redaction plus legal review. Finserv research-note draft: ~30 seconds versus ~3 days through compliance approval. Figures are illustrative pending instrumented benchmarks.
Semantic Preservation Score
A 0–100 measurement of how much usable signal survives the protection boundary. Operators see the score before publishing the output and choose the tier that maintains LLM utility for each workflow class.
Cost-per-Useful-Answer
Total cost amortized across provider fees, routing logic, and the protection boundary — captured per receipt so your CFO sees the unit economics, not just the platform bill.
Provider portability
Workflows are written against the VeilEngine execution layer, not a provider SDK, so switching providers is a config change rather than a re-engineering project. Portability is validated per engagement against your provider mix.
Questions about VeilEngine
Auditors run our verifier offline
Detailed coverage of the evidence-fabric primitives, the canonical schemas, the verifier CLI, and the framework-mapping engine lives on the Trust page. Built for the CISO, CCO, and external auditor — not for marketing.