What to Log for an AI Feature, Field by Field

Log enough to reconstruct any AI decision months later without the original engineer in the room. That means the input, the exact model and prompt version, the retrieved context, the raw output, the post-processing, the final action, and who or what approved it. Most teams log the output and nothing else, then cannot explain a single decision when a customer or a regulator asks. The fix is boring and specific: decide the fields up front and write them every time.

I have written elsewhere about why audit trails belong in AI systems. This post is the what. Here are the fields, and why each one earns its place.

The fields you must capture on every AI call

Treat each AI interaction as an event with a stable ID. Attach these:

• Request ID and timestamp. The spine everything else hangs on.
• Actor. The user, service, or agent that triggered the call, plus tenant or account ID.
• Model identifier and version. Not "GPT" or "our model." The exact version string. When the model changes, your outputs change, and you need to know which one produced this result.
• Prompt version. Reference the exact template, not the rendered text alone. Prompts drift. Version them like code.
• Full input. The user message and every piece of retrieved context or document text that went into the window. If you cannot see what the model saw, you cannot explain what it did.
• Raw output. Before any parsing, filtering, or formatting. The model's actual response.
• Post-processing result. What your code did to that output: parsed fields, validation results, anything you rejected or rewrote.
• Final action and outcome. What actually happened in the world, and whether a human approved it.
• Confidence or abstention signals. If the system scored its own certainty or chose to refuse, record it.

That set lets you replay any decision. Miss the model version or the retrieved context, and you are guessing.

Why "just log the output" fails you

The output alone answers nothing useful. A customer says the AI gave them a wrong number. You look at the log. You see the wrong number. You cannot see what data it was given, which model produced it, or which prompt version was live that day. You cannot tell whether it was a bad input, a stale prompt, a model regression, or a genuine model error.

With the full field set, you trace it in minutes. This is the difference between a system you can make defensible after the fact and one where every complaint becomes an unsolvable mystery. It is also what turns a vague "explainability" promise into a real capability, which is the practical side of explainability versus accuracy for AI buyers.

Structure it so you can actually query it

A log you cannot search is a graveyard. Store these as structured records, not free-text blobs. You want to answer questions like "show every decision from model version X between these dates where a human overrode the output." That query is impossible against a wall of text.

Link each record to the run it belongs to so you can trace a full workflow run to debug it, not just a single call in isolation. For multi-step agents, the individual call logs roll up into a run trace, and the run trace is what you actually reason about.

What not to log, and how long to keep it

Do not blindly log secrets, full payment details, or raw regulated data in plaintext. Redact or tokenize sensitive fields. The goal is reconstructable decisions, not a second copy of your most sensitive data sitting in a logging system with weaker controls.

Retention is its own decision with real tradeoffs, and I cover it separately in how long to keep AI audit logs. For now: pick a period, write it down, and enforce deletion. An indefinite log is a liability, not a virtue.

This is the same logging spine under every agent I run on Girard AI. It is not glamorous work. It is the work that lets you answer the one question a serious buyer always asks: when your AI does something, can you show me exactly what it did and why. Log the right fields and the answer is yes.