There is a version of the AI story in which business analysts become redundant. If you can describe a problem in plain English and an AI system will figure out the solution, who needs someone to translate between the business and the technology team?
That version is wrong. The discipline of business analysis is more important in the AI era than it was before — for a reason that takes about thirty seconds to understand once you've seen it in practice.
AI makes bad requirements faster.
What bad requirements look like at speed
A traditional software project with bad requirements produces bad software slowly. You discover the requirements were wrong when the system is built, tested, and delivered. That's expensive. It's also visible — you can trace the failure back to a point in time when the right questions weren't asked.
An AI-assisted project with bad requirements produces bad outputs immediately and at scale. The model is trained on a misunderstood process, or fine-tuned on data that encodes the wrong assumptions, or deployed to automate a workflow that nobody had actually mapped correctly.
We worked with a professional services firm that used a large language model to automate a significant part of their client intake process. The model was technically excellent — state-of-the-art architecture, well-tuned, impressive benchmark performance. It failed in production within six weeks.
The failure had nothing to do with the model. It had to do with the intake process itself. The process the firm thought they had — documented, trained on, used to create the training data — was not the process they actually ran. In practice, experienced staff made dozens of undocumented judgement calls that weren't in the process documentation and weren't in the training data.
The AI system faithfully automated the documented process. The documented process was fiction.
What business analysts actually do
The caricature of a business analyst is someone who documents requirements in a template and passes them to developers. That's not what good BA work looks like.
Good business analysis is investigative. It's the practice of discovering what a process actually is — not what the documentation says it is, not what senior managers believe it is, but what the people doing the work do on a Tuesday morning when something unusual comes in.
It involves sitting with the people doing the work. It involves asking why something is done the way it's done, and being comfortable with the answer "we've always done it that way." It involves identifying the implicit knowledge that experienced practitioners hold but have never needed to articulate, because until now they were the ones making the decisions.
That investigative work is what AI projects consistently skip. The model is the exciting part. The requirements are the boring part. And the boring part is where the project fails.
What changes in the AI context
In a traditional software project, bad requirements produce a system that does the wrong thing. Humans notice, because humans are using the system. The feedback loop exists.
In an AI-powered process, bad requirements produce a model that confidently does the wrong thing at scale, in ways that can be invisible until the damage is significant. The model doesn't know it's wrong. It doesn't flag uncertainty in the places where a human would hesitate. It just produces outputs, consistently, based on the process it was trained on.
This is why the front-end of an AI project — the discovery work, the process mapping, the identification of implicit decision rules — is more important than it's ever been. Not less.
The organisations that are succeeding with AI delivery are the ones that invested in understanding what their processes actually are before they tried to automate them. The ones that are struggling are the ones that assumed the documentation was accurate.
If you're planning an AI initiative, the requirements work should happen before the model selection. Talk to our business analysis team about discovery.