Store the full prompt only where the record is meaningless without it. Redact or hash the rest. UK GDPR data minimisation asks whether each field is adequate, relevant and limited to your purpose, not whether logging is permitted at all. In Mickai every entry is hash-linked and anchored by signed checkpoints held off the machine, so later changes are detectable.
Does logging AI prompts breach data minimisation?
Not on its own. Article 5(1)(c) of the UK GDPR asks whether personal data is adequate, relevant and limited to what is necessary for the purpose you have documented, so the real question is never whether you are allowed to log. It is whether each field in the record is doing work for a purpose you can name out loud.
I have sat in enough of these meetings to recognise the shape of the argument. The audit side wants the whole prompt, because without it nobody can reconstruct why the system produced what it produced. The privacy side hears "keep everything a caseworker, adviser or analyst typed into a free-text box" and reaches for the brake. Both are describing a real risk. The mistake is treating the prompt as one indivisible object. It is not. A prompt is a container holding several kinds of content, and those kinds have very different evidential value and very different consequences if they leak.
Separate them and minimisation stops being a standoff. It becomes a schema decision you can write down and defend, normally inside the DPIA you should already have.
What does the ICO actually say about minimisation in AI?
The ICO's guidance on AI and data protection handles security and data minimisation together, and it does not treat minimisation as an instruction to hold as little as possible. It treats it as a requirement to hold what is necessary for a purpose you have identified, and to have considered the techniques that would let you hold less. That framing is useful, because it puts the burden on your design rather than on a yes or no answer about logging.
Two consequences follow. First, "we keep the full prompt because the vendor keeps the full prompt" is not a position. The purpose has to be yours. Second, if a technique exists that preserves the evidential value of the record while reducing the personal data inside it, you are expected to have considered it and to be able to say why you did or did not use it. The NCSC's introduction to logging for security purposes points the same way from the other side of the house: work out what questions the log has to answer before you decide what goes into it.
Which parts of a prompt belong in the audit record?
Nearly always the structural fields. Rarely the whole free-text body. In practice a prompt splits into layers, and you should be explicit about which layer you are keeping and why.
The layers that earn their place are the ones that make an entry meaningful without the text. Who initiated the action, and who approved it if it was consequential. When, to the second, and in what order relative to everything else. Which model ran, at which version, with which configuration and system instruction. What was retrieved and fed in, identified by document reference rather than by content. What the system proposed. What was actually done. Those fields answer the questions an auditor or a regulator will ask, and most of them are not the subject's personal data at all.
The layer to think hard about is the operative instruction. The layer to be most careful with is unstructured free text, which is where third-party personal data and special category data arrive without anyone having decided that they should. If the record is unintelligible without the instruction, keep the instruction. If what it needs is the narrative paragraph somebody pasted in, ask which question that paragraph answers that the structural fields do not.
When should you hash a prompt instead of storing it?
Hash when you need to prove later that a specific text was the one submitted, but you do not need to read it back. A hash held in the record binds the entry to that exact input: anyone holding a copy of the text can show that it matches, and any difference surfaces immediately.
Be honest about what that buys. If you discard the text entirely, the hash will not tell you what the instruction said. It settles disputes between parties who both hold a candidate copy, and nothing more. It is also not an anonymisation step. Where the original is recoverable or re-derivable, and short prompts drawn from a predictable set are very re-derivable, the hash is pseudonymised personal data and stays inside the regime. Salting or keying helps against guessing, but the key then becomes another thing you have to govern.
The pattern that holds up under questioning is layered. Structural fields in the record in clear. The operative instruction in the record where it is genuinely needed. Free text in a separate store with its own retention clock. A hash of that free text in the record, so the two can still be tied together years later.
How do you answer a subject access or erasure request against a log?
You answer it by having designed for it, not by searching afterwards. A log entry about an identifiable person is personal data, so it falls inside the scope of a subject access request, which means the record has to be searchable by subject and not only by time.
Erasure is where architecture decides the answer. An append-only, hash-linked record cannot have an entry cut out of the middle without breaking verification, and anyone promising otherwise has either not built one or is describing something else. The way through is to keep erasable content out of the chain in the first place. If the chain carries the structural fields and a hash of the free text, and the free text lives in a separate store, then deleting that text on request leaves the chain intact and still verifiable, with a dated gap that is itself part of the record. Article 17(3) matters here too: where you retain something because another legal obligation requires it, you say which obligation, and you log that decision like any other.
How long should prompt records be kept, and who decides?
A named person decides, per record type, and the decision is written down before the first entry exists. Storage limitation under Article 5(1)(e) is not satisfied by a platform default that nobody chose.
The inputs are mostly external. Deployers of high-risk systems under the EU AI Act must keep the logs their system generates for at least six months under Article 26(6) of the EU AI Act, where and when that regime reaches them. FCA-regulated firms sit under the SYSC record-keeping rules, which require orderly records of their business and internal organisation. Sector retention schedules, limitation periods and your own complaints window pull in the same direction. Set the clock on the structural record to the longest obligation that genuinely applies. Set a much shorter clock on the free text, because the two do not need the same lifetime, and pretending they do is how organisations end up holding years of raw text they cannot justify.
How does a signed, hash-linked record change the trade-off?
It moves integrity out of the text. In the Mickai Sovereign Intelligence Operating System, every consequential action is sealed into the Open Audit Record: entries are hash-linked in sequence and signed under ML-DSA-65, the post-quantum scheme NIST published as FIPS 204 in 2024, with signed checkpoints anchored off the machine that produced them.
That last part is load-bearing. A bare hash chain on its own proves very little against an attacker who can write to the file, because every input to the chain is available to them and they can recompute it forward. A signed checkpoint held somewhere they cannot rewrite is what turns the chain into evidence. The record is tamper-evident, not tamper-proof: nothing physically stops a determined party altering a file, but alteration makes verification fail, and that failure is exactly what an auditor is looking for. Verification runs offline against a public key, using tools that are not ours, which is the only version of this worth anything to a third party.
The effect on minimisation is direct. When the strength of the record comes from the chain, the signature and the checkpoint rather than from hoarding every character a user typed, you can keep less and still show more. It runs on hardware the customer owns, so none of it depends on shipping text offsite to a service that will tell you afterwards what it did with it. Cloud stays valuable for work that is not regulated. The argument is not with the people building compute or cloud. It is with the assumption that a regulated organisation has to rent its intelligence and take a vendor's word for the record.
Frequently asked questions
Is a prompt personal data?
Often yes. If the prompt identifies someone, or describes an identifiable person, it is personal data under Article 4 of the UK GDPR, and that includes the third parties a user mentions rather than only the user. Free text is the risky part, because special category data arrives in it without anyone deciding that it should.
Can we delete a prompt from an audit log if someone asks us to?
Not from inside an append-only, hash-linked chain: removing an entry breaks verification, which is the point of the chain. Design around it instead. Keep the erasable free text in a separate store, keep only structural fields and a hash of that text in the chain, and deletion then leaves the chain verifiable with the gap visible.
Does hashing a prompt count as anonymising it?
No. A hash is pseudonymisation, not anonymisation, wherever the original can be recovered or re-derived, and short prompts drawn from a predictable set are easy to re-derive by brute force. Pseudonymised data remains personal data under the UK GDPR. Salting or keying raises the cost of guessing, but the key then needs governing.
Do we need a DPIA before we start logging AI prompts?
Usually yes. Logging AI prompts at scale involves new technology and often systematic monitoring, both of which sit among the ICO's triggers for a DPIA under Article 35. Do it before you switch logging on, not after, because the DPIA is where you record which fields you keep, why, for how long, and what you rejected.
Should the audit log sit inside the AI system or outside it?
Outside it, or at least outside anything the AI system itself can rewrite. A record that the system under scrutiny can edit is not evidence about that system. In Mickai the Open Audit Record is sealed at the point of the action and anchored by signed checkpoints held off the machine, so verification is independent of what is being audited.
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
- Generative AI Logging Checklist: What UK Firms Record
- 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)