The Problem
Every major SaaS AI governance platform today shares a common architecture: your prompts flow through their servers, your completions are processed on their infrastructure, and your employees’ AI interactions are stored in their databases. In exchange, you receive dashboards, policy enforcement, and audit trails.
This is the governance paradox: the tools built to protect your data require you to surrender it.
Consider what governance actually requires: tracking which models were called, by whom, with what policies applied, and what the outcomes were. None of that requires seeing prompt content. Token counts, cost metrics, latency, and status codes are sufficient for comprehensive governance — and they carry zero confidential information.
The regulatory pressure
The EU AI Act (enforcement begins February 2026 for high-risk systems), NIST AI RMF, and ISO/IEC 42001 all impose requirements on organizations deploying AI in production. Regulated industries face additional obligations: HIPAA for patient data, GDPR for EU personal data, and sector-specific guidance from regulators still writing the rules.
These requirements create a dilemma: enterprises need governance tooling, but the tooling itself must not create new compliance exposure. A HIPAA-covered entity cannot route clinical prompts through a SaaS vendor’s servers, even with a BAA.
Zero-Knowledge Architecture
DAX Enterprise is built on a single architectural principle: the governance layer should never see the governed data.
This is achievable because inference governance can be decomposed into two planes with different data requirements:
Control plane (governance metadata only)
The control plane manages policies, identities, approvals, audit logs, and budgets. It receives usage events containing: model ID, user ID, token counts, cost estimate, latency, HTTP status code, and timestamp. It never receives prompt content, completion text, or any user-generated content.
Data plane (inference only)
The data plane is an OpenAI-compatible inference proxy that runs in the customer’s GCP project exclusively. It validates access tokens, enforces rate limits, applies guardrail policies, and proxies requests to the configured provider.
The zero-knowledge guarantee
The guarantee is architectural, not contractual. The control plane has no endpoint that accepts prompt content. The gateway has no code path that transmits prompts to the control plane. The usage event structure contains only numeric and identifier fields. This is not a privacy policy — it is a code constraint.
BYOC Design
Bring-Your-Own-Cloud means both planes run in the customer’s GCP project. DAX operates no infrastructure on the customer’s behalf and has no access to their data, network, or credentials.
| Component | Location | DAX Access |
|---|---|---|
| Control plane API | Customer Cloud Run | None |
| Portal (Next.js) | Customer Cloud Run | None |
| Inference gateway | Customer Cloud Run / GKE | None |
| PostgreSQL | Customer Cloud SQL | None |
| Redis | Customer Memorystore | None |
| Provider API keys | Customer Secret Manager | None |
| Prompt / completion data | Never stored | N/A |
Workload Identity for Vertex AI
When routing inference to Google Vertex AI, the gateway uses Workload Identity — the GCP service account bound to Cloud Run is granted roles/aiplatform.user directly. No API key is needed and there is no secret rotation burden for Vertex models.
Compliance Coverage
DAX maps natively to the frameworks enterprise buyers, legal teams, and auditors actually require. No custom integrations, no compliance spreadsheets — every control is a built-in platform feature.
| Standard | Requirement | How DAX Covers It |
|---|---|---|
| NIST AI RMF | GOVERN — AI policies | Named guardrail policies, RBAC, audit log evidence trail |
| NIST AI RMF | MAP — Risk identification | Model catalog with risk_tier, autonomy_tier, use-case context per access request |
| NIST AI RMF | MEASURE — Analytics | Usage events across org/model/user/team/project + incident severity metrics |
| NIST AI RMF | MANAGE — Response | Guardrail engine, budget hard blocks, incident lifecycle (open → resolved) |
| EU AI Act | Art. 6 — Risk classification | risk_tier + eu_ai_act_category on every model, compliance coverage dashboard |
| EU AI Act | Art. 14 — Human oversight | autonomy_tier enforcement — autonomous models require guardrail policy |
| EU AI Act | Art. 13 — Transparency | explainability_doc_url + bias_assessment_url fields, coverage metrics |
| EU AI Act | Art. 73 — Incident reporting | Incident log with severity lifecycle, auto-creation from guardrail violations |
| ISO/IEC 42001 | AI system inventory | Model catalog with lifecycle status, provider, version, governance metadata |
| ISO/IEC 42001 | Shared responsibility | Built-in printable shared responsibility matrix, documented BYOC boundary |
| SOC 2 Type II | Access control | RBAC, model approval workflow, token scoping — least-privilege by default |
| SOC 2 Type II | Audit logging | Append-only audit log, 25+ event types, CSV export for external auditors |
| GDPR / HIPAA | Data sovereignty | BYOC: prompts never leave customer cloud — architectural, not contractual |
EU AI Act Alignment
The EU AI Act imposes tiered obligations based on risk level, with enforcement for high-risk systems beginning February 2026.
Risk classification (Articles 6, 51)
DAX implements four-tier risk classification on every model: high, medium, low, and minimal. Each model also carries an eu_ai_act_category field. The compliance dashboard tracks classification coverage.
Human oversight (Article 14)
The autonomy tier field classifies each model as Assistive (HITL), Conditional (HOTL), or Autonomous (HOOTL). Autonomous models require an assigned guardrail policy before activation. The approval workflow satisfies Article 14’s oversight requirements.
Transparency (Article 13)
The explainability_doc_url field links each model to its decision-scope documentation. The compliance dashboard measures coverage and reports a pass/fail check.
Incident reporting (Article 73)
The incident log provides the workflow required for serious incident reporting. Guardrail blocks above a configured severity threshold automatically create incidents, flowing through open→investigating→resolved with timestamped resolution notes.
NIST AI RMF Alignment
The NIST AI RMF organizes AI governance into four functions: Govern, Map, Measure, and Manage. DAX implements controls across all four.
GOVERN
RBAC with five built-in roles plus custom role definitions satisfies accountability requirements. Named guardrail policies serve as org-wide AI usage policies. The audit log provides the accountability evidence trail.
MAP
The model catalog with risk tier, autonomy tier, EU AI Act category, and use-case context captured via justification and intended_use on access requests satisfies MAP requirements.
MEASURE
Usage events with org/model/user/team/project dimensions give the measurement data MEASURE requires. The incident log with severity classification provides incident metrics.
MANAGE
The guardrail engine implements risk treatment controls. Budget enforcement with hard blocks prevents runaway spend. The incident lifecycle implements response and recovery processes.
Getting Started
Option 1: Self-hosted (Community, free)
Option 2: Live pilot (hosted by DAX)
The full platform is running at app.enterprise.dax.studio. Sign up with your work email — no credit card, no sales call.