Blog 08

· 8 min read · By Ilyas Berel and Shihab Berel · Updated

Every AI consultancy demo works. That is what demos are for, and it is why they are useless as an evaluation method. A financial firm choosing an AI partner is really evaluating things the demo cannot show: how the consultancy treats confidential data, who actually does the work, what happens when the model is wrong, and whether anyone will still be maintaining the system a year in.

We sit on one side of this market, so read what follows with that in mind. These are the questions we believe a well-run M&A, corporate finance or financial services firm should put to any AI consultancy, including us, before signing anything.

01

Where will your data sit?

The answer you are looking for is architectural, not contractual. In whose environment does the work run? Does client material ever leave your firm's control? Under what terms are models called, and do those terms exclude training on your data? A consultancy that answers with certifications and reassurance rather than architecture has told you something important.

For a firm handling material under NDA, ask for a concrete description of the data flow: where information is stored, who processes it, what access is needed and what is retained. Secure and private handling matters in every hosting model. A client-controlled deployment may be appropriate, but it does not replace checking the processing terms and access controls of every service involved.

02

Who actually does the work?

In many consultancies the people who sell the engagement, the people who design it and the people who build it are three different groups, and the firm's context is lost twice in translation. Ask who you will actually be talking to after the contract is signed, and whether that person writes code. The answer predicts the quality of everything that follows.

Small firms are badly served by layered delivery models. A ten-person advisory firm does not need a steering committee; it needs an engineer who understands how the firm runs deals and can ship a change the same week it is asked for.

03

What happens when the model is wrong?

It will be wrong. The question is whether the consultancy has designed for that or is hoping around it. Where does a person check the output before it matters? Can every extracted figure be traced back to its source document? What is the procedure when a mistake gets through? Consultancies that have shipped real systems answer these questions quickly and specifically, because they have been burned into the answers.

Be wary of anyone whose reliability story is that the models are getting better. They are, and it is not an answer. A financial firm needs to know how the system behaves on the day the model has a bad afternoon, not on the day the next version ships. The answer to look for is specific and dull: a named person checks this output, every extracted figure links back to its source, and a mistake that gets through is fixed through the maintenance arrangement rather than absorbed by the firm.

04

What would they refuse to build?

A consultancy that thinks every workflow needs AI is selling coverage, not judgement. The honest version of this work involves regularly telling a client that a workflow should be left alone, solved with a standard product, or automated without any model involved at all, because deterministic automation is cheaper and more reliable where no judgement is required.

Put the question directly: which parts of our firm would you not touch, and where would you not use AI? The quality of the answer is a fair proxy for the quality of everything else.

05

Who maintains it in month thirteen?

AI systems age faster than ordinary software. Models are deprecated, terms change, prices move, and the prompts and grounding that worked in January drift by autumn. A build with no maintenance arrangement is a countdown, and the firm will be back in the market within eighteen months, this time with a legacy system to untangle.

The arrangement to look for is a build followed by an ongoing engagement, with the same people, on terms the firm can leave without penalty. The exit terms matter: ask what happens to the system, the code and the data if you walk away, and expect a specific answer with a timescale attached.

06

Why does a demo tell you so little?

A demo runs on data the vendor chose, in an environment the vendor controls, on a task the vendor rehearsed. Every one of those conditions disappears the day the system meets a live mandate: documents in inconsistent formats, a template the firm changed last month, a counterparty who does things differently. The demo shows what the model can do at its best; the firm needs to know what the system does on an ordinary Tuesday.

The useful substitute is a short first build on the firm's own material, handled securely and privately under agreed processing arrangements and reviewed by the firm's own people. Working software within weeks, used on real work, produces evidence a demo cannot: where the output is reliable, where the checkpoint has to sit, and whether the team keeps using it without being asked.

07

What should the exit terms say?

Ask before signing, because this is where lock-in hides. Confirm that the firm owns its data and software, can receive a handover in standard formats and knows the ongoing hosting or provider requirements. Agree a retention and deletion timescale, a clear access-offboarding process and short, rolling notice without a penalty.

Verdalyze's own terms are a rolling 4-week retainer with no exit penalty, handover in standard formats and deletion of anything we hold within 90 days. Whatever a consultancy's terms are, they should be that specific. A vague answer about exit is a precise answer about lock-in.

08

What separates an engineering firm from a slide deck?

The distinction is visible in the first conversation. Firms that engineer AI into confidential financial work talk about workflows, tenants, permissions and checkpoints. Firms selling coverage talk about transformation and model names. A short list of tells:

  • They ask how the firm runs deals before they describe what they sell.
  • They can say, in one sentence, where the firm's data will sit.
  • They name the person who will write the code.
  • They tell you which of your workflows they would not touch.
  • They describe what happens when the model is wrong without being prompted.
  • Their proposal ends with maintenance, not with handover.

None of these require the firm to understand the technology. They only require the consultancy to have done the work before.

09

What should you ask on the first call?

Six questions cover most of the ground. Where does our data sit, structurally? Who does the work, and do they write code? Where is the human checkpoint, and what is the procedure when the model is wrong? What would you refuse to build for us? Who maintains the system after launch, and on what terms can we leave? And can you show us something you have built for a firm like ours that is still in daily use?

None of these questions requires technical knowledge to ask, and all of them require competence to answer. A consultancy that welcomes them is worth a pilot. A consultancy that deflects them has answered anyway.

Written by Ilyas Berel and Shihab Berel, Verdalyze. Published 2 September 2026, updated 20 September 2026.

Sources

Primary sources referred to above.

  1. 01ICO: Data protection impact assessments
  2. 02Office of the Privacy Commissioner of Canada: principles for generative AI

What is slowing your team down?

Tell us how your firm runs deals. We will help you identify the first useful system to build.

Contact us