Compliance & deployment
AI.Guard is engineered for regulated environments. We are explicit about which controls are in place today, which are in flight, and which are customer-configurable.
EU AI Act & US State Laws
Aligned
Audit trail, human oversight, and risk-tier policy scoping aligned to EU AI Act and emerging US frameworks like the Colorado AI Act.
ISO/IEC AI Standards
Mapped
Capabilities mapped to ISO/IEC 42001 (AIMS), 23894 (Risk), 5338 (Lifecycle), and TR 5469 (Functional Safety).
Privacy & Sector Controls
Implementation support
Configurable masking, audit, and retention controls can support customer programs mapped to GDPR, CCPA, and financial-sector expectations. Compliance remains customer-specific.
NIST AI RMF & OWASP
Playbook Aligned
Control mapping is available for NIST AI RMF functions and OWASP LLM Top 10 mitigation surfaces; effective coverage depends on deployment and policy configuration.
Deployment patterns
| Capability | SaaS | Single-tenant | Air-gapped on-prem |
|---|---|---|---|
| Infrastructure | MOAI Labs Cloud (multi-tenant) | Isolated cluster in MOAI or your cloud account | Customer-owned cluster, no internet egress required |
| Data residency | US East, EU West | Choice of region across AWS / GCP / Azure | Customer-controlled, fully |
| Prompt / response retention | In-flight only, never persisted | In-flight only, never persisted | Never leaves customer network |
| Tokenization vault | Per-tenant, KMS-encrypted | Per-tenant, customer KMS | Customer-managed |
| Update cadence | Continuous (daily) | Weekly, staged windows | Manual via signed artifact bundle |
| Runtimes supported | — | Linux, Kubernetes, OpenShift | Linux VM, Kubernetes, OpenShift, Nomad |
High availability
The gateway runs as a stateless horizontally scaled service. Tokenization vault and policy store are the only stateful components and replicate across availability zones.
- • Multi-AZ active/active by default
- • Health-checked behind your existing load balancer
- • Rolling policy reloads — no request drop on update
Fail-open vs fail-closed
Each policy declares its failure mode explicitly. There is no implicit default. Highly regulated workloads should prefer fail-closed; availability-sensitive workloads may choose fail-open with degraded inspection.
- • Fail-closed: request denied if inspection cannot complete
- • Fail-open (degraded): request passes with structural checks only, full audit emitted
- • Mode change requires a policy review with second-approver