AI in business analysis has been one of the most discussed topics lately. Since I started working as a business analyst, I have been trying to move forward with a focus on efficiency and impact, and along the way I have had the opportunity to observe the current state of AI more closely through both my own experience and the research I have done.
On one side, there are those who think that everything can now be done with AI. On the other side, there are those who see it as nothing more than a temporary wave of productivity. However, when we look at what is being written about this topic outside, we see a more balanced picture. Professional sources such as IIBA treat AI not only as a tool that provides automation, but also as an element that transforms the practice of business analysis. At the same time, they particularly emphasize the importance of human judgment, critical evaluation, and oversight.
I believe that from the perspective of business analysis, the real question is not this: “What can AI do instead of us?”
Because business analysis is not merely the act of writing documents. At its heart, the discipline carries a far deeper responsibility: reducing uncertainty, posing the right questions, spotting contradictions, recognizing the distance between a need and its solution, interpreting the expectations of different stakeholders, and tying decisions back to business impact. That is why AI does not wipe out what a business analyst does. Instead, by accelerating some of the more surface-level work, it actually brings the core of the role into sharper focus.
How do I use AI in business analysis?
I use AI mostly for clarifying requirements, defining scope, discovering points I had not anticipated, and supporting the decision-making process. In my company, I shape product-related decisions together with our team. After that, I start thinking about what this requirement means from the end user’s perspective, how it should work on the UI side, and how it should look. Then I question the topic from a technical perspective. What is the infrastructure-side equivalent of this request? Are there any missing points? What might the required effort be? What kind of workload will this turn into on the developer side? Are there still ambiguous areas that need to be clarified?
For me, the most useful part of AI starts exactly here. Because at this point, AI stops being only a tool that produces text and turns into an assistant that offers me alternative perspectives, makes overlooked areas visible, and helps me test my own train of thought. I see this even more clearly especially when working with agent structures such as business analyst or UI/UX expert.
Sometimes these tools surface a scenario that had escaped my attention, sometimes they give the scope a clearer structure, and sometimes they let me consider the user-side consequences of a request from an entirely different angle. Looked at this way, AI can genuinely provide meaningful support for business analysis.
Where AI falls short: the context it cannot see
But in my experience, this is also exactly where the difficult part begins. The outputs I get from AI or from agents are not always correct. In fact, quite often they increase my workload as much as they reduce it. Sometimes the reason is that the prompt was not well constructed enough, while at other times it comes down to a much more fundamental reason: no matter how strong the agent is, it cannot grasp the true context of the request as well as I can. Because a requirement is not just a written request. Behind that request there are decisions made in the past, problems that were previously experienced, managerial priorities, product strategy, technical constraints, and team dynamics. No matter how knowledgeable the agent role is, no matter how much context I provide, ultimately the real burden of the request still remains with me.
When I look at a requirement, I am not only looking at what is being said at that moment. I am also thinking about why a similar decision was made before, why a certain approach was rejected, what sensitivities have formed within the team, or what kinds of issues were previously experienced on the technical side.
The biggest risk: when false clarity looks like real clarity
AI, on the other hand, often gives me an output that looks structured and convincing. But something being correct and something appearing convincing are not the same thing. That is why I think the biggest risk of AI in business analysis is this: its ability to make false clarity look like real clarity.
A text can be fluent.
The bullet points can be well organized.
UI suggestions can seem logical.
Technical questions can appear sufficient.
But none of these mean that the problem has truly been understood correctly. This is why I see AI not as an authority, but as a thinking space.
Expanding the decision space, not making the decision
What I have found healthiest is not letting AI decide on my behalf, but letting it widen the space in which I decide. In practice, that means I turn to AI to produce a first draft, to approach a topic from multiple angles, to expose missing pieces, to raise additional questions between the technical and business sides, and to spot the gaps between user experience and requirements. The final judgment, however, remains mine. Because a business analyst’s value is not simply in generating outputs, but in being able to assess how accurate, how feasible, and how well suited to the context those outputs really are.
For me, this is where AI’s greatest contribution lies: not in thinking instead of me, but in pushing me to think more deeply.