In brief
- On an AI project, the Business Analyst no longer specifies exact behaviour. Because AI is probabilistic, they define a measurable level of quality instead.
- Their key deliverables are now the to-be process with human oversight, the evaluation set and acceptance criteria expressed as success rates.
- Gains are measured across the whole process, human review included, not on the AI’s task alone.
- In Europe, the AI Act classes some uses as high-risk (credit, life and health insurance, HR, public benefits), so the BA needs to classify the use case from the outset.
What changes for a Business Analyst on an AI project?
Short answer: the core of the job stays the same: understanding the need, modelling the process, writing requirements and supporting acceptance testing. But AI produces likely answers rather than certain ones, so the BA has to think in terms of success rates, human oversight and monitoring over time.
| Topic | Traditional project | AI project |
|---|---|---|
| Behaviour | Same input, same output | Likely output, which can vary from one run to the next |
| Requirement | “The system calculates the correct amount” | “The amount is correct in at least 95% of cases in the evaluation set” |
| Acceptance testing | Each test case passes or fails | A rate measured on a fixed set, by segment |
| Human role | Uses the system | Supervises, validates, corrects, takes over |
| After go-live | The system either works or is down | Quality can drop with no visible error (drift) |
| Data | Inputs to the process | Also drives the quality and the bias of the output |
The 6 steps of an AI project, from the Business Analyst’s point of view
Short answer: scope, assess feasibility, design the process, define and measure quality, deploy in a controlled way, then monitor over time. Each step ends with an explicit go / no-go decision.
Scope: does the problem actually call for AI?
Wouldn’t a simple rule, a form or a process redesign do the job?
- Describe the business need and the expected value (time, cost, quality).
- Quantify the current state: volumes, lead times, error rates.
- Choose between AI, a business rule, a process change or a hybrid approach.
Deliverables: quantified business case, AI / rule / hybrid decision.
Assess feasibility: process, data, regulation
Is the process under control, is the data available, and is the use case allowed?
- Check that the process is documented, stable and has an owner.
- Identify the source of truth for each data item, its quality and who can access it.
- Classify the use case under the AI Act and identify the impact assessments it requires.
Deliverables: feasibility analysis, regulatory classification record.
Design: build the AI into the process
Where does the AI step in, where do humans stay in control, and what happens when in doubt?
- Model the as-is and to-be process (in BPMN, for instance), separating AI tasks, human tasks and business rules.
- Define human oversight, the confidence threshold and the escalation path.
- Plan a fallback for when the AI is unavailable.
Deliverables: to-be process, functional requirements, oversight matrix.
Evaluate: define what “good enough” means
How will we know the solution is ready?
- Agree the ground truth with subject-matter experts.
- Build a representative evaluation set, including edge cases and cases where the AI should decline to answer.
- Write acceptance criteria as success rates, by segment and by population group.
Deliverables: evaluation set, AI acceptance criteria, acceptance test report.
Deploy: go live in a controlled way
Do users know when to trust the AI and when to overrule it?
- Update procedures and roles (process owner, supervisors).
- Train users on the system’s limitations and on automation bias.
- Set up logging, and the explanations owed to the people affected.
Deliverables: deployment plan, procedures, training materials.
Operate: make sure the solution keeps performing
Who notices when quality drops, and what happens next?
- Track quality indicators, not just availability.
- Watch for drift: new data, new business rules, a model update by the vendor.
- Rerun the evaluation set after every change.
Deliverables: quality dashboard, periodic reviews.
15 AI concepts every Business Analyst should know
Short answer: you don’t need to code, but you do need these concepts to ask the right questions and write testable requirements.
| Concept | In plain terms | What the BA does |
|---|---|---|
| Use case fit | Is the problem a good fit for AI, or would a rule do better? | Qualifies and sizes the need before looking at solutions |
| Deterministic vs probabilistic | A rule always gives the same answer; a model gives the most likely one | Keeps calculations and legal rules deterministic |
| Human in the loop | A person validates or corrects the output before it takes effect | Defines who validates what, and how quickly |
| Ground truth | The verified correct answer, used as the benchmark | Identifies who knows it and writes the labelling rules |
| Evaluation set | A fixed set of test cases, rerun after every change | Builds it from common, rare and tricky cases |
| Hallucination | A false or made-up answer, delivered with confidence | Includes questions the sources cannot answer |
| RAG | The AI answers from documents retrieved from a knowledge base | Identifies the authoritative sources and who can access them |
| Prompt template | A reusable, version-controlled instruction | Reviews it as they would a specification |
| Guardrail | A control that blocks or flags an out-of-bounds input or output | Lists what the AI must never say or do |
| Confidence threshold | The level below which the output is routed to a human | Has the business set the threshold based on measured data |
| Data lineage | Where each data item comes from and how it has been transformed | Maps the data flows and their owners |
| Model drift | A gradual drop in quality, without any deliberate change | Defines the indicators and alert thresholds |
| AI acceptance criteria | Requirements expressed as success rates on an evaluation set | Writes them, by segment and by group |
| Escalation path | Who takes over when the AI cannot decide | Models it, including the fallback mode |
| Total process effort | Time saved, minus the time added for checking and correcting | Measures the gain across the whole process |
Also worth knowing: bias and fairness, explainability, precision and recall, context window, AI agents, prompt injection.
How do you write an acceptance criterion for an AI system?
Short answer: as a success rate measured on a fixed evaluation set, never as a single pass/fail case. A good criterion has a metric, a threshold, the test set, a breakdown by segment and the errors that are never acceptable.
| ID | AI-AC-014 |
|---|---|
| Objective | Route incoming requests to the right department |
| Metric | ≥ 95% correct answers |
| Evaluation set | 300 real cases, anonymised and representative |
| Segmentation | French and Dutch measured separately |
| Critical cases | 0 errors tolerated: these cases are always escalated |
Three pitfalls to avoid
- An overall rate that hides a weak segment: 95% on average can mask 70% for one language or one type of case.
- Accuracy on imbalanced classes: with 2% fraud, a system that never flags anything still scores 98% accuracy. Measure precision and recall instead.
- Tuning to the evaluation set: if you adjust the prompt while looking at the test cases, they stop measuring anything.
How do you measure the real gain from AI?
Short answer: across the whole process. From the time the AI saves, subtract the time added for checking, correcting and handling escalations.
Real gain = time before − (AI time + review + rework)
Example: a case that took 12 minutes now takes 2 minutes of AI processing, 6 minutes of human review and 1 minute of rework: 9 minutes in total. The real gain is 3 minutes per case (−25%), not the 10 minutes the AI’s own time would suggest.
Hidden costs need to be factored in too: maintaining the evaluation set, monitoring, training, licences and compliance, as well as the cost of an error that slips through the controls.
What the AI Act and other regulations require
Short answer: obligations depend on the use case, so the BA needs to classify it during scoping. A writing assistant carries almost no obligations; a credit or welfare decision carries many.
The AI Act (Regulation (EU) 2024/1689) defines four levels: prohibited practices, high risk, transparency obligations (a chatbot, for instance) and minimal risk. Since 27 July 2026, the Digital Omnibus (Regulation 2026/1744) has pushed back the obligations for Annex III high-risk systems to 2 December 2027. The prohibitions, the AI literacy obligation for staff (Article 4, in force since February 2025) and most transparency obligations have not been postponed.
| Sector | Examples of high-risk uses (Annex III) | Examples usually not high-risk |
|---|---|---|
| Banking | Creditworthiness assessment and credit scoring of individuals | Financial fraud detection (expressly excluded), internal assistants |
| Insurance | Risk assessment and pricing in life and health insurance | Non-life pricing, claims handling, customer service |
| Public sector | Eligibility for, granting or recovery of public assistance benefits | Writing assistant, case summaries |
| Human resources | Recruitment, CV screening, performance reviews, promotion | Scheduling, internal FAQ |
The obligations that shape the BA’s work
- Effective human oversight (Article 14): whoever provides oversight must understand the system’s limitations and be able to override or stop it.
- Data governance (Article 10): data that is relevant, representative and checked for bias.
- Fundamental rights impact assessment (Article 27): required before deployment for public bodies, private entities providing public services, and deployers of credit scoring or of life and health insurance pricing.
- GDPR: Article 22 governs fully automated decisions with legal or similarly significant effects.
Sector regulators add their own expectations, such as EIOPA’s August 2025 opinion on AI governance in insurance. This guide is not legal advice: always confirm a use case’s classification with your compliance team.
Common mistakes BAs make on AI projects
- Starting from the technology (“we need a GenAI use case”) instead of the business problem.
- Automating an unstable process: the AI simply scales up its flaws.
- Treating past decisions as ground truth: they carry the errors and biases of the people who made them.
- Rubber-stamp human review: a reviewer handling 300 cases a day is no longer really reviewing anything.
- Measuring the gain on the task rather than across the whole process.
- Treating go-live as the finish line, when quality can drift without anyone noticing.
The Business Analyst’s checklist for an AI project
- Does the need really justify AI, rather than a simple rule?
- Is the current state quantified (time, volumes, errors)?
- Has the use case been classified under the AI Act, with the required impact assessments?
- Do we know what the right answer is, and who can confirm it?
- Are the data and documents used up to date and properly protected?
- Does the to-be process show where humans step in and how escalation works?
- Is there a fixed evaluation set that includes difficult cases?
- Are the acceptance criteria quantified, by segment and by group?
- Does the supervisor have the time, the skills and the authority to say no?
- Can a decision be explained to the person it affects?
- Is anyone monitoring quality after go-live?
- Is the gain measured across the whole process?
Frequently asked questions
What does a Business Analyst do on an AI project?
The Business Analyst makes sure the AI addresses a real need, fits it into the business process, puts numbers on what “good enough” means and organises human oversight. In short, they turn a probabilistic system into verifiable requirements.
Do you need coding skills to be a Business Analyst on an AI project?
No. You need a working understanding of how AI behaves (probabilistic outputs, RAG, hallucinations, drift) to ask the right questions and write testable requirements, but building the system remains the technical team’s job.
How do you write an acceptance criterion for an AI system?
An acceptance criterion for AI is expressed as a success rate measured on a fixed evaluation set: a metric, a threshold, the test set, a breakdown by segment and a list of zero-tolerance errors. For example: at least 95% correct answers on 300 real cases, measured separately in French and in Dutch.
What is an evaluation set?
A fixed set of test cases with their correct answers, rerun whenever the prompt, the model or the data changes. It is the AI equivalent of a regression test suite.
When do the AI Act’s high-risk obligations apply?
Since the Digital Omnibus (Regulation 2026/1744) came into force on 27 July 2026, the obligations for Annex III high-risk systems apply from 2 December 2027. The prohibited practices, the AI literacy obligation and most transparency obligations have not been postponed.
How do you measure the real gain from AI?
Compare the time the whole process takes before and after, including human review, corrections and escalations. A task that drops from 12 to 9 minutes per case, review included, saves 3 minutes, or 25%, even if the AI itself takes only 2 minutes.
Mathieu Romain, Lead Business & Functional Analyst with more than 13 years of experience, mainly in life and non-life insurance.
IREB-certified in requirements engineering. This guide brings together published good practice and the European regulatory framework; it is not a substitute for legal advice.
Sources
- Regulation (EU) 2024/1689, AI Act, EUR-Lex
- AI Act Service Desk (European Commission), Annex III
- AI Act Service Desk, Article 27
- National Law Review, the Digital Omnibus comes into force
- EIOPA, Opinion on AI governance and risk management (August 2025)
Scoping an AI project?
I help teams with business analysis, process design and turning needs into verifiable requirements.
Get in touch