Any region. Any framework.
A declarative policy engine at the router edge — residency, provider eligibility, data-class handling, retention and audit — bound to org, project, key or a single request.
This page is maintained by llmcloud.ai to describe our security, privacy and compliance posture. It is not an independent certification. Where a capability is on the roadmap, we mark it clearly.
Region-pinned routing
Constrain every request to providers hosted in a specific region. EU-only, US-only, UK-only, India-only and more. Hard fail if no eligible peer is available — never silent leakage.
Provider allow-lists
Per-tenant registry of which upstream providers are contractually eligible. HIPAA BAA signed? Zero-retention terms? Data-processor role? Filter on any of it.
PII / PHI / PCI handling
Detect and redact, tokenize, or block sensitive classes at the edge. Round-trip synthetic placeholders so nothing sensitive touches an upstream.
Log residency & retention
Pin the log store to a region. Configure retention from 0s (zero-retention) to 7y (regulated verticals). Right-to-erasure workflows for GDPR / CCPA / DPDP.
Signed audit trail
Hash-chained records with actor, purpose_of_use, lawful_basis, policy_id, model, provider and region. Exportable to Splunk, Datadog, S3 or Azure Sentinel.
DPA / BAA / SCCs self-serve
Click-through DPA, HIPAA BAA (eligible plans), SCCs, UK IDTA, Swiss addendum, KSA and UAE addenda from the dashboard.
POST /v1/policies
{
"name": "eu-healthcare",
"residency": { "regions": ["eu-frankfurt","eu-ireland"] },
"providers": {
"require": ["hipaa_baa","zero_retention","gdpr_dpa"],
"deny": ["cn-*","us-gov-*"]
},
"data_classes": {
"pii": { "action": "redact" },
"phi": { "action": "tokenize" },
"pci": { "action": "block" }
},
"retention": { "logs_days": 30, "prompts": "none" },
"audit": { "sink": "customer-splunk", "hash_chain": true }
}# Bind to a key
PATCH /v1/keys/hospital-agent
{ "policy": "eu-healthcare" }
# Per-request override
POST /v1/chat/completions
Headers:
X-LLMCloud-Policy: eu-healthcare
X-LLMCloud-Purpose: clinical_summary
Body:
{ "model": "auto:quality", "messages": [...] }
# Response headers report enforcement
x-llmcloud-policy-id: pol_01H...
x-llmcloud-residency: eu-frankfurt
x-llmcloud-provider: anthropic-eu
x-llmcloud-guardrail: pii=redacted,phi=tokenizedWhat the policy engine actually enforces
A compliance claim is only worth what the gateway refuses to do. Every policy below is a hard constraint evaluated before a request is dispatched, not a preference the router can trade away for latency or price. When a constraint cannot be satisfied the request fails with an explicit error naming the policy that blocked it, and the failure is recorded in the audit log with the same policy identifier returned in the response headers.
Requests pinned to a jurisdiction execute only on provider endpoints whose inference, cache, and logging all sit inside it. No cross-region failover, no spillover to a nearby region during capacity events — a pinned request that cannot be served in-region fails instead.
Allow-lists and deny-lists per key or project, evaluated against provider attributes such as retention window, sub-processor list, and certification status. A newly certified provider does not automatically enter your pool.
PII, PHI, and PCI detectors run at the edge before dispatch, with per-class actions: redact, tokenize with reversible mapping held in your region, or block the request outright.
Zero-retention is the default for prompt and completion bodies. Metadata retention windows are configurable per project, and providers that cannot contractually honour the setting are excluded from routing for that project.
Every request emits a signed record: policy identifier, resolved provider, region, guardrail actions taken, token counts, and latency. Records are exportable and hash-chained so tampering is detectable.
Keys carry their own policy bundle, so a staging key can be permissive while a production key is restricted to one region and a handful of certified providers, without deploying different code.
Detailed documentation — coming soon
The controls above are the complete picture of what the gateway enforces today. The following per-jurisdiction and per-framework references are being prepared and will be published as standalone documents once the underlying attestations land. Until then, ask us directly and we will send the current position in writing.
Compliance FAQ
Which frameworks do you cover?+
GDPR and the EU-US Data Privacy Framework, UK GDPR, Swiss FADP, CCPA/CPRA, PIPEDA and Quebec Law 25, LGPD, APPI, PDPA, DPDP, the Australian Privacy Act, UAE PDPL, KSA PDPL and POPIA, plus AI-specific frameworks including the EU AI Act, NIST AI RMF and ISO/IEC 42001, and vertical regimes such as HIPAA, PCI DSS, FedRAMP, IRAP, DORA and CJIS.
Are you certified?+
Certification programs are in progress and we publish current status and target dates rather than implying completed audits. Contractual instruments such as the DPA and BAA templates and the technical controls — residency pinning, redaction, retention, signed audit export — are usable today.
Can we self-host in our own VPC?+
Yes. The open-source router runs the same policy engine inside your account, so prompts and logs never leave your infrastructure while you keep the catalog, routing policies and audit format.
What happens when a provider changes its retention policy?+
Provider attributes are re-verified continuously and a change to retention, sub-processors or region coverage recomputes eligibility immediately. Projects whose policy no longer matches stop routing to that provider on the next request rather than at the next contract review.
Does the router see prompt content?+
It processes prompt content in memory to apply guardrails and dispatch the request, and does not persist bodies under the default zero-retention configuration. Enabling logging is an explicit per-project choice with its own retention window.
How do we prove enforcement to an auditor?+
Each response returns the policy identifier, resolved region and provider, and the guardrail actions applied. The corresponding signed audit records export as a hash-chained file, so an auditor can verify that the enforced policy matches the declared one on a per-request basis.