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.
The EU AI Act asks a high-risk deployer to evidence exactly how an AI system behaves, and that is impossible when the weights, the run logs and the training-data lineage sit on infrastructure you neither own nor can audit. Article 9 demands a documented risk-management system across the lifecycle; Article 10 sets data-governance duties over training, validation and testing data; Article 12 requires automatic logging of events over the system's operation; Article 13 demands transparency and interpretable output for deployers; Article 14 requires effective human oversight; and Article 72 imposes post-market monitoring. A shared cloud model cannot give a deployer the logs, the lineage or the model-version control needed to satisfy any of these, and it exposes personal and special-category data to a processor in the process. Mickai keeps the model, the data governance and the full decision record on hardware the organisation owns, so every inference is logged automatically to a sealed, tamper-evident Open Audit Record with the features and the model version that produced it. Human-in-the-loop gates are enforced before any action class your governance defines, and the whole system can be inspected, replayed and evidenced to a regulator without a vendor in the loop.
The 6 obligations this framework imposes, each met by construction on hardware you own and mapped to the subsystem that enforces it.
Risk Management System
Mickai supports the Article 9 duty to operate a documented risk-management system by keeping every model, evaluation and mitigation on hardware you own, so risks are identified, tested and controlled locally across the lifecycle. The evaluations and their outcomes are sealed to the Open Audit Record, giving a continuous, reproducible evidence base rather than a vendor's assurance. Model changes and their risk assessments are versioned and attributable. The whole process stays under your governance and never depends on an external service.
Data Governance and Training Lineage
The Article 10 data-governance duties over training, validation and testing data are met by keeping that data and its lineage on hardware you own, so provenance, representativeness and bias examination are documented and controlled locally. Because Mickai runs its own specialised sovereign models inside your perimeter, the datasets are never exposed to a shared platform and the lineage is sealed to the audit record. Data-governance decisions are attributable and reproducible. Nothing about the data pipeline depends on a third party.
Automatic Event Logging
Article 12 requires high-risk systems to log events automatically over their operation, and Mickai meets this by sealing every inference and action to a post-quantum Open Audit Record with the inputs, features, model version and timestamp. The trail is tamper-evident, reproducible and held on hardware you own, so it survives independent scrutiny without vendor cooperation. Logging is a by-product of the work rather than a bolt-on. The record is complete and available for the system's full lifetime.
Transparency and Explainability to Deployers
Mickai satisfies the Article 13 transparency duty by recording the features and reasoning behind each high-risk decision and presenting interpretable output to the deployer, all sealed to the audit record. A deployer can understand and evidence how the system reached a given result rather than accepting an opaque cloud output. The explanation is reproducible for an affected person or a regulator. Transparency is built into every inference rather than approximated afterwards.
Human Oversight and Intervention
Article 14 requires effective human oversight, and Mickai enforces human-in-the-loop gates before any action class your governance defines, with the ability to review, override or halt a decision. Sensitive actions can require a fresh operator authorisation, and every intervention is sealed to the audit record. Oversight is enforced by the system before execution rather than reconstructed after the fact. The human remains genuinely in control of the high-risk decision.
Post-Market Monitoring and Incident Traceability
Mickai supports the Article 72 post-market monitoring duty by continuously recording deployed behaviour to the Open Audit Record, so drift, anomalies and incidents can be detected and investigated locally. Because the trail is a causally linked, reproducible record, any incident can be traced back to the originating inputs, model version and operator. Monitoring evidence stays on hardware you own and never depends on a vendor. Serious-incident reporting is backed by a complete, tamper-evident lineage.
The advantages hold across every framework, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
How does an on-premise AI operating system satisfy the EU AI Act?
Mickai runs high-risk AI systems on hardware you own, fully offline, so the models, the data governance and the full decision record stay inside your perimeter and under your control. Every inference is sealed to a post-quantum Open Audit Record with its inputs, features and model version, which evidences the Act's duties for risk management, data governance, logging, transparency, human oversight and post-market monitoring. The obligations are met by construction rather than assumed of a black-box cloud model.
Can a deployer evidence Article 12 logging with Mickai?
Yes. Every inference and action is logged automatically to a tamper-evident Open Audit Record with the inputs, features, model version and timestamp, which meets the Article 12 automatic-logging requirement as a by-product of the work. The trail is held on hardware you own, so it survives independent scrutiny without vendor cooperation and is available for the system's full lifetime.
How is human oversight enforced under Article 14?
Mickai enforces human-in-the-loop gates before any action class your governance defines, with the ability to review, override or halt a decision, and sensitive actions can require a fresh operator authorisation. Every intervention is sealed to the audit record. Oversight is enforced by the system before execution rather than reconstructed afterwards, so the human remains genuinely in control of the high-risk decision.
Does Mickai expose our data or models to a shared platform?
No. Mickai runs its own specialised sovereign models inside your perimeter, so training, validation and test data and the model weights are never exposed to a shared platform, and the full data lineage is sealed to the audit record. This meets the Article 10 data-governance duties locally, with provenance and bias examination documented and attributable. Nothing about the data pipeline depends on a third party.
How does Mickai support post-market monitoring under Article 72?
Mickai continuously records deployed behaviour to the Open Audit Record, so drift, anomalies and incidents can be detected and investigated locally, and any incident can be traced back to the originating inputs, model version and operator. Monitoring evidence stays on hardware you own and never depends on a vendor. Serious-incident reporting is backed by a complete, tamper-evident lineage.
Is Mickai a competitor to cloud AI for regulated systems?
No. The public cloud remains valuable for non-regulated work. Mickai is the answer specifically for high-risk, regulated AI where the deployer must evidence exactly how the system behaves, which a shared cloud model cannot support. The distinction is architectural, and the capability is built on 104 filed UK patent applications covering approximately 2,340 claims, owned by Mickai LTD.
Bring EU AI Act in-house.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and we will walk the obligations, the regulatory crosswalk and the deployment that fits.