What AI consulting actually involves for a financial firm

The productive uses are unglamorous. First drafts of teasers, buyer profiles and company summaries, assembled from the firm's own templates and files rather than from the open internet. Review of documents at volume: pulling the terms that matter out of a hundred NDAs, or the key figures out of a data room. Meeting and call notes that land filed, structured and searchable. Extraction of financials from unstructured accounts into a working model.

What these have in common is that each replaces hours of junior or senior time on work that has a checkable output. None of them replaces judgement. A firm that starts from the question "which of our workflows burns the most hours on drafting, reading or retyping" will find better uses for AI in an afternoon than a vendor demo will show it in a quarter.

The model is the smallest part of a working system. The larger parts are the plumbing: connecting the mailbox, the file structure and the templates the firm already uses; grounding the model in the firm's own documents so it drafts from fact rather than from pattern; respecting the permission structure, so the system can never show a person a document they could not open themselves; and handling the failure cases, because there will be failure cases.

This is why generic AI tools disappoint in financial firms. A chat window with no access to the firm's documents produces fluent, useless text, and one with unmanaged access to everything is a confidentiality incident waiting to be written up. The value sits in the narrow band between those two, and reaching it is engineering work, specific to each firm.

Deal work is confidential by definition, which rules out the default architecture of most AI products: client data uploaded to a vendor's environment, pooled infrastructure, and terms that permit the vendor to improve its service on your material. For a firm handling mandates under NDA, the first question about any AI system is structural. Where does the data go when the model reads it, and who else can see it there?

The defensible arrangement starts with secure and private handling. Agree where information is stored and processed, who can access it and which providers are involved. Model processing terms, retention and review checkpoints should be explicit. Deployment within the firm's own environment is one option, rather than a promise that applies to every engagement.

Language models are confident and fallible, which is a dangerous combination in a business where a wrong number can reach a client. The systems that survive in financial firms are built so that AI produces drafts and people make decisions. The model assembles the first version of the teaser; a person signs it off. The model extracts the figures; the workflow shows where each one came from so it can be checked in seconds.

This is not a limitation to apologise for. A reliable first draft of a document that used to take a day is most of the value, and a firm that knows exactly where the human checkpoint sits will trust the system enough to keep using it. Vendors who talk about removing the human from the loop are describing a risk appetite, not a capability.

It starts with the workflow inventory, not the technology: which processes consume the most hours, where the errors are costly, what the firm already does well. The first build targets one workflow, ships as working software within weeks, and is used on live work while it is still being refined. From there the system grows in short cycles, shaped by what the team actually asks for rather than by a roadmap written before anyone had used anything.

The engagement also has to outlast the build. Models improve, prices fall and the firm's processes change, so an AI system that nobody maintains is stale within a year. Whoever builds it should expect to run it, measure it and keep adjusting it. If the proposal ends at handover, the useful life of the system probably does too.

It begins with a short call about how the firm runs deals today: where the hours go, where the errors are costly and what already works. From that comes a workflow inventory and a single first target, usually a document assembly or document review task. Scope and price for the initial build are agreed up front, and the work is priced per firm rather than per seat.

The build then ships as working software within weeks, working from the firm's templates and files under agreed access, hosting and processing arrangements. A named person reviews every output. The team uses it on live mandates while it is refined. The people on the first call are the people who build it and answer questions afterwards; there is no handover between a sales team and a delivery team.

Access, context and a reviewer. Access means a scoped, revocable route into the firm's Microsoft 365 tenant, granted by the firm under confidentiality terms it signs off. Context means the templates, folder structures and habits the workflow already runs on, because the system is built around them rather than replacing them. The reviewer is the person whose judgement the drafts are for.

What the firm does not have to provide is a data migration, a new platform or a change in how the team works day to day. Most of what we build sits alongside Outlook, Excel and Microsoft 365. Where an existing tool is genuinely costing time we say so, but nothing is replaced unnecessarily. Nor does the firm need a technical person on its side of the table. The conversation is about how deals run, and translating that into software is the part we are paid for.

Verdalyze does not publish prices, because every engagement is scoped to one firm's workflows. What is fixed is the structure: a one-off initial build to get the first system live, then a retainer billed every 4 weeks on rolling terms that covers hosting oversight, fixes and continued development. There are no per-seat surcharges, no exit penalties and no lock-in.

The number that matters more than the fee is the one set in the first week: the hours the target workflow currently costs. An engagement is worth continuing when the hours returned each cycle are visible to the partners, and worth stopping when they are not. That is the test we apply to our own work, and the retainer terms are designed so a firm can act on it. A firm that cannot see the hours coming back should stop paying for the work.

Pilots that never leave the demo environment, because the vendor cannot meet the firm's data requirements in production. Per-seat AI add-ons priced on hype rather than on hours saved. Accuracy claims quoted without a denominator. Proposals that name the model but not the workflow. And any supplier who cannot explain, in plain terms, where your client's data sits while the model is reading it.

The test we suggest applying to any AI proposal, including ours, is narrow and practical: name the workflow, count the hours it currently costs, state where the data goes, and show the checkpoint where a person signs off. Proposals that survive those four questions are worth piloting. Most do not survive them. The questions are also cheap to ask. Each takes a sentence, and a supplier who has built this before answers all four without going away to check.