Sooner or later someone asks why an automated workflow did what it did. A customer disputes a refund. An auditor wants to see who approved a payment. A manager wants to know why a message went out in the wrong tone. If the only record is the final output, you cannot answer.
An audit trail is the record that lets you reconstruct a decision after the fact. This post covers what it should contain, what to be careful about, and how to make it usable rather than just large.
The test for a good trail#
Pick any run from last month and try to answer five questions without asking the person who built the workflow:
- What started it, and when?
- What did each step receive and produce?
- Which model, tools and knowledge were used?
- Did a person approve, edit or reject anything, and who?
- What was the final action, and did it succeed?
If you can answer all five from the record alone, your trail is doing its job. If you need to guess, something is missing.
What to record#
Run-level fields. A run identifier, the workflow and its version, the trigger (a message, an API call, a schedule), the start and end times, the final status, and the total tokens and cost. These make runs findable and let you spot patterns.
Step-level fields. For every step: its type, the input it received, the output it returned, how long it took, and whether it succeeded. For model steps, add the model name and the instruction used. For tool calls, record which tool was called and with what arguments, because that is where real-world effects happen.
Knowledge used. When an agent answers from documents, record which chunks it was given. An answer you cannot trace to a source is hard to defend.
Human decisions. Who was asked, what they saw, what they chose, what they changed, any reason they gave, and when. This is the part auditors ask about first.
Identity and permissions. Which user or API key started the run, and in which workspace. If a key was used, which one.
Changes over time. Edits to the workflow itself. A trail that shows the run but not the version of the workflow that ran is only half useful.
Retries and re-runs: keep the original#
When a step fails and someone fixes it, there is a temptation to overwrite the failed run with the successful one. Do not. The failed attempt is evidence, and so is the fix.
The cleaner model is to treat a retry or an edited re-run as a new run that links back to the original. The old record stays intact, and the link shows what was changed and why. Cadrix works this way: retrying a step or re-running with edits creates a new linked run, and history is never overwritten.
Personal data in logs#
A full trail contains whatever the workflow touched, and that can include names, emails, account numbers and document contents. Logging everything and keeping it forever creates a second privacy problem. A few practical rules:
- Decide per workflow what needs full input and output capture, and what only needs metadata.
- Mask or omit fields you never need to read again, such as card numbers or ID numbers.
- Limit who can open traces. Viewing a run is a permission, not a default.
- Set a retention period and stick to it. Keep it as short as your obligations allow.
Credentials should never appear. In Cadrix, secrets are stored as encrypted connections and are not shown to builders or to the model, so they do not end up in prompts or traces.
How long to keep it#
There is no single number. It depends on what the workflow decides and which rules apply to you. For one regulated category, the EU AI Act is specific: deployers of high-risk AI systems must keep the logs automatically generated by the system, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months, unless other EU or national law says otherwise (Article 26(6)). The Act's logging provision for providers (Article 12) says high-risk systems must technically allow automatic recording of events over the lifetime of the system. For some biometric systems it lists minimum content, including the time of each use and the people who verified the results.
Three cautions. First, these duties apply to high-risk systems as the Act defines them, which many business workflows are not. Second, the application dates for high-risk obligations were pushed back by an amending regulation in 2026, so check current dates. Third, sector rules such as finance, health or tax records may require longer. Ask your legal or compliance adviser which applies to you. This is not legal advice.
A reasonable internal default: keep run traces for as long as you would need to answer a dispute about the decision, and keep the approval records at least as long as the underlying transaction records.
Make it usable#
A trail nobody can read is not an audit trail. Three habits help.
Filters. You should be able to find runs by status, workflow and date range, and export the list.
One-click depth. Start from a list of runs, open one, and see each step in order with its input and output. Avoid trails that require a database query.
Alerts on the trail itself. A run that failed three times in an hour is a signal. Surface failures; do not wait for someone to open the log.
In Cadrix#
Every execution of every workflow is listed with its status, duration, tokens and cost. Open one to see what each step received and returned, with timings. Runs can be filtered by status, workflow and date, and the list can be exported. Human approvals are steps in the trace, so the decision sits next to the action it allowed. Retained history depends on your plan: run history is kept for 30 days on Starter and without a time limit on paid plans, per the governance page.
If you must keep records longer than your plan retains them, export the run list on a schedule and store it in your records system.
A starting checklist#
- Every run has an ID, a version and a trigger.
- Every step records input, output, status and duration.
- Tool calls record the tool and its arguments.
- Human decisions record who, what and when.
- Retries and re-runs create new linked runs.
- Personal data is minimised, access is restricted, retention is set.
- Someone reviews a sample on a schedule.
Sources#
- EU AI Act, Article 12: Record-keeping
- EU AI Act, Article 26: Obligations of deployers of high-risk AI systems
- Orrick, EU AI Act Update: Digital Omnibus finalizes compliance changes (July 2026)
- Model Context Protocol specification, Tools: security considerations (2025-06-18)
- Cadrix governance: audit and run tracing
