When an agent makes or supports a regulated decision — a transaction, a credit call, a sanctions check — the log must satisfy what banks already do for AML. The standards are stricter than what most product teams build for agents. Here is the shape and the gap to close.
What "decision log" means in regulated contexts
Three layers of detail beyond a regular audit log:
- Decision provenance — what data the decision was based on, with references to source records.
- Reasoning capture — the chain of inference that led to the decision.
- Approval chain — who or what approved each step, with timestamps.
A traditional audit log says "agent A did X". A decision log says "agent A decided X because of inputs B, C, D, with approval from system rule E".
Where this applies
Sectors where decision logging is already (or about to be) mandatory:
- Banking — AML / BSA / KYC / OFAC sanctions.
- Insurance — claims decisions, especially with AI assist.
- Healthcare — clinical decision support (covered by HIPAA + sectoral).
- Hiring — automated screening (US state laws, EU AI Act high-risk).
- Credit — adverse action notices (FCRA in US).
If your agent touches any of these, this article is mandatory reading.
The schema
A working schema, broader than the audit trail:
CREATE TABLE agent_decisions (
id bigserial primary key,
ts timestamptz not null default now(),
decision_type text not null,
subject_id text not null,
agent_id text not null,
human_reviewer_id text,
-- inputs
input_records jsonb not null,
input_record_hashes text[] not null,
-- reasoning
reasoning_chain jsonb not null,
rules_evaluated text[] not null,
-- decision
decision jsonb not null,
confidence numeric,
-- approval
approval_path jsonb not null,
-- integrity
prev_hash bytea,
hash bytea not null
);
CREATE INDEX ON agent_decisions (subject_id, ts);
CREATE INDEX ON agent_decisions (decision_type, ts);
Every regulated decision lands here. Hash chain enforces tamper resistance.
The three Lines of Defence
In banking, decisions face three reviewers:
- First Line — the operator that made the decision.
- Second Line — risk and compliance review.
- Third Line — internal audit.
Each line needs different views over the same logs:
- First line sees decisions per agent, per session.
- Second line sees decision quality and outlier patterns.
- Third line sees the chain integrity and process compliance.
Build one log; provide three views.
Reasoning capture
The hardest part. The agent's reasoning must be:
- Captured verbatim — the chain of thought that led to the decision.
- Stable — the same input produces the same logged reasoning.
- Reviewable — humans can read it and understand.
See decision explainability for the underlying technique. The decision log is where the captured chain-of-thought lives.
Retention
| Regulation | Retention |
|---|---|
| BSA / AML (US) | 5 years |
| GDPR audit | 12–24 months |
| FCRA adverse action | 25 months |
| EU AI Act high-risk | 10 years post-market |
| State insurance | varies; up to 7 years |
Pick the maximum applicable; costs are dominated by storage class, not retention period.
Approval chain detail
Every regulated decision has at least one approver, even if automatic. Capture:
- Who (or what rule).
- When.
- What was reviewed (inputs, reasoning, alternatives).
- What the alternative would have been (if applicable).
Auditors specifically look for evidence that approval was meaningful, not rubber-stamped.
Suspicious activity reporting
For AML specifically, the agent must:
- Flag suspicious patterns even when the decision itself was approve.
- Store the flag, the reasoning, and the disposition.
- Generate SAR-shaped output on demand.
Your agent's decision log feeds the SAR workflow. Treat them as one system.
Integrity proofs
For decisions subject to litigation, three integrity layers:
- Hash chain within the log.
- Periodic anchor to a tamper-evident store (internal trust store, blockchain-style append-only log).
- External attestation (auditor signs off on chain validity quarterly).
Without these, defending the log in court is harder.
What does NOT count as compliant logging
- Logs without reasoning — the regulator wants to see the inference, not just the output.
- Logs in mutable storage — DB rows that can be edited.
- Logs without approval chain — automatic approval still must be logged.
- Logs that exclude failed decisions — denied approvals matter for fairness audits.
Common mistakes
- Reasoning chain too verbose — log only what is needed, redacted of PII.
- No human-reviewer field — even fully automatic decisions should record the rule that approved.
- No subject-centric view — auditors ask "show all decisions about subject X"; build the index.
- No exception handling — what about errors? They are decisions too.
Where this is heading
Three trends by 2027: standardised decision-log schemas published by sectoral regulators, vendor decision-log products targeting agentic systems specifically, and decision-log integrity proofs becoming a bid requirement in regulated procurement.