Trust · Data residency
AI enforcement decisions, trust scores, agent identities, and vault entries are all processed and stored in the region you configure. Jurisdictional boundaries are enforced at the infrastructure level, not by policy, by architecture.
What this means for AI enforcement
Most data residency discussions are about where files are stored. Xybern's question is different. The data we handle, enforcement decisions, policy evaluations, cryptographic proof, is regulatory evidence. It needs to be in the right jurisdiction, processed there, and auditable by regulators there.
Processing happens in region.
The verification engine that evaluates your AI actions runs in your configured region. Trust scoring, policy evaluation, claim decomposition, all in-region. The decision is made in your jurisdiction, not transferred out for processing and returned.
The vault anchors in region.
Every SHA-256 hash anchor that makes your enforcement record tamper-evident is computed and stored in your configured region. The cryptographic proof of your AI governance record is jurisdictionally bound.
Agent identities stay in region.
Cryptographic agent identity records, the profiles that tell Xybern who is acting and what they are authorised to do, are provisioned, stored and evaluated in your configured region. No cross-region identity lookups.
Region coverage
Deploy AI enforcement workloads in the region that matches your regulatory profile. Each region maps to dedicated infrastructure, dedicated compute, dedicated storage, dedicated vault anchoring, and the applicable regulatory frameworks for that jurisdiction.
Enforcement decisions, vault entries, agent identities and trust scores all processed in US data centres. GLBA, SOX, and HIPAA compliant infrastructure. No transatlantic data transfer under any circumstance.
Infrastructure
Regulatory frameworks
EU-only compute and storage. GDPR Article 44 transfer restrictions satisfied by infrastructure design, not by adequacy decision or SCCs. EU AI Act compliance built into the enforcement pipeline.
Infrastructure
Regulatory frameworks
UK-resident infrastructure with post-Brexit data sovereignty controls. SM&CR accountability records remain in UK jurisdiction, critical for financial services firms where senior manager accountability must be demonstrably UK-based.
Infrastructure
Regulatory frameworks
Data map
This is not a policy statement. This is a data map. Every type of data Xybern handles, where it is stored, where it is processed, and whether it ever crosses a regional boundary. The answer to the last column is always the same.
| Data type | Stored in | Processed in | Crosses region? | Regulatory basis |
|---|---|---|---|---|
| Enforcement decisions | Configured region | Configured region | Never | GDPR Art.44 / UK DPA s.17 |
| Agent identity records | Configured region | Configured region | Never | GDPR Art.44 / FCA accountability |
| Trust scores | Configured region | Configured region | Never | GDPR Art.44 |
| Vault entries (hash chain) | Configured region | Configured region | Never | Evidence preservation rules |
| Policy configuration | Configured region | Configured region | Never | Operator control |
| Audit exports | Configured region | Configured region | Never | Regulatory submission |
Xybern does not operate a global data lake. There is no centralised processing. Your enforcement decisions never leave your region.
Residency tagging
In Xybern, residency is a first-class field on every object. Workspaces, data sources, enforcement decisions and vault entries all carry an explicit residency tag that is checked at every operation.
Residency tagging across every object
Every workspace, enforcement decision and vault entry carries an explicit residency field that is checked at every operation.
Per workspace residency field
Every workspace is locked to a region at creation. The residency field cannot be changed after the workspace is provisioned, this prevents post-hoc jurisdiction changes.
Per source residency tag on upload
Every data source uploaded to a workspace is tagged with its residency region at ingest time. Defaults to the workspace residency if unspecified.
Residency checked at every enforcement operation
The enforcement engine checks the workspace residency before processing any action. A request routed to the wrong region returns an error, it does not silently process in the wrong jurisdiction.
Residency recorded in every vault entry
The vault entry for every enforcement decision carries an explicit residency field and an anchored_in field showing the specific infrastructure region where the hash was computed. Auditors can verify jurisdiction at the entry level.
Get started
Deploy regional data controls across your AI enforcement infrastructure with full regulatory alignment. Your enforcement decisions stay in your jurisdiction. Always.