Trust center

Built for the auditor, not the marketing slide

The trust page exists to answer the questions a CISO, Chief Compliance Officer, General Counsel, or external auditor asks before a procurement decision — with concrete framework coverage, the open verifier, our sub-processor posture, and the regulatory calendar that governs our roadmap.

01

Encryption-first architecture

The boundary is structural, not behavioral. Sensitive data is secured before reaching the provider; each request and its result are receipted. The architecture is designed so the provider never holds raw entities — with cryptographic receipts your auditor verifies offline.

02

Auditor-verifiable evidence

Cryptographic receipts link into a per-session, tamper-evident chain. Auditors run the open verifier CLI against an exported session evidence package, all offline. The evidence holds without trusting our platform.

03

Framework-mapped controls

Twelve frameworks mapped from regulatory text to runtime control evidence. Updates are compiled into the vertical pack per engagement, and a framework refresh that would break a mapped control is flagged for review.

Framework coverage

The frameworks we map — to runtime control evidence

Each framework below carries an initial coverage model into the evidence fabric and, where needed, an engagement-specific vertical pack. Mapping is reviewed quarterly against the regulatory calendar. Maturity tags signal public-control posture: Mapped (coverage model available for engagement validation), Provisional (issued; on the roadmap), Proposed (in design). Detailed control crosswalks are shared under engagement; the public page summarizes the model.

Healthcare · Mapped

HIPAA / HITECH

45 CFR 164.308–164.318 administrative, physical, and technical safeguards mapped to evidence-fabric primitives. Detection targets the Safe Harbor 18-identifier set at the protection boundary, with coverage validated per engagement; non-text identifiers (e.g. full-face photographs) are blocked by default. Where PHI would reach a provider, routing is restricted to BAA-eligible relationships established per engagement; otherwise PHI is protected at the boundary before any request reaches the provider.

164.308 Admin 164.310 Physical 164.312 Technical 164.502(d) De-ID
All verticals · Provisional

SOC 2 Type II

Trust Services Criteria coverage: Security, Availability, Processing Integrity, Confidentiality, Privacy. Type II attestation is on the audit pathway with a target audit window in 2026. Evidence-fabric receipts feed first-party control evidence into the engagement.

CC1-CC9 A1 PI1 C1 P1-P8
Finserv · Mapped

SEC Reg S-P · SEC Rule 17a-4

Customer information safeguards under Reg S-P and the 17a-4 books-and-records retention rule. Designed to support 17a-4(f) electronic-record-system / audit-trail-alternative requirements — signed receipts plus a per-session hash-linked chain (transparency-log inclusion proofs are on the roadmap) — subject to firm policy, counsel review, and current FINRA/SEC guidance at deploy time.

Reg S-P 17a-4(b)(4) 17a-4(f) ATA MNPI handling
Insurance · Mapped

NAIC AI Model Bulletin

NAIC AI Model Bulletin (adopted December 2023; state implementation 2024 onward) governance principles mapped to vertical-pack policies. State DOI variation handled via the framework-mapping engine. Per-session signed evidence with engagement-scoped retention aligned to LoB statute-of-limitations; cross-session replay-by-claim is on the roadmap.

NAIC 2024 State DOI Replay-by-claim
Legal · Mapped

ABA Model Rules

Rule 1.1 (competence), 1.6 (confidentiality), 5.3 (non-lawyer assistance), 5.5 (UPL). Privilege-preserving protection at the boundary for client-side workflows. A counsel-directed enterprise mode is designed so work-product mental impressions stay client-side — counsel directs which workflows qualify.

Rule 1.6 Rule 5.3 Privilege Work product
Education · Mapped

FERPA · COPPA · IDEA

20 U.S.C. 1232g education-record identifiers tokenized at the boundary. FTC COPPA Rule update (effective per Federal Register publication) — separate consent for AI training, targeted advertising, third-party disclosures, and data-retention limits — designed to be honored via a parental-consent vector (per-record, not per-platform); consent-vector enforcement is engagement-scoped. IDEA-aligned IEP drafting with documented-disability accommodations.

FERPA COPPA IDEA PPRA
Global · Mapped

GDPR · CCPA / CPRA

Article 6 lawful basis, Article 17 erasure, Article 32 security of processing, Article 35 DPIAs supported via the policy engine. CCPA / CPRA opt-out controls and "sale of personal information" determinations mapped to the policy engine; per-dimension consent enforcement is engagement-scoped.

GDPR Art. 32 Art. 35 DPIA Schrems II CCPA
AI governance · Mapped

ISO/IEC 42001 · ISO 27001

42001 AI Management System (AIMS) controls mapped to evidence primitives. 27001 ISMS controls covered by the parallel security framework. Independent audit pathway scoped for 2026–2027 conditional on enterprise customer demand signal.

ISO 42001 ISO 27001 Annex A
US federal · Mapped

NIST AI RMF

AI RMF v1.0 Govern / Map / Measure / Manage functions mapped to the policy engine. Generative AI Profile (NIST AI 600-1) extensions integrated. Each control emits evidence to the framework-mapping engine for first-party demonstration.

NIST AI RMF AI 600-1 Govern-Map-Measure-Manage
EU · Provisional

EU AI Act

Article 9 risk management, Article 10 data & governance, Article 12 record-keeping, Article 13 transparency, Article 14 human oversight, Article 50 transparency obligations. High-risk Annex III tagging supported per workflow. Effective dates tracked in the regulatory calendar.

Art. 9-15 Annex III Art. 50 (Aug 2026)
Multi-jurisdictional · Provisional

State + sectoral AI laws

Colorado SB21-169, NYC LL144, California SB1047 (struck-down successor watch), Texas TX-RDIA, Illinois BIPA. Tracked in the regulatory calendar; mapped to vertical-pack policy when a customer activates the jurisdiction.

CO SB21-169 NYC LL144 TX-RDIA BIPA
AI-specific · Proposed

AIUC-1

AI Use-Case framework v1.0 target Q3 2026. Eight hardening domains tracked; Domain 6 (triage / routing) is implemented with outbox-pattern reliability, with production rollout engagement-scoped. Vertical Edge AI participates in the AIUC-1 v1.3 readiness review.

AIUC-1 v1.0 Domain 6 implemented Q3 2026 target
The open verifier

Auditors verify offline — no platform trust required

The verifier CLI is the load-bearing artifact of the trust architecture. Your auditor downloads it, points it at an exported session evidence package, and confirms each receipt’s cryptographic signature and the package manifest — without any call to our infrastructure, without any dependency on our continued operation. The package carries a per-session hash-linked chain; automated chain-walk verification in the CLI is on the roadmap.

If Vertical Edge AI ceased to exist tomorrow, the evidence you hold today would still verify. That is the design constraint, and it’s the reason we publish the verifier as an open, auditable artifact rather than a closed service.

  • Offline operation — no network calls, deterministic outputs, reproducible across auditor environments
  • Cryptographic chaining — per-receipt signatures, a per-session hash-linked chain, tamper-evidence (cross-session transparency-log inclusion proofs: roadmap)
  • Round-trip integrity (roadmap) — designed so a protection-boundary attestation confirms provider input contained zero raw entities; per-request proof bundles are not yet emitted
  • Provider-independent — verification holds regardless of which model served the request
Download the sample package and run the verifier offline — no form, no NDA
Verifier CLI
Illustrative
$ ve-verify ./session-evidence.json [OK] schema_version 1.2.0 [OK] receipt_signatures valid [OK] session_event_chain linked [OK] policy_decisions all signed Session evidence verified. No platform contact required.
Sub-processors

Every party that touches your data — named, scoped, and contracted in your engagement

The protection boundary comes first. For the launch path, Tier 1 (gateway) workflows send only protected or de-identified payloads to a provider, processed in the selected region. Tier 0 client-side workflows are scoped separately for engagements where no entity data may leave the customer perimeter.

Every party that may touch data in a Tier 1 workflow — the LLM provider, the evidence store, the runtime host — is named in the register we share during procurement, scoped there to a single purpose and data category, and bound by the data-processing terms in your engagement’s DPA, with 30 days’ notice before any change and a per-vertical opt-out. We keep that register current and provide it in full during procurement, rather than on a public page.

Where a workflow routes to an external provider, it does so under the agreement appropriate to that workflow, established as part of your engagement. BAA-eligible routing is available where a provider offers it on an eligible service tier — eligibility for a BAA is not the same as a signed BAA, and a BAA is not the control we lead with. Where a provider is not under the required agreement, regulated entities are protected at the boundary before any request reaches it, so the provider never receives them.

The full register, with the data category each party may touch and the residency of each, is shared under engagement — not published here, by design.

This marketing site itself sets no tracking cookies; visitor traffic is measured with cookieless, aggregated analytics only.

Regulatory calendar

The deadlines that move our roadmap

Our framework mappings refresh on a published cadence anchored to the regulatory calendar. Each entry below has a source-confidence tier (final / provisional / proposed) and a primary citation.

2 Aug 2026 · Final
EU AI Act Article 50 transparency obligations effective
General-purpose AI obligations, disclosure to natural persons interacting with AI, deepfake labeling. Disclosure templates for these obligations are compiled into the vertical pack per engagement.
2 Aug 2027 · Provisional
EU AI Act high-risk obligations (Annex III) effective
Risk-management, data & governance, record-keeping, transparency, human oversight, accuracy / robustness. The vertical-pack policy engine carries the per-workflow risk tagging.
22 Apr 2026 · Final
FTC COPPA Rule update effective
Effective dates per Federal Register publication. Update introduces separate consent for AI training, targeted advertising, third-party disclosures, and data-retention limits. The education vertical pack is designed to carry a per-record consent vector across these dimensions; consent-vector enforcement is engagement-scoped (roadmap).
Q3 2026 · Proposed
AIUC-1 v1.0 framework release
AI Use-Case framework finalization. Vertical Edge AI participates in v1.3 readiness; Domain 6 (triage / routing) implemented, production rollout engagement-scoped.
Continuous · Quarterly refresh
Framework re-audit cadence
All framework mappings reviewed every 90 days against primary regulatory sources. Customers receive a delta notification when a refresh changes a control they rely on.
Verify before you talk to us

Run the verifier yourself — the sample package is public

The sample evidence package and the verifier are a public download — no form, no NDA, no sales call. Run it against your own validation environment. The production verifier ships with your VeilEngine engagement, signing with your own key against your live deployment.

Download the sample evidence package Or email a question →