There is no more common question at the start of an AI initiative, and none more misleading, than "how much will it cost?" In regulated finance the honest answer is that the figure a partner quotes for the build is rarely where the real cost of AI implementation lives. The build fee is the visible part — the sticker — and it is usually the smallest and most predictable line in the whole exercise. The costs that decide whether the programme pays back are the ones that never appear on the proposal: the process work, the parallel run, the integration rework, and the ongoing accountability a regulated automation carries for as long as it runs. An institution that budgets for the sticker and forgets the rest is the one that later calls the project over budget — when in truth it was under-scoped from the start.
Start with what you can see. The build cost scales with the shape of the work, and it is worth naming the ladder plainly. Automating a single, well-defined workflow — a monthly reporting run, a factsheet production cycle — sits at the bottom. Integrating across several systems that were never designed to talk to each other — custody, accounting, the data warehouse — sits higher, because the difficulty is in the seams. A broader platform that a team runs day to day sits higher still. The scope decides the figure, and a serious partner narrows the scope before quoting rather than widening it. But notice what this ladder is really measuring: not the sophistication of the model, which is rarely the hard part, but the complexity of the process and the number of systems the work has to reach into.
The first hidden cost is the process itself. The uncomfortable truth of regulated automation is that most of the effort — and therefore most of the cost — is not the code; it is the work of describing the process end to end, naming every control point and sign-off, and redesigning the parts that were only ever held together by an experienced person's judgment. This is the majority of the engagement, and it is invisible on a feature list. It is also the work that cannot be skipped: an automation built on an undocumented process simply automates the confusion, faster. Institutions that treat process mapping as an overhead to be minimised are the ones who pay for it twice — once in the rework, and again in the audit finding.
The second hidden cost is the transition. A regulated workflow does not go live with a switch; it runs in parallel with the process it replaces until reconciliation holds, run after run, and that parallel period is a genuine cost most budgets omit. For a stretch — usually around the second month — the institution is paying to operate two processes at once and adding review on top, so the new workflow costs more than it saves before the curve turns. This is the second-month dip, and it is entirely predictable. Budgeting for it honestly is the difference between a board that reads the dip as expected and one that reads it as failure and pulls the plug a few weeks before the return arrives.
The third hidden cost is rework — most of it around data and integration. The clean demo built against a tidy sample is not the same as the production workflow that has to survive real inputs, and the gap between them is paid in integration effort no one quotes upfront. Data lineage that looked settled turns out to carry the same figure at two values in two systems; a connection to a source system behaves differently under load than it did in testing. None of this is exotic, and all of it costs time. The institutions that are surprised by rework are the ones that never audited their data foundation before building; the ones that did fold the cleanup into the plan and were not surprised at all.
The fourth hidden cost is the one that outlasts every other: ownership. A regulated automation is not a one-time purchase; it is a process that has to be monitored for drift, kept current as the underlying systems change, and made ready to answer an audit or a FINMA request long after the invoice is settled. That is an ongoing line, not a closing one, and a partner who presents a regulated automation as a finished project rather than a running commitment has quietly moved that cost onto your desk without naming it. The right question is not only what the build costs, but who owns the workflow after go-live and what keeping it audit-ready costs each year.
So the useful way to think about the cost of AI implementation is not a single figure but a total cost of ownership, read across the build, the process work, the transition, the rework, and the years of running it. The discipline that keeps that number honest is the same one that keeps the whole programme honest: start with a single workflow whose baseline you can prove, scope it narrowly, measure it, and let the proven case fund the next one rather than committing to a platform before the first process has paid back. That is how reporting across 39+ funds at a leading Zurich investment foundation was built — one measurable workflow at a time, each earning the next. If you want a defensible estimate rather than a hopeful one, an AI Audit is where it starts: it maps the whole cost of ownership before a line of the build is committed, which is the only figure worth trusting. It is the same discipline that runs through everything we build.