Log nine things for every generative AI action: who asked, what they asked, which documents were used, what the system did, which model version answered, who approved it, when, from which device, and the outcome. Mickai seals each consequential action into the Open Audit Record before it runs, so the record is made by the system, not added afterwards.
What should a generative AI log capture for every action?
Nine fields, all nine joined to a single record. Anything less leaves fragments that nobody can reconstruct a year later.
Who asked. A named person, not a service account or a shared key. If the log says ai-service-prod, you have recorded your infrastructure, not your staff.
What they asked. The request as submitted, including the system instruction in force and any parameter the user changed.
Which documents were used. Identifiers and versions of everything retrieved, not the text itself.
What the system did. Not only the words returned. Every tool called, file written, record updated, message drafted.
Which model version answered. A specific version identifier plus the configuration in force at the time. The same request against a different version is a different event.
Who approved it. For anything consequential: the named approver, what was shown to them at the point of decision, and what they decided.
When. Separate timestamps for request, approval and execution. The gap between approval and execution is where the interesting failures live.
From which device. Host, session and network origin.
The outcome. What was returned, what happened downstream, and any error or refusal.
Why is an ordinary application log not enough for AI?
An application log records that a request happened. For AI you also need what governed the answer, because the same question asked twice will not reliably produce the same answer. Without the retrieved context, the version identifier and the configuration you cannot reproduce the output, so you cannot explain it. You are left asserting that the system behaved, which is not evidence.
The second problem is integrity. Most application logs are written by the same platform whose behaviour is under question, kept in a store an administrator can edit, and rotated out within days or weeks. A record that the subject of an investigation can quietly amend carries no weight in one.
The language matters here. Nothing is tamper-proof. A determined administrator with physical access can destroy any record. What a record can be is tamper-evident: each entry is cryptographically sealed at the moment it is made, so any later edit, reordering or deletion breaks verification and surfaces as a failure instead of passing silently. Tamper-proof claims prevention, which nobody can honestly offer. Tamper-evident claims detection, which is what an auditor needs and what can be demonstrated.
Which fields does an auditor actually ask for?
Auditors rarely ask for a field list. They pick one output and walk backwards from it. Who asked for this. What did the system read. Who approved it. When. Has any of it changed since.
So the field that matters most is the one nobody puts on a checklist: a single correlation identifier tying request, retrieval, approval, execution and outcome into one chain. Nine fields spread across five systems with no shared key is a reconciliation project, and that is where records get quietly rebuilt from memory.
Two practical tests. First, can you export the chain for one action as a self-contained file, with no live connection to the vendor. Second, can the recipient verify that file offline, with a public key, using tools you did not write. If verification depends on your own console telling the auditor everything is fine, you have a dashboard, not a record. That is the difference between a log and an AI audit trail.
Should you log the documents an answer was drawn from?
Yes, but log references, not copies. Store the document identifier, its version, a cryptographic hash of the exact content read, the section or page range retrieved, and the ranking value if retrieval used one.
Copying source text duplicates whatever personal or confidential data it held into a store you must now retain, secure and eventually delete. The hash does that work instead. It proves the document read then is the document you hold now, and shows immediately if the source has changed. That is usually the real question in dispute. Answers rarely go wrong at random. They go wrong because the system read the superseded version of a policy.
One caveat, since most document estates are partly scanned. A local optical character recognition runtime has read scanned PDFs in our controlled tests, but extraction and ingestion integration inside the operating system is still being completed. Treat scanned intake as work in progress.
How long should generative AI logs be kept?
For deployers of high-risk systems the EU AI Act sets a floor. Article 26(6) requires deployers to keep the logs a high-risk system generates automatically, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise, in particular data protection law.
Six months is a floor, not a target. In practice set it to the longest of three: the statutory retention on the business record the AI action touched, the limitation period for any claim arising from it, and your own window for detecting a problem after the fact. For most regulated processes that lands well beyond six months.
UK law sets no equivalent figure. Under UK GDPR you choose a period, document why, and defend it. That pushes most organisations towards two-tier retention: keep the sealed metadata record for the long period, and keep the payload (prompt text and returned output) for a shorter one. Because the integrity proof is built on hashes, deleting a payload does not invalidate the chain. You can still show an action occurred, who approved it, and that the record is unaltered, long after the content has gone. The ICO guidance on AI and data protection covers the data protection side, and our note on how long to keep AI decision logs has more.
Who should be able to read, and who should never be able to change, the log?
Nobody changes it. Not the platform administrator, not the compliance team, not the vendor, and in our case not us. The store is append-only. Corrections are new entries referencing the original, never edits in place.
Reading needs tiers. Audit and compliance read broadly, including payloads, under logged access. Line managers read their own area. Engineers get operational visibility with payloads redacted. Every read is itself an event in the record.
The separation that matters most: whoever can approve a consequential action must not be able to alter the record of having approved it. Get that one wrong and every other control is decorative. The NCSC's guidance on secure operation and maintenance of AI systems covers the monitoring and logging side of this well.
What does EU AI Act Article 12 expect of the record?
Article 12 puts the duty on the system, not on a policy document. High-risk AI systems must technically allow the automatic recording of events across their lifetime, and that capability has to support identifying situations where the system may present a risk, plus post-market monitoring.
The design implication is plain. Recording has to be a property of the system, produced automatically as it runs, not a reporting exercise assembled afterwards by people who were not there. A log compiled at quarter end is not what the Article describes, however tidy it looks. Fuller walkthrough: Article 12 record-keeping.
Most internal generative AI use is not high-risk, so the Article does not bind it directly. I would still use it as the template. It is the most specific published statement of what a regulator expects an AI record to contain, and building to the stricter standard now costs less than retrofitting it later.
How does Mickai record AI actions on hardware you own?
The Mickai Sovereign Intelligence Operating System runs on hardware the customer owns. It is offline capable, and no data leaves the estate. This is not an argument against the companies building the compute and cloud layers. Cloud remains the right answer for a great deal of non-regulated work. The assumption I disagree with is that a regulated organisation must rent its intelligence, ship its data offsite, then take a vendor's word for what happened to it.
The Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The order matters. The entry is sealed and persisted before the action executes, so the record is a precondition of doing the work rather than a report about it. Consequential actions then wait for a named person to approve them, and that approval is part of the same sealed chain. An auditor exports a record and verifies it offline with a public key, using tools that are not ours. That is what sovereign AI means in practice.
Mickai LTD is a UK company, Companies House 17166618, holding 104 filed UK patent applications carrying 2,340 claims. The platform spans 63 studios, 14 production-ready at launch and 49 in development, with 50 specialised models. A closed beta is open, with one regulated company onboarding as a design partner. If the record-keeping question is still unresolved in your rollout, settle it before the first incident.
Frequently asked questions
Do we need to log every prompt, or only the ones that lead to an action?
Only the ones that lead to an action, as a minimum. Log every action the system takes and the request that produced it. Purely informational questions can be logged as metadata without payloads if you want to limit personal data. Anything that writes, sends, files or decides needs the full nine fields and a named approver.
Is our existing application or cloud activity log enough for AI?
Almost never. Application logs show that a call happened, not what shaped the answer. They usually omit the retrieved sources, the model version and the approval, and they sit in a mutable store the platform team controls. You need the inputs that governed the output and an integrity seal that makes later edits visible.
How long must we keep AI logs under the EU AI Act?
Deployers of high-risk AI systems must keep automatically generated logs, where those logs are under their control, for a period appropriate to the intended purpose and at least six months, under Article 26(6). That is a minimum. Match the longer of your sector retention rules and the limitation period for a claim.
Can I log AI use without collecting extra personal data?
Yes, largely. Log references rather than content: document identifiers and hashes instead of source text, and user identifiers resolved through your existing directory rather than copied profile data. Keep sealed metadata for the long retention period and payloads for a short one. That satisfies data minimisation while keeping the chain verifiable.
Should the AI log be owned by IT or by compliance?
Compliance owns the requirement and the retention period. IT owns the pipeline and the access tiers. Neither should be able to change entries. If one team owns both the approval right and the ability to edit the record, the separation of duties has gone, and that is the first thing an auditor tests.
Related briefings
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
- AI Audit Logs vs Data Minimisation: Keep Full Prompts?
- AI Incident Response Plan Checklist for UK Organisations
- Keeping Oversight as AI Scales Across a Business
Deploying private AI
- Private AI for Business: What It Is and How It Works
- Offline AI Assistant: What It Can Do for Your Staff
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)