The Statutes Predate the Technology
GLBA became law in 1999. The Fair Housing Act was enacted in 1968. ECOA in 1974. None of these statutes mention large language models, feature weights, or automated decisioning pipelines. They govern mortgage AI deployments regardless.
The compliance error is assuming the law must be new before the risk becomes real.
For mortgage lenders, GLBA exposure in AI systems concentrates at three operational levels: vendor data flows, employee use of unapproved tools, and model-generated inferences that trigger privacy and fair-lending consequences. Each level requires a distinct response. All three can be addressed within 30 days if the institution moves deliberately.
What GLBA and the FTC Safeguards Rule Actually Require

GLBA requires financial institutions to protect nonpublic personal information and disclose information-sharing practices. The FTC Safeguards Rule — which applies directly to non-bank independent mortgage banks — requires every covered institution to develop, implement, and maintain a comprehensive written information security program. 16 C.F.R. § 314.3(a).
That program must rest on a written risk assessment identifying reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information. 16 C.F.R. § 314.4(b). It must implement safeguards controlling those risks, including a documented inventory of data, personnel, devices, systems, and facilities. 16 C.F.R. § 314.4(c)(2). It must also require service providers, by contract, to maintain appropriate safeguards. 16 C.F.R. § 314.4(f).
The FTC’s breach-notification amendment, effective May 13, 2024, added a duty to notify the FTC within 30 days of discovering a notification event involving the unencrypted customer information of 500 or more consumers. 16 C.F.R. § 314.4(j). The triggering predicates turn on three defined terms: “customer information,” “notification event,” and “service provider.” An institution that cannot trace where borrower data went cannot determine whether those predicates are met.
Depositories and bank affiliates operate under parallel interagency information-security standards. Different regulatory doors, same operational question: where does borrower data go, who can use it, and under what controls?
Every AI tool that processes borrower data implicates that question directly.
The Core Problem
The first question is what a vendor does with borrower data after the institution sends it. OCR platforms ingest tax returns. Income-verification tools ingest bank statements. CRMs profile borrower behavior. Pricing engines ingest risk signals. Servicing platforms predict default probability. Each of these is a data-flow event with GLBA consequences.
A vendor that uses borrower NPI to improve a commercial model is not merely performing the contracted service. It is using customer information to build its own product. That creates direct tension with the GLBA service-provider exception under the FTC Privacy Rule, 16 C.F.R. § 313.13, and the parallel CFPB Regulation P, 12 C.F.R. § 1016.13.
The exception functions only when the contract prohibits the nonaffiliated third party from disclosing or using the information other than to carry out the purpose for which the institution disclosed it. If model training is not contractually limited to the institution’s service, the disclosure may fall outside the exception entirely — pushing the institution back into the privacy-notice and opt-out regime under 16 C.F.R. §§ 313.7, 313.10.
Many existing AI vendor contracts do not solve this. Some were signed before the business understood model training as a data-use issue. Others incorporate online terms no one reviewed with GLBA in mind.
Four Contract Provisions That Must Now Be Standard

Data-use limitation. Borrower data may be used only to provide the contracted service. No retention, training, improvement, sale, transfer, or secondary use except as expressly authorized in writing. This is the operational core of the § 313.13 service-provider safe harbor and the § 314.4(f) oversight obligation.
Audit rights. The institution must be able to verify the vendor’s data-handling practices, including subprocessor use and retention schedules. A contractual right to audit is not a luxury — it is a Safeguards Rule requirement.
Breach notification. The vendor must notify the institution promptly — preferably within 24 hours — after discovering unauthorized acquisition of borrower NPI. The 24-hour standard is a contract requirement, not a universal regulatory mandate. It is necessary because the institution faces its own regulatory clocks after discovery, including the FTC’s 30-day rule and state cybersecurity-notification regimes.
Subprocessor control. No borrower NPI should move to a subprocessor without written authorization, flow-down obligations, and institutional visibility into the subprocessor’s role.
A pre-2024 AI vendor agreement that lacks these provisions is not a solved compliance file. It is an open GLBA risk item.
Why This Risk Moves Faster Than Vendor Risk
Shadow AI is the use of consumer AI tools for mortgage work without institutional approval. It is the faster-moving risk because it requires no procurement process, no IT ticket, and no management decision. It requires only a browser and a borrower file.
A loan officer, processor, underwriter, or servicing employee pastes borrower information into a consumer AI tool to summarize, translate, draft, or compare. The employee is trying to work faster. The institution has still disclosed NPI to a third party without vendor diligence, contractual restrictions, audit rights, approved retention terms, or privacy-notice analysis.
Consumer Terms Are the Danger Zone
The distinction between consumer and enterprise AI environments is not semantic — it is the compliance line. OpenAI’s consumer Privacy Policy (effective June 27, 2025) states expressly that OpenAI may use content provided by users to improve its services, including training the models that power ChatGPT. The API, ChatGPT Team, ChatGPT Business, and ChatGPT Enterprise operate on the opposite default: customer content is not used to train OpenAI’s models.
The compliance issue is not whether generative AI can be used in mortgage operations. It is whether the institution has moved that use into an enterprise environment with negotiated controls and the correct default.
The Written AI Acceptable Use Policy

The fix begins with a written AI Acceptable Use Policy. It should prohibit employees from entering NPI into any AI tool not approved by compliance and technology leadership. It should define NPI in plain English, list approved tools, explain how new tools are reviewed, and state consequences for violations. Employees should acknowledge it in writing.
An unenforced policy is not a control. It is evidence the institution knew the risk existed.
The approval process must also be fast. If employees wait weeks for a decision, they will route around it. A workable system asks for the tool name, intended use case, data involved, and business purpose — and returns an approval, rejection, or escalation within a defined period.
Finding the Shadow-AI Footprint
The first inventory should be direct. Survey loan officers, processors, underwriters, closers, secondary-marketing staff, and servicing employees about the AI tools they actually use. Compare the responses to the approved-tool list. The difference is the current shadow-AI footprint.
This survey is not a punitive exercise. It is a data-collection exercise. The institution cannot govern what it cannot see.
The Federal Floor Is Not the Ceiling
GLBA is the federal floor. More than 20 states had operative privacy regimes by mid-2026, including California, Virginia, Colorado, Connecticut, Texas, Oregon, and New Jersey, among others. Their GLBA exemptions and enforcement models differ. The institution’s obligations depend on the borrower’s state of residence, the institution’s geographic footprint, and the scope of each statute’s exemption.
AI makes state privacy analysis harder because models generate inferences. A model may infer likely race, national origin, language preference, immigration status, household composition, financial stress, or default propensity from other data points. California expressly treats certain inferences as personal information when drawn from personal information to create a consumer profile. Inferences involving sensitive characteristics carry sharper obligations still.
The Fair-Lending Dimension
Inferences can become fair-lending evidence. The FHA disparate-impact framework remains governed by Texas Department of Housing and Community Affairs v. Inclusive Communities Project, Inc., 576 U.S. 519, 542–43 (2015), with the Court’s “robust causality requirement” as the operative standard. A model that encodes protected characteristics through zip code, surname, language, or behavioral proxies can create the record plaintiffs need to argue the system reproduced protected-class effects.
A generative AI assistant used to draft adverse-action explanations creates an additional Regulation B problem if the explanation does not accurately identify the specific principal reasons actually considered or scored. See 12 C.F.R. § 1002.9(a)(2), (b)(2); Official Interpretation 9(b)(2)-2.
The institution should not ask only whether it collected protected-class data. It should ask what the model inferred, what proxies it used, whether those inferences affected treatment, and whether the institution can explain and defend the result.
The Operational Answer: AI Data-Flow Mapping

The Safeguards Rule already requires a written information security program built on a written risk assessment and a documented inventory of data, personnel, devices, systems, and facilities. 16 C.F.R. §§ 314.3(a), 314.4(b), (c)(2). For AI, that means the institution’s data inventory must include every AI tool that touches borrower NPI.
For each AI system, the institution should document five points:
- What borrower NPI enters the tool — field level, not category level.
- What the tool does with that NPI — including generated inferences, not only direct outputs.
- Where the data goes after processing — vendors, subprocessors, cloud providers, and any downstream systems.
- How long the data is retained and under what authority — contractual, regulatory, and operational retention schedules.
- Which state privacy laws may apply — including whether a GLBA exemption displaces them for each relevant borrower population.
This map becomes the foundation for vendor management under § 314.4(f), privacy analysis, Safeguards Rule documentation, incident-response readiness under § 314.4(j), and examination defense.
An institution that can produce an AI data-flow map in the first hour of an examination signals control. An institution that needs three weeks to assemble one signals paper compliance.
30 Days to Close the Largest Gap

The largest immediate exposure can be reduced in 30 days through five sequential actions.
Day 1–2: Issue a written interim directive. Prohibit NPI input into consumer AI tools effective immediately. Identify the approved enterprise tools employees may use while the full policy is finalized. This stops the bleeding before the map is drawn.
Days 3–7: Send data-handling inquiries to every AI vendor processing borrower NPI. Ask what data is retained, for how long, for what purpose, through which subprocessors, and whether any contractual restriction limits secondary or commercial use. The responses will identify which vendor agreements require immediate renegotiation.
Days 5–10: Run the shadow-AI survey. Survey all operational staff — loan officers, processors, underwriters, closers, secondary-marketing, and servicing. Compare responses to the approved-tool list. Document the gap.
Days 10–20: Adopt and enforce the AI Acceptable Use Policy. Require written employee acknowledgment. Establish the fast-track approval process for new tool requests. Enforce the policy from the date of adoption.
Days 15–30: Integrate the AI inventory into Safeguards Rule documentation. Map each AI tool against the five data-flow points above. Incorporate the map into the institution’s written risk assessment under 16 C.F.R. § 314.4(b) and (c)(2). Identify open vendor-contract gaps and assign remediation timelines.
Closing Reflection
Borrowers whose bank statements are pasted into consumer AI tools will not always know it happened. The institutions themselves may not know either. That is precisely the nature of the exposure.
GLBA compliance for mortgage AI is not waiting for a novel statute. The risk is already present in the contracts, tools, employee habits, and undocumented data flows operating inside mortgage businesses today. The statutes are old. The models are new. The gap between them closes only when the institution maps the data, controls the tool, and governs the disclosure — deliberately, in writing, and before the examination begins.
Comments (0) No comments yet
Want to join this discussion? Login or Register.
No comments yet. Be the first to share your thoughts!