AI Project Requirements: What to Prepare Before You Start

Most delays in AI projects aren't technical. They're weeks spent waiting on something the client was always going to have to provide: a security review, a data access approval, a domain expert's calendar, a decision nobody was authorised to make.

Which means the most useful way to think about ai project requirements is not "what do we need to document" but "what has a lead time." The items below are sorted on that basis, because preparing the easy things first and discovering the slow things in week six is how a twelve-week project becomes a twenty-week one.

Conventional software requirements specify behaviour: when the user clicks this, the system does that. Every condition has a defined, deterministic response, and testing means checking whether the system did the specified thing.

You cannot write AI requirements that way, because the system's outputs are probabilistic. What you specify instead is a set of acceptance thresholds and failure behaviours: achieve at least this precision on this held-out dataset, escalate to a human below this confidence level, never take this action without approval, respond within this latency budget.

This changes what you need to prepare. Less energy on enumerating features, considerably more on defining what "correct enough" means numerically and what happens when the system is wrong, which is a question most teams postpone until it becomes urgent.

These have calendar dependencies you don't control. Beginning them on day one of the engagement rather than day one of needing them is worth more than any document in this article.

The pattern worth noticing is that none of these are engineering tasks and all of them sit on your side of the line. A vendor cannot accelerate your security team's queue, and the common failure is nobody starting the process because it felt premature before the contract was signed.

This is what a competent vendor will ask for first, and having it ready shortens discovery considerably. For each dataset the project might need, record six things:

What it is and roughly how much of it exists. Where it lives, specifically, including whether it's reachable by API, export, or only through a person running a report. What format it's in, since text PDFs, scanned PDFs, and structured records are three different projects. Who owns it and who can authorise access. How fresh it is and how often it updates. And what you're permitted to use it for, which is a legal question, not a technical one.

The last two are the ones most often skipped and most often decisive. Data you have but cannot legally use for model training is not usable data, and discovering that in week five rather than week one changes the architecture rather than the schedule.

A practical shortcut: rather than describing your data, extract a representative sample including the messy cases. Twenty real documents tell a vendor more than three pages of description, and the awkward examples are the ones that actually determine the estimate.

Three roles need naming before work starts, and they're frequently assumed rather than assigned.

A domain expert who can answer what correct looks like in ambiguous cases, with actual time allocated rather than goodwill. A decision-maker who can approve scope changes without convening a committee, since AI projects generate more mid-course decisions than conventional builds. And an owner after launch, because a model with no named owner degrades quietly regardless of how well it was built. choosing an AI development partner covers the corresponding questions to ask on the vendor side.

On budget, prepare a range rather than a number, and separate build cost from the first year of running cost, which includes inference, monitoring, and retraining. Quoting a build budget while mentally assuming it covers the year is a common source of friction later, and AI development pricing guide breaks down what typically sits in each.