How Regulatory Scrutiny of AI Vendors Is Changing Procurement

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.

Three things the new scrutiny actually changes

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 system access or infer data beyond what it is authorized to?

• Is there a kill switch and a clear human-oversight chain?

• How exposed is the institution to the vendor's subcontractors?

• What is the exit path if the vendor has a breach?

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 for these questions

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:

• Audit trail: every agent action logged, versioned, and traceable. Answers the audit-trace question.

• Role-based access and capability ceilings: an agent only touches the data and actions its role permits. Answers the data-access and guardrails questions.

• Human oversight: clear authority to stop or override an agent. Answers the kill-switch question.

• Per-tenant isolation: your data stays yours, with a virtualized copy for compliance and rollback. Answers the data-boundary and exit questions.

• Open architecture: no single-model lock-in, so swapping the vendor is a real option. Answers the exit question structurally.

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 next 18 months

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.