AI in fintech engineering: who touches the data, and how

AI in fintech engineering: who touches the data, and how

AI in fintech engineering is the use of models, coding assistants and agents inside the teams that build financial software, under a condition most industries can postpone: every piece of data a model can read, and every line of code it writes, has to trace back to a decision someone made and can explain. The technology is the same one every engineering team is adopting. What changes in a regulated business is that "we'll sort out access later" is not an option, because later is when someone asks to see the record.

For a fintech engineering leader, that turns the usual question around. The question is not how fast the team can adopt AI. It is what an AI model, and the engineer using it, is allowed to touch, and how the company would show that. The rest of this article covers what changes when a regulated team adopts AI, how to map what a model can reach, and the three controls that make adoption defensible: data access, review and logging. The claim behind it is simple: in a regulated industry, controls don't slow AI adoption down. They are what allows a company to say yes to it.

What changes when a regulated engineering team adopts AI

Adopting AI widens what engineering touches. A coding assistant reads the repository it works in. An agent with terminal access can run commands, open files and call services. A developer debugging an incident can paste a log line into a chat window, and that log line may contain a customer's account number.

None of this is new as a risk category. The OWASP Top 10 for LLM Applications lists sensitive information disclosure among the main risks of AI systems, covering personal data, financial details and security credentials, among others. What is new is the speed. Most teams add the capability faster than they add the review, and in a fintech the gap between the two is where an audit finding comes from.

The practical shift is that AI tools become part of the system that handles financial data. They need the same treatment as any other component with access: an owner, a defined scope and a record.

What can an AI model touch? Mapping data access first

Before choosing controls, map what the AI tools in the engineering workflow can reach today. In most fintech teams, the inventory has five layers:

• Source code. Usually the first thing an assistant sees, and usually acceptable, with exceptions such as code that embeds business rules the company treats as confidential.
• Configuration and secrets. Environment files, keys and tokens. A model should not be able to read them, and neither should anything it sends them to.
• Test data. Safe when it is synthetic or masked; a real risk when it is a copy of production.
• Production data and logs. Customer records, transactions, and the logs and tickets that quote them.
• Connected services. Anything an agent can call: databases, internal APIs, cloud consoles.

The map shows two things quickly: which layers are already exposed, and which ones nobody has decided about. The second list is usually longer, and it is the one to work through first.

Data access, review and logging: the controls that let you say yes

The page on AI, security and data profiles describes what a security engineer owns in an AI rollout: "access and data governance around AI systems · review of what the new capability exposes · the controls that let you say yes to adoption." The three controls below follow that order.

Data access: decide what each tool can read

Most AI coding tools now ship with settings that limit what they can see, and those settings are the first control to configure. Two examples from public documentation:

• GitHub Copilot supports content exclusion, configured at repository, organization or enterprise level, so specified files are ignored. The same documentation notes a limit worth knowing: Copilot CLI and agent mode in Copilot Chat in IDEs do not support content exclusion. A control that covers one mode of a tool and not another is a gap to document, not a box to tick.
• Claude Code uses permission rules in its settings files, including deny rules that stop it from reading files such as .env. Settings managed by the organization take precedence over what an individual engineer configures.

The principle behind both is least privilege: each tool gets access to what the task needs, and nothing more is granted by default. Production data stays out of prompts unless it has been masked.

Review: AI-written code goes through the same gate

Code generated by a model is still code that will move money. It goes through the same review as code written by a person, by a reviewer who understands what it touches. Teams that already run a security-first engineering culture extend their existing review rules to AI output rather than inventing new ones. The rule that matters most is accountability: the engineer who merges AI-written code owns it as if they had typed it.

Logging: keep a record you could show

The third control is the one that turns a good practice into something a regulated company can demonstrate. Keep a record of which AI tools are approved, which repositories and data each one can reach, who changed those settings and when, and which changes were reviewed. The exact form depends on the tools and the company's existing audit process. The test is the same everywhere: if someone asked tomorrow what a model could see last quarter, could the team answer?

Who owns the decision about what AI can reach

Every one of these controls depends on a decision that has to sit with someone in the company. The DevelopersLATAM page on who legally employs the engineers puts it this way: "Someone in your organization owns the decision about what that reach includes, what it excludes, and who reviews it when the work changes shape in month four."

That owner is usually the engineering leader together with security, not the individual developer and not an outside provider. Engineers can bring the discipline. The decision about scope stays with the company that carries the risk.

Frequently asked questions

What is the role of AI in fintech?

In fintech, AI is commonly used to detect fraud, assess credit risk, automate customer service and monitor transactions for compliance. Behind each of those uses sits an engineering team that builds and maintains the models, and in a regulated business that team also has to control what data each model and each AI tool can reach.

What are the top 3 AI security risks?

The first three risks in the 2025 OWASP Top 10 for LLM Applications are prompt injection, sensitive information disclosure and supply chain risks. For a fintech engineering team, the second one is usually the most immediate: customer data, credentials or financial details reaching a model or a tool that should never have seen them.

Will ChatGPT leak my data?

It can, if sensitive data is pasted into it without the right plan and settings. OpenAI states that, by default, data from its business plans and its API is not used to train its models; personal accounts work under different settings. In a fintech, customer data should never go into a prompt unless it has been masked.

‍

Where engineers with a security discipline fit

The hardest part of these controls is not configuring a setting. It is having engineers who treat access and review as part of the job from the first day. DevelopersLATAM engineers bring the frameworks and playbooks of the group they belong to, which the ACL and DataArt page describes, and the site names what those frameworks cover: "how code gets reviewed, how access is granted, how data is handled, and what an engineer is allowed to point a model at." They follow the practices of the company they join, and the company keeps the final word on scope.

If your fintech team is adopting AI faster than it is adding review, the gap is usually a profile, not a policy. The AI, security and data profiles page explains what each profile owns, and how we work explains how they are assessed, and you can talk to the team about the position you need to fill.

‍