How to scope an AI project so it actually ships

The most common brief we see is some version of "we want to use AI on our documents". It is not a scope. It cannot be estimated, built, or evaluated, and every week spent refining the wording makes it no more buildable.

The fix is not more detail. It is a different shape of statement.

Step 1 — Name one repeated decision

Good AI scopes describe a decision a human currently makes many times a week. Not a capability, not a technology, not a department. A decision, with an actor and a frequency.

The right-hand column is estimable. You can count how often the decision happens, sample a hundred instances, and measure how well a system does on them. The left-hand column can do none of that.

If you cannot sample a hundred past instances of the decision, you do not have a scope yet — you have a theme.

Step 2 — Define what being wrong costs

Every model-backed decision has an error rate. Pretending otherwise is the root cause of most stalled AI pilots. So price the errors before you build, separately in each direction — because they almost never cost the same.

• False positive: the system acts when it should not have. What is the cost, and who notices?
• False negative: the system fails to act when it should have. What is the cost, and who notices?
• What error rate makes this worth doing at all, given that the human baseline is not perfect either?
• Who is accountable when it is wrong — and does that person have the ability to override it?

Note that the honest comparison is not against perfection — it is against the current process, including the errors humans already make under time pressure at 5pm on a Friday. Ask for that baseline. Teams rarely have it, and gathering it is often the most valuable week of the project.

Step 3 — Confirm the data exists before you design anything

A model can only use information that is actually present in what you give it. This sounds obvious and is violated constantly: teams scope a system to make a judgement that depends on context living in someone's head, in a separate system nobody mentioned, or in a phone call.

1. Take twenty real past instances of the decision.
2. For each, write down what a competent human needed in order to decide.
3. Check that every one of those inputs exists in a system you can read from, at the moment the decision is made.
4. If something is missing, that is the project — plumbing it in, or narrowing the scope to the cases where it is present.

This exercise takes a couple of days and routinely reshapes a project more than any architecture decision that follows.

Step 4 — Size the first slice honestly

The first deliverable should be narrow enough to build and evaluate in weeks, and representative enough that it surfaces the hard parts. Those two constraints fight each other, and resolving that tension is most of the skill in scoping.

• Narrow by segment, not by difficulty. One document type, one region, one queue — including its awkward cases. Cherry-picking the easy examples produces a prototype that proves nothing.
• Include the integration you are most worried about. If the legacy system is the risk, touch it in slice one.
• Ship it to a handful of real users rather than a demo audience. Internal users behave differently from stakeholders in a review.
• Build the evaluation set in the same slice. Without it, slice two is guesswork.

Step 5 — Write the one-page scope

A scope that survives contact with engineering fits on a page and answers six things:

1. The decision, with actor and frequency.
2. The inputs available at decision time, and where each one lives.
3. What a false positive costs and what a false negative costs.
4. The threshold at which the system acts alone, and where everything else goes.
5. The evaluation set: how many cases, who labelled them, and what "correct" means.
6. What is explicitly out of scope for this slice.

That last line is the one people skip and the one that saves the project. An AI scope without explicit exclusions expands until the deadline arrives.

If you have a decision in mind and are not sure it passes these tests, describe it to us in a couple of sentences. Telling you a use case will not work is a faster and cheaper service than building it.

• scoping
• playbook
• project planning
• buying AI