How Financial Institutions Can Secure Data When Adopting AI

Key Takeaways

• AI gets no security exemption. Customer information in a prompt, a vector database or a chat log is still customer information under GLBA.
• The riskiest moment is often the pilot, when real account data lands in a tool nobody has assessed.
• Anonymizing or tokenizing identifiers before inference removes the most data from scope with the least disruption to the work.
• The April 2026 interagency model risk guidance that replaced SR 11-7 leaves generative and agentic AI outside its scope, so institutions have to set those controls themselves.
• Payment data has its own AI guidance now. The PCI Security Standards Council published Security Considerations for AI Systems in October 2026.
• Incident clocks still run with AI involved: 36 hours for banks to notify their regulator, and 30 days for FTC-covered firms when 500 or more consumers are affected.

None of this argues for slowing down. It argues for doing the data work before the model work, because retrofitting controls later costs more and leaves gaps examiners notice.

Below is what current rules expect and how to apply them at each stage, from the first experiment to agents in production.

Why AI Adoption Changes Where Financial Data Lives

Core banking systems keep customer data in a few guarded places. AI spreads it out. A loan officer pastes a borrower file into an assistant. A RAG pilot turns ten years of call notes into embeddings. A summarization tool may keep prompts in a vendor log for weeks. Each is a new copy that rarely appears in the data inventory.

The data includes account numbers, Social Security numbers, balances, card details and the financial identifiers that make a person easy to find. We have already covered the risks of generative AI for financial institutions before. This guide stays with securing the data as adoption happens.

What Current Rules Already Require

Many teams wait for an AI-specific law, but for US financial institutions most obligations already exist.

The GLBA Safeguards Rule

The FTC's Safeguards Rule, at 16 CFR Part 314, covers non-bank financial institutions such as mortgage lenders, finance companies and many fintechs. Banks follow the parallel Interagency Guidelines Establishing Information Security Standards. The FTC version requires a written risk assessment, access limited to the customer information each person needs, encryption in transit and at rest, multi-factor authentication for anyone accessing an information system, and monitoring and logging of authorized users.

Three parts matter most for AI. Section 314.4(c)(2) asks firms to identify and manage their data and systems, so an AI tool holding customer data belongs in the inventory. The disposal rule expects customer information to be disposed of within two years of its last use for the customer, with stated exceptions, so prompt logs and embeddings need a retention policy too. Section 314.4(f) requires firms to select capable service providers, bind them by contract and assess them periodically, and an AI vendor receiving customer data fits that test.

Incident notification clocks

Two deadlines shape how fast a team must react. Under the computer-security incident notification rule, a bank must notify its primary federal regulator no later than 36 hours after it determines that a notification incident has occurred. A bank service provider, which can include an AI vendor, must notify its bank customers as soon as possible when an incident has materially disrupted or degraded covered services for four or more hours, or is reasonably likely to.

For FTC-covered institutions, the Safeguards Rule requires notice to the FTC no later than 30 days after discovering unauthorized acquisition of unencrypted customer information involving at least 500 consumers. Encrypted data counts as unencrypted if the key was also accessed. Discovery starts when any employee or agent other than the person who caused the breach knows about it. Incidents that nobody detects are easy to miss with AI tools that lack proper logging.

Model risk guidance after SR 11-7

For fifteen years, SR 11-7 was the reference point for model governance at US banks. On April 17, 2026, the Federal Reserve, OCC and FDIC replaced it with revised interagency guidance issued as SR 26-2. The new guidance is risk-based, is expected to be most relevant to banks with more than $30 billion in assets, and states that non-compliance alone will not lead to supervisory criticism.

The part most AI teams miss is a footnote. The agencies say generative and agentic AI models are novel and rapidly evolving and so sit outside its scope, while its principles still apply to traditional and non-generative AI models. The OCC has said the agencies plan a request for information on banks' use of AI. Until then, each institution's own governance has to cover large language models, which is a strong reason to control the data feeding them.

Third-party risk guidance in transition

The 2023 Interagency Guidance on Third-Party Relationships remains in effect. In September 2026 the banking agencies and the NCUA proposed replacing it with a more tailored, risk-based version, with comments due November 16, 2026. Either way, using a third party does not reduce a bank's responsibility. A structured AI vendor evaluation is the practical way to meet that expectation.

Payment Card Data and AI

The PCI Security Standards Council's Security Considerations for AI Systems is advisory, and PCI DSS itself takes precedence where the two differ. It recommends a least agency approach that limits each AI system to the access it needs, a named person who accepts responsibility for AI output, and explicit human approval before an agent with access to cleartext cardholder data takes any action involving that data.

Two scoping points stand out. An AI system with access to tokenized or encrypted card data and also to the tool that detokenizes or decrypts it should be treated as having access to readable data. And contracts with external AI providers should explicitly prohibit using the organization's data for training. Teams handling payment records should read the supplement before card data enters a model and keep keys and passwords out of prompts and logs.

If You Operate in the EU

European operations add two layers. The Digital Operational Resilience Act has applied since January 17, 2025, and most AI services a financial entity relies on will fall under its ICT third-party and incident reporting rules. Our earlier look at DORA and AI risk covers that in depth. Under the EU AI Act, creditworthiness assessment and credit scoring of individuals, along with risk assessment and pricing for life and health insurance, are high-risk uses. After the 2026 Digital Omnibus, the obligations for those Annex III systems apply from December 2, 2027. The 2026 regulation tracker follows the wider timeline.

Securing Data at Each Stage of AI Adoption

Frameworks help organize the work. The NIST AI Risk Management Framework, released on January 26, 2023, groups activities under Govern, Map, Measure and Manage, and NIST added a Generative AI Profile, AI 600-1, on July 26, 2024. When the FFIEC retired its Cybersecurity Assessment Tool on August 31, 2025, it pointed institutions to alternatives such as NIST CSF 2.0, which pairs well with the AI RMF.

Before the pilot: find and classify the data

List the use case, the data it needs and the data it could reach. A fraud triage assistant needs transaction patterns, not full card numbers. A complaints summarizer needs the complaint text, not the customer's date of birth. Sensitive data discovery across shared drives, ticket systems and email shows what an AI connector would actually pull in.

Then label it. Data classification before AI adoption lets you write simple rules such as "restricted data never leaves our network" that engineers can enforce in code.

During the pilot: minimize and anonymize

Pilots go wrong when someone copies production data into a sandbox to save time. Set a rule that pilots run on anonymized, tokenized or synthetic data unless a named risk owner signs off. Prompt anonymization replaces names, account numbers and addresses with placeholders before text reaches the model, then restores them in the response for authorized users.

The method matters. Tokenization keeps a reversible mapping and suits workflows that need re-identification, while irreversible anonymization suits analytics. The trade-offs are laid out in anonymization versus tokenization. Whichever you pick, protect the mapping table as carefully as an encryption key.

Choosing the deployment model

Where the model runs decides how much data leaves your control. Public tools, enterprise SaaS, private cloud and on-premises setups each place the risk differently, and private AI deployment is often the right fit for core banking and wealth data. How Data residency matters too for cross-border clients, since where inference and logs sit can trigger transfer rules.

Going to production: access, logging and monitoring

Production AI should inherit normal identity controls. Use single sign-on and multi-factor authentication, limit retrieval to the documents each user could already open, and keep an audit trail of prompts, retrieved sources and outputs without storing raw identifiers in the logs themselves. For retrieval systems, RAG security depends on enforcing permissions at query time, not at ingestion alone.

Monitoring should also look outward. Employees will try unapproved tools if approved ones feel slow, and shadow AI is a frequent path for customer data to leave a bank.

Agents and automation

Agents act, not just answer. Give each agent its own identity, the narrowest permissions that work, and a clear list of actions that need human-in-the-loop approval, such as moving money, changing customer records or sending external messages. The PCI guidance also advises against combining sensitive data access, external communication and untrusted input in a single agent. AI agent security explores these permission patterns further.

The rules overlap more than they conflict. Each rewards knowing where data is, limiting what can reach it and proving it later. The AI audit checklist is a useful way to gather that evidence before an exam.

Where Questa AI Fits

Most of these controls get easier once the model never sees real customer identities. That is the approach behind Questa AI. Questa Blackbox installs inside the institution's own network, strips or tokenizes identifying information before anything reaches an AI model, and matches responses back to real records on-premises, with single sign-on and full activity logs included.

For a bank or lender, that changes the scoping conversation. Analysts can keep using familiar assistants while account numbers, names and positions stay inside the perimeter. If your teams already use AI on customer files, put an anonymization layer in front of them now, before a pilot quietly becomes production. finance solutions page shows the workflows Questa supports.

Frequently Asked Questions

Conclusion

For financial institutions, the way to secure data when adopting AI comes down to a sequence: know the data, minimize it, anonymize what the model does not need, hold vendors to service provider standards, and log enough to prove all of it. Existing rules already point that way, even where they leave generative AI to the institution's own judgment.

Pick one AI use case that is live or about to launch, trace where its customer data travels this month, and close the first gap you find. Each use case after that gets easier.

This article is for general information only and is not legal, regulatory or compliance advice. Requirements differ by charter and jurisdiction, so confirm obligations with qualified counsel.