Imagine a scenario where an underwriter pastes a borrower’s bank statement into a consumer generative AI tool and asks for a summary of income patterns. Unfortunately, while the answer to the underwriter’s query appeared in seconds of the request, a major compliance problem appeared alongside the answer.
In the foregoing circumstance, as well as a multitude of similar scenarios where a borrower’s nonpublic personal information is transmitted to a third-party platform outside an institution’s vendor-management framework, this creates major compliance issues where there isn’t any negotiated data-use restriction, audit rights, subprocessor controls, retention limits, and assurances that the information will not be used to improve the provider’s models. In fact, the institution may not even have any record that the disclosure occurred. As such, this could very easily be a Gramm-Leach-Bliley Act (“GLBA”) issue, a Safeguards Rule issue and, depending on the borrower’s state of residence and the use case, it may also be a state privacy issue.
The technology is new. The statutes are not. ECOA was enacted in 1974. The Fair Housing Act was enacted in 1968. GLBA became law in 1999. Those laws do not mention large language models, feature weights, model training, or automated decisioning. They still govern mortgage AI deployments. The compliance mistake is assuming the law must be new before the risk becomes real.
For mortgage lenders, GLBA risk in AI systems appears at three operational levels: vendor data flows, employee use of unapproved tools, and model-generated inferences that trigger privacy and fair-lending consequences.
GLBA Reaches The Tool, Not The Buzzword
GLBA requires financial institutions to protect nonpublic personal information and disclose information-sharing practices. The FTC Safeguards Rule requires every covered financial institution to develop, implement, and maintain a comprehensive written information security program. 16 C.F.R. § 314.3(a). The program must be built on a written risk assessment that identifies 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 designed to control those risks, including by identifying and managing the data, personnel, devices, systems, and facilities that support business objectives. 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 16 C.F.R. § 314.4(j), included a duty to notify the FTC as soon as possible, and no later than 30 days after discovery, of a notification event involving the unencrypted customer information of 500 or more consumers. The triggering predicates run on three defined terms: “customer information,” “notification event,” and “service provider.”
Non-bank independent mortgage banks fall squarely within the FTC Safeguards Rule. Depositories and bank affiliates operate under parallel interagency information-security standards. Different regulatory doors, same operational question, which is, “Where does borrower data go, who can use it, and under what controls?”
Every AI tool that processes borrower data implicates that question. 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. A generative AI assistant used to draft adverse-action explanations may ingest NPI and create 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 (reasons disclosed must relate to and accurately describe the factors actually considered or scored).
The institution cannot solve this by calling the system “AI.” Instead, it must map the data and control the disclosure.
Level One: Vendor Data Flows
The first question is what the vendor does with borrower data after the institution sends it. Four facts should be answered in writing before the tool goes live: whether the vendor retains the data, whether the vendor uses it to train or improve models, whether the vendor shares it with subprocessors, and whether the vendor’s retention practices align with the institution’s GLBA obligations.
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 works 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. See 16 C.F.R. § 313.13(a)(1)(ii); 12 C.F.R. § 1016.13(a)(1)(ii).
If model training is not contractually limited to the institution’s service, the disclosure may fall outside the service-provider exception. The institution is then pushed back into the privacy-notice and opt-out regime, with notice and opt-out obligations under 16 C.F.R. §§ 313.7, 313.10 and 12 C.F.R. §§ 1016.7, 1016.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 should now be standard for AI vendors that touch borrower NPI.
First, a data-use limitation: borrower data may be used only to provide the contracted service, with no retention, training, improvement, sale, transfer, or secondary use except as expressly authorized in writing. This is the core of the § 313.13 / § 1016.13 service-provider safe harbor and the § 314.4(f) service-provider oversight obligation.
Second, audit rights: the institution must be able to verify the vendor’s data-handling practices, including subprocessor use and retention.
Third, breach notification: the vendor must notify the institution promptly, preferably within 24 hours, after discovering unauthorized acquisition of borrower NPI. The 24-hour period is a contract standard, not a universal regulatory mandate. It is necessary because the institution may face its own regulatory clocks after discovery, including the FTC’s 30-day notification rule under 16 C.F.R. § 314.4(j) and state cybersecurity–notification regimes.
Fourth, subprocessor control: no borrower NPI should move to a subprocessor without written authorization, flow-down obligations, and visibility into the subprocessor’s role.
A pre-2024 AI vendor agreement that lacks these provisions should not be treated as a solved compliance file. It should be treated as an open GLBA risk item.
Level Two: Shadow AI
The larger and faster-moving risk is shadow AI: employees using consumer AI tools for mortgage work without institutional approval.
The most common example is simple. A loan officer, processor, underwriter, or servicing employee pastes borrower information into a consumer AI tool to summarize, translate, draft, compare, or explain. The employee may be 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 current version of OpenAI’s consumer Privacy Policy (effective June 27, 2025) states expressly that OpenAI “may use Content you provide us to improve our Services, for example to train the models that power ChatGPT,” and directs users to instructions on how to opt out of that use. OpenAI’s Business Terms governing 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 distinction matters. The compliance issue is not whether generative AI can be used. It is whether the institution has moved use into an enterprise environment with negotiated controls and the correct default.
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. The policy must then be enforced. 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 the process. A workable system asks for the tool name, intended use case, data involved, and business purpose, then returns an approval, rejection, or escalation within a defined period.
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 answers to the approved-tool list. The difference is the current shadow-AI footprint.
Level Three: State Privacy Law And AI Inferences
GLBA is the federal floor. State privacy laws may add obligations depending on the borrower’s residence, the institution’s footprint, and the scope of each statute’s GLBA exemption. California, Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Iowa, Tennessee, Delaware, New Jersey, and New Hampshire, among more than 20 states, have operative privacy regimes by mid-2026, though their exemptions and enforcement models differ.
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 can raise even sharper obligations.
This matters beyond privacy. Inferences can become fair-lending evidence. The CFPB’s 2026 Regulation B amendments narrow the agency’s effects-test position under ECOA, but they do not eliminate private litigation theories or Fair Housing Act disparate-impact risk. 91 Fed. Reg. 21,621 (Apr. 22, 2026). 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 battleground. A model that encodes protected characteristics through zip code, surname, language, or behavioral proxies can create the record plaintiffs need in order to argue that the system reproduced protected-class effects.
The institution should not ask only whether it collected protected-class data. Rather, 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 the data, personnel, devices, systems, and facilities that support the institution’s business objectives. 16 C.F.R. §§ 314.3(a), 314.4(b), (c)(2). For AI, that means the institution’s data inventory must include AI tools.
For each AI system, the institution should document five points: what borrower NPI enters the tool; what the tool does with that NPI, including generated inferences; where the data goes after processing, including vendors, subprocessors, and cloud providers; how long the data is retained and under what authority; and which state privacy laws may apply, including whether a GLBA exemption displaces them.
This map becomes the foundation for vendor management under 16 C.F.R. § 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.
First, your institution should immediately issue a written directive prohibiting NPI input into consumer AI tools effective immediately, as well as identify the approved enterprise tools employees may use while the full policy is finalized.
Second, your institution should send data-handling inquiries to every AI vendor that processes borrower NPI, including questions about what data may be getting retained, for how long, for what purpose, through which subprocessors, and whether there are any contractual restrictions on secondary or commercial use of such data.
Third, your institution should run the shadow-AI survey and compare responses to the approved-tool list.
Fourth, your institution should adopt a well-written AI Acceptable Use Policy, require employee acknowledgment, and enforce it.
Fifth, your institution should integrate the AI inventory into the institution’s Safeguards Rule data-flow documentation under 16 C.F.R. § 314.4(b) and (c)(2).
At the end of the day, borrowers that have their bank statements pasted into consumer AI tools, won’t always know it happened. Similarly, the institutions themselves may not know either. As such, GLBA exposure is not waiting for a novel AI statute, as it is already present in the contracts, tools, employee habits, and undocumented data flows operating inside mortgage businesses today.
Old statutes, new models. The gap closes only when the institution maps the data, controls the tool, and governs the disclosure.
