What Gets Logged on Every Inference

Record-keeping is the least discussed part of AI governance and the first thing anyone asks for when something goes wrong. The question is never whether a firm has a policy about AI use. It is whether, for one specific output produced on one specific day, there is a record of what happened, and that record either exists from the moment of the work or it does not exist at all.

So it is worth being concrete about what a per-inference record contains, because claiming to log everything is the kind of statement that falls apart under a single follow-up question. Every model call in Qonera writes a row, and the row is more specific than most teams expect it to be.

What the record holds

Which model produced the output, and under which label within the run, so a three-model stress test can be reconstructed afterward rather than collapsed into one anonymous result. How many tokens went in and came back, the total, and what the call cost, alongside the per-million token prices in effect at the time, which is what makes a historical cost figure meaningful instead of an artifact of today’s pricing.

Which provider served the request and in which region, the detail that matters when somebody asks where processing physically happened. A hash of the system prompt, so you can establish which instruction set was in force without storing the prompt text itself. That is a deliberate trade: you get verifiability without creating another copy of sensitive configuration sitting in a log table.

How long the call took, and whether it succeeded, timed out, or failed, with an error code and message when it did. The outcome of content safety screening. And a risk assessment: a level, the specific flags raised, and when the assessment ran, so a response that was screened and found clean stays distinguishable from one that was never screened at all.

Why the failures are the valuable part

A log containing only successful calls is a marketing document. The rows that establish credibility are the ones recording a model that timed out, a call that errored, a response that tripped a safety flag and went to review. Those entries are what demonstrate the record was written by the system as the work happened, rather than assembled later by somebody reasonably confident about what must have occurred.

The same logic explains why assessed-and-clean is stored separately from never-assessed. Collapsing those into one reassuring state would make every historical row look checked, which would be convenient and untrue. One honest caveat follows directly: records created before a given field existed do not carry it, so older rows hold less than recent ones, and pretending otherwise would defeat the purpose of keeping the log in the first place.

Where this connects to obligations

The record-keeping expectations in the Act and the transparency expectations pull in the same direction, which is easy to miss because the two are almost always discussed separately. Transparency governs what you tell the person receiving the output. Record-keeping governs whether that statement can be substantiated afterward, and a disclosure with no record behind it is a written claim about your process that you have no way to support.

Qonera is the AI governance platform for professional teams, built around a structured review and approval workflow where this logging is a by-product of doing the work rather than a separate compliance exercise, and where the trail is append-only and hash-chain verified so that later edits are detectable. The article-by-article mapping is published on the EU AI Act page. Nobody reads an inference log for pleasure, and the entire value of having one is that on the day somebody asks, the answer is a lookup rather than a reconstruction.

This article is for general information only and does not provide legal advice. Organisations should consult qualified legal counsel about how Article 12 and the EU AI Act apply to their specific systems, workflows, and obligations.