AI and GLBA Compliance: Customer Financial Data in AI Systems

Banks, lenders, insurers, and other financial institutions are deploying AI into the workflows that hold the most sensitive customer information: servicing, underwriting, collections, and fraud. The privacy and safeguards obligations that govern that information do not pause for AI; they extend to prompts, retrieval indexes, agent memory, logs, and the vendors and model providers behind the systems. This guide covers how, drawing on FISTA Solutions' AI enablement practice. The broader control framework is in the AI controls for financial services whitepaper and a domain example in ai in lending. This article is general guidance, not legal advice; institutions should confirm obligations with counsel and compliance.

Where does nonpublic personal information reach AI systems?

Component	Examples	Obligation
Prompts	Customer questions with account details; agent queries	Minimization; access control
Retrieval indexes	Statements, applications, correspondence embedded for assistants	Encryption; permission trimming; retention
Agent memory	Stored customer facts and history	Purpose limits; deletion
Logs and traces	Prompts, outputs, retrieved content	Redaction; retention; access control
Model providers	Data sent to APIs	Service provider oversight; contracts
Outputs	Summaries, decisions, communications	Accuracy; human oversight

How should AI vendors and model providers be overseen?

As service providers under the safeguards program: due diligence on their security practices and certifications, contracts requiring appropriate safeguards and limiting use to the institution's purposes, prohibition on training with customer data, flow-down to subprocessors including model providers, breach notification, and periodic reassessment. Verify terms for the exact service tier in use. The risk program is in ai third party risk management and the questionnaire in the ai vendor security questionnaire.

Which security program controls must cover AI components?

Access controls and least privilege for retrieval and tools, so assistants read and act only within the caller's permissions; encryption in transit and at rest for indexes, memory, and logs; monitoring and logging of AI activity with redaction; multi-factor authentication for AI system administration; secure development and change management for prompts and models; regular testing including adversarial tests; and secrets management for provider keys. Access design is in ai access control and architecture in ai and zero trust architecture.

What should the risk assessment include?

AI-specific threats alongside conventional ones: prompt injection that exposes customer data or triggers tool misuse; leakage through outputs, logs, or memory; over-broad retrieval; vendor and model changes that alter behavior; and over-reliance on AI outputs in customer-affecting decisions, each with likelihood, impact, control, and owner. Model risk management applies to AI models used in decisions. Leakage controls are in ai data leakage prevention and model risk in ai model risk management.

How do notices and sharing rules apply?

Privacy notices describing categories of information shared and with whom must reflect AI vendors and uses; sharing with AI service providers must fall within permitted exceptions or the notice; and opt-out rights where applicable must be honored across AI systems. Notices written before AI adoption should be reviewed against actual data flows. Transparency practice is in ai transparency notices.

How should incident response cover AI?

Incident plans should define AI events: leakage of customer information through outputs or logs, injection incidents, unauthorized tool actions, and vendor incidents affecting customer data; with detection through AI monitoring, containment through gateway controls and fallbacks, assessment of affected customers, and notification obligations. Disclosure practice is in ai incident disclosure.

What records demonstrate compliance?

An inventory of AI systems with the customer information each processes; service provider due diligence and contracts; the risk assessment with AI threats; control testing results including adversarial tests; access reviews; monitoring evidence; training records; and incident records. Examiners increasingly ask for these. Broader privacy practice is in ai data privacy compliance.

What mistakes are common?

Model provider APIs treated as outside the service provider program; retrieval indexes unencrypted or unfiltered by permission; logs retaining customer data indefinitely; risk assessments that omit AI threats; notices unchanged after AI adoption; and no adversarial testing of customer-facing assistants. Each is a finding an examiner can reach quickly.

What does compliant practice look like?

A lender deploying a servicing assistant inventories the customer information it touches, applies permission-trimmed retrieval and encryption to the index, redacts and retention-limits logs, signs service provider terms with training prohibitions and subprocessor flow-down, adds AI threats to the risk assessment with controls, runs adversarial tests before launch and after model changes, updates its notice, and defines AI incidents in its response plan. Examiners receive the inventory and evidence on request.

How FISTA Solutions helps financial institutions with AI compliance

FISTA Solutions builds AI systems for financial institutions with permission-aware retrieval, encryption, redacted logging, least-privilege tools, adversarial testing, and audit trails, and helps clients extend service provider oversight and risk assessments to AI. The AI enablement practice leads controls design, AI agents ship with the safeguards, and forward deployed engineers embed with client compliance and security teams. The record behind the approach is 150+ projects with 99.9% uptime.

To deploy AI on customer financial data within your safeguards program, message FISTA on WhatsApp, or read the AI controls for financial services whitepaper for the full control set.