AI Safety & Guardrails

Course Content

AI Safety & Guardrails

5 sections · 50 lessons

What is the importance of audit logs in AI systems?

What you need to know

What one record looks like

JSON
{  "decision_id": "dec_01J9ZK4",  "trace_id": "4bf92f3577b34da6",  "ts": "2026-09-22T10:41:07Z",  "principal": {"user": "u_88213", "tenant": "retail-bank-in"},  "input_sha256": "9f2c1e…",  "retrieved": [{"doc": "loan_policy", "version": "2026-07-01"}],  "prompt_version": "support_v42",  "model": "vendor-model-2026-05-14",  "params": {"max_tokens": 600},  "tool_calls": [{"name": "get_emi_schedule", "args": {"loan": "[LOAN_7f2a]"}}],  "guardrails": [{"check": "pii_output", "result": "pass"},                 {"check": "groundedness", "score": 0.94, "result": "pass"}],  "output_ref": "audit-store://2026/09/22/dec_01J9ZK4",  "human": null,  "tokens": {"in": 1840, "out": 212},  "latency_ms": 2310}

The input is stored as a hash plus a redacted copy elsewhere; the loan number is a token, not the real value; the full output sits in a separate access-controlled store. The record has everything needed to reconstruct the decision.

Why it matters

  • Incident scoping: replay logs to find every affected user.
  • Regulatory evidence: the EU AI Act requires high-risk systems to automatically record events; financial and health regulators have their own record-keeping rules.
  • Appeals: a disputed decision must be reconstructed as it was, not re-run on a model that has since changed.
  • Accountability: shows who approved what.

Engineering constraints

  • Redact or tokenise personal data at write time.
  • Encrypt, restrict access by role, and log access to the logs.
  • Append-only / WORM storage, so records cannot be quietly edited by people they might implicate.
  • Retention: long enough for regulators and disputes, short enough for data-protection duties; write both down.
  • Completeness: never sample audit logs for consequential decisions.

A real-life example

A customer of a bank's chatbot complains that on 3 August it told him his home-loan EMI would not change after a rate cut, and he made a financial decision based on that. The bank's audit log shows the exact answer, that it cited the loan policy version from 1 July, that the EMI came from the get_emi_schedule tool, and that the tool returned the pre-cut schedule because the rate-cut batch job ran on 5 August.

The chatbot was faithful; the data was stale. The bank apologises, adjusts the customer's case, and adds a "data as of" date to every EMI answer. Without the log, the bank would have had to choose between believing the customer and believing the model, with no evidence either way.

Follow-up questions to expect

  • "Isn't logging prompts a privacy risk?" — Yes, which is why you redact, tokenise and restrict access, and store the full text only where it is really needed.
  • "How long should you keep logs?" — Set by law, contracts and dispute windows — often months to years for financial decisions — and document the reason.
  • "How do you prove logs weren't changed?" — Append-only storage, hash chains or object-lock features, and separate permissions for writing and deleting.