Compare potential partners on the work that matters after the demonstration: workflow understanding, information access, exception handling, total cost, testing, staff adoption and ownership after launch.
A financial services firm can find plenty of people willing to demonstrate AI.
The harder decision is choosing someone who can carry a useful idea through the systems, information, controls and staff adoption required to make it dependable.
That distinction matters because the provider may need access to internal records, integrations and operating knowledge. The firm may also depend on the resulting workflow after the original builder has moved on.
The Bank of England and FCA found that a third of the AI use cases reported in their 2024 financial services survey were third-party implementations. The same research noted increasing concern about dependency on outside providers. External expertise is already part of the market. The buying decision still deserves careful scrutiny.
The following questions help leadership compare potential partners on the work that will matter after the demonstration.
Can they describe the workflow before prescribing the technology?
Ask the provider to explain what they need to learn before recommending a solution.
A credible answer should include the trigger that begins the work, the records and systems involved, the people who prepare and review it, the awkward cases and the business result worth improving.
Consider a monthly client report. Producing a first draft may be only one part of the process. Someone still needs to identify the current source, resolve missing inputs, compare unusual movements, apply the correct client format and approve the final communication.
A provider who starts with a model or agent may miss the surrounding work that determines whether the result is useful.
Will they make the whole commitment visible?
The initial build is rarely the complete cost.
Ask what your team will need to provide during discovery, testing, review and rollout. Clarify one-off implementation fees, recurring software and model costs, support arrangements, maintenance and the effect of future workflow changes.
The proposal should also say what is outside scope. A narrow implementation can be valuable, but leadership should know whether it depends on later data work, system changes or additional phases.
If the provider cannot explain the likely commitment until after the project begins, the firm cannot compare alternatives properly.
How will information move through the system?
Ask the provider to draw the path taken by a document, record or instruction.
Which system supplies the information? Is it copied or retrieved when needed? Which model or service receives it? What is retained? Who can access the workflow, its outputs and its logs?
The answer needs enough detail for the appropriate internal or external reviewers to examine it. General claims that a product is secure do not explain how the proposed workflow will handle the firm's information.
NIST's AI Risk Management Framework calls for defined roles, documented human oversight and controls for third-party software and data throughout the AI lifecycle. The exact requirements will depend on the firm and the use case, but the implementation partner should be ready to make those decisions visible.
What happens when the information is incomplete or wrong?
The clean example tells you whether the system can work. Awkward examples tell you whether the provider understands operations.
Give each provider the same representative cases. Include a missing document, an old template, conflicting records or an instruction that should be escalated rather than completed.
Ask what the system will do, what the user will see and who will be responsible for resolving the exception. A confident answer produced from weak information can create more work than a clear refusal or flag.
Testing should examine the final workflow, including human review and correction. Speed to first draft is a poor measure if the reviewer has to reconstruct the work before trusting it.
Who owns the result after launch?
Your firm should know who owns the workflow, integrations, instructions, documentation and operational decisions after implementation.
Ask whether you will receive current documentation, administrator access, configuration records and a practical handover. Clarify what can be moved to another provider and what depends on a proprietary platform or licence.
The provider should also explain who handles a failed integration, changed source document, model update or new access requirement. These questions expose the difference between a demonstration and an operating capability.
How will staff learn to use it properly?
Adoption needs more than a launch call.
Users need to understand when the workflow applies, which information may enter it, what requires review and how to report a problem. Managers need to know whether people are using it, whether exceptions are increasing and whether the expected improvement is appearing after review effort is counted.
Ask how the provider will involve the people who already run the process. Their knowledge of recurring exceptions often determines whether the final design works outside the ideal example.
Can they state what should remain with people?
A strong provider should be comfortable limiting the system.
Ask which decisions, approvals and communications should remain under human responsibility. The answer should reflect the actual workflow rather than a broad promise that a person will remain involved somewhere.
AI may collect approved information, compare records, flag gaps or prepare a draft. The firm still needs to define who reviews the sources, resolves uncertainty and approves anything that affects a client or material decision.
What evidence will decide whether the project worked?
Agree the baseline and acceptance criteria before the build begins.
Useful measures may include elapsed time, staff effort, corrections, missing-item follow-up, turnaround, exception volume or the percentage of work accepted after review. The right measure depends on the reason for changing the workflow.
Ask what result would cause the provider to revise, narrow or stop the project. A credible implementation process leaves room for evidence that the proposed use case is not ready or is better served by conventional automation.
A practical comparison checklist
Workflow
Can the provider explain the real process, including its exceptions and approvals?
Commitment
Are implementation, software, support and client time visible?
Information
Can you see what data moves where, who can access it and what is retained?
Testing
Will representative and awkward cases be tested with clear acceptance criteria?
Ownership
Will your firm receive the access, documentation and handover needed to operate the result?
What should the final choice come down to?
Choose the partner whose proposal makes the operating reality easiest to inspect.
The firm should be able to see the workflow being changed, the result being pursued, the information involved, the limits placed on the system, the full commitment and who will own it afterwards.
Halyard works with financial services leadership and operating teams to assess and implement AI inside recurring workflows. We begin with the work, agree the boundaries and commercial scope, then test the implementation with the people who will use and review it.
If your firm is comparing approaches, bring one workflow and one awkward example to the conversation. That is usually enough to reveal whether the discussion is grounded in the work you actually need to improve.
Related Halyard resources
Further reading
Founder of Halyard, an AI implementation company helping financial services firms find and implement practical AI safely.