Compliance & governance¶
🔒 Enterprise edition. Compliance enforcement attribution, the ISO/IEC 42001 audit-evidence view, and the dashboard Compliance Insights panel are part of the Enterprise tier. The enforcement itself (guardrails, routing, deny rules) runs on every tier; what Enterprise adds is the proof layer. See Licensing & tiers.
This is the page to read first if your job is to answer one question: "Can I prove our AI is governed?"
Most of this guide is organised by screen. This page is organised by that question. It tells the end-to-end story and points you to the screen-level detail at each step.
The story in one line¶
A regulated AI deployment has obligations it must guarantee. The control plane enforces them and produces the evidence that it did, measured as a share of real traffic, mapped to your auditor's framework. It does not claim to make you "compliant"; it makes you provable, and is precise about exactly which controls it speaks to. That candour is the point.
1. The obligation: what a regulated deployment must guarantee¶
Strip away the frameworks and every AI-governance regime asks for the same three operational guarantees:
| Obligation | The question behind it |
|---|---|
| Data residency / sovereignty | "Is regulated data staying in the region and with the providers we're allowed to use?" |
| Sensitive data | "Is PII / secret content being kept out of the models?" |
| Model access | "Are only the permitted callers using the permitted models?" |
Everything else in this story exists to guarantee these three and prove the guarantee held.
📌 Worth knowing. This is why the dashboard speaks in obligations, not mechanism names. A compliance officer reasons about residency and sensitive data, not about "guardrail_mask events." The product meets them where they think.
2. How the control plane enforces it: two engines, three obligations¶
There are exactly two enforcement engines, and between them they cover all three obligations:
- Routing enforces data residency. A compliance-tagged routing rule pins traffic to a compliant region/provider; regulated requests never reach a disallowed destination. The mechanics: Routing, and how to tag a rule for compliance is on Compliance.
- Guardrails enforce sensitive data. A guardrail blocks or masks PII / secret content before it leaves your boundary, using static (regex) and ML (ONNX) tiers. The mechanics: Guardrails.
- Access control / deny rules enforce model access: the caller-not-permitted case. Also a routing-family rule; see Routing.
Two engines, three obligations. That's the whole enforcement surface; there is no fourth hidden mechanism, which is itself part of the honesty: you can reason about the complete set.
3. How you prove it: the part auditors actually care about¶
Enforcement without evidence is an assertion. This is the half of the story that makes the control plane a compliance tool rather than just a passthrough, and it has three pieces:
It's a measured percentage, not a checkbox¶
The dashboard reports each obligation as the share of real traffic that was residency-controlled, sensitive-data protected, or access-controlled, over a window, against a real denominator. "We have a PII policy" is a checkbox anyone can tick. "97.3% of traffic carrying sensitive content was masked or blocked this quarter, here are the 2.7% and why" is evidence. The obligation rail on the dashboard is that number; Compliance explains how to read it.
It's an immutable record¶
The evidence reads from the per-request record frozen at write time; historical coverage stays stable even when you change policies later. The attestable configuration trail (which routing/provider/supplier rules changed, by whom, when) lives in the Audit log. Per-request decisions live in Request Logs.
It's mapped to your auditor's framework: ISO/IEC 42001¶
This is the part that turns "the control plane has logs" into "here is the evidence for control A.6.2.8." The control plane maps its runtime evidence to ISO/IEC 42001:2023 (the AI Management System standard) and states, per control, exactly what role it plays:
- For 4 controls it is the system of record: the auditor's evidence is the control plane's data.
- For 5 controls it enables your evidence: it supplies the runtime primitive that makes your process for that control achievable.
- For the other 29 it says, plainly, "that's your process, not ours."
That last line is the differentiator. The control plane does not claim to make you ISO 42001 compliant; the product literally cannot express that, by design. It makes a precise, conservative, honest claim about a specific 9 of 38 controls. To a CISO preparing for an assessment, that candour is worth more than an inflated coverage score, because an inflated score is a credibility failure the moment the assessor probes it.
The full role model, the 9 controls, and exactly how to talk to an assessor: ISO/IEC 42001 audit evidence.
⚠️ Watch out. The one-click tamper-evident assessor export is on the roadmap, not shipped. The evidence data is retrievable today (Request Logs, Audit, Reports); what's "Coming soon" is the single attested per-control pack. Tell an assessor exactly that: it's a good-practice signal, not a weakness. Detail: ISO/IEC 42001 § Getting the evidence out today.
4. Where the whole story is true at once: the dashboard¶
The story isn't four screens you assemble in your head. It reads end-to-end on one panel: the Dashboard Compliance Insights panel.
- The obligation rail: the three guarantees as % of traffic (beat 1 + 3).
- The ISO/IEC 42001 block: the audit-evidence state and role mapping (beat 3).
- VidaiGuard status: are the enforcement engines actually on, static and ML, each independently (beat 2).
- Compliance posture by subject: is your automated / agent traffic enforced as well as human use (the automated-decisioning assurance auditors increasingly ask for).
That panel is the payoff of this story. Everything above is why each number on it means what it means.
Where to go next¶
You've read the arc. The screen-level detail:
- Compliance: the mechanics, including tagging rules for compliance, reading each panel block, the reference tables, and common questions.
- ISO/IEC 42001 audit evidence: the proof half in depth, covering the role model, the 9 controls, the honest-scope framing, and the assessor do/don't.
- Guardrails: the sensitive-data enforcement engine (static + ML).
- Routing: residency + model-access enforcement; how to tag a rule for compliance.
- Audit Log: the attestable configuration trail.
- Dashboard: the synthesis panel in context.
- Cost control: the other flagship story (the control plane's spend discipline), structured the same way.