How to Write a One-Page Charter for an AI Pilot

Five sections do the work, plus a compact header that names the pilot, the sponsor, the pilot lead, the decision date and the workflow under test. Keep the whole page at about 500 words; the header carries facts, the sections carry decisions.

Two habits make the page usable. First, write "unknown, discovery required" wherever evidence does not exist rather than inventing precision; an explicit gap is safer than a fabricated number (Juan Carlo). Second, keep the charter free of model and vendor names. The hypothesis should describe the result, not commit the team to one framework.

A useful distinction before you draft: a proof of concept asks whether the approach can work on representative cases, a pilot asks whether it improves a real workflow under bounded conditions with named users and human oversight, and production asks whether the organization can operate it over time. Only the middle question belongs in a pilot charter, and the scale, revise or stop decision at the end is the gate into the third (Juan Carlo).

Scope is the section that prevents scope creep, and it only works if the out list is as specific as the in list. Andrew Ng's guidance for first AI projects is to start small and pick a project with a specific business thesis, noting that projects chosen because a team has a lot of data in some area, with the expectation that the AI team will find value, tend to fail (Harvard Business Review). A scope section is where that thesis gets pinned down.

Write the in list against one workflow, one user group, one volume and one time window. A strong scope statement reads like an address, not a strategy: one workflow, one queue or category, one team, one date range. If a sentence could describe two different workflows, it is too broad.

The out list is where you spend the political capital. Typical entries for a first pilot:

• Any autonomous customer-facing output; humans review before anything is sent.
• Adjacent workflows that share the same data, even if they look easy.
• New data sources that require a procurement or privacy review not yet completed.
• Changes to pricing, eligibility or account-level decisions.
• Additional languages or regions beyond the named user group.
• Reuse of pilot outputs in production systems before the decision date.

The charter template used in published guidance draws the same line: a support triage pilot explicitly excludes fully autonomous customer response, account-level escalation decisions and refund handling even while it includes classification, summarization and routing recommendations (InitializeAI). Naming exclusions prevents a successful narrow test from quietly becoming an uncontrolled rollout.

One more rule: the pilot tests one AI pattern, whether classification, extraction, retrieval, summarization, drafting or decision support. If the in list mixes three patterns, you have three pilots and one page that cannot describe them.

A metric without a baseline is an opinion. The most common consequence of undefined success criteria is that an organization runs a pilot, observes performance at the end and has nothing to compare against, so a 12 percent error rate reduction sounds significant until someone asks what the error rate was before (AI Assembly Lines).

Use four numbers on the page, and no more:

1. The primary outcome metric, the single KPI that changes if the AI is working.
2. The baseline, measured on the current workflow with a stated source and measurement window.
3. The target, the minimum improvement that justifies the next investment.
4. Guardrail metrics, the things that must not regress beyond a stated tolerance.

A worked example makes the arithmetic concrete. Suppose a team handles 8,000 inbound tickets per month and the current median handling time is 11.4 minutes, measured from the ticketing system over the previous eight weeks. The team sets a target of a 20 percent reduction in median handling time on the subset of tickets in scope, and a guardrail that first-contact resolution must not fall by more than 2 percentage points. With those numbers written down, a 14 percent improvement is a clear "revise," not a debate. Without them, it is a slide.

This is also why "productivity" is a bad metric. No one agrees what it means, so proving ROI becomes impossible (Savvi AI). Attach every success metric to a number that already exists in a system of record.

Sample size is a decision too. Guidance for AI pilots suggests defining how many participants you need, selecting them from the eligible pool rather than asking for volunteers, and running a treatment group against a comparable control that does the same work without the tool (Institute of AI PM). Volunteers inflate adoption numbers; skeptics alone tell you nothing about broad rollout. Write the selection rule on the page.

Finally, pre-register the analysis. State the metric, the measurement window and who computes it before any results arrive. If the approach changes after preliminary data, record what changed and why.

A budget cap without a trigger is a wish. The cap is the maximum the pilot may spend without returning to the sponsor, and the trigger is the event that forces a re-decision before the cap is reached.

Write the cap as a single number with categories, for example: total ceiling, split across people time, vendor or API usage, data preparation and evaluation. Then write one trigger sentence, such as: if committed spend reaches 70 percent of the cap and the primary metric has not moved by at least half the target, the pilot pauses for a sponsor review within five business days.

Three practical rules:

• Count people time. Pilots that only count licenses underestimate cost, and one writeup of charter mistakes points out that change management and ongoing costs are routinely underfunded, not just tooling (Dan Cumberland Labs).
• Separate run cost from build cost. Usage-based inference spend scales with volume; decide up front whether the cap covers a fixed volume of test cases.
• Name who can raise the cap. Only the sponsor, and only in writing, appended to the page.

If your pilot spans several model types, text generation, extraction, embeddings and speech, a single API with prepaid US dollar pricing makes the usage line on the charter easy to forecast. That is what Quanta Inference provides, and it keeps the budget section to one row per model type instead of one row per vendor.

Diffused accountability is the quiet killer. When accountability is distributed instead of assigned, no one owns the outcome (Dan Cumberland Labs). Counter-intuitively, the charter gets clearer when one person holds several roles; what matters is that every responsibility has a name next to it.

Two additional rules keep this honest. First, the business owner is not the pilot lead; the person who built the thing should not be the person who certifies it worked. Second, the data owner grants the minimum permission for every action the pilot takes, and prohibited data types are listed explicitly, which is how charters handle sensitive inputs in practice (Juan Carlo).

If your team lacks an experienced pilot lead, a line-of-business expert who has run adjacent work can fill that seat. Quanta Experts pairs such a person with your context and hands back finished deliverables, which is often enough to get the charter written in a week rather than a quarter.

Stop conditions are the part teams skip and the part sponsors remembers. Write them as conditions, not feelings, and include four kinds:

• Performance floor. If the primary metric moves the wrong way for two consecutive measurement windows, stop.
• Quality guardrail breach. If a guardrail metric crosses its tolerance, pause and review before more volume is processed.
• Data or rights failure. If a required data source is unavailable, or its terms of use no longer cover the pilot, stop.
• Cost trigger. If projected spend will exceed the cap before the decision date, stop and review.

Schedule the review before launch. A pilot that runs longer than eight weeks for a non-infrastructure AI feature is usually a sign of scope creep or unclear success criteria (Institute of AI PM). Put the decision date in the header, then add a short cadence: a weekly written check on the primary metric, the guardrails and spend, and a mid-pilot review that can invoke any stop condition.

Change control belongs on the page too. The charter is reviewed at the fixed cadence and amended only by written agreement between sponsor and pilot lead, with the amendment dated and appended. No silent edits to the target after results start arriving; that is the moving target problem in miniature (AI Assembly Lines).

Print this, fill it in, and get two signatures before the first API call or vendor invoice.

AI PILOT CHARTER
Pilot name:
Sponsor (name, title):            Decision date:
Pilot lead (name):                Review cadence: weekly check, mid-point review

1. SCOPE
Workflow (start to end):
In:  (users, volume per week, systems, AI pattern)
Out: (list at least five exclusions)
Data used (source, sensitivity, minimum permission):

2. SUCCESS METRICS
Primary metric:                   Baseline (value, source, window):
Target:                           Guardrail metric and tolerance:
Participant selection and size:   Analysis owner and method:

3. BUDGET CAP
Ceiling (USD):                    Split: people / vendor or API / data / evaluation
Review trigger (spend level and metric condition):

4. ROLES
Business owner:                   Data owner:
Risk reviewer:                    Users (named group):

5. STOP CONDITIONS
Performance floor:                Guardrail breach:
Data or rights failure:           Cost trigger:

Signed (sponsor):                 Signed (pilot lead):
Amendments (dated, appended):

If you are writing several of these at once, a free consulting call is a reasonable place to pressure-test the targets and triggers before you commit them to paper; the useful output is a recommendation you can paste into section two.