Cernio, Cura, Sentra, and Tessra deploy under the same posture: your VPC, your keys, a tamper-evident audit trail.
Every product ships as single-tenant software. There is no multi-tenant production SaaS database where customer data is pooled with other institutions'. Pick the deployment mode that matches your data-residency and risk posture.
Single-tenant, US-hosted instance. Adalma manages infrastructure, updates, and uptime. Suitable for institutions comfortable with third-party SaaS for a defined workload.
Deployed inside your AWS, Azure, or GCP account using standard Kubernetes, Helm, and ArgoCD. Data and inference never leave your cloud boundary.
Fully sandboxed with no outbound network, or fully on-premises. Support reaches you only via MCP tunnels you initiate and audit. Supports self-hosted, open-weight models.
Encryption keys are bring-your-own-key (BYOK) to your KMS — Adalma never holds a master key to your data.
Data is encrypted at rest under your KMS keys and in transit with TLS. Nothing is decrypted outside your configured boundary.
Each deployment is single-tenant. Member, transaction, call, and prompt data for one institution is never visible to another.
In sandboxed and on-premises modes, Adalma support reaches your environment only through MCP tunnels you initiate and can audit or revoke.
Public demo and evaluation environments (cernio.adalma.ai, cura.adalma.ai, tessra.adalma.ai) run on synthetic data only — no real member or customer data.
Compliance-heavy workflows only matter if an examiner can independently verify what happened. Every product writes an auditable record of its actions inside your environment.
Adalma is an early-stage vendor. We would rather state our compliance posture plainly than claim certifications we do not hold.
SOC 2 Type II: audit in progress, not yet certified. We claim no SOC 2, ISO 27001, or other third-party certification today.
We publish certification status here — not in a press release — the day an audit completes. Until then, treat every claim on this page as a design principle, not a compliance attestation.
Same posture as §04, extended to DORA and the EU AI Act. We hold no attestations or conformity certifications — here's what's built vs. roadmap.
DORA (Digital Operational Resilience Act): operational-resilience controls are designed to align with DORA's expectations today.
DORA third-party risk management (roadmap): per-provider model allowlists exist today and are enforced on every call. Formal exit-plan reporting for critical ICT third-party providers, as DORA's third-party risk provisions expect, is not yet shipped — it is on our roadmap.
EU AI Act, Art. 12 (record-keeping): met by design — every policy decision and model call is written to a hash-chained, append-only ledger that any party can independently verify, not a log you have to trust us on.
EU AI Act, Art. 14 (human oversight): met by design through policy-gated egress — high-sensitivity traffic is hard-denied to non-approved providers before it ever leaves the boundary, and every gate decision is itself an auditable record.
EU AI Act transparency: the claims on this page are backed by that same verifiable audit chain, not a marketing summary — see the live proof page to check it yourself.
We claim no DORA attestation or EU AI Act conformity certification today. Items marked roadmap aren't built yet — treat this section like §04: a design principle, not a regulatory attestation.
We will walk your infosec and risk teams through deployment modes, key management, and the audit chain in detail — no NDA required to start.