Justice in marble holding gold scales against the void, the balance a sovereign, sealed AI substrate delivers to a regulator

Compliance by architecture

Compliance by architecture, not by policy.

10 regulatory frameworks, 61 specific obligations, met by construction inside the Mickai Sovereign Intelligence Operating System. The system runs offline on hardware you own, so regulated data physically cannot leave the building, and every action is sealed to a post-quantum Open Audit Record you can hand a regulator. The controller boundary is enforced by physics.

Frameworks mapped

Obligations met

Data egress

104

Filed UK patents

The frameworks

Data protection satisfied by architecture

UK and EU GDPR

The UK GDPR and the EU GDPR govern how personal data is processed, stored, transferred and audited, and they place the heaviest burden on organisations that hand personal data to a third party. Mickai removes the third party entirely: every record is processed by the sovereign brains on hardware you own, fully offline, so your organisation stays the sole controller and there is no processor in the chain. Because the data physically cannot leave the building, the obligations that a shared cloud strains to meet, data residency, minimisation, the right to erasure and a complete record of processing, are enforced by construction and sealed to a post-quantum Open Audit Record.

7 obligationsSee how Mickai meets UK and EU GDPR →

Protected health information that never leaves the building

HIPAA

The US HIPAA Privacy, Security and Breach Notification Rules govern how protected health information is used, disclosed, safeguarded and audited by covered entities and their business associates. Mickai runs the entire clinical and administrative workload on hardware the organisation owns, fully offline, so protected health information is never disclosed to a cloud AI service and there is no business associate to contract with. Because the data physically cannot leave the building, the technical safeguards, access control, audit controls, integrity and transmission security, are enforced by architecture, and every access is sealed to a post-quantum Open Audit Record a regulator can inspect.

6 obligationsSee how Mickai meets HIPAA →

High-risk AI governance evidenced on demand

EU AI Act

The EU AI Act imposes a risk-tiered set of duties on the providers and deployers of AI systems, with the heaviest obligations falling on high-risk systems used in areas such as employment, credit, insurance, essential services and law enforcement. Mickai runs those systems on hardware you own, fully offline, so the models, the training data governance and the decision record all stay inside your perimeter and remain fully under your control. Because every inference is sealed to a post-quantum Open Audit Record with its inputs, features and model version, the Act's demands for risk management, data governance, logging, transparency, human oversight and post-market monitoring are evidenced by construction rather than assumed of a black-box cloud model.

6 obligationsSee how Mickai meets EU AI Act →

Operational resilience without a critical cloud dependency

DORA

The Digital Operational Resilience Act holds financial entities in the EU accountable for the resilience, oversight and concentration risk of every information and communications technology system that supports their business, including third-party AI services. Mickai removes the critical third-party dependency at source: the sovereign brains run on hardware the firm owns, fully offline, so there is no cloud AI provider to designate, monitor, contract around or exit. Because the system, the data and the audit record all sit inside the firm's own perimeter, DORA's demands for ICT risk management, incident reporting, resilience testing and third-party oversight are satisfied by architecture and evidenced through a post-quantum Open Audit Record.

6 obligationsSee how Mickai meets DORA →

Network and information security on owned infrastructure

NIS2

The NIS2 Directive raises the cybersecurity and incident-reporting obligations on essential and important entities across the EU, and it makes senior management directly accountable for the security of the systems the organisation relies on, including its supply chain. Mickai reduces the attack surface at source: the sovereign brains run on hardware the organisation owns, fully offline, so there is no cloud AI service to secure, no data egress path to defend and no additional supply-chain link to assess. Because the system, the data and the audit record sit inside the organisation's own perimeter, NIS2's demands for risk management, supply-chain security, incident handling and reporting are satisfied by architecture and evidenced through a post-quantum Open Audit Record.

6 obligationsSee how Mickai meets NIS2 →

Cardholder data that stays out of scope by design

PCI-DSS

The Payment Card Industry Data Security Standard governs how cardholder data is stored, processed and transmitted, and it makes the size of the audited environment a direct function of where that data can flow. Mickai keeps cardholder data on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and never enters a shared, multi-tenant environment. Because the data physically cannot leave the building, the standard's demands for access control, protecting stored data, restricting transmission and logging every access are enforced by architecture, and every touch of cardholder data is sealed to a post-quantum Open Audit Record.

6 obligationsSee how Mickai meets PCI-DSS →

Every model inventoried, validated and explainable on demand

Model Risk (SR 11-7 and PRA SS1/23)

The US Federal Reserve SR 11-7 guidance and the UK PRA SS1/23 supervisory statement set the expectations for model risk management in regulated financial firms: every model must be inventoried, developed and documented soundly, independently validated, governed with clear ownership and remain explainable on demand. Mickai keeps the models, the run logs and the decision lineage on hardware the firm owns, fully offline, so validation and governance are conducted against systems the firm controls end to end rather than a vendor black box. Because every inference is sealed to a post-quantum Open Audit Record with its inputs, features and model version, the firm can evidence exactly how a model reached a figure, which is the core of both frameworks.

6 obligationsSee how Mickai meets Model Risk (SR 11-7 and PRA SS1/23) →

Controlled technical data that never crosses a border

ITAR and Export Control

The US ITAR and EAR regimes, alongside UK and EU export-control law, restrict who may access controlled technical data and where it may travel, and they treat exposure of that data to a foreign person or a foreign server as an export in itself. Mickai keeps controlled technical data on hardware the organisation owns, fully offline and air-gapped, so it is never transmitted to a cloud AI service, never stored on a foreign server and never exposed to an unauthorised person. Because the data physically cannot leave the building, the core export-control obligations, no unauthorised export, access limited to authorised persons and a complete record of who accessed what, are enforced by architecture and sealed to a post-quantum Open Audit Record.

6 obligationsSee how Mickai meets ITAR and Export Control →

Controlled unclassified information secured on owned hardware

CMMC

The US Cybersecurity Maturity Model Certification programme requires defence contractors to protect controlled unclassified information against a defined set of security practices before they can win and keep defence work. Mickai keeps controlled unclassified information on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and the assessed boundary contracts to systems the organisation controls end to end. Because the data physically cannot leave the building, the practices that CMMC assesses, access control, audit and accountability, system and communications protection and incident response, are enforced by architecture and evidenced through a post-quantum Open Audit Record.

6 obligationsSee how Mickai meets CMMC →

NHS data security standards met on owned hardware

NHS DSP Toolkit

The NHS Data Security and Protection Toolkit requires every organisation that handles NHS patient data to evidence, each year, that it meets the National Data Guardian standards for data security and protection. Mickai keeps NHS patient data on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and remains inside the organisation's own perimeter as sole controller. Because the data physically cannot leave the building, the toolkit's expectations around personal-data handling, access control, audit trails, secure configuration and incident response are enforced by architecture and evidenced through a post-quantum Open Audit Record that maps directly to the standards.

6 obligationsSee how Mickai meets NHS DSP Toolkit →

Questions

How does Mickai make a regulated organisation compliant?

Mickai enforces compliance by architecture rather than by policy. The Sovereign Intelligence Operating System runs entirely on hardware the organisation owns, fully offline, so regulated data physically cannot leave the building and no third-party processor enters the chain. Every action is sealed to a post-quantum Open Audit Record, giving a tamper-evident evidence trail an auditor or regulator can verify. The controller boundary is held by physics, not by a data-processing agreement.

Which regulatory frameworks does Mickai address?

Mickai maps to 10 major frameworks across 61 specific obligations, including UK and EU GDPR, HIPAA, the EU AI Act, DORA, NIS2, PCI-DSS, model-risk supervision (SR 11-7 and PRA SS1/23), ITAR and export control, CMMC and the NHS DSP Toolkit. Each obligation is met by the same owned, offline, sealed substrate rather than a per-framework bolt-on.

Does on-premise AI remove the cloud-transfer problem entirely?

Yes. Because inference runs on the customer's own hardware with zero data egress, the cross-border transfer, sub-processor and CLOUD Act exposures that make regulated data hard to place in public-cloud AI do not arise. There is no egress event for a regulator to question, and the audit record proves it.

The controls beneath it

Security architecture →

Assurance status

What is verifiable today, stated plainly.

Mickai does not yet hold third-party certifications such as ISO 27001, ISO 42001, SOC 2 or Cyber Essentials Plus, and this page claims none. Formal certification is on the company roadmap. Assurance today rests on what you can verify yourself: the browser-based offline audit verifier proves any Open Audit Record chain with the operator public key alone, the signing is standard FIPS 204 ML-DSA-65, and the architecture can be inspected running on your own hardware in a briefing.

Mickai provides the architecture and the evidence trail. Compliance determinations for your organisation remain with your firm, its compliance function and its advisers; the mappings on this page describe how the architecture supports those determinations, not a legal conclusion made on your behalf.

For investors and evaluators

Compliance an auditor can verify, and a market worth backing.

The same owned, sealed substrate that supports these frameworks is the moat. When you want the market sizing, the model and a working demonstration, request a briefing or read the investor case.

See the investor briefing