GLBA and AI

The pain GLBA AI compliance is causing our customers

Financial institutions deploying AI face a stacked compliance environment. GLBA governs customer data. SR 11-7 governs models. FCRA/ECOA govern credit decisions. UDAAP governs consumer treatment. State laws add more. AI runs across all of these categories simultaneously. When a financial institution adds AI to fraud detection, credit decisioning, customer service, or marketing, every applicable law comes with it. GLBA is the baseline data protection layer that most institutions built compliance around, and adding AI stresses that layer.

What GLBA AI compliance requires

The Safeguards Rule

Financial institutions must develop, implement, and maintain a written information security program. The FTC updated the Safeguards Rule in 2021 with more specific requirements: risk assessment, access controls, encryption, multi-factor authentication, monitoring, and incident response. AI systems processing NPI must be integrated into the security program.

The Privacy Rule

Financial institutions must provide privacy notices explaining information practices, offer opt-out rights (in some cases), and limit sharing of NPI with non-affiliated third parties. AI vendors receiving NPI are third parties subject to these constraints unless service-provider exceptions apply.

The Pretexting Provisions

Prohibit obtaining customer information under false pretenses. AI voice cloning and deepfake attacks against financial institutions raise pretexting concerns that GLBA anticipates.

Third-party oversight

Financial institutions remain responsible for how their AI vendors handle NPI. Vendor management, contract terms, and ongoing monitoring are Safeguards Rule requirements.

Interaction with other frameworks

GLBA sits alongside SR 11-7 for banks, CFPB enforcement for consumer finance, and state financial regulator oversight. NAIC has issued AI guidance for insurance that layers on top of GLBA. Compliance programs must integrate across all applicable frameworks.

Why GLBA AI compliance matters to you

Every financial institution subject to GLBA is subject to the enhanced Safeguards Rule. The FTC and functional regulators (Federal Reserve, OCC, FDIC, NCUA, state insurance commissioners) enforce GLBA. Enforcement can produce substantial civil penalties and consent orders. Adding AI without integrating into GLBA compliance is a documented enforcement risk.

What the research says about GLBA AI

The academic literature on GLBA AI is ahead of most corporate practice, and it is unusually blunt. Two findings are worth putting in front of any executive who thinks this is a compliance formality.

“ML can be less transparent and explainable than traditional regression models, which may raise unique questions about compliance”

Brotcke, Journal of Risk and Financial Management (2022)

That is the gap between having AI and governing it. The second finding is the one that tends to change the room.

“Effective data governance is important for minimizing data breach activity and mitigating bias”

Pahune, Rewatkar et al., Big Data and Cognitive Computing (2025)

Neither of these is a fringe position. Both come from peer-reviewed work, and both describe the condition most organisations are actually in when the question about GLBA AI arrives from the board, the buyer, or the regulator.

How to get compliant with GLBA and AI: a 5-step path

This is the sequence that works, and it is not the sequence most organisations choose. They start with the framework and work backwards toward reality. Start with reality.

1. Inventory the AI in scope. List every AI system that could fall under GLBA AI. Record what it does, what decision it influences, what data it touches, and who owns it. You cannot govern AI you cannot name, and almost every organisation we assess is running more AI than its leadership believes.
2. Determine whether you are actually in scope. Work out precisely which of your AI systems and activities GLBA AI reaches, and write the determination down with its reasoning. Do this in writing. A documented scope determination, right or wrong, is defensible. An undocumented assumption is not.
3. Assign one accountable owner. Name a person, not a committee, with the authority to stop a deployment. Governance without someone who can say no is documentation, not control.
4. Build the evidence file. Assemble the documentation GLBA AI expects: the scope, the risk assessment, the controls, the testing evidence, and the incident record. Assemble it before anyone asks. Reconstructing it under a regulator's deadline costs several times more and looks exactly like what it is.
5. Set a review cadence and hold it. Re-run the assessment on a schedule and after any material change to the model, the data, or the use case. Alignment decays. A control tested once is a snapshot, not a control.

Done in this order, GLBA AI becomes tractable. Done out of order, it becomes a document nobody uses and a control nobody exercises.

Frequently asked questions about GLBA AI compliance

Does GLBA apply to fintechs?

Yes. GLBA applies to any entity significantly engaged in financial activities, which reaches many fintechs.

Are AI vendors third parties under GLBA?

Vendors processing NPI on behalf of the institution generally fall within service-provider exceptions if properly contracted. But third-party oversight obligations still apply.

How does GLBA AI interact with state financial privacy laws?

Many states have their own financial privacy rules that impose additional obligations. California's CCPA/CPRA reaches financial services in some contexts. State insurance departments have their own rules.

Where does GLBA AI compliance fit in SRJ's work?

The financial services sector-rules addendum in Volume III of The Operating Discipline for AI Library™ addresses GLBA-specific AI compliance, alongside SR 11-7 and CFPB coverage.

The stacked-compliance problem in GLBA AI

A bank adding AI to fraud detection is not doing one compliance exercise. GLBA governs the customer data. SR 11-7 governs the model. ECOA and FCRA govern any decision that touches credit. UDAAP governs how the customer experiences the outcome. State law adds more. GLBA AI compliance is the data protection floor beneath all of it, and it is the one most institutions assume is already handled because they handled it years ago for systems that were not AI.

What the updated Safeguards Rule actually changed

The 2021 revision made the requirements specific rather than aspirational. Written risk assessment. Access controls with least privilege. Encryption of NPI at rest and in transit. Multi-factor authentication. Continuous monitoring or annual penetration testing plus biannual vulnerability assessments. A named qualified individual accountable for the program. Incident response plan. Each of these applies to AI systems processing NPI exactly as it applies to a core banking platform.

Third parties are where GLBA AI exposure concentrates

Most financial institutions do not build their AI. They buy it, and the vendor sees the data. The Safeguards Rule holds the institution responsible for that vendor's handling of NPI. Contracts must impose safeguards, permit oversight, and require incident notification. An AI vendor who cannot describe how NPI is segregated, retained, and deleted is a finding waiting to happen.

Primary sources on GLBA AI

The authoritative texts and agency pages behind this summary. We keep this page current, but where a compliance decision turns on exact wording, read the source. Anything concerning GLBA AI that carries legal consequence should be confirmed against the enrolled text or the issuing body, not against a secondary summary, including this one.

• FTC, Gramm-Leach-Bliley Act