Getting an AI pilot into production in financial services

The pilot works. The review is where it stops.

Most financial firms already have an AI pilot. Far fewer have one in production. In the 2026 CSBS survey of community banks, 53 percent of the 330 banks that answered said they were piloting AI or using it in limited ways across specific functions, and only 9 percent said AI was deployed across multiple functions or integrated into core operations. The OCC's Spring 2026 Semiannual Risk Perspective describes the same caution from the supervisor's side: banks are adopting generative and agentic AI in specific use cases, with guardrails and human-in-the-loop accountability.

The pilots rarely stall on the model. They stall on evidence: what the system decided, who approved it, where the data sat, and whether any of that survives model risk, security and audit review. That gap is the subject of why most enterprise AI pilots never reach production. In financial services it is wider, because every one of those reviews has a regulator standing behind it. This piece is for the CTO, CIO or head of AI at a mid-market bank, lender, insurer or wealth firm who has to get a pilot across it.

SR 11-7 is gone, and its replacement leaves generative AI to you

On April 17, 2026 the Federal Reserve, the OCC and the FDIC issued SR 26-2, Revised Guidance on Model Risk Management, which supersedes and replaces SR 11-7, the 2011 guidance most model risk functions were built around. The Federal Reserve says the new letter is expected to be most relevant to banking organizations with over $30 billion in total assets. And a footnote sets the newest systems aside: generative AI and agentic AI models are novel and rapidly evolving, and so are not within the scope of the guidance. The same footnote adds that a banking organization's own risk management and governance practices should guide the governance and controls for anything the guidance does not cover.

The OCC's bulletin rescinding its 2011 guidance says the agencies plan to issue a request for information that considers banks' use of AI, including generative and agentic AI. Months earlier, in OCC Bulletin 2025-26, the OCC said its model risk guidance does not, and should not be interpreted to, require community banks to perform annual model validation.

For a mid-market firm the practical reading is simple. No federal checklist will approve your generative AI pilot for you. Your own model risk, compliance and security functions will decide, and they will reach for the concepts they already trust. Expect them to ask for effective challenge, which SR 26-2 describes as a critical and objective challenge by people with the expertise, the independence and the standing to force a change. A system can only be challenged if it was built to be inspected.

What your reviewers will ask the system to show

The questions are predictable, so the answers can be designed in from the first architecture. What the system is for and what it must never do. What it was tested against, and what score it had to reach. Which model, prompt and retrieval version produced a given answer. What a person can read to understand why. Who approved the release, and how to roll it back.

Broker-dealers have the clearest public statement of this so far. FINRA Regulatory Notice 24-09 reminds member firms that its rules apply whether a firm develops a generative AI tool itself or uses a third party's, including features embedded in products it already buys. FINRA's 2026 Annual Regulatory Oversight Report lists practices such as storing prompt and output logs for accountability and troubleshooting, tracking which model version was used and when, and validation and human-in-the-loop review of model outputs.

Those practices are good engineering for any regulated firm, which is why our AI engineering work carries them as defaults rather than options. Every decision the system takes is recorded with its inputs, the model and prompt version behind it and a reason a reviewer can read. The acceptance criteria live in an evaluation suite written in the business's own language, because evaluation is the contract your reviewers will hold the system to.

Credit, insurance and decisions a person must explain

Some uses carry obligations of their own. A lender that takes adverse action on a credit application still has to give reasons: under Regulation B, section 1002.9, the statement of reasons must be specific and indicate the principal reason for the action. The CFPB withdrew a batch of guidance documents in May 2025, among them its two circulars on adverse action notices, one of them written for credit decisions based on complex algorithms, but the regulation itself still applies.

Insurers face the same point from the other direction. New York's Insurance Circular Letter No. 7, on AI in underwriting and pricing, states that an insurer may not rely solely on a third party's claim of non-discrimination, and that the responsibility to comply with anti-discrimination laws remains with the insurer at all times. The NAIC adopted a model bulletin on insurers' use of AI systems in December 2023 and tracks which states have adopted it.

We build decision support for credit, underwriting and servicing so that each recommendation carries its inputs, its model version and a reason a reviewer can read, and so that the system proposes while a person with the authority decides. Where a system of record must stay the system of record, the AI reads and proposes, and the write path stays inside the controls you already have. None of this is a legal or compliance opinion, which Caltor does not give. It is a system your counsel, your compliance officer and your examiner can inspect.

The vendor in the middle

Almost every pilot depends on someone else: a model provider, a software vendor, and often a firm like Caltor building the system. None of that moves the responsibility. In their September 2026 proposal for third-party risk management guidance, which would replace the 2023 interagency guidance, the federal banking agencies repeat that a banking organization's use of third parties does not diminish its responsibility to meet its obligations to the same extent as if it did the work itself. SR 26-2 says the same of vendor models: the bank may lack access to the code, data or method behind them, but the principles of model risk management remain applicable.

So the vendor review is part of the path to production, not a formality before it. Ask every party in the chain the same things: where your data goes and what is retained, what the system can reach and act on, how a model change reaches you, and what evidence you will get for your own review. When Caltor is the builder, we complete the questionnaire ourselves, take your security team through the architecture and the threat model we write for every AI system, and accept the controls your program requires of any supplier.

Data, change control and the systems of record

Two architecture decisions are painful to retrofit in a regulated firm, so they belong in the first design. The first is where the data sits. We work inside your cloud accounts and identity systems rather than copying data out, and design retrieval so the model can only reach documents the person asking is already entitled to see. The second is change control. Model, prompt and retrieval changes ship the way code ships: versioned, tested against the evaluation suite, reviewed, and released through your own change process with the previous version recoverable.

Change control matters more than it used to, because the model underneath you will change whether you plan for it or not. Providers retire models on published schedules, and each migration has to pass the same review as the first release. We set out what that does to the budget in what an AI agent costs to run. The estate beneath all of this, the pipelines, serving, isolation and audit trail, is the work of our data and platform practice.

A first production slice

The fastest route to production in this sector is narrow. Choose one use case with a named business owner, where the system proposes and a person decides. Write the acceptance criteria into an evaluation suite before the build, and have the business owner sign the threshold. Write the threat model before the architecture is fixed. Produce the documentation for model risk, security and audit review as a deliverable, not under pressure at the end. Then run the system beside the existing process until the results agree.

Your reviewers do not have to invent a vocabulary for any of this. In February 2026 the US Treasury released a Financial Services AI Risk Management Framework, which adapts the NIST AI Risk Management Framework to the operational, regulatory and consumer protection considerations of financial services. A system built to produce its own evidence maps onto a framework like that without a reconstruction exercise.

This is how Caltor works in financial services. We build systems your risk, audit and security functions can inspect, and hand them the evidence to do their own work; we do not certify a system or act as your independent validation function. If a use case in your book stalls every time it reaches model risk, security or audit, book a conversation with a founding partner and we will tell you how we would build it and where the evidence would come from.