A growing share of Business Analysis portfolios now include requirements that were drafted, at least in part, with a language model. That is not a problem in itself. The standard has never cared which tool produced a first draft. What it cares about is whether the analyst understood the need, tested the specification and can answer for what was built.
Over the past cycle, our research team worked with assessors to look closely at where model-assisted drafting improved the work and where it quietly made it worse.
Where drafting helps
- Turning rough workshop notes into a consistent structure, so gaps become visible sooner.
- Generating candidate acceptance criteria that the analyst then challenges and prunes.
- Spotting ambiguous terms and inconsistent naming across a large specification.
- Producing alternative phrasings for stakeholders with different levels of technical knowledge.
In each of these cases, the analyst stayed in control of the substance. The tool accelerated the mechanical parts of the job and left more time for the thinking.
Where it misleads
The failures were subtler. The most common was plausible completeness: a model will happily produce a full, well-organised set of requirements from thin input, filling the gaps with reasonable-sounding assumptions. The document looks finished, so nobody goes back to ask the question that would have exposed the missing constraint. Assessors also saw generic non-functional requirements copied in without being tested against the actual service, and process descriptions that matched the manual rather than how the work really flows.
The risk is not that the draft is wrong. It is that the draft is convincing enough that nobody checks.
How assessment treats it
Candidates do not need to hide or apologise for automated drafting. They do need to show where the substance came from. In the evidence review, assessors check provenance: which parts of the specification were grounded in elicitation, observation or data, and which were generated. In the professional discussion, a typical question is simple. Pick one requirement and tell us how you know it is right.
From BIPS Professional upwards, where an analyst owns analysis for a product or domain, assessors increasingly expect candidates to describe their own rules for using these tools. What will you never delegate? How do you check a generated acceptance criterion against the real service? Strong candidates have a clear answer, and it usually involves going back to a stakeholder rather than back to the prompt.
The underlying principle is the same one that runs through all of our work on automation. Whoever submits the work owns the work. A requirement drafted by a model and approved by an analyst is the analyst’s requirement, and the evidence trail from need to result has to hold up regardless of how the first draft was produced.