Why most AI projects in finance fail

I currently work as the director of finance data strategy and governance at Visa, where my job is essentially all things data: data strategy, data foundations, and revenue reporting.

Before this, I led finance transformation initiatives at Autodesk. Across both roles, my focus has always come back to the classic trio of people, process, and technology.

Lately, I've been interspersing that with something I care about deeply: the importance of a product mindset when it comes to building AI in finance.

I want to walk through what that means, why so many AI initiatives in finance fail, and what I think teams should actually do about it.

Watch the full podcast episode with Abhishek Chandna here:

Building AI the product way

When I talk about building AI the product way, I mean a fundamental switch in mindset. Here is what I have seen: a lot of finance teams approach AI projects the same way they approach ERP upgrades.

With an ERP upgrade, you have a project plan, a delivery date, and then the project is done. It ships, and it's done and dusted. That is not how AI projects work, and it never will be.

AI is always a living capability, and understanding that distinction is essential. That is where the product mindset kicks in.

Instead of asking "has this model been built?" or "has this project been completed?", I think a more useful question is "has this improved the end-to-end decision?"

That is what product thinking gives you: you start asking who the user is, what workflow you are trying to embed AI into, what decision you are actually trying to improve, and whether that decision has, in fact, improved.

Until you have those feedback loops in place, users will simply go back to their old ways of doing things, and your AI product will not succeed. That is not the outcome anyone wants.

I was watching one of Sam Altman's speeches recently, and he made a point that stuck with me: the real power of AI does not lie in the perfect model you have built or the perfect project you have embedded.

It lies in how well that AI is woven into your everyday workflows. That, to me, is the real power of AI.

Why AI projects in finance fail

I see two recurring reasons AI initiatives fail in finance. The first is that people start from the wrong place. They do not have good foundations in place, they have not defined a clear process, and there is no alignment on what the actual problem is that they are trying to solve.

Everyone involved may be pulling in different directions about what they are trying to achieve. So the first and biggest issue is people starting from the wrong place, often trying to build the perfect model before they have taken care of the fundamentals.

The second reason is that finance, by its nature, is a system of systems. You have data, processes, accountability, and compliance, and they are all deeply intertwined.

If there is no alignment across those pieces, AI will not be a magic bullet. It becomes the classic case of garbage in, garbage out, except now it produces garbage much faster and much more seamlessly, which does not help anyone. Individuals end up saying, "this is fancy, but it's all wrong."

Those are, in my mind, the two key reasons AI initiatives fail, and the way around both is to hone in on a product mindset: thinking about the decision, the end user, and the true problem you are trying to solve before you jump straight into a solution.

I understand why finance teams are cautious here, too. Finance deals with sensitive data, and if something goes wrong, the consequences can be serious. Andy Grove, the former CEO of Intel, once made the point that systems fail when there is a lack of understanding.

That is exactly what happens with AI adoption in finance. There is a lack of understanding of how these models actually work, and that breeds resistance to moving away from legacy systems.

Start small: the variance analysis example

My advice, both to my own team and more broadly, is to always start with something small. I have seen a lot of people try to build out an entire AI strategy and refuse to get started until everything is perfect.

Instead, you want to look for a process that happens frequently, causes real pain, and is not overly ambiguous. You want your fundamentals in place so that you are set up for success.

At the end of that first AI workflow, you do not want people saying, "this is super cool, but it doesn't work, so I don't care about it."

You want feedback like, "this looks simple, and it improves my life by a certain percentage. I'm going to use it."

A good example from FP&A that a lot of people will relate to is variance analysis commentary.

Analysts put this together every month or every quarter, pulling in inputs from different sources, thinking through which drivers impacted the analysis for that period, and writing up a commentary based on what they are seeing. A large chunk of that work is a great use case for AI.

Let AI handle the mundane part of producing a first pass at the variance commentary, so the analyst is not starting from a blank page.

Instead, AI creates the first draft, and the analyst reviews it, checks that the drivers make sense, refines the pieces, and sends it up to leadership.

That, to me, is a huge value add for analysts and for leadership alike. Start with something small. Do not try to boil the ocean.

Data and process are the foundations

In the world of product-led AI, process and data are the absolute foundations you need in place before you even think about the AI model itself.

Data gives you trust. Process gives you scalability and repeatability.

If your definitions are misaligned, or your process is broken, you are simply going to speed up and churn out bad data and bad outputs, because your foundations are broken.

This is exactly where a product-first mindset matters. When you truly approach a project this way, you are forced to ask the hard questions:

Is my data broken?
Are my definitions aligned?
Is the process repeatable?
Will my end users actually benefit from this AI model?
Is the decision I am trying to improve well aligned and clear?

Wearing a product manager's hat and genuinely embracing that mindset helps you avoid the exact issues people run into when their AI model gets built but produces the wrong data because the underlying data was never fixed.

Even with large language models more broadly, this holds true. When people first started using tools like ChatGPT, there was a sense that it could produce magic out of nowhere.

But these models fill in gaps with educated guesses when they do not have the full picture, and they can do so quite convincingly. The more reliable and complete the information you give them, the better the output.

It is very much a synergy between human expertise and AI efficiency, not a replacement of one by the other.

Even today, as these models keep improving at a remarkable rate, they still hallucinate. Reducing that comes back to getting your foundations right.

What a good AI MVP actually looks like

Going back to fundamentals, an MVP is a minimum viable product. Its job is to give you good input and feedback from your end users on how to improve the AI model.

It is not supposed to be your final end goal, packaged up and handed to users to simply adopt. An MVP is something users test and give you feedback on: maybe it is still hallucinating on certain decisions, maybe it needs another round of iteration.

It should be a genuinely iterative piece where the first version gives you feedback that you use to improve the experience for the end user.

I often think back to Eric Ries's book, "The Lean Startup," which I would recommend to anyone trying to embrace a good product mindset. It reiterates the definition of an MVP well: it is not a shortcut to rolling out your product, but a way to generate good testing outputs.

So my answer, in short, is that a good MVP is an outcome that gives you good feedback, which you can iterate on to improve the end result for your end users.

Getting that balance right is genuinely difficult. You do not want to spend all your development time building something the end user never wanted in the first place, but you also do not want to under-build to the point where you cannot get meaningful feedback.

That happy middle ground, where you have built enough for users to give you real feedback without pouring in all your development time on the wrong thing, is the crux of a good MVP process.

One thing I always recommend to teams is to avoid vanity metrics. Do not go for the flashy metrics that make you feel good but do not actually help move the needle on whether your AI model is good or bad. Track actionable data through your MVP instead.

Human judgment still owns the decision

I am a strong believer that humans in the loop is a genuinely critical idea, not just a talking point. The way to think about it is to be intentional about which part of the process humans own.

Humans should own the parts of a workflow that involve judgment, materiality, or any critical decision.

AI should handle the mundane work: producing commentary, surfacing patterns across months or years, and summarizing everything into a neatly tied document that a human then reviews.

Think of it almost like having your own intern in the form of these AI agents. They move you past the problem of starting from a blank page by giving you a solid first draft to work from, and then you iterate on it.

The key is being intentional about what AI should solve and what requires a human, the actual expert, to review and own the final decision.

How I prioritize AI use cases

When it comes to deciding which AI use cases to build first, I think about it in two ways. If you are just getting started, go back to the principle of not trying to boil the ocean.

Look for something well defined, where the data and process are already in reasonably good shape, the process itself is not ambiguous, and it is a critical, high-frequency process with real visibility and real pain attached to it.

The other angle I encourage people to think about is solving pain points in their own day-to-day work. For my team, we have built simple Copilot agents that handle some of our regular, repetitive tasks.

For example, we regularly need to compare two versions of an Excel file to see what has changed, which columns saw updates, and what the materiality gap looks like.

We let the agent take a first pass, it gives us a solid output, and we iterate on it and help the agent improve over time.

So beyond thinking about your end users, look at your own day-to-day work and consider what you could hand off to an agent so you can focus your attention elsewhere.

How I use AI myself

People sometimes ask what I actually use AI for day to day, so I will share my three main use cases.

First, I use it constantly for a first, solid draft of any communication.

I try to give it a good prompt, asking it to think strategically or tactically, or to wear a leader's hat versus an analyst's hat, because the quality of the prompt really determines the quality of the output.

Second, I live and breathe in the world of data, and I use AI, especially Copilot, to help me look at variances and surface trends I might not have noticed on my own.

My productivity has increased quite a bit because of the patterns it has prompted me to consider.

Third, whenever I am handed a weak, poorly defined problem, which happens often in any workplace, I use AI to help me structure that problem into smaller, more manageable pieces.

Three takeaways

If I had to leave finance leaders with three things to take away from this conversation, they would be these.

First, get your foundations in place. Data and process are the critical foundations, and if your definitions are not aligned, your AI model will not work, no matter how sophisticated it is.
Second, wear the product hat. Genuinely embracing a product mindset helps you avoid the situations where an AI model does not behave the way it was intended to.
Third, start small. Do not try to boil the ocean. Pick something non-ambiguous, with a reasonably high frequency, where the decision you are trying to improve is crisp, aligned, and well defined.

The biggest myth I would like to put to rest is the idea that you need a perfect model in place before you can begin. People get caught up in whether to use a linear regression model, or in making the end goal statistically significant to some precise degree.

All of that matters eventually, but you need your foundations and a clearly defined problem first.

You need alignment on what problem you are actually trying to solve before you jump into picking the best model, the best technology, or the best large language model.

I like to close on a quote from Satya Nadella, the CEO of Microsoft, who has spoken about how technology products succeed when the foundations are genuinely in place.

That is exactly what I would want finance leaders to sit with. Make sure your foundations are in place: not just your data and your process, but your product mindset, and a clear sense of which decision actually needs your input.

Why most AI projects in finance fail (and how to fix that)