One document that turns an AI idea into a buildable project: the problem, the metric, the data, how quality is tested, who builds it, the milestones and the risks.
By the Ryz Labs team · Updated October 2026
An AI project scope defines seven things before anyone builds: the problem and the users, the success metric with today's baseline, an inventory of the data the system needs and its access status, an evaluation plan with a test set from real tasks, the team and roles, milestones from proof of concept through pilot to production, and the risks with owners. If any of the seven is blank, the project is not ready to staff. The template below fits on a few pages and becomes the reference the team builds against.
AI project scoping template
1. Problem and success metrics
Field
Fill in
Project name
[Name]
Problem statement (one sentence)
[Operations analysts spend hours a day classifying and routing inbound requests by hand]
Users and volume
[Who uses it, how many, how often]
Today's process and baseline
[Steps, time per item, error rate, cost]
What the AI system does
[Classifies requests, extracts key fields and proposes a route; an analyst confirms]
What it must not do
[Act without confirmation; expose records across teams]
Primary success metric
[Time per request, with target]
Quality metric
[Share of correct routes on the held-out test set, with target]
Guardrail metrics
[Error rate on high-risk categories; cost per request; latency]
Business owner and engineering owner
[Names]
2. Data inventory
Source
Owner
Format
Volume and age
Quality issues
Sensitive data (PII etc.)
Access status
Used for (retrieval / eval / training / context)
[Request inbox]
[Ops lead]
[Emails with attachments]
[Daily volume; 2 years kept]
[Duplicates, forwarded threads]
[Customer names, account numbers]
[Pending privacy review]
[Context, eval]
[Source]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
3. Evaluation plan
Item
Plan
Test set
[Number of real past items, sampled across categories and difficulty]
Labels
[Who labels, how disagreements are resolved]
Held-out portion
[Share kept untouched until milestone reviews]
Graders
[Code checks for format; expert review or calibrated LLM judge for correctness]
Run frequency
[Every prompt, model or retrieval change, in CI]
Pass bar per milestone
[POC bar; pilot bar; production bar]
Live monitoring
[Sampled review of production outputs; user feedback]
4. Team and roles (AI pod)
Role
Responsibility on this project
Person
Allocation
AI tech lead
Architecture, model choice, eval bar, technical risks
[Name]
[ ]
AI or LLM engineers
Retrieval, prompts, tool calls, evals, guardrails
[Names]
[ ]
Data engineer
Pipelines from sources, permissions, freshness
[Name]
[ ]
Backend engineer
Integration with the systems users work in
[Name]
[ ]
MLOps or platform engineer
Deployment, tracing, cost monitoring
[Name]
[ ]
Business owner
Metric, labeling time, user rollout
[Name]
[ ]
Security partner
Data access, injection testing, launch approval
[Name]
[ ]
5. Milestones from proof of concept to production
Milestone
Exit criteria
Target date
Owner
M0: Scoped
This document approved; data access requested; team named
[Date]
[Business owner]
M1: Proof of concept
POC bar met on the held-out test set with real data; cost per request measured
[Date]
[AI tech lead]
M2: Pilot
Pilot group uses it in their real workflow; pilot bar met; feedback collected
[Date]
[Business owner]
M3: Production
Production gates passed: quality, data access, security, cost, monitoring, rollout plan, owners
[Date]
[Engineering owner]
M4: Review
Metric compared with baseline; decide to expand, improve or retire
[Date]
[Executive sponsor]
6. Risk register
Risk
Likelihood
Impact
Mitigation
Owner
[Privacy review delays document access]
[Medium]
[High]
[Start review at M0; begin with approved sources]
[Data owner]
[Model quality below bar on rare categories]
[ ]
[ ]
[Route rare categories to humans; add labeled examples]
[AI tech lead]
[Low adoption by analysts]
[ ]
[ ]
[Build inside their current tool; involve two analysts from M1]
[Business owner]
Use this template
How to use this scoping template
Write the problem statement and baseline with the business owner first. If the baseline is unknown, measure a week of the current process before going further.
Fill the data inventory with each source's owner and request access for every source on the day the scope is drafted.
Write the eval plan and agree the pass bar for each milestone before building. The test set comes from real past items, not invented examples.
Name the team in the roles table. A role with no name is a gap to fill before M1.
Set milestone dates working back from when the business needs results, and check them against data access timing.
List the top risks with owners, and review the register at every milestone.
Get the business owner, engineering owner and security partner to approve the scope. That approval is M0.
Example: a scoped milestone with evidence
Field
Example
Milestone
M1: Proof of concept for request routing
Exit criteria
Routing accuracy on the held-out set at or above the agreed bar; no cross-team record exposure in permission tests; cost per request within budget
Result
Accuracy met the bar overall but missed it on two rare categories
Decision
Proceed to pilot with those categories routed to analysts; add labeled examples before M2
Common AI scoping mistakes
Scoping the technology instead of the problem. "Build an agent" is not a scope. Start from the workflow and the metric.
No baseline. Without today's numbers, nobody can say whether the project worked.
Data access treated as a detail. Access and privacy reviews are often the longest item on the critical path.
Eval plan written after the build. A bar set after seeing results is not a bar.
Staffing only AI engineers. Data, integration and operations work usually exceeds the model work.
Stopping at the pilot. Plan the production milestone and its owner from the start, or the pilot becomes the end state.
Need the team to build what you scoped?
Ryz AI pod teams are dedicated pods of senior engineers, typically a tech lead with AI, ML and backend engineers, that take a scoped AI project from proof of concept to production in your cloud and repos, alongside your team. They work on your team, reporting to your leads, on US business hours including New York hours. Only the top 1% of the tens of thousands of engineers we interview make it, and Fortune 500 engineering teams work with us. Typical cost is $7,000 to $15,000 per engineer per month, so the team line of your scope is easy to price. Talk to us to scope your pod, or read about forward-deployed engineers.
The problem and users, a success metric with today's baseline, a data inventory with access status, an evaluation plan with a real test set and pass bars, the team and roles, milestones from proof of concept to production, and a risk register with owners.
How do you define success metrics for an AI project?
Pick one primary business metric tied to the workflow, such as time per item, plus a quality metric measured on a held-out test set and guardrail metrics for high-risk errors, cost and latency. Measure the baseline before building.
Who should be on an AI project team?
An AI tech lead, AI or LLM engineers, a data engineer, a backend engineer for integration and an MLOps or platform engineer, plus a business owner who commits labeling and rollout time and a security partner for data access and launch approval.
What milestones should an AI project have?
Scope approved with data access requested, proof of concept on real data, a pilot in the users' real workflow, production after passing readiness gates, and a review against the baseline that decides whether to expand, improve or retire.
How is scoping an AI project different from a normal software project?
Quality is probabilistic, so the scope needs an evaluation plan and pass bars rather than only a feature list. Data access, privacy review and cost per request also carry more risk than in most software projects.
We use cookies to operate our site, improve your experience, and (where you consent) for analytics and marketing. By clicking Accept All you agree to our use of all cookies. See our Privacy Policy for details.
Privacy choices
Cookie preferences
Essential cookies
Required for core site functionality, security, and your saved privacy choices.
Always active
Analytics cookies
Help us understand how visitors use the site so we can improve performance and content.
Marketing cookies
May be used to measure campaigns and make marketing more relevant.