A Banker's Guide to Deploying AI in a Regulated Environment

When I speak with bankers, AI is brought up immediately in every conversation. What I didn't expect was how often those conversations ended in the same place: compliance. The bankers I meet with aren't worried about whether AI could help them; most of them already know it could. They are worried about what it looks like realistically in a regulated environment.

That's a fair question, and the more I hear it, the more I realize there's a real gap between the conversations happening with AI vendors and the ones happening in compliance meetings at banks. So I want to walk through what I've been hearing, what the regulatory landscape actually looks like right now, and a handful of practical questions that should make the path forward feel less murky.

The compliance landscape, in plain English

A few realities to start with.

There is no single federal regulation that says "here is how to do AI in a bank." There are, however, several existing frameworks that examiners are already applying to AI use cases, and a handful of newer guidance documents that explicitly call out AI. Most of them are not new ideas dressed up for the moment. They are existing risk management expectations applied to a new kind of system.

The frameworks worth knowing:

Model Risk Management (SR 11-7). Federal Reserve guidance from 2011 that lays out what model risk management looks like at a bank. It applies to AI models the same way it applies to credit scoring models or stress test models. Most examiners will start here.

OCC Bulletin 2023-17 (Third-Party Risk Management). Updated guidance on how banks evaluate, contract with, and monitor third-party vendors. If your AI is coming from a vendor, this is the framework that governs how you justify the relationship.

FFIEC IT Examination Handbook. The interagency guidance that governs IT and information security expectations at examined institutions. AI deployments touch most of these areas.

CFPB 1071. Small business lending data collection rule that will require banks to collect and report specific data on small business loan applications. If AI is touching any part of that process, the data outputs need to be examiner-ready.

What examiners actually care about

A lot of the AI compliance conversation has been louder than it needs to be. Examiners are not asking questions that bankers have not already had to answer for other kinds of systems. The questions are familiar, but answers might be slightly different.

The five things examiners are consistently asking when AI shows up in an exam:

1. Where did this output come from? Every recommendation, classification, or decision the AI surfaces needs to be traceable back to the underlying documents and data. If the answer to "show me how you got there" is anything other than a clean audit trail, the conversation gets harder.
2. Who made the final decision? Examiners want to see that credit decisions, customer-facing communications, and other regulated outputs are reviewed and approved by a person at the bank. AI can do the analysis, but a person makes the final call.
3. How do you document the model? SR 11-7 expects documented model development, validation, ongoing monitoring, and challenge from an independent function. AI models are no exception.
4. How are you managing the vendor relationship? OCC Bulletin 2023-17 applies. The bank is still responsible for what the vendor does, and examiners will want to see contractual provisions, performance monitoring, and exit planning.
5. What is your bias and fairness story? Especially in lending, examiners want to know how you have tested for disparate impact and how you are monitoring on an ongoing basis.

None of these should be a surprise to a bank that has dealt with examiner expectations before. The work is making sure the AI solution you deploy can actually answer them.

The questions to ask any AI vendor

Most of the heavy compliance lift can be addressed at the vendor evaluation stage if you ask the right questions early. Here are the ones I would not skip:

• Can you show me a sample audit trail for a real customer's deployment? Not a screenshot, not a demo–an actual exportable record.
• How are you ensuring the accuracy of the model?
• How does your model risk documentation map to SR 11-7?
• What does your third-party risk package look like, and does it cover what an OCC examiner expects under Bulletin 2023-17?
• Who at your company is responsible for examiner conversations if I get a question I cannot answer?
• How are you handling CFPB 1071 data flow for the loan applications your system touches?

A vendor that has thought this through will have answers ready. A vendor that has not will start hedging immediately. That will tell you everything you need to know.

The practical path forward

An organization must make sure that its AI due diligence runs through compliance, not around it. The institutions I have seen do this well start narrow. They deploy in a low-risk back-office workflow first, things like document handling, data validation, and exception flagging. They document everything from day one. And they bring their compliance team into the conversation at the beginning rather than at the end. The result is AI deployment that does not surprise the examiner, and a bank that has the institutional muscle to do the next one faster. At the end of the day, it is about protecting the customers who trust us with their life savings.

If your team is somewhere between not knowing where to start and trying to figure out the right first workflow for your institution, I would be glad to have that conversation. Let's connect.