AI Project Scope of Work: What to Include

An AI project scope of work is where I’d settle the choice between a budget the AI is merely told to respect and a limit the software actually enforces. If you run an online shop, a marketing team or any business using paid AI agents, that difference can decide whether a workflow stays inside your operating budget or keeps spending after everyone assumed it had stopped.

A written scope should do more than list features. I’d use it to name the business task, the workflow, what the system can spend, how you’ll judge the result, and who gets to approve exceptions. In one project, we chose a cost estimate before each render, a log of spending for every shot, and spending caps enforced by the server. Only a person could raise a cap in the interface. We chose those controls over spending first and reporting the bill afterwards, or putting the budget only in the AI’s instructions. Across 303 renders, the median episode cost was about $6, according to the project record available in October 2026 (the AI video studio we built). The point isn’t that every project should use the same dollar limit. It’s that a prompt can ask the AI to stay within budget, while a server-side cap can stop it.

What an AI project scope of work needs to settle

A useful AI scope describes the work in terms your team can recognize, not just the software someone plans to build. The NIST AI RMF Playbook says tests and metrics should show whether a system is fit for its purpose and working as claimed; the right measures depend on the system’s purpose, audience and evaluation needs.

I’d start with the task and workflow: what starts the process, what information enters, what the AI does, what comes out, and where a person makes a decision. “Answer customer questions” leaves too much open. A usable scope says which questions, what sources the system can use, whether it drafts or sends answers, and who reviews an answer that could cost the business money.

Then define what the system will not do. An agent that drafts a reply but waits for approval has a different risk from one that sends the reply itself. The scope should state what may happen automatically, what needs human approval, and what happens when the input is incomplete or outside the agreed task. RAND’s 2024 report found that interviewed AI practitioners described failures tied to problems such as choosing the wrong metric, poor fit with a business workflow and insufficient data (RAND’s report). A feature list doesn’t resolve those mismatches.

Put budget controls where the system can enforce them

A budget cap is a technical rule that stops spending at an agreed limit. A sentence in a prompt is an instruction to the AI, not a server-enforced spending control. That distinction mattered in our video-studio work: we chose an estimate before each render, a spend log for each shot, and a cap the server enforced; only a person could raise it in the interface (the AI video studio we built).

I’d make the scope answer four things: who pays variable model or media charges, how the system estimates a run before it starts, where it records actual spending, and what happens at the cap. You may choose a different limit from the video-studio project, but the control should match the consequence of a mistake. A team producing paid marketing content may want an estimate and approval before a costly render. A small internal task may need a simpler threshold.

Budget approach	What it does	What can go wrong
Spend first, report later	Shows the total after the work runs	You learn about excess spending after it has happened
Put a budget in the AI’s instructions	Asks the model to follow a budget	The instruction is not a technical limit
Estimate, log and enforce a server-side cap	Shows a projected cost, records usage and stops at the limit	Work may need a person to review or authorize before continuing

The cap needs an agreed response, not just a number. In the video-studio scope, the editorial adjustment when an episode ran over was fewer motion shots, not a larger budget by default. I’d write down what your team can reduce first, who can approve a change, and what the system should do while waiting. An estimate gives a person something to consider before paying; a hard cap gives the business a way to stop execution.

A hard cap isn’t always the right level of control. For a one-off job that costs only a few dollars, adding an approval step can create more friction than protection. My advice is to set a condition for when the system must pause for approval, based on the cost or workload that matters to your business, rather than forcing the same process onto every tiny task.

Define tests that can pass or fail

Acceptance criteria are the agreed conditions a system has to meet before you accept it. “Works well” is not a test. A scope needs a set of inputs, test steps, a measurable pass threshold, and a named person who decides whether the result passes.

I’d ask the developer to specify the test data and procedures, including whether tests are manual, automated, adversarial or stress tests. Adversarial tests try inputs that could expose unsafe or unreliable behavior; stress tests check what happens under demanding conditions. NIST recommends documenting testing that identifies errors and limitations, and recording acceptable performance limits and corrective actions in the Measure Playbook.

For example, a scope could define what counts as a correct draft, what kinds of input must trigger human review, and what happens if the measured error rate crosses the agreed threshold. The exact threshold has to fit the task; there isn’t one universal pass mark for every AI system. NIST also recommends documenting risks or trustworthiness characteristics that the team has not measured and why. A test pass proves the system met the selected tests. It doesn’t prove it has been tested against every possible failure.

Acceptance also needs an owner after launch. NIST recommends checking performance before and after deployment and reassessing measures and controls as data, models or operations change. I’d name who reviews error reports, what triggers a new test, and who can pause or roll back the system. A test that passes on last month’s data doesn’t tell you whether a changed input source still works.

Write down data, dependencies and client responsibilities

The scope should say what data the client supplies, in what format, with what access and by when. If a developer needs invoices, product records or customer emails, vague promises to “share the data” can delay the work or leave the system untestable. RAND’s 2024 interviews identified inadequate data as one cause of AI project failures, which is why I treat data access as a delivery dependency, not a late technical detail (RAND’s report).

List the outside pieces the system depends on: models, APIs, tools and client data. An API is a service one software system uses to request information or actions from another. NIST recommends monitoring external inputs and third-party tools because changes in those dependencies can affect performance and risk (NIST’s Measure Playbook). Ask who pays for those services, who owns the accounts, and what happens if a provider changes or becomes unavailable.

Privacy terms need to be specific to the project’s data and access. Name what information the developer can see, how the system uses it, and which client person approves access. Don’t treat a privacy promise as a substitute for the data plan: a scope also needs to show what the system will receive and where that information goes. Your own lawyer or compliance officer should confirm the requirements that apply to your business.

Separate deliverables, ownership and changes

A fixed-price AI development contract needs a boundary around what the price covers. List deliverables, assumptions, exclusions, client responsibilities and the written change-order process. A change order is an agreed record of new work and its effect on price or timing. RAND’s report describes interview-based failure causes such as misunderstanding the problem, optimizing for the wrong measure, workflow mismatch and inadequate data; writing down the boundaries gives both sides a place to resolve those issues before a deadline turns them into a dispute (RAND’s report).

I’d also separate ownership into named categories: client data, custom code, documentation, credentials, third-party components and reusable vendor materials. Paying an invoice does not automatically transfer every right. Under U.S. copyright law, copyright initially belongs to the author, and work-made-for-hire treatment applies only under statutory conditions; the relevant agreement requires a signed written instrument (17 U.S.C. § 201). Have your lawyer review the language that applies to your contract.

The scope should cover what happens if work fails an acceptance test, a person requests a feature outside the boundary, or a dependency changes. Define who approves a change, how the added work is estimated, and whether the original delivery pauses while the parties decide. I’d be wary of a fixed price paired with a vague deliverables list: neither side can reliably tell whether a late request is a correction or a new feature.

Compare the ways to get the work done

You can adapt an off-the-shelf tool, hire a developer or studio, or build internally. The right route depends on whether an existing product fits your workflow, whether you can maintain the system, and how much control you need over data and spending. I wouldn’t pick a route from the word “AI” alone.

Route	Worth considering when	Scope questions to settle
Off-the-shelf tool	Its workflow and controls already fit your task	Can you set a hard spend limit, test with your data and export your work?
Freelancer or small studio	You need a custom workflow but don’t need an internal team to build it	What will be delivered, who owns it, and how are changes approved?
In-house team	You can assign people to build, test and maintain the system	Who owns each decision, and who handles support when the original team moves on?

For a custom system, WebDaddy offers fixed-price AI packages listed on its services page: an agent for routine work starts at $500 with a 7-day Starter package, and a document assistant starts at $800 with a 7-day Starter package. Those options cover specified tasks and document limits; a larger or different system is scoped separately. I’d compare any package with your actual workflow and acceptance criteria, rather than assuming a listed starting package covers every requirement.

A written plan is only useful if it reflects how people will use the system. A 2024 Education Week report on the Los Angeles Unified chatbot described concerns about an overly broad remit, privacy and vendor continuity. The reporting also noted that the tool was temporarily turned off amid vendor turmoil (Education Week’s account). I’d use that as a reason to ask what happens to client accounts, code and documentation if a vendor can no longer support the work, not as a reason to assume every project has the same risk.

Use this checklist before you approve the scope

A useful checklist turns the discussion into decisions someone can verify. I’d keep these points in the scope itself, not in a separate call that nobody can refer back to.

1. Name the workflow. Write down the trigger, input, AI action, output and human decision point.
2. Set the boundaries. State what the AI can do automatically, what it cannot do, and when it must hand work to a person.
3. Define the budget control. Record who pays variable usage charges, the pre-run estimate, the server-side cap, and who can raise it.
4. Agree on acceptance tests. Name test data, procedures, measures, pass limits, approver and the correction or rollback if a test fails.
5. List data and dependencies. Specify what the client supplies, the format and access needed, and the models, APIs and tools the system uses.
6. Set ownership and change terms. Separate the deliverables and rights, list exclusions, and require written approval for new work.
7. Write the support plan. State the support period, covered bug fixes, response route, monitoring responsibilities and billable maintenance.

For fixed-price work, the scope should also say when client data or approvals are due, because those dependencies affect whether the work can be completed as planned. NIST recommends clear responsibility and accountability for AI risk management, which supports naming the client approver, escalation owner and person who can authorize exceptions (NIST’s Measure Playbook).

My final check is simple: where does the spending limit live? If the answer is “in the prompt,” I’d ask what stops the system at the server. In the prompt, a budget is a wish; on the server, it’s a limit.