An AI coding tool can suggest functions, tests, configurations and documentation, but it cannot own the bank’s software risk. Generated code remains a proposed change that must pass the same—and sometimes enhanced—security, quality, data and release controls as code written by a person.
Governance starts with approved uses and accountable owners
The bank defines which tools, repositories, languages, environments and tasks are approved, who may use them and which systems require additional review. A low-impact test script and code for authentication, payments or customer decisions do not create the same consequences if the suggestion is wrong.
Product and technology owners remain accountable for requirements, architecture and production behavior. Procurement, information security, legal, privacy, model or AI governance and third-party oversight may also be involved, but using an outside model does not transfer the bank’s responsibility for the released software.
Information boundaries protect customers, secrets and code
Policies identify what may be entered into an AI service and whether prompts, code or outputs may be retained or used by the provider. Customer information, credentials, cryptographic material, confidential business logic and restricted source code require controls matched to their sensitivity and the service’s actual data handling.
Technical restrictions can block unapproved tools, limit repository access and detect secrets before content leaves a controlled environment. Training and attestations help, but they do not replace enforceable access, logging and data-loss controls where the exposure could be material.
Generated code is treated as an untrusted proposal
A developer reviews whether the suggestion meets the intended requirement, handles errors safely and fits the surrounding architecture. The review also considers insecure patterns, fabricated interfaces, unnecessary privileges, hidden assumptions and dependencies that the tool may introduce with convincing but incomplete code.
The bank preserves appropriate version, author, review and tool-use evidence so a change can be traced and reproduced. Provenance and licensing concerns are assessed under the organization’s standards rather than assuming that generated output is automatically original, permitted or suitable for reuse.
Secure development controls test the complete change
Peer review, automated tests, security analysis, dependency checks and environment-specific validation examine the code in context. Tests cover expected behavior and failure conditions, including authorization boundaries, data handling, concurrency and interactions with existing services.
AI can help propose tests or corrections, but an AI-generated check can repeat the same mistaken assumption as the code it evaluates. Independent evidence, risk-based human review and established secure-development practices are therefore necessary before approval.
Controlled release and monitoring preserve accountability
An approved change moves through segregation of duties, change records and deployment controls appropriate to the system. Limited release, feature flags or other safeguards may reduce exposure, but only when success measures, rollback steps and responsible decision-makers are defined in advance.
Production monitoring looks for defects, security events, unusual resource use and customer impact. Incidents and recurring review findings feed back into tool permissions, coding standards and training so the bank improves the development process instead of treating each bad suggestion as an isolated developer error.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.