Because scope exclusions do not remove legal, conduct, privacy, or third-party obligations. A bank still owns what the system does, what data it handles, and what vendors supply it. If an AI assistant misstates customer information, writes a harmful narrative, or exposes data, supervisors can still treat that as unsafe or unsound practice or a violation of law.
Why scope exclusions do not remove supervisory accountability
SR 26-2 may narrow a banking agency's AI-specific expectations, but it does not erase the bank's duty to run a safe, sound business. Supervisors still look at outcomes: whether the system is reliable, whether customers are treated fairly, and whether the bank can explain and control what the tool does in production.
That is why a generative AI use case can remain supervisory concern even when the guidance text does not directly govern it. If the bank deploys the tool, the bank owns the control environment around it, including approvals, oversight, testing, and the decision to allow it in the first place.
What still creates risk when the AI model itself is outside the scope
The risk does not come only from model governance. It also comes from conduct errors, privacy exposure, vendor dependency, and weak operational controls around the way staff or customers use the system. A bad answer, a misleading summary, or an unsafe automated action can create the same supervisory problem as a more traditional control failure.
That is why the bank must assess the use case end to end, not just ask whether the underlying model is named in the rule. The relevant question is whether the bank is creating customer harm, data exposure, misleading communications, or unmanaged third-party reliance.
The pattern is familiar in broader AI governance. The AI Risk Assessment Guide is useful here because the real issue is not the label on the model, but the risk profile of the use case, the data it touches, and the control that remains around it.
Why banks should treat generative AI as a conduct, privacy, and third-party issue
When an assistant writes a harmful narrative, misstates customer information, or leaks confidential material, the failure is not only technical. It can implicate disclosure duties, complaint handling, recordkeeping, customer communications, and outsourcing oversight. Those are all familiar supervisory lenses even when AI is only one part of the chain.
Vendor structure matters for the same reason. If a third party provides the model, hosting, prompt layer, or retrieval service, the bank still needs to understand what data is sent out, how it is retained, and what contractual and monitoring rights exist. The bank cannot outsource accountability, only some execution.
That is also why privacy and vendor controls stay relevant even when a banking bulletin does not explicitly cover the model. The Third-Party AI Risk Guide helps frame the obligation that remains with the bank, especially around retention, training restrictions, and supplier oversight.
When customer data is involved, the privacy dimension can become the dominant supervisory concern. The AI and Privacy Guide is relevant because AI output quality and data handling are inseparable when the system may reveal, infer, or echo personal data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, Manage | GenAI bank use cases need risk scoping and lifecycle oversight beyond scope exclusions. |
| Recommendation — Map the use case, measure its harms, and manage it as an enterprise AI risk. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Supervisory concern includes whether harmful AI outputs and decisions are reviewed and explainable. |
| IA-5 — Authenticator Management | AI assistants often rely on credentials or tokens that still require lifecycle control and revocation. | |
| Recommendation — Review AI activity and exception handling so harmful outputs are detectable and traceable. Rotate and revoke credentials used by AI services before they become a standing exposure. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party AI services can still create bank accountability through supplier dependence and data sharing. |
| Recommendation — Impose supplier controls that define retention, usage limits, and oversight rights for AI vendors. | ||
| GDPR | Article 5 — Principles relating to processing of personal data | AI assistants that touch customer data can create privacy and purpose-limitation obligations. |
| Recommendation — Limit AI data use to what is lawful, necessary, and transparent for the specific banking purpose. | ||
Practitioner Guidance
What to verify: Confirm whether the use case can affect customer communications, regulated disclosures, or personal data before deciding it is low risk. If the answer is yes, the control question is not whether the model is in-scope, but whether the bank can supervise the outcome and evidence that supervision.
Decision rule: If the tool can speak to customers, summarize regulated content, or process bank data, treat it as a governed business service with documented approval, testing, and monitoring. If it is only a sandbox experiment with no production data or customer impact, the supervisory burden is lower, but the exit criteria should still be explicit.
What practitioners underestimate: The highest exposure often comes from ordinary use, not exotic model failure. A well-tuned assistant can still create unsafe practice if staff rely on it without review, if vendors retain prompts, or if output is reused as if it were approved advice.
Practitioner takeaway: Scope exclusions can narrow the rulebook, but they do not narrow the bank's duty to control customer harm, data handling, and third-party exposure.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- When does a short-lived API key still create material risk?
- How should banks build an AI cyber risk action plan that stands up to supervisory review?
- Why does on-device AI in iOS 26 still create privacy risk for sensitive user data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org