How finance teams can safely deploy AI-built applications

Finance teams at banks and large financial institutions are building more of their own internal applications with AI coding assistants, often faster than IT or internal audit can review them.

This article covers the risks that come with AI-built finance applications, who signs off before one reaches production, and the steps for deploying AI-built finance applications safely.

• Finance teams increasingly use AI tools like ChatGPT, Claude, Cursor, and v0 to build internal applications, often without direct engineering support.
• These teams routinely handle sensitive financial and customer data, which raises the stakes around where an AI-built application runs and what it can access, compared to internal tools in most other functions.
• The main risks are not the AI itself, but what happens after: unscoped data access, hardcoded credentials, and applications that reach production without a segregation-of-duties or controls review.
• If your finance-built applications need somewhere to land, Northflank gives you a deployment target with sandboxed testing, preview environments, RBAC and governance controls, audit logs, and bring your own cloud deployment for organizations that need sensitive data to stay inside their own VPC. WingBank, one of Cambodia's largest banks, uses Northflank for this kind of workload. Get started for free or book a demo.

An AI-built application in finance is a tool generated with an AI coding assistant to support an internal finance function, rather than licensed vendor software. Common examples include internal reporting dashboards, reconciliation helpers, and applications that surface data from core banking or accounting systems for internal use.

These applications are typically built by finance or operations staff using tools like ChatGPT, Claude, Cursor, or Replit, without a formal engineering review process behind them. At scale, these applications often sit close to sensitive financial and customer data, which raises the stakes of where the application runs and what it can access.

Finance functions frequently need custom reporting, reconciliation, and internal workflow tools that don't exist natively in their core systems. Engineering teams often deprioritize these requests in favor of customer-facing or regulatory work, which creates a backlog similar to what other operations teams experience.

AI code generators let finance staff describe a workflow in plain language and get a working prototype quickly. This turns tool creation from an engineering ticket into something finance can attempt directly, which explains the pace of adoption in this function.

The risk with AI-built finance applications comes less from the code generation step and more from what the resulting application is allowed to access. Finance teams routinely handle sensitive financial and customer data, which carries a different risk profile than most internal business tooling.

None of these risks are unique to AI-generated code. They are the same risks that apply to any internal finance application built outside a standard review process, but AI generation makes it faster to reach production without that process happening at all.

Applications that handle sensitive financial or customer data, or that support actions requiring independent approval, carry considerations beyond general data security. This is a meaningfully different risk category from a read-only internal reporting tool.

Segregation of duties is a foundational financial control that separates who can action, approve, and record a given process, so that no single person or tool can complete it end to end without independent review. Organizations subject to SOX or similar financial reporting and regulatory controls typically extend this requirement to internal applications, not just manual processes.

For this reason, any AI-built application supporting a process that requires independent approval should typically go through internal audit or controls review before production use, in addition to the technical review applied to other internal tools. Northflank does not provide financial controls or compliance guidance, and this article does not substitute for it. It provides infrastructure controls, described later, that support isolating and auditing these applications while that review happens.

Ownership for AI-built finance applications is typically split three ways. Finance usually owns the application's logic and use case, IT or security owns data access and deployment approval, and internal audit or controls owns sign-off for anything supporting a process requiring independent approval.

This split only works if finance, IT, and internal audit agree on it before an application reaches production, not after. For a more detailed breakdown of how this ownership model applies across departments, see how enterprises should manage ownership, access, and security for AI-built apps.

A safe deployment approach for AI-built finance applications generally follows a consistent sequence, regardless of which AI coding tool generated the app.

1. Scope data access before testing. Give the application read or write access only to the specific data it needs, not broad access to financial or customer records.
2. Test in an isolated environment. Run the application in a sandbox separate from production data before connecting it to live systems. Northflank provides sandboxes for this kind of isolated testing.
3. Apply access controls and secrets management. Store credentials in a secrets manager rather than in the generated code itself. Northflank's secret groups can be used for this.
4. Log and audit application activity. Keep a record of what data the application read or modified, so issues can be traced during an audit.
5. Define a promotion path with the right sign-off. Set a review step before production use, and route anything tied to segregation-of-duties requirements through internal audit or controls in addition to IT.

For guidance specific to non-engineering teams building these applications, see how non-technical employees can build and ship internal apps with AI securely and how to vibe-code securely.

This section refers to the deployment path an AI-built finance application takes from its first working prototype to regular production use, not the initial code generation step covered above.

This lifecycle mirrors how enterprises are approaching AI-built applications more broadly. For a fuller breakdown of this progression, see from prototype to production: the enterprise lifecycle of an AI-built app.

Northflank provides infrastructure for running AI-built internal applications in isolated environments, separate from production systems, until they are reviewed and approved. WingBank, one of Cambodia's largest banks, uses Northflank for this kind of workload.

• Sandboxes for applications that execute AI-generated or user-submitted code: microVM-backed isolation using Kata Containers, or syscall-level isolation using gVisor, relevant for finance applications with agentic or code-execution features rather than static dashboards.
• Preview environments for testing changes before they reach production: each change can run in its own isolated environment, so updates to an AI-built application are validated before touching live data.
• RBAC at organization, team, and project level: roles can be scoped to specific projects, and permissions granting access to secrets are flagged as sensitive before assignment.
• Projects as the isolation unit: each finance team gets its own project containing services, databases, and secret groups, so one application doesn't share infrastructure with another handling more sensitive data.
• Secret groups: credentials can be stored centrally and injected at runtime rather than pasted into generated code. Groups can be typed as secret values or configuration values, with RBAC configured separately for each type.
• Audit logs at organization, team, project, and resource scope, recording who deployed what, when, and what data access changed. This can support the evidence internal audit needs, though the audit process itself remains an organizational decision, not something the platform automates.
• BYOC for organizations that need sensitive financial or customer data to stay inside their own VPC: deploy inside your own AWS, GCP, Azure, Oracle, Civo, CoreWeave, or on-premises environment, rather than a shared vendor environment.
• Compliance: Northflank is SOC 2 Type 2 certified and HIPAA compliant, meeting the standards required to handle protected health information (PHI). Under an Enterprise contract, Northflank supports Business Associate Agreements (BAAs).

Also see: best tools for deploying internal AI apps covers platform options for this use case in more depth, and why smart enterprises are insisting on BYOC for AI tools explains the reasoning behind that deployment model. For teams evaluating whether they need a dedicated internal developer platform for this, see what is an AI internal developer platform (IDP)?

It can be, provided the application goes through data access scoping and a review step before reaching production. The risk is not the absence of engineers, but the absence of any review process at all.

Broad access to financial or customer records, and unscoped credentials for core systems, are the highest-risk categories. Applications should generally start with the minimum data set needed for their specific function.

Yes. Applications that support a process requiring independent approval typically need internal audit or controls review in addition to standard IT review, since these processes relate to segregation-of-duties requirements and, for public companies, SOX-relevant controls.

Most organizations require at least a lightweight review of data access and credentials before an application touches production financial or customer data, even if the application itself was built quickly.

Yes. Deployment options like Northflank's BYOC allow an application and the data it touches to stay inside an organization's own VPC, rather than running in a shared vendor environment, which is relevant for organizations with data residency or infrastructure control requirements.

Shadow AI refers to AI tools or AI-built applications used inside an organization without IT or security visibility. Finance-built applications can fall into this category if they are deployed and connected to sensitive data without going through any approval process.

• Enable AI-built apps without shadow IT: Covers how organizations formalize approval and visibility for AI-built tools at scale, rather than relying on ad hoc review.
• How enterprises should manage ownership, access, and security for AI-built apps: Breaks down how responsibility for AI-built tools typically splits between the building team and the governing team.
• From prototype to production: the enterprise lifecycle of an AI-built app: Details the stages a tool typically passes through between an initial prototype and regular production use.
• How non-technical employees can build and ship internal apps with AI, securely: Focused guidance for teams like finance building tools without a dedicated engineering background.
• How RevOps teams can safely deploy AI-built internal tools: The equivalent framework applied to RevOps, useful for comparing how risk and ownership shift across departments.