How to govern AI test automation in banking

AI test automation governance in banking is the set of controls that determines how artificial intelligence (AI) may design, maintain, execute or analyse software tests, and how people verify its outputs. It defines permitted uses, accountable owners, risk-based approval gates and retained evidence so AI-assisted testing supports reliable decisions about banking software releases.

Define the scope and risk

Start by identifying each AI use case. Examples include generating test scenarios from requirements, suggesting changes to brittle selectors, classifying test failures, prioritising regression suites and operating an agent that interacts with test applications. Record the tool, model or service, data inputs, connected systems and the decisions it can influence.

Set boundaries according to the impact of a mistake. A tool that drafts test ideas for review carries different risks from an agent that executes payment workflows, changes test data or recommends release approval. Restrict permissions to the minimum needed. Keep AI execution in controlled, non-production environments unless a separately assessed use case explicitly permits otherwise.

This governance concerns AI used in the testing process. It is distinct from testing an AI system used by a bank, such as a credit decision model or customer chatbot. The two activities can share controls, while each needs its own scope, risks and acceptance criteria.

Assign accountability and approval gates

Name an accountable owner for each use case. Responsibilities may sit across quality engineering, application delivery, information security, data protection, model risk and compliance teams, depending on the bank's operating model. Define who approves initial use, who reviews changes and who can suspend the tool when its behaviour or dependencies change.

Use approval gates before AI-generated or AI-modified tests enter a controlled suite. A qualified reviewer should check that each test traces to an approved requirement, risk or defect; uses valid test data; has a meaningful expected result; and does not weaken an existing assertion. Keep human approval for release decisions where the bank's process requires it. AI-generated summaries or pass/fail classifications should not silently replace source test results.

Control test data, access and execution

Apply the bank's existing security and data-handling rules to prompts, logs, screenshots and test artefacts. Prevent customer data, credentials, payment details and other restricted information from being sent to an AI service unless that use has been assessed and authorised. Prefer synthetic or appropriately protected data. Check retention, access and deletion arrangements for any external service involved.

Limit tool permissions and separate test identities from production identities. For browser or desktop automation, restrict access to approved applications and test accounts. For API-driven tests, use scoped credentials and controlled endpoints. An AI agent that can initiate a transfer should be prevented from reaching production payment services, even if the test scenario itself is legitimate.

Validate outputs and preserve evidence

Treat generated tests as proposals until they pass review and execution checks. Verify that they reflect the intended banking rule, cover relevant boundaries and failure paths, and assert observable outcomes such as transaction status, account balance or ledger posting. Check for duplicate tests, missing negative cases, unstable selectors and assertions that pass without proving the requirement.

For each governed run, retain enough information to reconstruct what happened: the approved test and its version, the AI tool and relevant configuration, input material, human changes and approvals, execution environment, results, and any investigation of failures. Apply the bank's evidence retention and access policies. A generated explanation alone is insufficient evidence if the underlying test result cannot be traced and reproduced.

Monitor failure modes over time. AI-generated tests may misread ambiguous requirements, rely on outdated interface details or classify an application defect as environment noise. Model, prompt, connector, selector or application changes can alter results. Reassess the use case after material changes, investigate unexpected output and disable or roll back the AI function if controls fail.

Worked example: duplicate payment prevention

Suppose an AI assistant proposes a regression test for duplicate payment prevention. The reviewer checks the scenario against the approved payment requirement, confirms that the test uses a controlled account and test payment endpoint, and verifies the expected behaviour: submitting the same idempotency key twice must not create a second payment. The test then runs with a stable identifier and checks both the API response and the resulting payment record. The bank retains the approved case, execution output and review record. If the assistant later changes the expected result or endpoint, the test is held for review before reuse.

Make governance part of release decisions

Define how AI-assisted results feed into existing test governance and release criteria. Report human-reviewed coverage and unresolved failures separately from unreviewed AI suggestions. A release owner should be able to distinguish executed tests from proposed tests, and confirmed defects from automated failure classifications. Align controls with applicable regulatory obligations, internal policies and the bank's risk management framework; the required controls depend on the use case and jurisdiction.