The Business Analyst Role in AI Projects: What Changes and What Doesn't

Business analysts in AI projects often hit the same wall: the techniques that work in traditional requirements gathering don't quite fit. You're used to asking "what must the system do?" but the engineers are talking about probabilities, confidence scores, and training data. The vocabulary is foreign. The deliverables feel unclear.

This isn't an experience gap. It's a framework gap. Here's how to close it.

## What doesn't change

Your core skills transfer completely. Stakeholder interviews. Facilitation. Documentation. Translating business needs into something an engineering team can build. Process mapping. Edge case identification. These are more valuable in AI projects than in traditional ones, because AI projects fail not from bad models but from unclear requirements.

Most AI models are technically functional. They fail because nobody defined what "correct" means. That's a BA problem. And it's one you're equipped to solve.

## What changes: 6 things your traditional requirements document is missing

A standard requirements document — functional specs, user stories, acceptance criteria — covers about 70% of what an AI team needs. Here's the other 30%:

### 1. Probabilistic output range

Traditional requirement: "The system shall display the recommended action."

AI requirement: "The system shall display the recommended action when confidence ≥ 80%. When confidence is 60–79%, display the recommendation with a visual uncertainty indicator. When confidence < 60%, escalate to a human."

You're not describing what the system does — you're describing what it does *at each confidence level*. This is new. You need to add it.

### 2. Human-handoff triggers

At what point does the AI hand off to a person? This sounds obvious but is almost always missing from first-draft requirements. Define it explicitly:

- When should the AI refuse to answer? - When should it answer but flag for human review? - When can it answer autonomously?

### 3. Fallback behavior

What happens when the AI can't answer — or when it fails? The system needs a defined fallback state. "I don't know" is a valid answer. Hallucinating a confident-sounding wrong answer is not. Specify what the fallback looks like, what it says, and what happens next.

### 4. Guardrail conditions

What must the AI never do, regardless of the input? These are hard constraints — not "try to avoid" but "must never." Common examples: - Never recommend a specific medication dose without a doctor review flag - Never reference competitor products by name - Never generate output that could be interpreted as legal advice

Guardrail conditions are your most important requirements in a high-stakes AI system. They're also the ones most commonly left out of first-draft specs.

### 5. Data quality requirements

Traditional systems are deterministic — garbage in, garbage out, but at least you know what went in. AI systems are trained on data that shapes their behavior before you've touched them. Your requirements need to include:

- What training data assumptions does this model make? - What input formats will cause degraded performance? - What happens when a user submits an input the model wasn't trained on?

### 6. Eval threshold

What does "ready to ship" mean for this AI feature? Not in general — specifically, for this use case: - What accuracy rate on your golden set is acceptable? - Which failure modes are dealbreakers vs. acceptable risks? - Who makes the final go/no-go call, and what evidence do they need?

If this isn't in your requirements document, the team will negotiate it under pressure in the final week before launch. Define it at Framing.

## The new questions to ask in your intake interview

Replace these with AI-adapted versions:

| Traditional question | AI project version | |---|---| | "What must the system do?" | "What can the AI decide autonomously vs. when must a human decide?" | | "What are the acceptance criteria?" | "What does 'good enough' look like, and who defines it?" | | "What happens when it fails?" | "What's the fallback when the AI can't answer, and what does it say?" | | "What are the edge cases?" | "What inputs will the model struggle with? What should it do when it sees them?" | | "Who approves the requirements?" | "Who owns the behavioral contract, and who makes the go/no-go call?" |

## Where BAs fit in the ADLC

The AI Development Lifecycle gives BAs a clear lane across all six phases:

**Discovery**: Run the AI suitability assessment. Is this actually a problem AI solves? Is there sufficient data? What's the risk profile if the AI is wrong?

**Framing**: Write the requirements document — the updated version with all six sections. Contribute to the Specify document alongside the PM (Spec Owner). This is your primary deliverable.

**Architecture**: Review the proposed system design against your requirements. Flag anything that contradicts a guardrail condition.

**Build**: The hardest phase for BAs — there's less to own, but you're on call to clarify requirements as edge cases surface. Keep a decision log.

**Eval**: Contribute to the golden set. Your domain knowledge is what makes the test cases representative. Review the EvalForge report against your defined thresholds.

**Production**: Contribute to the incident playbook. If the AI does something wrong in production, what's the triage process? Who's notified? What gets rolled back?

## The career implication

AI teams need BAs who understand probabilistic systems. Most BAs don't, not because they're less capable, but because nobody has taught them the framework. The BAs who learn the 6 missing requirements and the ADLC vocabulary become the person every AI project team wants in the room.

That's not a minor career advantage. In 2026, with AI initiatives at nearly every company with a development budget, it's the difference between being the BA who attends AI meetings and the one who drives them.

[See how the Forward Deployed course teaches this in week 2 →](https://forwarddeployed.app/seminars)