SR 26-2 vs GLBA Safeguards: Which Governs Customer Data in Bank AI Prompts?
Neither replaces the other. SR 26-2, the Federal Reserve's revised model risk management guidance, governs how a bank manages models. GLBA security requirements govern how a bank safeguards customer information, including nonpublic personal information, wherever it is handled. A prompt that contains customer data is a customer information question first, and the AI system that receives it is a model risk question. Treat this as a scoping and control-mapping exercise with two owners, not a choice of one regime.
Mapping prompt-level obligations to runtime controls
- 1
Allow
The data class is permitted for this tool and use case under written policy. Record the policy version and the decision.
- 2
Redact
Nonpublic personal information is removed or masked before the prompt reaches the model, or before a response reaches the user.
- 3
Block
The data class is not permitted for this destination, such as a third-party model without completed service provider assessment.
- 4
Escalate
A defined case goes to a named human approver, and the approval, approver and timestamp become part of the record.
Evaluation criteria for prompt-level data controls
- Can it enforce allow, redact, block and escalate-for-approval decisions before data reaches a model or a user?
- Does it detect nonpublic personal information in unstructured text, and are false positives and negatives measured?
- Does each decision record the policy version, data classes detected, action taken, approver and timestamp?
- Are retention period, export format and data residency configurable to the bank's requirements?
- Does it support service provider risk assessment for third-party model providers?
- Can its records support both model risk documentation and information security program documentation, including incident scoping?
What each regime regulates
The two sources differ in issuer, legal basis and subject matter. SR 26-2 is a Federal Reserve supervisory letter titled Revised Guidance on Model Risk Management, dated April 17, 2026. It states that the revised guidance highlights sound principles for effective model risk management, while recognizing that practices appropriately vary among banking organizations based on their risk profiles and model usage. GLBA's security standards sit in a different place: they are rules and guidelines under the statute's security pillar, which covers practices to safeguard information from unauthorized access, use and disclosure.
The label "GLBA Safeguards Rule" needs scoping for banks. The FTC Safeguards Rule (16 CFR part 314) applies to financial institutions under FTC jurisdiction. Banks supervised by the Federal Reserve are addressed by the interagency information security guidelines, codified by the Fed at 12 CFR Part 208 Appendix D-2 for banks and Part 225 Appendix F for bank holding companies and covered nonbank subsidiaries. The comparison below applies to both, noting where they differ. Status is as of November 2026.
- Issuer and basis: SR 26-2: Federal Reserve supervisory guidance. GLBA security: FTC rule for FTC-jurisdiction institutions, and interagency guidelines for banks.
- Subject matter: SR 26-2: model risk management principles. GLBA security: an information security program protecting customer information.
- Scaling principle: SR 26-2: practices vary by risk profile and model usage. Interagency guidelines: a written program appropriate to size, complexity and the nature and scope of activities.
- Customer data: SR 26-2: no prompt-level customer data text is relied on here. GLBA security: customer information is any record containing nonpublic personal information, handled by or on behalf of the institution.
- Third parties: GLBA security (FTC rule): institutions must take steps to ensure service providers safeguard customer information in their care.
- Typical owner: SR 26-2: model risk management. GLBA security: information security. This split is an internal choice, not a mandate.
Where they overlap and where each is silent
The overlap is practical rather than textual. An AI assistant that accepts employee prompts is both a system the bank may need to treat as a model and a channel through which customer information is handled. The Safeguards Rule defines customer information by the record, not the tool: any record containing nonpublic personal information, handled or maintained by or on behalf of a financial institution. A prompt carrying that data is therefore customer information whether it goes to an internal assistant or a third-party model API. The FTC describes the information security program as covering how an institution accesses, collects, distributes, processes, stores, uses, transmits and disposes of customer information. That language is broad enough to read onto prompt transmission and response storage. This is an interpretation, because the GLBA text is technology-neutral and does not mention AI.
The gaps run in both directions. GLBA security requirements do not ask whether a language model is conceptually sound, validated or appropriately used; they ask whether customer information is protected. SR 26-2 is built around model risk management and its stated principle is risk-based variation by model usage, so how it applies to a given assistant depends on the bank's own model definition, inventory and documented rationale for each use case. Neither document prescribes a specific prompt control such as redaction. Those are design choices a bank must justify against both frameworks.
The 2021 amendments to the FTC rule, effective January 10, 2022, added detail on access controls, authentication and encryption. These are the closest sourced hooks for runtime controls. Separately, a 2023 FTC amendment requires FTC-jurisdiction institutions to report a notification event, meaning unauthorized acquisition of unencrypted customer information involving at least 500 consumers. That makes prompt-path records relevant to incident scoping.
Ownership and examiner evidence
The sourced material does not say that SR 26-2 allocates ownership of prompt-level customer data handling, so any split is the bank's decision. A workable arrangement assigns the information security function ownership of data handling controls and service provider assessment, and the model risk function ownership of inventory, use-case rationale and ongoing oversight of the AI system. Document how they coordinate, and who decides when a prompt control change alters a model's risk profile. Accountability for service providers stays with the institution regardless of who supplies the model.
Examiner evidence expectations for AI are not spelled out in the guidance discussed here, so plan evidence from first principles. Under the information security lens, a defensible set shows the written program and its data class policy, an inventory of AI entry points that can receive customer information, risk assessment coverage of those entry points and their service providers, and per-interaction records of what was allowed, redacted, blocked or escalated. Under the model risk lens, it shows the AI use case in inventory, the risk-based rationale for its use, and the same decision records demonstrating the system operated within its approved limits. One evidence stream that serves both documentation sets reduces reconciliation work.
Where Trussed fits
Trussed enforces policy in the execution path across models, agents, tools and AI sites, with decisions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it produces audit-ready evidence of what the AI was allowed to do and what it did. Deployment is self-managed in the customer cloud, with configurable retention and data residency.
That approach addresses the evidence gap described above, but it does not decide scope or ownership for you. Trussed is deepest in insurance, a regulated financial sector, and its production record includes 18+ months of continuous operation in a regulated enterprise and 100+ models under one policy plane. Its evidence is mapped to frameworks such as NAIC, NYDFS and NIST. Its value for a bank is framed through examiner scrutiny, model risk management and evidence, and any fit should be tested against the criteria in the previous section.
One prompt, two supervisory lenses
Prompt with customer data
Free text that may contain nonpublic personal information.
GLBA security lens
Is customer information safeguarded when handled, transmitted and stored?
SR 26-2 lens
Is the AI system managed as a model, with risk-based rationale for its use?
Runtime decision
Allow, redact, block or escalate, with evidence of what happened.
Map your prompt controls to both regimes
Walk through your AI entry points, data classes and evidence requirements with a Trussed expert.
Talk to an Expert