AI Audit Log Design Guide: The AI Usage Evidence Required by the EU AI Act, ISO/IEC 42001 and Japan's AI Guidelines, and How to Keep It

Using generative AI internally, building AI features into a product, handing work to AI agents: whichever way you use it, you will soon be asked to explain who is using that AI, for what, and how it is controlled. The person asking may be an auditor, or it may be a customer's security questionnaire.

At that point, verbal explanations and policy documents are not enough. The question is whether you can show it with records. This article walks through what regulations and standards require, what to record, where to record it, and what conditions make the records hold up as evidence, so that you can keep generative AI audit logs in a form that works as evidence.

What is a generative AI audit log?

A generative AI audit log records, for each AI run, when it happened, who (or which agent) ran it, which model was used and what decision was made, kept in a form that a third party can check later.

Its purpose differs from that of everyday operation logs or application logs.

The biggest difference is that the readers are outsiders. If you cannot show an outsider that the log has not been altered after the fact, it remains weak as evidence no matter how detailed it is.

Why "AI evidence" is being asked for now

There are three main reasons:

• Customer security reviews: questionnaires increasingly ask about generative AI use, including scope of use, what data is entered, and how logs are retained
• SOC 2 Type II and ISMS (ISO/IEC 27001) audits: you must show that controls operated throughout the observation period, and AI use is part of what you are asked to explain
• The spread of AI agents: AI increasingly works autonomously in place of people, so you need records that can trace "who did it" down to the individual AI

Quick reference: what regulations and standards require for records

The following was confirmed in primary sources as of 31 October 2026.

The key point is that what the EU AI Act postponed is the application date, not the logging requirement itself. When the obligations start to apply, you will need to already have "at least six months" of logs accumulated. Realistically, the logging setup should be put in place now, not just before the application date.

Primary sources: EU AI Act Article 12, Article 19, Article 26, Article 113 (application dates) (European Commission AI Act Service Desk); AI Guidelines for Business (METI, Japan, in Japanese); Entry into force of the AI Promotion Act (Cabinet Office, Japan, in Japanese)

What to record

Recording the following fields for each AI run makes explanations easier.

Should you keep the full text of prompts and outputs?

In most cases, you do not need to keep the content itself; a fingerprint (hash) plus metadata that contains no content is enough.

Content tends to include customers' personal data and confidential information, and the more you accumulate, the greater the damage if it leaks. If you keep the hash, you can match it against the content you hold when a problem arises and confirm that "this was the input and output."

OWASP's guidance on preventing prompt injection in LLMs, in its revision of 4 October 2026, also asks that logs keep "security-relevant metadata and decisions" and exclude credentials and unnecessary sensitive data (OWASP Cheat Sheet).

Where to record

What you can record, and how much it can be trusted, depends on where you record it.

Rather than choosing between code and proxy, the reliable approach is to combine them. Use the proxy to capture every call without gaps, and record the reasons for decisions from the code layer that made them.

One more important point: logs you write and store yourself are, on their own, hard for outsiders to trust. You need a mechanism that shows they cannot be rewritten later. The next section explains this.

Conditions for evidence that holds up in an audit

For logs to work as evidence, you need these five things:

1. You can show they have not been rewritten: if you chain each record's fingerprint (hash) to the previous record, rewriting any single record in the middle breaks every link after it, so tampering can be detected
2. A third party can check them on their own: make the records verifiable locally, without having to trust the company or service that kept them
3. The retention period is met: cover the EU AI Act's "at least six months" and the audit observation period (often 6 to 12 months)
4. It is clear whose action it was: if AI is used through shared accounts or shared keys, you cannot explain who used it. Record people and agents separately
5. Missing fields are clear: stating explicitly which fields are not recorded lets you describe the scope of your records honestly. A record that does not make clear what it leaves out actually undermines trust

Issues specific to AI agents

AI agents call tools and carry out work autonomously on behalf of people. This raises issues that differ from generative AI used directly by people.

• Identify each agent: record which agent did what, separately. If everything runs on a single API key, you cannot tell them apart
• Keep tool calls: the risk is completely different depending on whether the agent only generated text or operated an external system
• Record whether a human review took place: whether a person checked before an important operation bears directly on explaining where responsibility lies
• Include coding agents: the coding agents engineers use every day are also AI calls in terms of traffic. They are easy to overlook, but should be included in what you record

What SPHIOR can do

SPHIOR's AI governance is a mechanism for keeping records that meet the conditions described above.

Ways to record (four options)

Supported AI and tools

When the destination API belongs to a known provider, the proxy records that provider's name; otherwise (for example a self-hosted model or an internal gateway), it records the destination hostname as is. Where a call was sent is never filled in by guesswork. Setup instructions are in the documentation.

How records are handled

• Content is not sent: by default, prompt and output text is not sent; only a fingerprint (hash) and metadata are recorded
• Records are kept in a tamper-evident form: each record is canonicalized and hashed, chained to the previous record, and the time is anchored externally in batches
• Third parties can verify them: with the published verification tool, anyone can check records locally without trusting SPHIOR
• Decisions stay with your own system: allow and deny decisions are made by your own guardrails, and SPHIOR records the result
• Fields that are not recorded are stated explicitly: for example, the proxy does not record cost unless you set unit prices (actual unit prices vary with discounts and contracts, so they are not guessed). The proxy also cannot see your own guardrails' decisions, so the assumption is that you record decisions from the code layer

What you can show your auditor

• A list of runs (filterable by agent, model, decision and period)
• Counts per agent × model, and the distribution of decisions (allow, deny, etc.)
• Verification information for each record
• A verification pack for a specified period (up to 1,000 records per export; for larger volumes, export in separate periods)

Pricing

There is no per-record usage billing. Usage billing would make it "cheaper to record less," which contradicts the goal of recording everything without gaps. Paid plans keep recording even beyond their limit, and the free plan never turns into a paid plan on its own. See Pricing for details.

Frequently asked questions

Is six months of log retention enough?

Articles 19 and 26 of the EU AI Act specify "at least six months." A longer period may be required depending on the purpose, and audits such as SOC 2 Type II require you to cover the observation period (often 6 to 12 months). If other laws set different requirements, you must follow those as well.

If we don't keep prompt text, can we still investigate when something goes wrong?

If you keep the fingerprint (hash), you can match it against the text you still hold or the provider's logs to confirm whether that was the input and output. The more text you accumulate, the greater the damage in a leak, so the realistic approach is to decide whether to keep text by weighing the need for investigation against the risk of a leak.

Can this replace ISO/IEC 42001 certification?

No. Certification is obtained through an audit by a certification body. Audit logs are one of the materials used in that audit and in explanations inside and outside your organization.

Is a log we built ourselves not good enough?

It can be. However, when you present it to outsiders, you need to be able to explain that it has not been rewritten after the fact. Putting it in a form that shows this, using hash chaining and external time anchoring, keeps the explanation short.

Summary

• A generative AI audit log is a record for explaining to outsiders. What matters more than detail is that it cannot be rewritten and shows whose action it was
• The EU AI Act postponed its application dates, but the requirements for automatic logging and at least six months of retention remain
• The baseline is to record fingerprints and metadata rather than content. State explicitly which fields are not recorded
• Combine the proxy and the code layer, and include AI agents and coding agents in what you record

Related: How to Present GitHub Change Management as Evidence for ISO 27001 and SOC 2