Home/Insights/The cost of AI implementation
AI implementation9 min read

What does AI implementation cost for a financial services firm?

The useful number includes the workflow, information, integration, testing, adoption and ongoing operation required to produce a dependable result.

In brief

There is no responsible universal price for AI implementation. Leadership can still make the cost understandable by separating discovery, configuration or build work, integration, testing, software usage, internal time, support and future change.

A financial services leader comparing AI proposals usually wants a simple answer: what will this cost?

A responsible answer begins with the workflow. Preparing a first draft from one approved file is a different commitment from retrieving information across several systems, applying permissions, handling exceptions, recording review and supporting the process after launch.

The model or software licence may be visible on a pricing page. The implementation cost sits around it. That includes understanding the work, connecting the right information, defining what the system may do, testing ordinary and awkward cases, training users and maintaining the result when the process changes.

This is why two proposals that both promise an AI assistant can carry very different costs and very different levels of operating responsibility.

Start with the business outcome and the current baseline

The firm needs to know what it is trying to improve before it can judge whether the investment is proportionate.

For a recurring report, the baseline might include preparation time, waiting for inputs, review effort, corrections and late delivery. For onboarding, it might include repeated requests, incomplete records, elapsed time and the number of handoffs before the file is ready for approval.

These measures do not need to be perfect. They need to show where the current cost sits and which part of the result matters enough to change.

Without a baseline, leadership can compare invoices but cannot compare value.

Separate assessment from implementation

An early assessment pays for clarity. It should show how the workflow runs, what information and systems it depends on, where judgment enters, what a useful first release would include and what conditions could make the project unsuitable.

Implementation pays for the operating capability. Depending on the scope, that can include configuration, custom development, integrations, access controls, test cases, documentation, training and rollout support.

Keeping these decisions separate helps the firm avoid approving an open-ended build before it understands the work. It also leaves room for a sensible conclusion that the process or data needs attention first.

Account for the complete cost

A useful proposal should separate one-off and recurring costs.

One-off work may include workflow discovery, solution design, data preparation, configuration, integration, testing, documentation and training. Recurring costs may include software licences, model usage, hosting, monitoring, maintenance, vendor support and periodic review.

The firm's own time belongs in the calculation as well. Operators may need to explain exceptions, reviewers need to test outputs, technology or security staff may need to examine access, and leadership must make scope decisions. A lower external fee can still be expensive if the project consumes large amounts of internal attention.

Future changes matter too. A new template, system field, approval rule or client requirement may require the workflow to be updated and tested again.

Understand what makes a project more expensive

Cost tends to rise when the workflow spans several systems, relies on inconsistent documents, needs fine-grained permissions, affects important client outputs or contains many exceptions that must be handled visibly.

The need for custom interfaces, data migration, historical cleanup, specialist review, separate environments or extensive support can also change the commitment.

A narrow workflow using approved information from a stable source is usually easier to scope and test than a broad assistant expected to answer questions across the whole firm.

Narrow does not mean trivial. The right first project is bounded enough to inspect and important enough for the result to matter.

Compare proposals on assumptions, not only totals

Ask each provider to state what its price assumes about data quality, system access, client availability, test cases, approvals and support after launch.

Check whether software and usage charges are included. Ask which integrations are part of the scope, how many workflows or teams are covered, what acceptance evidence is required and what happens if the source process changes.

A fixed price can create useful certainty when the deliverable and assumptions are clear. It can create false comfort when the scope is described only as implementing AI across a department.

The most useful comparison is the cost of reaching the same defined operating result, with the same responsibilities and exclusions visible.

Decide in stages

Leadership does not need to approve every possible phase at once.

A practical sequence is to assess the opportunity, approve a bounded first implementation, test it against agreed criteria and then decide whether to expand. Each stage should produce information that makes the next decision easier.

This protects the firm from treating an attractive demonstration as a commitment to a larger programme. It also protects a useful project from being judged against expectations that were never part of the scope.

Questions that make the cost easier to compare

Outcome

Which operating result is the project expected to improve, and what is the current baseline?

Scope

Which workflow, systems, users, information sources and exceptions are included?

Internal effort

Who from the firm is needed for discovery, testing, approval and ongoing ownership?

Recurring cost

Which licences, model usage, hosting, support and maintenance continue after launch?

Change

What happens when a source system, template, instruction or approval requirement changes?

What should leadership expect before approving a budget?

The firm should be able to see what it is buying, what its own team must contribute, what the capability will cost to operate and what evidence will decide whether it worked.

A provider may not be able to price an unfamiliar workflow accurately from the first conversation. They should be able to explain what they need to learn and how that information will turn into a bounded proposal.

Halyard begins with the workflow and the business decision. We make the implementation boundary, client commitment, recurring requirements and ownership visible before the firm approves a build.

Related Halyard resources

Further reading

Max Bates
Max Bates

Founder of Halyard, an AI implementation company helping financial services firms find and implement practical AI safely.