Selling AI to a bank takes more than a convincing demo

An AI demonstration can make a difficult task look remarkably simple. A customer letter appears in seconds. A long document becomes a tidy summary. A dashboard offers a confident answer. For an Australian supplier trying to sell that system to a financial institution, the harder conversation starts when the demonstration ends.

Who can see the information? How was the answer tested? Can an employee stop the process? What happens when a supplier changes the model underneath it? Those are practical purchasing questions, and a useful starting point for a business preparing its first serious procurement discussion.

A program focused on getting through procurement

The National AI Centre's Buy Australian AI Partnership Program is aimed at helping Australian AI businesses prepare to work with financial-sector buyers. Its stated focus includes procurement, security and governance. That makes it relevant to suppliers with something more developed than a promising idea, but it should not be read as government certification of a product.

There is a timetable discrepancy to resolve. On 7 October, the National AI Centre page listed an October start different from the delivery partner's schedule. Stone & Chalk listed a national digital phase from 12 October to 4 December 2026, followed by an accelerator in early 2027. Its page said applications had closed. Businesses should confirm dates with the program before relying on either listing. Participation does not guarantee a pilot, purchase or contract.

A sales proposal can make the procurement discussion concrete by showing how the product behaves inside the buyer's organisation, including when it produces a poor answer and who handles the result.

Start with one job and a clear boundary

Consider a hypothetical supplier offering a tool that drafts responses to routine customer enquiries. “Improves customer service” is too broad to evaluate. A narrower proposal would say which enquiries it handles, which records it reads and which cases it passes to a person.

The supplier could then show a sample workflow: an employee opens an enquiry, the tool proposes a response, the employee checks it, and the organisation records the approved version. This example is not a finding about any bank's actual process. It illustrates why a buyer needs more detail than a speed claim.

A useful proposal also states what the tool cannot do. Perhaps it must never change an account, decide a complaint or send a message without approval. Those limits should be visible in the workflow and supported by controls. The buyer should be able to see those limits enforced during a test, with the outcome recorded.

The National AI Centre's adoption foundations set out six practices covering responsibility, impacts, risks, information, testing and human control. For a supplier, these provide headings for evidence. For a buyer, they provide questions to ask before accepting the promise of a demonstration.

Make the evidence easy to examine

A compact evidence pack could describe the proposed use, the information involved, the people responsible and the testing completed. It should distinguish an internal test from an independent assessment. If a result came from a small sample of easy questions, say so.

Test examples should include awkward cases: missing records, contradictory instructions, an unexpected document format and a request outside the agreed purpose. Record what counts as an acceptable response before running the test. Otherwise, a fluent answer can be mistaken for a correct one.

For each material weakness, explain the response. A tool might refuse the request, ask for missing information or pass it to a trained employee. The practical question is whether that response actually happens under the conditions the buyer is likely to encounter.

The government's screening questions are designed for early consideration of an AI use case. They are not a numerical safety score or a substitute for a full assessment. An issue identified through screening is a reason to investigate and manage it, rather than an automatic verdict for or against the purchase.

Explain the supplier chain

A small business may build its product using another company's model, hosting service or document-processing tool. The buyer needs a plain explanation of those dependencies, including which provider handles which information and which changes the supplier can control.

The National AI Centre's implementation guidance treats responsibility across development and deployment as an ongoing concern. Buying a component does not remove the need to understand its role in the final system.

A useful commercial discussion therefore includes change management. If a model update alters the answers, who notices? Which tests run again? Who can pause the service? How does the buyer receive an incident report without exposing more sensitive information in the reporting process?

These questions also help a supplier set a realistic scope. Supporting a narrow, well-tested use case may be more credible than promising to automate an entire department.

Before a procurement meeting, prepare one example of a successful task, one example of a failed task and a clear explanation of the controls around both. A buyer can then assess the product's actual behaviour. That is firmer ground for a decision than the most impressive answer produced during a sales call.