You filled out the AI section of a vendor questionnaire. You named your tools, described who reviews the output, and said what happens if something breaks. Then you submitted it and the process went quiet. Nobody wrote back to say whether your answers were good enough, or what happens next.
That is not because nobody read it. It is because the review happening next has almost nothing to do with how well you wrote your answers and almost everything to do with an obligation your bank customer had before it ever thought about buying anything from you.
If you read the earlier piece on answering these forms, this is the other half: what a bank's risk team is actually trying to learn from the section you filled in, and how it assesses what you wrote. It is not a continuation of that piece, and it will not walk back through the same eight questions. It is what happens after you hit submit.
Why the bank has to ask
Banks increasingly rely on AI and other technology delivered through third parties, and their supervisors have been clear for years that outsourcing the work does not outsource the responsibility. The Federal Reserve, FDIC and OCC issued interagency guidance on third-party relationships back in June 2023 that runs across the whole lifecycle: due diligence before signing, contract terms, ongoing monitoring, and what happens when the relationship ends. It applies whether the third party sold the bank a spreadsheet template or an AI product, and it helps explain why a form like yours asks what it does.1
New York-regulated banks carry a second layer on top of that. NYDFS clarified in October 2025 how an existing rule, 23 NYCRR Part 500.11, is expected to apply across that same lifecycle, and its guidance specifically names AI among the technologies delivered through third parties. It does not create a new AI-specific requirement. It explains how a requirement banks already had reaches vendors that use AI, which is exactly why your form has an AI section bolted onto a security review that existed long before AI did.2 The same letter says contracts should consider a clause on acceptable use of AI, and on whether the bank's data may be used to train AI models. That ties AI use to the contract the vendor signs.
There is a narrower piece of guidance worth knowing about too, mostly so you know its limits. The Federal Reserve's SR 26-2, issued this April, revised the guidance examiners use for model risk management, covering traditional quantitative models and non-generative AI. It says plainly that generative and agentic AI models, the kind most vendor questionnaires are actually asking about, are not within its scope for now. That gap is exactly why the third-party guidance above is doing more of the work here than a model-specific letter can.3 A vendor can still create third-party risk even when its generative AI sits outside model-risk guidance.
None of this is about your product specifically. It is about your bank customer's own obligation to know who and what touches its operations, and your form is how it fills in a blank on its own risk register using your words instead of its own. Depending on the bank, the person actually reading your answers might sit in third-party risk, cyber, compliance, procurement, or model risk. Whichever desk it lands on, they are all trying to answer the same basic question: what risk did we take on, and can we show how we manage it.
Why "we keep a human in the loop" isn't enough
A generic claim like that fails for a specific reason: it gives a reviewer nothing to check. Who is the human. What do they look at, and how often. What happens the week that person is out. A risk analyst reading a stack of these forms for a living has learned to read a sentence with no owner, no threshold, and no evidence as a sentence that means nothing has actually happened yet.
The answers that hold up share a shape, not because reviewers reward detail for its own sake, but because that shape is auditable. A control, a named owner, some evidence the control ran, and a date it was last checked is something a reviewer could ask to see. A promise is not.
What the bank can actually test
Here is the part that catches people answering one of these forms for the first time. The bank may not have access to the vendor's underlying model the way it could inspect something built internally. Even when a vendor shares technical documentation, directly evaluating training data or model weights usually isn't the review a third-party risk analyst is performing, and the internals of a model you license from someone else usually aren't yours to hand over even if you wanted to.
So much of the review depends on evidence it can actually test. Much of what it checks is whether you can point to a contract clause granting audit rights, an independent report from someone who already tested the controls, a list of who else touches the data downstream of you, and a record of how you handled a problem the last time one came up. None of that opens the model. All of it tells a reviewer whether your claims are the kind that would survive being tested.12
A documented record of finding and fixing a problem can be more reassuring than a spotless record with no evidence anyone was checking. That's why your track record, with this bank or with anyone, often carries as much weight in this review as your technology does.
What a quiet model swap actually costs them
Depending on your contract, a material change to the model underneath your product may trigger a notification or reassessment. From where you sit that reads like a courtesy. From the bank's side it is closer to a dependency.
A model change that materially changes the service, its behavior, or its risk profile may force the bank to revisit an assessment it already completed and signed off on. If you swap the model and do not say so, the bank has no way to know that assessment is now stale. That gap tends to surface later, at an exam or an audit, in a way that has nothing to do with whether the new model actually performs fine.
What looks like a routine update from your side may be a change-control event from theirs. It turns a documented risk into an undocumented one, on a review the bank is on the hook for, not you.1
Why banks ask harder than everyone else
A retailer buying your workflow tool wants it to work. A bank buying the same tool has a supervisor asking whether the bank knows what it bought. That difference explains why a bank's form runs longer, repeats itself, and keeps circling back to ownership and change control long after you think you already answered the question. The form is not really about your product. It is a piece of the bank's own compliance file, and your section is the part it could not write on its own.
What actually helps
Given all that, the useful move is not writing a more reassuring answer. It is naming what exists: who owns it, what would show a reviewer it ran, and when it last changed. Treat a material model change as something to check against your notification obligations before you ship it. If notice is due, it protects the bank's assessment more than it protects your reputation. And do not read the silence after you submit as disapproval. Most of what happens next is paperwork on the bank's side, not a verdict on yours.
Where Agent Micho Fits
We build the automations these forms end up describing, so ownership, monitoring, and a change log exist from the start instead of getting reconstructed under a deadline. If a questionnaire is asking you for things you cannot currently answer, that gap is usually smaller to close than it looks.
Sources
- Interagency guidance on third-party relationships, Federal Reserve, FDIC and OCC, June 2023. Covers the full relationship lifecycle: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. States plainly that using a third party does not reduce a bank's responsibility for the risk.
- The vendor lifecycle for third-party cybersecurity risk, covering due diligence, contracting, ongoing monitoring, and termination: NYDFS industry letter of October 21, 2025, clarifying 23 NYCRR Part 500.11. It names AI among the technologies this now has to cover, but it is not an AI-specific standard, and it expressly does not impose new obligations.
- SR 26-2, "Revised Guidance on Model Risk Management," Board of Governors of the Federal Reserve System, April 17, 2026. Supervisory guidance rather than a binding rule, applying a risk-based approach to traditional quantitative models and non-generative AI, expected to be most relevant to banking organizations with more than $30 billion in assets, superseding SR 11-7 (2011) and SR 21-8 (2021). The guidance states that generative and agentic AI models are not within its scope, which is why it is cited here only as a narrower, related example rather than the main basis for how banks treat AI vendor risk.
- What the assessment process actually looks like, and why certain answers read as gaps rather than confidence, comes from having sat on both sides of these reviews, not from a published rubric.
A note on the images in this piece: the hero and the listing illustration are both AI-generated.