Applying One Set of NPI Handling Rules to AI Across Every Bank Business Line

What a single NPI standard has to say before it can be enforced

Retail, commercial, wealth, lending and servicing teams each adopt AI through their own tools, vendors and prompts. When each line interprets the NPI requirement separately, the same customer data is redacted in one workflow, passed along in another and shared with a third-party model in a third. Written policy does not settle this, because it does not show what a model, agent or tool call was actually allowed to do in a given interaction.

The regulatory anchors are familiar. GLBA safeguards standards call for reasonable administrative, technical and physical safeguards for the security, confidentiality and integrity of customer information. Those standards appear in the Interagency Guidelines for banks and in the FTC Safeguards Rule, 16 CFR Part 314, for institutions under FTC jurisdiction. The Privacy Rule governs when and how banks may share NPI about consumers with nonaffiliated third parties, and it requires notices covering the categories of information collected and disclosed. OCC testimony states that banks must meet applicable privacy and information security requirements when they use AI. As of November 2026, the material reviewed shows these rules as current.

The Privacy Rule's logic already contains conditions a machine can check: the category of information, whether the recipient is an affiliate or a nonaffiliate, whether an exception applies, and the customer's opt-out status. A usable standard adds the purpose of the interaction and states an outcome for each combination: allow, redact, block or escalate. Which exception applies to a given disclosure is a legal determination. Counsel should make it once, and the result should be encoded in the rule rather than left to each team.

Define the shared rule set, then scope business lines and exceptions

Start from the bank's GLBA program and write the canonical standard in four parts: the NPI categories in scope, the permitted recipients (including third-party models and vendor tools), the permitted purposes, and the required outcome for each. Keep the rules specific enough to test. A rule such as 'account numbers must not appear in prompts sent to externally hosted models unless masked' can be checked with sample inputs. A rule such as 'handle customer data responsibly' cannot.

Then inventory the AI tools, vendors and prompts in each business line and map each to the rule set. Customer-facing and servicing uses deserve early attention because they sit closest to NPI. Treat every path as one of three cases: it sits under the enforcement layer, it has compensating controls approved by the accountable owner, or it is a gap to close. Contracted activities are treated as the bank's own and vendors need ongoing oversight, so vendor-hosted tools outside the bank's own path need contract controls at a minimum.

Business-line differences should not become separate rule sets. Record each one as an exception with a named owner, a stated reason, the rules it modifies, an expiry date and a review trigger. A wealth team that legitimately needs a different outcome for a specific purpose then holds a documented deviation from one standard, and the rule set remains the single thing an examiner has to read. Assign an accountable owner for the canonical standard itself, and bring model risk management, cybersecurity and the business lines into one change process.

• NPI categories, permitted recipients, permitted purposes
• One outcome per combination: allow, redact, block or escalate
• Exceptions with owner, reason, scope, expiry and review trigger
• Per-line inventory of tools, vendors and prompts mapped to the rule set

Specify the evidence that shows the rules were applied

Examiners and model risk management teams ask the same underlying question: for this interaction, what was the system allowed to do, and what did it do? A policy document answers the first half. Evidence generated by enforcement answers both. The specification below is practitioner design, to be agreed with your supervisors and internal audit rather than treated as a prescribed format.

Each decision record should identify the interaction or tool call, the business line, the acting user or agent, the destination model or tool, the version of the rule set, the rules evaluated, the action taken and the time. Where an exception applied, the record should carry the exception identifier. Where a human approved an escalation, it should carry the approver and the outcome. Records of this kind can be sampled by an examiner without relying on anyone's recollection.

Evidence should also cover the tests. Keep a suite of sample NPI inputs with expected outcomes, run it on a schedule and after any change to a model, prompt, vendor or tool, and retain the results. This addresses the testing and monitoring expectation directly and shows that the rules still work after change.

Set retention and data residency by the bank's own records policy, and map the evidence fields to the GLBA program first. Mapping to NIST AI RMF, NYDFS or other frameworks then becomes a matter of tagging the same records to additional controls. Model risk management principles are described as technology-agnostic and may not fully fit some AI tools, so document how NPI enforcement complements model validation rather than replacing it.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions include allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Enforcement runs at runtime, not after the fact, and it generates audit-ready evidence mapped to frameworks including NYDFS and NIST. Deployment is self-managed in the customer's cloud, with configurable retention and data residency.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic and more than 100 models under one policy plane. Its customers are in insurance, pharma, healthcare and education, and insurance is where it is deepest. The approach in this guide does not depend on any particular product, and the rule set, exception process and evidence specification remain the bank's own to define.