Guidance
How to verify an AI supplier's audit log yourself, offline
Most vendors say their AI is auditable. Fewer can answer the actual question: can you check the record is genuine without them, without the internet, and without trusting their word for it?
The short answer
An AI audit record is only as trustworthy as your ability to check it without the vendor's help. The questions that separate a genuinely verifiable record from a marketing claim: is each entry independently timestamped, using a standard like RFC 3161 or a public timestamp anchor, rather than a date the vendor's own database could quietly edit? Who holds the signing key, the vendor or you, and can the vendor still produce a valid-looking record if your organisation and the vendor ever part ways? Is a person's approval bound to the exact action taken, so a record cannot be replayed against a different one, and does the system technically refuse to execute an unapproved action rather than merely logging that it should have been blocked? Is there a published specification of the record format and signature scheme, so a verifier can check it with independent tools, not the vendor's own app? If a vendor cannot answer these plainly, an audit trail claim is a feature description, not evidence.
Almost every AI vendor now says something about auditability. Far fewer can answer a narrower, more useful question: if you took the record away from their platform entirely, with no internet connection and no cooperation from them, could you still confirm it is genuine? This is a deeper look at one question from Unified's broader sovereign AI vendor checklist, worth its own explanation given how easy the answer is to fake with reassurance rather than mechanism.
That question separates a real audit trail from a log file with a reassuring name. Here is what to actually ask.
Is each entry independently timestamped?
A timestamp a vendor's own system writes into its own database proves nothing on its own: the same system that wrote the record could, in principle, rewrite it. Independent timestamping means the time is attested by something outside the vendor's control, RFC 3161, the Internet X.509 Public Key Infrastructure Time-Stamp Protocol, is the established standard for this, or an anchor into a public, append-only source that predates and postdates the record. Ask specifically which mechanism is used, and whether it was in place from the record's creation or added later as a claim rather than a built feature.
Who holds the signing key?
A cryptographic signature proves a record has not been altered since signing. It does not prove the record was honest at the moment of signing, and it offers no protection at all if the party who might want to misrepresent an event also controls the key used to sign the record of it. Ask plainly: does the vendor hold the only key, does the customer hold their own key, or does the scheme require both parties for a valid signature? A vendor who cannot answer this specifically, or who treats the question as unusual, has not thought about the failure case where the vendor's own honesty is what is in question.
A record only the vendor can produce and only the vendor can verify is a vendor's word, formatted to look like evidence.
The "can the vendor disappear" test
Ask what happens to the verifiability of past records if the vendor stops trading, revokes your access, or simply refuses to help with an audit. If verification depends on logging into the vendor's own platform, calling their support line, or trusting a database only they can query, the audit trail does not survive the relationship ending. A record that can be verified with a published specification and standard, widely available cryptographic tools, entirely offline, survives it. This is not a hypothetical: vendors are acquired, discontinued, or simply become unresponsive, and a genuine audit requirement usually spans longer than any single vendor relationship.
Is approval bound to the exact action, and enforced, not just logged?
Two separate questions hide inside "does a person approve consequential actions." First, is the approval cryptographically bound to the specific action, so a record of "approved" cannot be replayed or reattached to a different, unapproved action later? Second, does the system technically refuse to execute an action without that approval, or does it merely log a note that approval should have happened first? A system that can execute first and log second has a logging feature, not an approval gate. Ask for the specific mechanism that makes an unapproved action fail to execute, not just fail to be recorded as approved.
Is there a published specification, and has anyone tried to break it?
A record format and signature scheme that only the vendor's own tooling can read is not independently verifiable in any meaningful sense, whatever the marketing claims. Ask for a published specification: the record fields, the signature algorithm, and how a third party would verify a record using tools that are not the vendor's own. Ask, too, whether the scheme has been tested against a deliberately tampered or stripped-down record, not just demonstrated on a clean example. A vendor confident in the mechanism should be able to show a forged or altered record failing verification, not only a genuine one passing.
What algorithm migration looks like
Cryptographic standards move. A scheme that is sound today can be weakened by future advances, most concretely by progress in quantum computing against widely deployed signature algorithms. Ask whether the vendor uses a post-quantum signature standard already, such as ML-DSA under FIPS 204, or has a stated plan for migrating existing records if the underlying algorithm needs to change. A vendor with no answer to this has not planned past the current year's threat model.
Putting the checklist together
None of these questions requires specialist cryptographic knowledge to ask, only the discipline to ask them before signing a contract rather than after an incident makes the answer matter. A vendor confident in its own audit claims will answer each one specifically. A vendor that responds with reassurance rather than mechanism is telling you something too.
Questions readers ask
- What does independent timestamping actually protect against?
- A record dated only by the vendor's own database is only as trustworthy as the vendor's willingness and ability to keep that database unaltered. RFC 3161, the Internet X.509 Public Key Infrastructure Time-Stamp Protocol, or an anchor to a public, append-only source, lets a third party confirm when a record was created without relying on the vendor's internal clock or database integrity.
- Why does it matter who holds the signing key?
- A signature proves a record has not been altered since it was signed, but only if the key used to sign it was not accessible to whoever might want to alter the record. If the vendor holds the only key, the vendor can, in principle, produce a validly-signed record for something that did not happen as described. A customer-held key, or a scheme where the vendor cannot sign alone, closes that gap.
- What is the 'can the vendor disappear' test?
- It asks whether a record remains verifiable if the vendor stops trading, revokes access, or simply refuses to cooperate with an audit. A record that depends on the vendor's own servers, app or ongoing goodwill to verify fails this test. A record verifiable with a published specification and standard cryptographic tools, entirely offline, passes it.
Published by Mickai LTD. Written by Micky Irons.
Unified covers the field broadly and treats Mickai as one example within it. About the journal and the team.
Mickarle Wagstaff-Irons - Micky Irons, full name Mickarle Sean Junior Wagstaff-Irons. Founder and CEO of Mickai. Biography and related work.