The Decision Nobody Can Explain: Why Enterprise AI Needs a Memory

Blog

George Petrovic & Ranko Stojanovic, mLogica Analytics

Can you prove what your AI did? The evidence gap in enterprise ML.

Picture a request that lands on a Chief Risk Officer’s desk. An auditor is reviewing a decision made last spring. A customer application was declined, a payment was held, a crypto transaction was blocked, or a tax return was flagged for review. A machine learning model played a part. The auditor wants to know why.

The model has been retrained twice since then. The data scientist who built it has moved to another team. Someone finds a dashboard showing the model performed well “on average” that quarter. Nobody can show what the model actually saw, which version made the call, or how confident it was.

That is not a failure of the model. It is a failure of memory. As more decisions run through machine learning, that gap gets more expensive.

Why this matters now

AI is leaving the pilot stage. McKinsey’s The State of AI in 2026 reports that 44 percent of respondents now say AI is scaling across their enterprise, up from 38 percent a year earlier.[1] More models in production means more decisions that someone may one day ask you to explain.

Regulators have noticed. On 17 April 2026, the Federal Reserve, the OCC and the FDIC replaced the SR 11-7 model risk guidance with SR 26-2.[2] Its principles apply to traditional models and to AI models that are neither generative nor agentic. It describes an effective model inventory as one with “sufficient information to understand model risks,” covers ongoing monitoring of whether a model “is performing as expected,” and highlights aggregate risk from “interactions and dependencies among models.”

In Europe, the AI Act requires high-risk AI systems to “technically allow for the automatic recording of events (logs) over the lifetime of the system.”[3] AI used to assess the creditworthiness of individuals is on the high-risk list.[4] The Digital Omnibus on AI moved the deadline for these systems to 2 December 2027.[5] That buys time, but building record-keeping into these systems takes planning and effort.

For financial services, crypto, tax and global data organizations, the question is no longer only “Does the model work?” but “Can we prove what it did?”

Where the evidence goes missing

The gaps open quietly, one model at a time:

  • Decisions without context. A prediction arrives as a bare score. The confidence behind it, and the factors that drove it, stay behind in the data science environment.
  • No way to prove compliance. When a regulator or client asks whether an ML-driven decision was legitimate, there is no single record to point to.
  • Inconsistent foundations. Teams build models on ad hoc, outdated, or overlapping datasets with conflicting definitions. Two models can give two different answers to the same question.
  • Invisible dependencies. When a data source or a model changes, nobody can say which other models and decisions are affected.
  • Silent degradation. Business patterns shift, and models drift, with no continuous monitoring to catch it.
  • Lost know-how. What worked on the last project isn’t captured, so every new model starts from scratch.

One more gap gets less attention. Because model output is hard to interpret and doesn’t fit trusted workflows, many business teams set it aside. The organization pays for the model, then decides on a gut feeling.

How organizations cope today

The workarounds are understandable. Teams treat each prediction as a plain answer and move on. Analysts message the modeler when something looks odd. Drift is noticed when business results go wrong. Problems are investigated after the harm is done. Know-how builds slowly, inside a few people’s heads.

None of this is negligence. It is what happens when machine learning grows faster than the layer that should hold its evidence.

The questions leaders can no longer avoid

The questions Chief Risk Officers, Chief Data Officers, Heads of Model Risk, ML leads and auditors now ask sound like this:

  • Which models are we running today, in which version, and for what purpose?
  • What data was this model trained on, and how far can we trust it?
  • For this specific decision, what did the model see, and how sure was it?
  • If one model starts producing wrong results, how fast will we know, and what else is affected?
  • When an incident or a regulator forces the issue, can we prove we were compliant?

Most organizations can answer some of these for some models. Very few can answer all of them, for every model, on demand.

What the answer has to look like

Closing this gap doesn’t mean replacing the MLOps stack. It means adding what that stack was never designed to keep. In our view, a credible answer rests on a few principles:

  • A record of every individual inference. Each decision (an inference, in ML terms) is linked to the exact model and version, the input values, the context, the confidence, and the explanation. Why it matters: you can answer for one decision, not just for an average.
  • Lineage in both directions. Trace a decision back to the data behind it, and trace a data or model change forward to every model and decision it touches. Why it matters: you know what a change will affect before you make it.
  • Evidence that is actually kept. The data and features behind a decision are preserved, not just referenced. Why it matters: past decisions can be reconstructed after source systems change.
  • Governance built in, not bolted on. Policies and controls apply to data, models, and individual inferences. Why it matters: compliance rests on evidence, not on documents written after the fact.
  • Continuous monitoring. Drift, data quality and reliability are tracked across platforms. Why it matters: problems surface before customers find them.
  • Works with what you already have. It sits alongside existing ML platforms and pipelines; training, deployment and inference stay where they are. Why it matters: no rip-and-replace project.
  • Know-how that is reused. Proven approaches are captured as reusable model blueprints. Why it matters: new models don’t start from scratch.

IDL Illustration (ACP)

Today, when a Head of Model Risk is asked about a single flagged decision, it starts a chain of emails and meetings. With these principles in place, the same question becomes a lookup, answered with the model version, inputs, confidence, and explanation recorded when the decision was made.

Why this matters to the business

Organizations that can reconstruct their AI decisions can stand behind them in front of auditors, regulators, clients, and courts. They find root causes faster when something breaks. Business teams use ML insights because they come with the context needed to trust them. And the knowledge built into each model stays with the organization, not with whoever happened to build it.

Where we’re going

Our vision is simple: every AI decision should be explainable and reconstructable, long after it was made. This is the problem mLogica’s Inference Data Layer (IDL) is designed to solve: a system of record and evidence for enterprise AI/ML. The aim is complete, compliant ML from blueprint to production, without disrupting how your business works.

If these questions are already on your agenda, let’s talk about how this applies to your own models: Contact Us.

If you are an ML/AI solution provider, an MLOps platform, or an integrator, we would like to build that ecosystem with you.

Next week, we’ll lay out the framework behind it.

Models will keep getting smarter. The organizations that win will be the ones that remember what their models did, and why.

Follow mLogica on LinkedIn for the rest of this series: @mLogica

Sources

  1. McKinsey & Company / QuantumBlack, AI by McKinsey, The State of AI in 2026: On the Road to ROI, August 2026.
    https://www.mckinsey.com/~/media/mckinsey/business%20functions/quantumblack/our%20insights/the%20state%20of%20ai/the-state-of-ai-in-2026-on-the-road-to-roi-aug-2026.pdf
  2. Board of Governors of the Federal Reserve System, OCC, FDIC, SR 26-2: Revised Guidance on Model Risk Management, 17 April 2026.
    https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm
  3. Regulation (EU) 2024/1689 (AI Act), Article 12, Record-keeping.
    https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  4. Regulation (EU) 2024/1689 (AI Act), Annex III, point 5(b).
    https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  5. Regulation (EU) 2026/1744 (Digital Omnibus on AI), OJ L, 24 July 2026, in force 27 July 2026.
    https://eur-lex.europa.eu/eli/reg/2026/1744/oj
George Petrovic & Ranko Stojanovic, mLogica Analytics