Most of what a business analyst does on an AI project is the same work done on any project. You find out what the business needs, you write it down so it can be built and tested, and you make sure what gets delivered does the job. What changes is the detail, and the detail is where AI projects succeed or fail.
Start With Whether AI Is the Answer
Before any requirement is written, someone has to ask whether AI is the right tool. Many problems handed to an AI team can be solved with a rule, a report or a better form. A rule is cheaper to build, easier to explain and never drifts. The analyst is often the only person on the project who looks at the business problem before the technology, so ask the question early and write down the answer and the reasons.
When AI is the answer, the business case needs a measure of success the business understands, not only the data team. "Model accuracy of 92%" means little to an operations manager. "Two in three claims processed without a person touching them" means a great deal. If you cannot state the measure in business terms, you will not be able to actually measure that success later.
Requirements for Something That Is Right Most of the Time
Conventional software is right or wrong. If a calculation is wrong, it is a defect and it gets fixed. A model is right most of the time, by design. Its requirements have to say how often it must be right, measured how, on which cases, and what happens when it is wrong.
"The system classifies incoming emails correctly" cannot be tested. A requirement that can be tested reads more like this: the system routes at least 95% of incoming emails to the correct queue, measured monthly against a sample checked by staff; emails it is unsure about go to a review queue; no complaint is routed to the general queue.
That last part matters. Errors do not all cost the same. A misrouted newsletter is a nuisance; a misrouted complaint can become a regulatory problem. The analyst works with the business to decide which errors are tolerable and which are not, and the requirements say so plainly.
The Data Is a Requirement Too
Most AI projects that fail, fail on data. The analyst does not need to build models, but does need to document what data exists, where it comes from, how good it is and whether it represents the cases the system will see in production. 10 years of records from one region will not train a model that works well in another. Records that staff corrected by hand without logging the correction will teach the model the wrong answer.
An experienced analyst already knows how to ask these questions. On an AI project they belong in the requirements, with an owner and a date, because the project cannot move forward without the answers.
People and Models Working Together
Very few AI systems run without people. The process model has to show where the model decides, where a person reviews, how exceptions flow and how corrections get back to the team that maintains the model. As-is / to-be process flows are as useful here as anywhere; the to-be flow simply has a new participant that is sometimes wrong.
Done well, the model takes the mediocre, mundane, repetitive work and people handle the cases that need judgment. Done badly, people spend their day checking work the model already got right, or trusting work it got wrong. The difference is in the design, and the design is the analyst's work.
Acceptance Is Agreed Before the Build
Acceptance criteria for AI are statistical, and they have to be agreed before the model is built. If they are set after the team has seen the results, the bar tends to move to wherever the model landed. Agree the test set, the measures and the thresholds first, and write them down.
After go-live the work continues. The world changes, and a model trained on last year's cases slowly gets worse on this year's. Monitoring requirements say what is measured, how often, who looks at it and what level of decline triggers a review.
Fairness and Accountability Are Requirements
Fairness, transparency and privacy are often treated as principles on a poster. For the analyst they are requirements like any other: stated, traced and tested. Which groups must the system perform equally well for? What must a person be told when a decision about them involved a model? Who is accountable when it goes wrong? Laws and frameworks in many countries now expect answers to these questions, and the requirements are where the answers are recorded.
What This Means for Your Career
None of this replaces business analysis. It builds on it. The analysts who will lead AI projects are the ones who already know how to elicit, model and validate requirements, and who learn what changes when part of the solution is a model. That is the gap the Certified AI Business Analysis Professional (AI-BAP) program was written to close.
Follow IIAAIT on LinkedIn for new articles.