By the same method used for any other system: log it. Record the inputs the AI received, every action and tool call it made, the outputs it produced, and who or what authorised each step, then retain and search those records like any other log stream. It is ISO 27001 A.8.15 discipline applied to a new kind of actor.
The standard approach adds a purchase: an AI observability tool alongside the SIEM, with its own console, its own retention window and its own invoice, plus a separate evidence pack to assemble each time an auditor or customer asks. Secure60 treats AI activity as a first-class log stream on the platform you already run, which removes the second tool, the parallel process, and the reconstruction under audit pressure.
The AI workers inside our own security operations are logged with the discipline this page describes, under our ISO 27001:2022 certification. Book a readiness call and we’ll map where AI acts in your environment and what it takes to evidence it.
The question arrives from three directions, frequently within the same year.
An auditor asks. Your ISMS already commits you to logging events on systems that matter. Once an AI system makes or influences decisions inside a certified process, the auditor requests the decision trail.
A customer security review asks. Questionnaires now carry an AI section covering whether AI or LLM-based systems are used, and how model actions are logged and reviewed. An unanswered row holds a deal in the same way an unanswered logging row did five years ago.
An internal incident asks. An agent misfires, or is reported to have done so. Establishing what it accessed, when, with whose data and on whose authority requires records rather than re-running the model, which is not a reliable reproduction of what happened.
All three are the same request: reconstruct what the system did from evidence. Regulatory direction is consistent with it, and an inability to reconstruct model activity is unlikely to be accepted under any final wording.
ISO 27001 A.8.15 already requires event logs to capture user ID, system activities, date and time, device and location, and network addresses. An AI audit trail applies that control to a new kind of actor, in four layers.
| Layer | What you record | The question it answers |
|---|---|---|
| Inputs | The prompt, the alert, the documents or data the system was given | What did it know and act on? |
| Actions | Every tool call, query and API call, with parameters and results | What did it do and access? |
| Outputs | The verdict, summary, recommendation or content it produced | What did it decide or create? |
| Authorisation | The agent’s identity, plus the human or policy that approved the action | Who allowed it, and who is accountable? |
The A.8.15 components map across directly. The user ID becomes a pair: the agent’s own identity and the human or policy that authorised it. System activities are the tool calls. Date, time, device and network context are unchanged. The new material is the input context — what the model was given to work with — which is another event payload.
Each layer is written at the point of action. A trail reconstructed afterwards from recollection and vendor dashboards is a narrative rather than evidence.
Three properties separate a trail that survives an audit from one that does not.
The same retention as your other security logs. Set by your ISMS retention policy rather than by what the AI tool’s console retains. Vendor dashboards truncate, rotate and become inaccessible when contracts end.
Searchable alongside the rest of your telemetry. Establishing what an agent accessed should be a query. It should also join across streams: where the agent’s log records one table read and the database logs record three, both streams in one place surface the discrepancy.
Attributable and tamper-evident. Shipped to your log platform like any other security stream, with identity attached, so the trail itself withstands scrutiny.
Built that way, one trail answers the auditor, the customer questionnaire and the incident review. Built per-tool inside each vendor’s console, each of those three requires separate assembly.
Saving the conversation log resembles logging: it is text, it is timestamped, and it is what product demonstrations show. A transcript records what the model said rather than what it did.
An agent that reports querying one table while querying three is the case the trail exists for, and the transcript will not show it. The load-bearing record is the action layer: every tool call with parameters, timestamps and results, tied to an identity and an authorisation. The transcript is retained as input context rather than as evidence of behaviour.
Our platform treats AI activity as a first-class log stream. Every model call and agent action is logged, attributable and reviewable — inputs, tool calls, outputs and authorisation — retained and searched alongside the rest of your telemetry, and governed as part of our AI Security capability. We apply the same rule internally: Secure60 holds ISO 27001:2022 certification, and the AI workers running inside our own security operations are logged with the discipline this page describes. When your auditor or your customer asks what your AI did, the answer is a search.
What should an AI audit trail contain?
Four layers, each timestamped and attributable: the inputs the system received, every action and tool call it made with parameters and results, the outputs it produced, and the authorisation context — which human or policy allowed it to act. A missing layer prevents a decision from being reconstructed from evidence.
Do we need new tooling to log AI systems?
Usually not. Model calls, tool calls and agent actions are events, and an existing log pipeline already handles events. The work is coverage: writing AI actions into that pipeline rather than leaving them inside a vendor’s console.
Is there a specific law that requires an AI audit trail?
The current pressure arrives through auditors, customer security reviews and existing controls such as ISO 27001 A.8.15 rather than one named statute. Requirements vary by market and sector and are tightening. One trail answers each of them.
Is saving the chat transcript enough?
No. A transcript records what the model said rather than what it did. The load-bearing evidence is the action log: every tool call, query and change, with parameters, timestamps and results, plus the authorisation. Keep the transcript as input context.
How long should we keep AI logs?
The retention your ISMS sets for other security logs. AI activity is the stream an auditor or customer is most likely to request next, which makes a shorter retention period the wrong default.
Who counts as the 'user' when an AI agent acts?
Two identities, both logged: the agent’s own identity, and the human or policy that authorised it to act. That pair is what makes the action attributable.
