A model declines a loan on a Tuesday. Eighteen months later, a regulator, or the applicant's lawyer, asks the bank to show exactly what the system decided, and why. That is the moment most institutions discover their records don't hold up.
AI is now making or shaping credit decisions at scale: approvals, declines, limits, pricing, fraud blocks. Each of those is a decision a bank is accountable for, to the customer, to a regulator, and potentially to a court. And accountability, when it is tested, comes down to a single question: can you produce a faithful, trustworthy record of what the system actually did?
For a surprising number of institutions, the honest answer is no. Not because they are careless, but because the tools they rely on were never built to be evidence.
The 18-month problem
Consider the timeline. An AI model declines an application. The applicant disputes it much later, after a complaint, an ombudsman referral, or a discrimination claim. Counsel asks the bank to show the precise input, the precise output, and the exact model version that produced that decision on that date.
By then, three things have usually happened:
- The application logs have rotated or been archived into something no one can cleanly reconstruct.
- The model has been retrained since, so the system that exists today is not the one that made the decision.
- Nothing cryptographically ties that decision to that model version at that moment.
The bank believes it acted correctly. It probably did. But belief is not evidence, and "trust our logs" is not a defence an outside party has to accept.
A log is a claim. Evidence is something an adversary can verify without trusting you.
Why ordinary logging quietly fails
Application logs, observability dashboards, and even vendor audit trails share the same three weaknesses the moment an outsider is involved:
1. They can be edited after the fact
Standard logs are mutable by design. Anyone with the right access, or a bug, or a bad actor, can alter them, and nothing about the record proves it wasn't changed. To a regulator or a court, "editable" and "unreliable" are close to synonyms.
2. They require trusting the party that produced them
A vendor dashboard shows you what the vendor chooses to show. When your own liability is on the line, "the provider says so" is exactly the dependency you don't want.
3. They don't survive time
Retention windows expire. Keys rotate. Schemas change. The one record you need is often the one that was overwritten eleven months ago.
What "proof" actually requires
Regulators are converging on the same expectation, whether it's the RBI's model-risk guidance in India, Article 22 of the GDPR on automated decisions, adverse-action requirements in the US, or Annex IV of the EU AI Act. Strip away the jargon and each demands the ability to reconstruct, defensibly, what a specific AI decision was. In practice that means a record that is:
- Complete: the exact input, the exact output, the model and version, the timestamp, and the policy in force.
- Tamper-evident, so any later change is detectable rather than merely discouraged.
- Independently verifiable: checkable by an auditor, regulator, or court without having to trust the bank or the AI vendor.
- Durable, provable months or years later, not just while the logs are warm.
Most logging stacks satisfy the first point and none of the other three. That gap is the whole problem.
From logs to receipts
The fix is a shift in kind, not degree. Instead of writing a mutable log line, you emit a signed receipt for each AI decision, a small record that captures the decision and is then cryptographically sealed.
Concretely, a decision receipt for a declined loan looks like this:
decision declined
ai_model risk-model-v7 · 2026-03-14
input_hash a3f2…9c1e (features, not raw PII)
output_hash 7b41…d0e5
prev_hash 92cd…4e5e (links to the decision before it)
timestamp RFC 3161 · trusted authority
signature Ed25519 · valid
Three properties make this evidence rather than a log entry:
- It's signed in a hardware security module, so it couldn't have come from anywhere else.
- It's chained. Each receipt references the one before it, so removing or altering a historical decision breaks every verification that follows.
- It's independently verifiable, anyone can confirm it with a public key alone, no access to your systems and no dependency on the AI vendor.
Crucially, the receipt records hashes of the input and output, not the raw customer data, so you get provable evidence without turning your audit trail into a second copy of sensitive PII.
The practical test. Pick any AI credit decision from the last two years and ask: could you hand a regulator a record of exactly what the model did, that they can verify themselves, without trusting your word? If the answer isn't a confident yes, that's the gap receipts close.
Why this is urgent now, not later
The regulatory calendar has stopped being theoretical. India's RBI has closed consultation on model-risk expectations for regulated entities. The EU AI Act's high-risk obligations, including the Annex IV documentation and Article 12 logging duties, apply from 2 December 2027, after the 2026 Digital Omnibus deferred them from 2026. The UAE's CBUAE has set responsible-AI expectations for financial institutions. Each one, in its own language, asks for the same thing: evidence of what an AI system did.
The institutions that will move fastest are the ones that treat this as an evidence problem today, while the deadlines are still weeks away, not the ones scrambling to reconstruct decisions after the first dispute lands.
See every AI-accountability deadline in one place
Our free 2026 AI Compliance Deadline Tracker maps the EU AI Act, RBI, UAE CBUAE, US, UK and global standards to the exact evidence each one expects you to produce.
This article is general information, not legal advice. Regulatory scope and dates change; verify against the official texts and your counsel before acting.