An AI memory layer the public sector can defend.
Designed for the regulatory, custodial, and accountability obligations that distinguish public-sector AI deployment from any other use case.
Short answer: memory is encrypted under a key your agency holds, erasure destroys that key rather than deleting a row, and the resulting tombstone is anchored on a public chain — so a citizen, an auditor, or a supreme audit institution can verify an erasure happened without asking SAIHM or your AI vendor to attest to it.
Public-sector duties SAIHM is built for
- Citizen sovereignty over their data. When a citizen requests erasure, the cryptographic key is destroyed. The record cannot be reproduced afterwards by anyone, including the operator. That is what “right to be forgotten” should mean in practice.
- Cross-border control. Different ministries, different jurisdictions, different data-localization rules — all running on one public protocol with the same compliance posture, without coupling sensitive memory to any one country’s vendor.
- No vendor lock-in. Public bodies should not be hostage to a private AI supplier’s commercial fate. SAIHM is Apache 2.0 and operates on a public network. Your data and your agent identities outlive any single supplier.
- Auditable by anyone. Build artifacts are committed to a public, dated, append-only ledger. Independent technical auditors — including those reporting directly to legislatures or supreme audit institutions — can verify what is running against what is published.
- Records-management alignment. Configurable audit retention aligned to your record-management framework: from short windows for working notes to long horizons for matters of state record.
- Procurement-friendly. Open license. No proprietary backend. No mandatory cloud region. No single-supplier dependency.
Where SAIHM fits in public-sector AI
Whether your context is a regulator, a benefits agency, a health authority, a defense ministry, a court, a tax authority, or a municipal service desk — SAIHM addresses the same shared problem: AI agents that need to remember things about citizens, cases, or matters of state, but where neither the citizen nor the state can accept that memory living in a private vendor’s opaque silo.
- Memory portability across agencies — with scoped, revocable sharing.
- Sovereign audit trails the agency itself controls.
- Cryptographic erasure capability that can be put in writing in a citizen charter.
- Public-protocol commitments suitable for legislative or supreme-audit-institution oversight.
How an erasure request becomes evidence
A citizen charter that promises erasure is only as good as the agency’s ability to demonstrate it afterwards. Deleting a row produces an assurance; destroying a key produces a result anyone can check.
This diagram is CC BY 4.0 — reproduce or adapt it, commercially or otherwise, with attribution. Download the SVG; the license travels inside the file. Credit as: How an erasure request becomes independently checkable by SAIHM, CC BY 4.0.
The distinction matters in procurement. A supplier who deletes rows is asking you to trust their process. A supplier who destroys keys is leaving ciphertext that cannot be opened — a claim your own auditors can test against the anchored record without SAIHM’s cooperation.
Real-world examples
Names invented; scenarios drawn from how the protocol actually fits public-sector contexts.
- Nadia, head of digital services at a regional benefits ministry. Deploys an AI to triage citizen claims. Erasure on request is a contractual requirement under the citizen charter; SAIHM’s cryptographic erasure produces a verifiable receipt the citizen can independently check on the public chain.
- IT lead at a court system. Pilots a research AI for chambers staff. The audit trail of what the AI knew about a particular matter at a particular time must be immutable for chain-of-custody purposes; SAIHM’s dated, append-only public-chain anchors satisfy the court’s evidentiary standard.
- Ezekiel, public-sector tech lead at a regional health authority. Wants to share specific aggregate AI insights with neighboring agencies (e.g., vaccination patterns) without granting cross-agency open access to the underlying records. SAIHM’s per-record sharing with revocation gives him exactly that gating.
- An analyst-tools team at a defense ministry. Memory must be sovereign and the running build must verifiably match what was published. SAIHM’s public-chain build commitments are reproducible by the ministry’s own internal audit without depending on a private vendor’s attestation.
What SAIHM will not do
- SAIHM’s operator will not look at your data — and cannot. Memories are sealed before they reach SAIHM.
- SAIHM will not run an opaque hosted backend you cannot audit.
- SAIHM will not gate the mechanisms compliance rests on. User-held keys, cryptographic erasure, the public audit anchor and the Apache-2.0 license are identical on every tier, including free. What scales with tier is quantity — retention duration, monthly volumes, sharing allowances, and SLA — and those are stated openly on the pricing page rather than negotiated per buyer.
- SAIHM will not retain a record after a citizen has invoked erasure. The key is destroyed.
Reasons to Join SAIHM now
- The procurement bar for AI in government is rising fast: erasure, vendor neutrality, sovereignty, and auditability are increasingly contractual rather than aspirational. SAIHM ships with all four.
- Public-protocol commitments make supreme-audit-institution and parliamentary oversight feasible in a way private SaaS cannot match.
- Open standards future-proof public investment against the next AI-vendor consolidation cycle.
Standards SAIHM maps against
Each crosswalk below states, clause by clause, which SAIHM mechanism addresses a requirement and where SAIHM does not address one. They are written for the reviewer who has to fill in an assessment, not for a brochure.
- GDPR Article 17 — right to erasure, mapped to key destruction rather than record deletion. Source text: Article 17 GDPR.
- EU AI Act — record-keeping and transparency obligations for high-risk systems. Source text: Regulation (EU) 2024/1689.
- NIST AI Risk Management Framework — govern, map, measure and manage functions. Source: NIST AI RMF 1.0.
- NIST SP 800-88 Rev. 2 — media sanitization, including cryptographic erase as a recognized sanitization technique. Source: NIST SP 800-88 Rev. 2.
- NIST SP 800-66 Rev. 2 — HIPAA Security Rule implementation, for health authorities. Source: NIST SP 800-66 Rev. 2.
- ISO/IEC 27001:2022 · ISO/IEC 27018:2025 · ISO/IEC 42001:2023 — information security, public-cloud PII protection, and AI management systems.
- Model Context Protocol — how SAIHM presents to agents as standard MCP tools, so adoption does not require a bespoke integration.
A crosswalk is a mapping SAIHM publishes, not a certification. Where SAIHM has not been independently assessed against a standard, the crosswalk says so on its own page rather than implying an audit that has not happened.
Questions a public-sector reviewer asks
- Can you prove a citizen’s record was erased, without us taking your word for it?
- Yes. Erasure destroys the key for that record, and a dated tombstone is anchored on a public chain. Your own auditors read that anchor directly — SAIHM does not sit between them and the evidence, and cannot alter it after the fact. What remains in storage is ciphertext with no key in existence that opens it. NIST SP 800-88 Rev. 2 recognizes cryptographic erase as a sanitization technique.
- What happens to citizen data if the AI supplier is replaced or goes out of business?
- Nothing. Memory is held under a key your agency controls, in storage your agency nominates, and the client is Apache 2.0. Replacing the AI vendor does not migrate the memory, because the memory was never inside that vendor’s account model. This is the dependency most public-sector AI contracts fail to unwind.
- Does this satisfy our data-localization requirements?
- SAIHM does not choose where your data lives — you do. Content is encrypted before it leaves your machine, so what crosses a border is ciphertext and the party on the other side holds no key. That changes the localization question from “which region is the vendor in” to “who holds the key”, which is a question your legal team can answer without a vendor’s cooperation.
- Is SAIHM certified against the standards it lists?
- No, and the crosswalks say so. SAIHM publishes clause-level mappings showing which mechanism addresses which requirement, and where it addresses none. A published mapping is a starting point for your own assessment, not a substitute for one. Treat any supplier who conflates the two as a procurement risk.
- Is any compliance capability held back for higher-paying customers?
- No. User-held keys, cryptographic erasure, the public audit anchor and the Apache-2.0 license are identical on every tier, including free. Retention duration, monthly volumes, sharing allowances and SLA scale with tier and are published on the pricing page. If a mechanism your compliance case depends on were tier-gated, your pilot would not transfer to production — so none of them are.
- Can we share records across agencies without opening the whole store?
- Yes. Sharing is granted per record and per recipient, authenticated, with expiry and revocation. A neighboring agency or an oversight body receives exactly what you grant, and the grant can be withdrawn afterwards — which a spreadsheet sent by email cannot be.
Taxonomies and crossovers
All taxonomies and crossovers are inherited by every AI Agent to streamline AI Agentic commerce possibilities. See the Appendix — Taxonomy authorities for the official sources SAIHM maps against.
For regulatory and audit review
The Trust Center consolidates SAIHM’s security, privacy, compliance, license, and disclosure posture in one document — including how cryptographic erasure satisfies GDPR Art. 17 / CCPA right-to-delete, what the public on-chain audit trail covers, and which sub-processors the protocol depends on.
Engage
For public-sector pilots, regulatory briefings, or independent-audit access, contact ops@saihm.coti.global. For coordinated security disclosures, see /security.txt or /trust#disclosure.
Pricing for all tiers is on the pricing page.