Last week, Reuters reported that the OCC and Federal Reserve have started asking banks, during routine exams, to map how they employ AI in higher-risk areas: lending, KYC, and sanctions screening, whether or not the AI was developed at the bank or by a third party.
Regulators are saying that accountability for third-party models rests with the bank, not the vendor. This means that a CIO has to put to every AI vendor the questions that the regulators are asking them.
Isn't this what has always been the case? Not quite.
1. The regulator's questions change who you procure from. A CIO now has to answer the same five things about any AI they deploy, whether it was procured or built in-house:
Can the institution reconstruct, after the fact, why the system did what it did? Can it access or infer data beyond what it is authorized to; is there a kill switch and human oversight; how exposed are you to the vendor's subcontractors; what is your exit if the vendor has a breach; and can you reconstruct why the system did what it did? Choosing an AI vendor is now a regulatory exposure decision, not just a performance one.
2. Principles-based supervision is harder than rules. Regulators are deliberately not writing prescriptive AI rules. They are applying what they already have: model risk management under SR 11-7, third-party risk, and consumer protection, because the technology moves faster than rulemaking ever will. That shifts the burden of proof. There is no checklist to clear. The institution must demonstrate, continuously, that its controls hold. A vendor that hands over a SOC 2 report and a smile has not done the work.
3. Build vs. buy shifted in both directions. Buying a general-purpose copilot means inheriting a vendor, and its subcontractors, you cannot fully audit or exit. That is now an exam liability. But building in-house does not escape it either: data boundaries, kill switches, and audit trails are exactly the parts that in-house teams underestimate. Building a model is not the same as operating one inside a governance boundary that survives an exam. The real question is not build or buy. It is governable or ungovernable.
Robin Shield was built to answer these exact questions. Robin Shield is the governance and controls layer of the Obin Platform, alongside Robin (the agent runtime) and Robin Studio (the builder). Each control maps to a question an examiner is now asking:
The controls regulators are now demanding are the ones we treated as the premise, not a feature. As we have written before, an AI that is 95% accurate can still be 100% wrong; in regulated finance, governance is the product.
The institutions that pull ahead over the next 18 months will not be the fastest to adopt AI. They will be the ones who can run it in production and defend it in an exam. Most of the market is still solving only the first challenge. Regulators have raised the bar; you need to plan to solve the second challenge as well.
