Data Security for AI in Finance: Protecting Financial Data

By Jane Ha · Updated Oct 11, 2026

Data security for AI in finance is the set of rules, technical controls and vendor checks that keep ledgers, bank details, payroll, customer records and unreleased results from ending up where they shouldn't be when you use AI tools. The risk isn't that AI is uniquely dangerous. It's that AI makes it easy to paste a whole spreadsheet into a box, connect a tool to the general ledger in five minutes, or send documents to a service in another country without anyone deciding that on purpose.

This guide is for CFOs, controllers, finance operations managers and security leads who are about to expand AI use across accounts payable, FP&A, treasury or the month-end close. It covers the four exposure points that matter most (leakage, access, vendor terms and data location), then gives you a sequence to put safeguards in place.

Key Facts

• The US Safeguards Rule requires covered financial institutions to put in place access controls, encrypt customer information held or transmitted, require multi-factor authentication for anyone accessing an information system, and oversee service providers (16 CFR 314.4).
• The same rule requires notifying the FTC when an event involves the information of at least 500 consumers, no later than 30 days after discovery (16 CFR 314.4(j)).
• OWASP lists sensitive information disclosure as a top risk for LLM applications, naming financial records among the data types at stake, and recommends sanitization, least-privilege access controls and user education (OWASP LLM02:2025).
• IBM's Cost of a Data Breach Report 2026 puts the global average breach cost at $4.99 million, a 12% rise on the year before (IBM).
• Under GDPR Article 44, personal data may be transferred to a third country only if the controller and processor meet the conditions in Chapter 5 (GDPR Art. 44).

Why Financial Data Needs Its Own AI Rules

Finance holds the data that's most expensive to lose: bank account numbers, payment files, payroll, tax identifiers, customer credit information, board-level forecasts and numbers that haven't been announced. Some of it is regulated, some of it is contractually confidential, and some of it is simply the kind of thing that moves markets or invites fraud.

In the US, the Gramm-Leach-Bliley Act sets the baseline for financial institutions. Congress described an "affirmative and continuing obligation" to protect the confidentiality of customers' nonpublic personal information, and directed regulators to set standards for administrative, technical and physical safeguards (15 U.S.C. 6801). Even if your company isn't a bank, your customers, lenders and auditors may flow those expectations down to you by contract.

AI changes the exposure in three ways. It lowers the effort needed to move data (upload a file, connect an API). It creates new copies of data in places finance never used to look, such as prompt logs, vector indexes and vendor-side storage. And it adds an interface, natural language, that people trust more than they should. If your data foundations aren't settled yet, start with finance data readiness for AI, then come back here.

The Four Places Financial Data Escapes

1. Leakage through prompts and uploads

The simplest leak is also the most common: a well-meaning employee pastes something sensitive into a public AI tool. A documented example is Samsung. In April 2023, engineers uploaded internal source code to ChatGPT, and the company then barred staff from using generative AI tools on company networks and devices. Its memo said data sent to such services is hard to retrieve or delete (The Wrap). That wasn't a finance team, but swap the source code for a supplier bank file or an unreleased forecast and the failure is identical.

Finance versions of this look like:

• An AP clerk uploads a vendor master export to get duplicates flagged.
• An analyst pastes a draft earnings narrative into a chatbot to tighten the wording.
• A controller drops a trial balance into a free tool to draft flux commentary (see AI variance analysis).

OWASP describes the broader category as sensitive information disclosure, where an LLM or its application exposes personal data, financial records, credentials or confidential business data through its outputs (OWASP LLM02:2025). The same page points to sanitizing data before it reaches the model, restricting data sources and educating users.

2. Over-broad access

An AI assistant connected to your ERP or document store (see AI in ERP systems for what those embedded assistants do) usually inherits whatever the connecting account can see. If that's an admin credential, the assistant can surface payroll to a user who'd never get access to the payroll module. The Safeguards Rule's answer is classic: implement and periodically review access controls, and authenticate and limit users to the data they need (16 CFR 314.4(c)(1)). It also calls for multi-factor authentication for any individual accessing any information system (314.4(c)(5)), which includes the AI tool's own console.

The pattern to avoid is a single shared service account with broad read access. The pattern to use is permissions that follow the person asking, so the assistant only retrieves what that person could open anyway. Our guide to data classification for AI access shows how to tier data so those permissions are easy to set.

3. Vendor terms and the supply chain

Every AI vendor is a service provider that touches your data. The Safeguards Rule expects you to select providers capable of maintaining appropriate safeguards, require those safeguards by contract, and periodically assess them (314.4(f)). For AI tools, the contract is where most of the real risk lives, because defaults differ by plan and product. Check these in writing, for the specific product and tier you're buying:

• Training use. Can your inputs or outputs be used to train or improve models? Is that off by default, and who can change it?
• Retention. How long are prompts, files and outputs stored? Can you set it, and can you delete on request?
• Subprocessors. Which other companies (model providers, hosting, support tools) can see your data, and how are you told about changes?
• Human review. Can vendor staff read your content for abuse monitoring or support, and under what conditions?
• Security attestations. Which independent reports cover the service, and do they cover the exact product you're using?
• Breach notice. How fast must the vendor tell you, and in what format? You may have a regulatory clock of your own.
• Exit. What happens to your data and any indexes built from it when you leave?

Treat a shift from a "free" or personal plan to a business plan as a different contract, not an upgrade of the same one.

4. Where the data lives

Data residency is the question of which country's servers hold your data, and where support staff and subprocessors can access it from. It matters because personal data about people in the EU can't flow freely to any destination. GDPR Article 44 allows transfers to a third country only when the conditions in Chapter 5 are met, and those conditions extend to onward transfers (GDPR Art. 44). Customer contracts, banking agreements and local rules can add their own location requirements.

Ask vendors three things: where is data stored, where is it processed (these can differ), and from where can personnel access it. If a tool calls a model hosted in a different region than the app itself, that's a transfer you need to account for.

Matching Controls to Finance Functions

How to Protect Financial Data in AI Tools, Step by Step

1. Map what data you have and where it flows. The Safeguards Rule starts from identifying and managing the data, personnel, devices, systems and facilities that matter (314.4(c)(2)). Add every AI tool to that map, including features switched on inside existing software.
2. Classify the data. Use three or four tiers, for example public, internal, confidential and restricted. Decide which tiers can go to which categories of tool. Write it in one page people will read.
3. Publish an approved-tools list and a short rule set. Say what's allowed in approved tools, what's never allowed anywhere (credentials, full bank account numbers, tax IDs), and who to ask. Pair it with your wider AI use policy so there's one source of truth.
4. Provide a good approved option. People paste data into public tools when the sanctioned route is slow or absent. A tool that's available, fast and covered by a business agreement does more than a ban.
5. Lock down access. Single sign-on, multi-factor authentication, role-based permissions and no shared accounts. Make sure the assistant's data connections respect user permissions rather than using one broad credential.
6. Reduce what the model sees. Mask, tokenize or redact identifiers before processing where the task doesn't need them. OWASP names tokenization and redaction among its mitigations.
7. Run vendor due diligence before go-live. Use the checklist above, get answers in the contract rather than a sales deck, and have security and legal sign off. Reassess on a schedule, as the rule expects.
8. Encrypt and log. The Safeguards Rule requires encrypting customer information held or transmitted (314.4(c)(3)). Keep logs of who used which tool on which data, with their own access limits, since logs can contain the very data you're protecting.
9. Plan for the incident. Decide in advance who declares an AI-related leak, how you contact the vendor, how you assess whether regulated data was involved, and who handles notification. Under the Safeguards Rule, an event involving at least 500 consumers has a 30-day FTC notice requirement (314.4(j)).
10. Train and retest. Short, example-based training for finance staff beats a policy PDF. Review access and vendor settings at least annually and whenever a vendor changes terms.

The NIST AI Risk Management Framework is a good structure if you want a recognized reference for governing all of this. It's a voluntary framework for managing AI risks, released in January 2023, and NIST published a Generative AI Profile for it in July 2024 (NIST). For control design in a public company, pair it with our guide to AI and internal controls.

Common Pitfalls

• Banning AI and calling it done. Bans push use onto personal devices and personal accounts, where you have no visibility at all.
• Trusting plan names. "Enterprise" on a pricing page doesn't tell you what the contract says about training, retention or review. Read the terms for the exact product.
• One broad service account. It makes setup easy and makes every user an admin through the assistant.
• Forgetting derived data. Embeddings, vector indexes, caches and logs hold your content in another form. Include them in retention and deletion rules.
• Ignoring AI features inside existing tools. A new assistant toggle in your expense or AP system may send data to a new subprocessor without a new procurement review.
• Skipping residency until a customer asks. Fixing where data lives after rollout is much harder than choosing the region at setup.
• No owner. If security, finance and IT each assume another team owns the AI tool, nobody reviews the vendor.
• Treating agents like chatbots. Tools that act, not just answer, need tighter permissions. The privacy implications are covered in AI agent data privacy.

What to Measure

• Coverage: share of AI tools in finance that are on the approved list, with a completed vendor review.
• Shadow use: unapproved AI tools detected in network or expense data each quarter.
• Access hygiene: share of AI integrations using per-user permissions and multi-factor authentication.
• Data minimization: share of sensitive fields masked before AI processing.
• Incident readiness: time from reported AI-related leak to a documented scope decision.
• Training: share of finance staff who have completed the AI data-handling session.

Where to Go Next

If you do three things this month, make them these: publish the one-page data classification and approved-tools list, replace any shared service accounts behind AI integrations with per-user permissions, and ask each AI vendor the seven contract questions above. Then schedule a quarterly review so the list stays true.