What a Bank Examiner Sees When They Look at an AI Program

When I was at the FDIC, I'd walk into a bank and within a few hours I could tell you whether the institution was well-run or held together with good intentions and stale policies. It wasn't magic. It was a trained eye looking at specific things in a specific order. The executives always wanted to show me their strategy decks. I wanted to see the exception reports.

That training doesn't leave you. I moved into enterprise AI and I found myself doing the same thing. Not because anyone asked me to. Because I couldn't stop noticing the gaps.

Here's what an examiner actually looks at, and why most AI programs wouldn't survive the scrutiny.

The first thing: who owns this?

Not the team. Not the department. A person. A name.

At the FDIC, the first question on any risk topic was accountability. Who approved this loan? Who authorized this vendor? Who signed off on this exception? If the answer was "the committee" and nobody could tell me which member actually made the call, that was a finding. Not a suggestion. A finding.

Most AI programs can't answer this question. Ask who owns a model in production — not who built it, who owns it right now — and you'll get a team name, a Slack channel, maybe a JIRA board. You won't get a person who is responsible for what happens when the model behaves in a way nobody anticipated.

That's the first thing an examiner notices. Not the architecture. Not the accuracy metrics. The absence of a named human being who is on the hook.

The second thing: show me the trail

Banks operate on a documentation principle that most AI teams have never heard articulated: if you can't evidence a control, the control doesn't exist.

A bank can tell me it reviews its loan portfolio quarterly. If it can't produce the review — the memo, the findings, the date, the reviewer's name — then the review didn't happen. The assertion is worthless. The evidence is the thing.

Now apply that to an AI program. The team says it evaluated the model before deployment. Where's the evaluation? What were the criteria? Who set the acceptance threshold? What alternatives were tested? What were the results? Who reviewed the results and decided "this is good enough to ship"?

I've been close to programs where the honest answer to every one of those questions was "it's in someone's head" or "we discussed it on a call." That's not governance. That's institutional memory, and institutional memory doesn't survive turnover, doesn't survive audit, and doesn't survive the moment someone asks you to prove it in writing.

The third thing: what happens when it breaks?

Every bank has a loan that goes bad. That's not a failure of the bank. That's banking. The question examiners ask isn't "did anything go wrong?" — it's "when something went wrong, did your process catch it, and can you show me how?"

This is where AI programs fall apart most consistently. The model ships. It runs. The dashboard is green. And somewhere underneath, the inputs are shifting, the distribution is drifting, the world the model was trained on is slowly becoming a different world than the one it's operating in. Nobody notices because nobody is looking — not with the discipline of someone whose job it is to look.

Monitoring dashboards are not monitoring. Monitoring is a person reviewing data at a defined interval, making a judgment, documenting that judgment, and escalating when the judgment says something is wrong. A dashboard that nobody opens on a schedule, with no documentation of what was reviewed, is decoration.

An examiner asks: when was the last time someone looked at this model's performance in production? Not when was the last time the dashboard refreshed. When did a human being look, decide, and write down what they found?

The silence after that question is the finding.

The fourth thing: your vendors are your risk

Most banks don't build their own models. They buy them — from vendors who provide credit scoring, fraud detection, BSA monitoring, and a dozen other functions. The bank's job is to govern what it didn't build, which is harder than governing what it did build, because the bank can't see inside the vendor's process.

This is identical to how most organizations use AI today. They don't train models from scratch. They use APIs, platforms, vendor tools. And the governance question is the same one I asked bank boards: do you understand what this vendor's model does, how it was built, what data it was trained on, how it's updated, and what happens when it produces a wrong answer? Can you evidence that you asked those questions and evaluated the answers?

Most organizations trust their AI vendors the way some banks trusted their model vendors — with a contract and an assumption. That's not due diligence. That's hope.

What this means if you're building an AI program

You don't need to have been an examiner to apply examiner discipline. Four questions cover most of it.

Who owns each AI system in production — by name, not by team — and is on the hook for what it does, including what it does wrong? Can you trace the trail from business decision through deployment to monitoring, with each link documented, dated, and attributable to a specific person? When a model degrades or fails, what is your actual process — not your plan, your process — and can you show me an example of it working? For the systems you didn't build yourself, how do you govern vendor AI when the vendor owns the product but you own the risk?

If your answers are honest, specific, and evidenced, your program is closer to defensible than most. If any of the four turns into "well, technically..." that's where findings will live when someone with my training walks in.

The discipline I learned at the FDIC isn't about bureaucracy. It's about the difference between an organization that can demonstrate it controls its risks and one that can only assert it does. That difference has always mattered. With AI, it matters faster.