AI inference audit trail: what to record for every model run

The questions an audit trail must answer

A result produced by a model becomes evidence the moment someone else relies on it: an analyst, a customer, an auditor, an insurer, a regulator or an engineer debugging an incident. Their questions are always about one specific run:

• Which model produced this result, and which exact version?
• What input did it receive?
• Where did it run, and on what runtime and hardware?
• When did it run, and how long did each phase take?
• What exactly came out, and is it the file we have now?
• Which of these facts were reported by the infrastructure, which were observed independently, and which were verified?

What to record for every inference

Model identity

A content hash (for example SHA-256) of the exact model artifact, plus its name and version. A name can be reused; a hash cannot.

Input identity

A hash of the input the model received, so the record can be checked against the data without storing it twice.

Execution environment

The provider and the kind of environment (cloud, edge or simulated), copied when the run is created and never rewritten.

Runtime and hardware

The runtime and device that executed the model, when they are known, with who reported them.

Timeline

When the run was created, submitted, started and finished, and how long it spent queueing and executing.

Output identity

A hash of every result artifact, so the file in hand can be proven to be the one the run produced.

Outcome

Whether the run succeeded, failed or was cancelled, with the reason.

Source of each fact

Whether a value was reported by the provider, measured independently, derived from recorded values or configured by an operator. Unknown values stay unknown, never zero.

Application logs are not an audit trail

Logs are written for debugging: they are mutable, sampled, rotated and usually name a model by a label rather than by the artifact that ran. A label such as “detector-v2” can point to different weights over time, and a log line rarely says where the run happened or who reported the timing.

An audit trail is a structured record per execution, keyed by immutable identifiers and kept with the result it explains. It answers questions about one run without reconstructing them from several systems.

• AI observability vs inference audit trailWhat monitoring answers, what an audit trail answers, and how to run both.

Reported, observed, verified

Not every fact in a record deserves the same trust. A provider can report the device it used and the time the inference took; that is a claim. The platform that ran the job can observe its own timestamps, data volumes and stored artifacts; that is an observation. Some facts can be checked independently, such as whether an output matches a known expected output; that is a verification.

A useful audit trail keeps the three apart and never promotes a reported value to a verified one. Auvryn shows every run’s provenance in exactly these three groups.

Training lineage vs inference traceability

“Model traceability” usually means training lineage: which data, code and experiment produced a model. Model registries and MLOps tools answer that question well.

Inference traceability starts where lineage stops: a registry knows which models were approved, but only the execution record can prove which one produced a particular result, on which input and where. The two are complementary; Auvryn focuses on the execution side.

Who needs one

Teams whose model outputs are used as evidence by someone else: Earth observation and remote sensing analyses, MRV and emissions monitoring, infrastructure inspection, insurance claims assessment and other decisions that can be audited or disputed.

Rules on record-keeping for AI systems, such as the EU AI Act’s logging obligations for high-risk systems, point in the same direction. An audit trail supports such obligations; by itself it does not make a system compliant.

What Auvryn records today

• The model artifact’s SHA-256, bound to the upload, and the validated model version used by each run.
• The input’s SHA-256 and size when you provide your own input.
• The execution environment and whether the run was simulated, copied when the run is created.
• Provenance in three groups — reported by the provider, observed by Auvryn, verified by Auvryn — with each telemetry value labelled by its source.
• Every result artifact with its SHA-256, the run’s timeline and its history, readable in the web app and through the REST API, SDK, CLI and MCP server.

Try it

Sign up and run the guided sample: it takes about a minute and shows a full run record. Then upload your own ONNX model, validate it and test it in an isolated sandbox. Runs on real cloud infrastructure are opened for approved pilots only.

What it is not

An audit trail is a sourced record, not a cryptographic attestation: it does not prove that a specific chip executed the model. Hardware attestation (trusted execution environments, signed quotes) is a separate, complementary layer.