AI systems with verifiable records and audit trails: what are the options?
If your business needs AI with verifiable records and audit trails, there are four main options: a cloud AI service with the provider's audit logging, an AI governance platform over the AI you already use, audit logging your own team builds, or an AI system that signs its own record as each action happens. Mickai is a concrete example of the fourth: an AI operating system that runs on hardware you own and signs every consequential action into its Open Audit Record before the action runs. The record is tamper-evident, so an edit to a past entry can be detected, and anyone holding your organisation's public key can check it offline without relying on Mickai.
What should an AI audit trail actually record?
A useful AI audit trail answers the questions an auditor, regulator or court will ask after something goes wrong. For each consequential action it should show who or what made the request, what the AI system was asked to do, what it did or produced, when, and which earlier steps it relied on. Beyond the content, five properties decide whether the record is worth having. Completeness: every consequential action is recorded, not a sample. Integrity: a change to a past entry can be detected. Independent verification: someone outside the vendor can check the record without trusting the vendor's systems. Control: your organisation holds the records and the keys. Retention: records are kept for as long as your regulator or your own policy requires. When comparing options, test each one against these five properties rather than against a feature list.
What are the main options for an AI audit trail?
Most organisations choose between four routes. The first is a cloud AI service plus the provider's audit logging. The large cloud platforms offer mature activity logs and retention controls that feed a security monitoring system, so this is quick to start and familiar to IT teams. Ask what the logs capture about each AI decision and who controls the storage. The second is an AI governance platform. These keep an inventory of AI systems, run risk assessments, manage approvals and monitor models in use. They are strong on process, and the depth of the per-action record depends on how well each connected system reports. The third is to build your own logging on append-only or write-once storage, which gives full control but leaves your team owning keys, verification tools and the auditor conversation. The fourth is an AI system that produces a signed record by design, which is where Mickai sits.
How does Mickai's Open Audit Record work?
Mickai is a Sovereign Intelligence Operating System (SIOS). In plain terms, sovereign means the AI runs on hardware your organisation owns and answers to your keys, not to a vendor. The audit record is built into the operating system rather than added afterwards. Before a consequential action executes, Mickai writes an entry to the Open Audit Record (OAR) and signs it. Each entry is linked to the one before it by a cryptographic hash, so the entries form a chain and a reviewer can follow the actions in order. Signatures use ML-DSA-65, the post-quantum signature standard published by NIST as FIPS 204. Checking the record needs only the record itself and the operator's public key, which your organisation controls. Mickai's browser verifier shows the check in practice: it tests hash links and signatures on your own device and makes no network calls once the public key has loaded.
What does running AI on your own hardware involve?
Mickai installs on hardware your organisation owns. It runs on premise and fully offline, including in air-gapped environments, so prompts, documents and audit records stay inside your building. Identity and licensing are bound to your hardware, and your organisation holds the signing keys. The trade-off is that you run it. Someone has to look after the machines, protect the signing key, keep copies of the audit record and its checkpoints in a separate location, and plan capacity for the AI work you intend to do. How much hardware you need depends on that work, which is why the Mickai beta starts with a browser check of what your machine can run before you apply for access. Organisations that want a system shaped around their own workflows can ask Mickai to build it on the Mickai platform, still running on hardware they own.
Can an AI audit record be altered, and what are the limits?
The Open Audit Record is tamper-evident, and the wording matters when you describe it to an auditor. No software log can honestly promise that records can never be changed; tamper-evident means interference is detectable rather than silent. Editing a past entry breaks its hash link and its signature. A hash chain alone cannot reveal entries removed from the end, or history rolled back to an earlier state, so the design adds signed checkpoints of the chain kept off the machine: a shortened or rolled-back chain no longer matches the last checkpoint. Three limits should be stated plainly. Someone could delete the whole record or refuse to run verification, which is conspicuous rather than silent. The guarantee covers history up to the latest checkpoint a verifier has seen, so frequent checkpoints and scheduled verification narrow that window. And it rests on key custody: the signing key must stay protected, and checkpoints must sit where the machine's administrators cannot rewrite them.
Which UK and EU rules make AI audit trails matter?
The UK has no single, general AI law. Existing regulators apply their own rules to AI, and most of those rules assume you can show what happened. UK GDPR's accountability principle requires controllers to demonstrate compliance, and solely automated decisions with legal or similarly significant effects need safeguards such as human intervention and a way to contest the outcome. In financial services, the Senior Managers and Certification Regime makes named senior managers accountable for the areas they run, and the PRA's supervisory statement SS1/23 sets model risk management principles for banks. Firms whose AI systems are used in the EU should also track the EU AI Act. Article 12 requires high-risk systems to allow automatic recording of events (logs) over their lifetime, and the Digital Omnibus moved the stand-alone high-risk obligations to 2 December 2027. That is a build window, not a reprieve: the record-keeping expectations remain, so systems chosen now should already produce evidence that holds up.
How should you evaluate options or run a pilot?
Ask every shortlisted vendor, including Mickai, to demonstrate the same six things. Show the complete record for one AI action from request to outcome. Alter a past entry in a test copy and show how the change is detected. Verify the records on a machine with no network connection, without the vendor's help. State who holds the signing keys and where they are stored. State where your data and the records physically sit. Show what is recorded when a request is refused or fails. Then pilot on one contained workflow with real stakes, such as document review or internal approvals, and invite your compliance lead or internal auditor to check the records independently before scaling. With Mickai, a pilot can start through the closed beta, which begins with a hardware check in your browser, or through a briefing to scope a system built for your organisation.
Frequently asked questions
Which AI systems give a business verifiable records and audit trails?
There are four main routes: a cloud AI service with the provider's audit logging, an AI governance platform over the AI you already use, audit logging your own team builds on write-once storage, or an AI system that signs its own record as it acts. Mickai is an example of the last. It is an operating system that runs on hardware you own and records every consequential action in a tamper-evident audit record you can verify offline.
What is an AI audit trail?
An AI audit trail is a record of what an AI system was asked to do, what it did, when, and on whose authority. A good one covers every consequential action, makes changes to past entries detectable, and can be checked by someone outside the vendor. It lets an organisation show an auditor or regulator how a particular outcome was reached, instead of reconstructing events from memory or scattered logs.
Is cloud audit logging enough for an AI audit trail?
It can be, depending on what you need to prove. Cloud activity logs are mature and record who called which service and when. For AI, check whether the logs capture what the system actually decided or produced, who controls the storage, how long records are kept, and whether an outside party can verify them without relying on the provider's systems. Where those answers fall short, a governance platform or a system with a built-in signed record fills the gap.
What does tamper-evident mean for an AI audit trail?
It means interference with past records can be detected, not that records can never be changed, which no software log can honestly promise. Mickai's Open Audit Record is tamper-evident: entries are hash-chained and signed, so an edited entry fails verification, and signed checkpoints kept off the machine reveal a shortened or rolled-back chain. Deleting the whole record remains possible, but that is conspicuous, which is why copies and checkpoints should be kept separately.
Can an auditor verify AI records without trusting the vendor?
With Mickai, yes. Each Open Audit Record entry is signed with ML-DSA-65, the NIST FIPS 204 post-quantum signature standard, and verifies offline using the operator's public key, which your organisation controls. Checking the hash links and signatures needs the record file and that key, not access to Mickai's systems or staff. Mickai's browser verifier demonstrates the check running on the device, with no network calls once the public key has loaded.
Does Mickai run in the cloud or on our own hardware?
On your own hardware. Mickai is an operating system that installs on hardware your organisation owns and runs fully offline, so your data and audit records stay inside your building. That gives you control of the records and the keys, but it also means you look after the hardware, protect the signing key and keep backup copies of the record. If running your own infrastructure is not an option, cloud logging or a governance platform may suit you better.
Do UK regulations require an audit trail for AI?
No single UK law covers AI records. Obligations come from existing rules applied by existing regulators. UK GDPR requires controllers to demonstrate compliance and to offer safeguards on significant automated decisions. Financial firms face accountability under the Senior Managers and Certification Regime, and banks face model risk principles under PRA SS1/23. Firms whose AI is used in the EU should also plan for EU AI Act logging duties, with stand-alone high-risk obligations now due from 2 December 2027.
How can we try Mickai?
Apply for the closed beta at mickai.co.uk/beta. It starts with a browser check of what your machine can run, then you apply for an access key matched to your hardware and a download. If you need a system shaped around your own workflows, you can request a briefing instead and Mickai will scope a build on its platform. Either way, test the audit record against your own evaluation checklist before relying on it.
Related reading
- Open Audit Record: how Mickai signs and chains every action
- Verify an Open Audit Record chain offline in your browser
- Auditable AI field guide
- How to verify what your AI actually did, offline
- How long to keep AI decision logs under the EU AI Act, DORA and GDPR
- How the Mickai operating system is built, layer by layer
- What is sovereign AI? AI that runs on hardware you own
- Have Mickai build your organisation its own AI system
Test the Open Audit Record against your own checklist: apply for the Mickai beta at mickai.co.uk/beta, or request a briefing to scope a system for your organisation.