Compliance
Compliance by design, not by paperwork
Governance is enforced at the storage layer on every request, by policy, with a signed record. The controls regulators and security reviewers ask about are how IronShard works, not a layer added on top. This page describes what those controls are and what they give you as evidence.
The controls
Access is scoped and enforced per agent. Every agent and user gets its own credentials, scoped per bucket, prefix, or key, with optional IP and time-window restrictions. Every request is policy-checked at the storage layer before data is served, and denials are recorded alongside approvals.
Every action is on record, signed. Reads, writes, merges, and policy decisions land in an immutable, cryptographically signed audit log. Records cannot be edited, deleted, or backdated. The log is searchable and exportable, and agents can query it over MCP. See Log
Lineage and reproducibility are automatic. Snapshots and branches record which data state each run used. Which dataset trained which model, and what a given run read and wrote, is answerable from the record rather than reconstructed afterward. See Branch
Production is isolated from experimentation. Agents work on a live, isolated copy of production and branch it per task. Nothing reaches production without passing review, whether that review is a policy check or a human sign-off. See Mirror
Data is fragmented, encrypted, and distributed. Every file is encrypted before it leaves your environment, erasure-coded into fragments, and distributed across multiple storage providers and regions. No single provider ever holds a complete file; each sees only encrypted fragments that are meaningless on their own. Reconstruction happens only for authorized requests, and every reconstruction is logged.
Residency is yours to set. Data is pinned to the jurisdictions you choose. Because providers hold only encrypted fragments, the compliance posture of any single provider or region does not determine yours, and multi-cloud, hybrid, and cross-border setups stay within the residency boundaries you define.
GDPR everywhere
Traditional storage ties GDPR compliance to physical location: personal data is protected because of where the bucket lives. IronShard inverts that. Protection comes from how data is stored, not where.
Every object is encrypted, erasure-coded into fragments, and dispersed across multiple providers and regions. Each provider holds a small, encrypted piece, never a complete file, and on its own that piece reveals nothing and cannot be reconstructed or interpreted. Storage providers are passive fragment hosts: they never participate in reassembly, governance, or inspection. Only IronShard's intelligence layer coordinates access decisions, policy enforcement, and fragment retrieval, and it reconstructs data only for authorized requests inside the governed environment.
The consequences for GDPR-regulated data:
- No individual provider can rebuild a file, even with full access to its own infrastructure.
- No single region or cloud ever sees raw personal data, which removes accidental residency violations.
- Compliance does not depend on where the underlying buckets live; IronShard enforces protection independently of the storage beneath it.
- Personal data can span multi-cloud, hybrid, and cross-border architectures without exposing file contents or breaching local restrictions.
Combined with encryption at rest, in transit, and during processing, jurisdiction pinning, scoped access, and a complete access record, this is a privacy model that travels with the data. Full architecture in GDPR Everywhere.
How this maps to regulation
IronShard does not certify your workloads, and no storage layer can. What it does is make the controls above defaults, so the evidence a framework asks for already exists.
- GDPR: the provider-independent privacy model above, plus encryption everywhere, residency controls, scoped access, and a complete access record.
- EU AI Act: documented data lineage, reproducibility, and immutable audit trails for training and inference data, the record the Act's transparency and accountability requirements depend on.
- Sector frameworks (HIPAA, GLBA, PCI-DSS, ISO 27001, SOC 2): IronShard is engineered to meet the storage-layer requirements these frameworks share: encryption, least-privilege access, tamper-evident logging, and residency. Underlying storage providers operate data centers certified to ISO 27001, SOC 2, and PCI-DSS; certifications on your own workloads remain your responsibility, and IronShard's evidence is built to support them.
FAQ
Is IronShard GDPR-compliant? IronShard is engineered to meet GDPR's requirements at the storage layer: encryption everywhere, jurisdiction pinning, scoped access, and a full access record. Compliance is a property of your processing, not of any single vendor; IronShard's role is to make sure the storage-side controls and evidence are already in place.
How does IronShard support EU AI Act obligations? Through automatic lineage and audit. Every dataset state, training run, and inference read is recorded and signed, so the questions the Act asks (which data did this model use, who accessed it, and can the result be reproduced) are answerable from the log.
Can healthcare and finance teams run AI agents on IronShard? Yes. Agents work on isolated branches of real data with per-agent scoping, and every access is logged immutably. IronShard is engineered to meet the storage requirements of HIPAA, GLBA, and PCI-DSS; the Enterprise page covers how these deployments are structured.
Where does my data physically live? Where you pin it. Data is fragmented and distributed across the providers and regions you choose, and it stays within those boundaries. No single provider holds a complete file.
Why does data lineage matter for compliance? Without versioning and lineage, you cannot prove which datasets trained which model, reproduce a result, or explain an output. IronShard captures dataset state and access history automatically, so lineage is a record you export rather than a document you assemble.
