All papers

Vendor Logs Aren't an Audit Trail: Why ChatGPT, Claude, and Gemini Logs Won't Pass Your Review

Your AI vendor keeps logs. That's not the same thing as an audit trail. Here's the difference, and why it's the gap that shows up in every audit and due-diligence process.

Your AI Vendor keeps logs, including but not limited to, OpenAI, Anthropic, Google, xAI, etc. That is true but it isn’t what you think it is.

A vendor log is a record the vendor keeps, in the vendor’s system, for the vendor’s purposes, billing, abuse detection, their own compliance. It’s not a record you can produce, in the form a review needs, about what happened in your environment, about your data, with your employees.

The difference is the whole argument. Here’s what It actually comes down to.

What is a vendor log?

A vendor log answers the vendor’s questions, not yours.

Typically it records; the request made, model response, token consumption, account it’s tied to & timestamp. Some of it is retained for a set period, some of it isn’t. Access to it is governed by the individual vendor’s terms, not yours.

What it generally does not do:

  • Tell you which employee made the request, in the context of your identity system
  • Tell you what the AI did with your data afterwards (where it went, which system it touched, what it changed)
  • Show you who approved the action, or that an approval was even required
  • Give you a record you can export and produce on demand, in a format a regulator or counterparty will accept.

A vendor log is a receipt of work done. It does not prove what happened next, who was responsible or even that it was allowed.

What an audit trail has to do

An audit trail answers the questions that a reviewer, audit or due diligence, actually asks (typically isn’t “did it happen”), it usually is something along the lines of:

  1. What did the AI do? The action, system and record.
  2. Who approved it? Tied to who actually approved the action?
  3. Where did the data go? In and out of what system, who processed it, who had access to it.
  4. Can you produce it today? As a record, not a reconstruction.

The first three are substance, the fourth is what makes it an audit trail rather than speculation.

The Gap

A vendor log tells you the work got done. An audit trail tells you what, who, when, where in an understandable and trackable way.

That’s not a nuance, it’s the core difference between “we use AI” and “we can defend our use of AI”.

Why this shows up in the review

This is the part that matters for the people reading this.

In an audit, a penetration test, a customer due-diligence questionnaire, or a regulator's inquiry, the question is never "do you use AI?" The question is:

"Show me what the AI did with our data, who authorised it, and where it went."

If your answer is "the vendor keeps logs," the reviewer hears: "I can't answer that, and I'd have to go ask a third party to find out."

That's not a compliance gap. That's an evidence gap. And evidence gaps are the ones that turn a passing review into a finding, a finding into a condition, and a condition into a problem.

The vendor's log is not your evidence. It's theirs. You don't control its format, its retention, its access, or its scope. When it's your obligation to produce, you're borrowing someone else's record to answer someone else's question.

What the audit trail looks like when it's built for you

This is what Aisty does, and it's the part that's easy to miss because it's invisible when it's working.

Every action the AI takes is logged in your environment, in your system of record. Not the vendor's. Yours.

  • What it did: the action, the record, the system, the timestamp.
  • Who it was for: tied to the person, through your identity, not a shared key.
  • Who approved it: and the threshold that decided whether approval was needed at all. You set the line. Low-risk actions run and log. High-risk actions stop and wait for a person.
  • Where it went: in, out, and to which system.
  • What each person used: per-person visibility, so you can see the spread, not just the total.

And the whole thing is retrievable on demand. When the reviewer asks, the answer is a record you pull, not a process you reconstruct and a vendor you chase.

That's the difference between a model and a system you can put in front of a board, a regulator, or a counterparty.

The honest framing

None of this is a criticism of the vendors. Their logs do what they're built to do, and they're not built to answer your reviewer's questions, because your reviewer's questions aren't their problem to solve.

The gap isn't that the logs don't exist. The gap is that the logs that exist aren't the logs you have to produce.

You can close that gap two ways. You can build the audit trail yourself, on top of the model, and own every part of it. Or you can use a system where it's already built, already governed, already logged, and already yours.

Either way, the thing to check is the same: when the reviewer asks "show me," can you show it today?

If the answer is "I'd have to go find out," you've found the gap.

Run the check

The free AI Exposure Audit maps every AI tool in your organisation, what each one can reach, and, the part most people haven't thought about, where the audit trail actually stops.

Free. Nothing installed. Nothing to rip out. You get the report either way, whether you ever talk to us again or not.

You don't owe us a decision. You owe yourself the answer to "can I show it?"

Run the full AI Exposure Audit →