AI Project Scope Management: Write Down What the System Must Not Do

Why does an AI scope drift faster than a software scope?

A software scope has a visible edge. An AI scope does not, and that is the whole reason the engagement that never ends is almost always an AI engagement.

In a conventional build, "the system can't do that" is a fact somebody can point at. The endpoint does not exist, the schema has no field, the library has no such method, the integration returns an error. The boundary is made of objects, so when a stakeholder asks for something beyond it, the answer is a sentence and a date. In an AI system the identical sentence is a hypothesis. Nobody in the room — including whoever built it — can reliably distinguish "this is outside the model's capability" from "we have not yet found the right retrieval step, the right example set, or the right wording." The boundary is invisible, and it moves every time a model is released, which is roughly every few weeks.

That asymmetry has a specific commercial consequence. Because no one can prove a request is out of bounds, no one can refuse it, so the request enters the backlog as discovery rather than as a change order. The scope does not get renegotiated; it gets absorbed. The pilot stays in "hardening" for a year, the original business case is quietly restated, and the exit criteria are still being discussed at the third steering committee.

An AI scope drifts faster than a software scope because the capability boundary is invisible, which makes writing down what the system must not do more useful than writing down what it must — a refusal can be checked, and a capability claim cannot.

The fix is not a better-written requirements document. It is a different document.

What goes into a scope that a software statement of work does not?

Four additions, none of them longer than a paragraph:

Intended purpose in one sentence. What decision or output this system exists to produce, and who is not permitted to rely on it. The EU AI Act classifies high-risk obligations partly by intended purpose, so this sentence is not a design nicety; it is the sentence a compliance reviewer will ask you to produce, and the one your own staff will assume if you leave it blank.

The exclusion list. For every requirement, the specific things the system must not do. This is the part most scopes omit, and it is the part that holds.

The review boundary. Which decision stays with a person regardless of measured accuracy, and which named role signs off when the system is wrong. Write the role, not the department.

The data boundary. Which sources the system may read, which it may write to, and what happens when a source is added later. Data additions are the most common scope expansion in AI work, and almost never appear in the original document.

What does an exclusion list look like on paper?

It is a table, and the right-hand column is what turns it into a business document. An example from a procurement workflow:

Three observations about this table. The middle column is what people want to discuss, and it takes ten minutes. The right column is what actually gets the project funded or stopped, and it takes a week. And the refusals are stable while the capabilities are not: "must not name a delivery date" will still be true after the next model release, whereas "must draft from the approved template" may become an understatement of what the system can do.

How do you price an exclusion before you approve it?

Every "must not" converts into a human step, and human steps have arithmetic. Volume times minutes, taken from observed work rather than declared work: if the exception log shows 400 items a month and the review takes twelve minutes on a sample of twenty cases, that exclusion costs roughly 80 hours a month at your loaded hourly rate. Not an estimate of effort. A number a controller can put next to a licence fee.

There is a second cost line on the machine side, and it is easier to get wrong than people expect. A page of dense text is roughly 700 tokens, so a 20-page policy pack that gets attached to every request is about 14,000 tokens. At 3,000 requests a month that is 42 million input tokens a month, before any output, before retries, and before the context grows because somebody added a third document. I do not quote a price per million here because list prices change faster than this article will; the point is that the volume is knowable in advance from your own request logs. If you cannot yet price the exclusion, price the decision it protects instead, using a cost model that treats a wrong output as a run-rate rather than a one-off write-off.

Which changes reopen the scope, and which do not?

Most scope fights are actually arguments about whether a change is significant. Decide that in advance rather than at the moment somebody senior asks for it.

The last row is the one people get backwards. A model upgrade is usually treated as free improvement, so it is deployed without re-testing, and it silently breaks an exclusion — the system starts summarising a document it was only supposed to flag. Meanwhile the opposite failure is just as expensive: lock the scope hard and refuse all change, and you keep paying humans for review work the current model does reliably. The resolution is a scheduled review, quarterly or tied to your release cadence, where the exclusion list is re-tested against the current model using a fixed evidence set. Scheduled review is cheap. Ad hoc expansion is not.

What does "done" mean when the boundary is invisible?

You cannot define completion as "the system does what we asked", because that sentence has no edge. Define it three ways instead.

The exclusion list has not changed for two consecutive review cycles. An evidence set of a few hundred historical cases, including the ones that should have been refused, is replayed on the current model and every refusal behaves as written. And every exclusion has a named owner and a monthly cost that a finance owner has already seen.

If a project cannot state those three things before the build begins, the honest conclusion is not that the scope needs more work. It is that nobody has decided what the system is for.

The refusals are the deliverable

The capability list you sign this month will be partially obsolete after the next model release, and the vendor's next pitch will assume it. The refusal list will not, because it encodes what your business is unwilling to delegate, and that is a property of your business rather than of any model. This is why I ask for the must-not-do column first in every engagement: it is the one section a room full of intelligent people can complete in an hour without knowing anything about machine learning, and it is the section that decides whether the work ends. Before the next steering committee, take whatever scope document exists and ask the room to fill in that column. If nobody can, you are not buying a system yet — you are buying an open-ended exploration at system prices, and you should say so out loud in the meeting where the budget is still on the table.