Most financial services firms have at least one successful AI pilot on the books. The demo worked. The proof of concept checked every box. And then, somewhere between "this looks promising" and "this is running in production," things stopped moving.
The technology isn't the problem. Snowflake, Alteryx, Cortex, these tools deliver what they promise. They work reliably, at scale, for firms that deploy them correctly. The problem is what firms expect automation to do with workflows that were never designed to be automated.
A proof of concept is designed to prove one thing: that the technology can do what you think it can. What it doesn't prove is that your workflows are ready for it.
This matters more in financial services than in almost any other industry. Investment management workflows are layered: 15, 20, sometimes 30 years of decisions made by people who are no longer at the firm, embedded in tools no longer supported, producing outputs that nobody fully understands anymore.
One portfolio manager at a large investment firm described the reality plainly: "The tool the person has is the tool they use. If you ask the plumber, it's a plumbing tool. If you ask the carpenter, it's a hammer." The result: up to six different methods for producing the same analytical output, depending on which analyst you asked. Different inputs. Different logic. Results that look similar but aren't.
You cannot automate a workflow like that. First, you have to understand what the workflow actually is.
Forrester found that 70–80% of analyst time at financial services firms goes to data preparation, not analysis. That statistic is cited constantly. What gets cited less often is what it means operationally: someone is manually pulling data, transforming it, reconciling it, and reformatting it before it ever reaches the model. Every day. For every report.
That manual process is a workflow. Usually an undocumented one. Usually running across Excel, a legacy system, a file server, and a vendor API that nobody planned to depend on this much.
Automating that workflow means replacing every step, not just the final output. Firms that automate only the last stage while leaving manual steps in place don't get automation. They get a slightly faster version of the same process, with a new failure point added at the seam.
Before automation can work, you need clear answers to two questions that most financial services firms cannot actually provide:
What does the workflow do, step by step? Not the high-level use case description: the actual decision points, data sources, transformation logic, and who does what and when. Not the "happy path" that lives in a SharePoint document from 2019. The real one, including the workarounds that have accumulated over a decade.
Who actually runs it? In most firms, the answer is: several people, in different ways, with different tools, producing outputs that look similar but are calculated differently.
A $146B AUM asset manager Continuus worked with had 20+ years of business logic embedded in legacy data feeds and Excel macros. Before any automation could move forward, that logic had to be documented, validated, and rebuilt: 51 custom attributes updated, five FactSet Standard Datafeeds restructured to replace flat-file processes. That work is unglamorous. It is also precisely what made the automation work. Data item requests that previously took six months now take one week.
The firms where automation delivers measurable results have one thing in common: they automated workflows that were already understood.
That doesn't mean clean or simple. A $90B AUM investment firm was running financial reports through Excel-based calculations that consumed hours of compute and required manual intervention at multiple stages. Rebuilding those workflows in Snowflake brought report processing 100x faster and enabled real-time analytics on $10M+ in monthly transactions. The speed improvement was real. But it was achievable because the underlying business logic had been mapped, validated, and rebuilt correctly, not just surrounded by new tooling.
When automation works, it changes what analysts spend their time on. When data prep is handled by pipelines, the 70–80% problem inverts. Analysts who spent most of their day building the input start spending most of their day using the output. That shift is quantifiable, visible on day one, and irreversible.
The firms that stall on AI automation typically share the same mistake: they tried to automate too much at once, or they automated the wrong thing first, something high-visibility but with fragile, poorly understood data inputs.
The depth-first approach starts with one workflow. The one with the clearest business pain and the cleanest data inputs. Prove the full stack: ingestion, transformation, governance, and consumption by an end user in production. Get one team using it. Then use the foundation you just built as the base for the next workflow.
Each subsequent use case gets faster and cheaper. The governance layer is already in place. The data pipelines already exist. The semantic layer already understands your business logic. The tenth workflow costs a fraction of the first.
The pilot that never became production wasn't a technology failure. It was a failure to map the workflow before trying to replace it. That step gets skipped because it isn't exciting. It also happens to be the step that makes everything else possible.