Logging and Tracing So Failures Can Be Reconstructed

Logging is not optional. When an AI system causes harm to a user or fails to perform its function correctly, regulators, auditors and the organisation itself will need to reconstruct what happened. Without logs, you have no evidence, no audit trail, and no way to prove the system was operating as designed. Logging is a regulatory requirement under the EU AI Act and ISO/IEC 42001, and it is a prerequisite for post-incident investigation.

What should you log? The answer depends on the use case, but a complete log captures: the user’s input, the model’s output, relevant context (user ID, timestamp, model version, any feature flags that were active), execution metrics (latency, token count, cost), user action after the model’s response (did the user accept it, reject it, ask a follow-up), and any errors or exceptions.

For a loan assessment model, logs should capture: the applicant’s data (name, income, employment status), the model’s decision (approve, reject, refer to human review), the reason for the decision (if the model provides one), which version of the model made the decision, the date and time, and whether the decision was later overridden by a human.

For a customer support chatbot, logs should capture: the customer’s message, the model’s response, whether the customer marked the response as helpful or unhelpful, and whether they escalated to a human agent.

Implement structured logging, not free-form text. Use JSON or a structured format so that logs can be queried, analysed and audited programmatically. A structured log entry might look like:

{“timestamp”: “2026-09-02T14:32:15Z”, “user_id”: “customer_42”, “model_version”: “gpt4-turbo-2024-12”, “input”: “What is the best credit card for travel?”, “output”: “Amex Platinum is…”, “output_length”: 245, “confidence”: 0.87, “latency_ms”: 1240, “tokens_used”: 156, “cost_usd”: 0.00234}

Log personally identifiable information only when necessary for the stated purpose. If you are logging to investigate a loan decision, you may need to log the applicant’s name and income. If you are logging aggregate metrics on model performance, you do not need to log names at all. Apply data minimisation: log only what is strictly necessary.

Implement log retention policies. Logs should be kept for a defined period, then deleted. UK GDPR does not specify how long you must keep logs, but a reasonable approach is to keep logs for as long as you might need to investigate or defend a decision. For loan decisions, this might be 7 years (matching lending regulation). For general chatbot interactions, this might be 30 days. Define your policy and enforce it.

Implement log storage and access control. Logs should be stored in a system that is separate from your application (a logging service like Datadog, ELK, Splunk, or CloudWatch). Logs should not be stored in the same database as sensitive business data. Access to logs should be restricted to authorised users: engineers for debugging, compliance teams for audits, and legal for investigations.

Implement audit trail immutability. Once a log entry is written, it should not be modifiable. If logs can be edited after the fact, their evidentiary value is zero. Most professional logging services provide immutability guarantees, but if you implement your own, use append-only storage and consider using cryptographic signing to detect tampering.

Implement tracing. A trace is a record of all the steps a request passed through as it flowed through your system. For a loan assessment decision, a trace might show: user submitted data, data validation passed, model received input, model made prediction, guardrail checked output, decision was logged, email notification was sent to customer. If something went wrong in the decision, tracing shows exactly where. Tracing is particularly valuable when a system has multiple components: if the user says “your chatbot gave me the wrong answer,” tracing lets you see whether the model was confused, the guardrails were too strict, the retrieval failed, or the log captured the wrong output.

Implement correlation IDs. Assign a unique ID to each user request when it enters the system. Pass this ID through every step of processing. When you log, include the correlation ID. This allows you to query all logs for a single request even if logs are stored in multiple services. For example, a correlation ID might be a UUID generated when the user submits a request. That ID is passed to the model inference service, the guardrail service, and the logging service. Later, when investigating a problem, you can search all logs for that UUID and see the complete chain of events that affected that one user.