How to assess an AI deployment plan: a buyer's checklist
When assessing an AI deployment plan, do not start with price. Start with whether it can answer eight questions. If it cannot, model parameters, architecture diagrams and case walls mean very little; if it can, price becomes comparable. The three most often skipped are also the three that cause trouble in year two: who owns the definitions, who operates the system afterwards, and how the engagement ends.
Eight-point checklist for an AI deployment plan
| Item | Question to ask | Warning sign |
|---|---|---|
| Starting position and data access | Which systems and which data? Via API, read-only account or export directory? | "We will connect the data" with no table or field names |
| Scope | How many things this round? What is explicitly not included? | Broad scope that shrinks repeatedly before acceptance |
| Definition ownership | Who settles each metric's definition, and where is it registered? | Definitions quietly left to the vendor; no owner when disputes arise |
| Deliverables | What exactly is delivered, item by item? | "A platform" with nothing that can be inspected |
| Acceptance metrics | How is each metric tested? Which data? What pass line? | "Good results" or "industry-leading" |
| Schedule and phases | How many phases, and what is visible at the end of each? | One total duration with no confirmable checkpoints |
| Operations | Who handles model updates, interface changes and server upkeep? | Delivery marks the end; nobody owns year two |
| Exit terms | If the engagement ends, how is data exported and access returned? | No exit terms, leaving you tied to one vendor |
Acceptance: replace adjectives with numbers
The most common dispute at acceptance is not missing technology but criteria that were vague from the start. The same phrase — "reasonably accurate" — can mean very different things to buyer and vendor. Write every metric as scope plus method plus pass line.
| Instead of | Write |
|---|---|
| Good recognition results | Extraction accuracy on the jointly confirmed sample set no lower than the agreed value, with 30 random samples re-checked per batch |
| Real-time synchronisation | Source data arrives within the agreed window, failures raise alerts, and the permitted delay is stated in the contract |
| Reports generated on time | Generated at the agreed frequency, including days with no anomalies, with gaps declared rather than left blank |
| Accurate alerts | Alert categories, thresholds, who reviews before release, and the maximum false-positive rate |
| Stable operation | Service hours, fault response and recovery times, and a monthly availability floor |
Budget and scale: use public references first
AI project prices vary widely, and public tender and award notices are the best reference. Public statistics put application-type large model awards in China at about 2,770 in the first half of 2026, roughly 60% of all large model awards, showing procurement shifting from buying models to buying scenarios. Industry reporting notes that application-type purchases by small and mid-sized banks typically sit around RMB 5 million, sometimes split or bundled. Those figures cannot be mapped onto your own project, but they help you judge whether a quote is in a plausible range.
More useful is asking what the price consists of: requirement analysis, data access, development and configuration, hardware, and annual operations. A vendor who can break the five parts out usually knows where the risks sit; a single total with no breakdown tends to grow later. For how to read cost structures, see our custom delivery and enterprise AI agent deployment pages.
Three things the buyer should prepare
- Name one counterpart. Data-access approval, definition sign-off and acceptance all need a person — ideally one who can commit on the company's behalf.
- Answer "can the data be read?" yourself first. Vendor cooperation and IT approval for a read-only account should be settled before the plan is finalised.
- State clearly what this round does not touch, in your internal project file. Doing that at kick-off keeps acceptance from being argued on a promise never made — it belongs at the start, not at the end.
Three common pitfalls
- Letting case walls replace verification. Ask for the specific scenario and site numbers; only what can be found in public reporting counts.
- Treating go-live as the finish. It is the beginning; no owner in the operating phase is the main reason systems die in year two.
- Comparing first-year quotes only. Hardware, annual operations and interface upkeep follow. Three-year total cost is the meaningful comparison.
If you have a plan in hand awaiting assessment, send us its scope, data-access route and acceptance clauses (contact) and we will return a written view: which points hold and which need filling in, at no cost.
In one line: judge an AI deployment plan by whether it can state which data is read, who sets the definitions, what is delivered, how it is accepted, who operates it and how it ends. Once those six are clear, price is the only thing left to discuss.
FAQ
- How can I tell a plan is mostly talk?
- See whether it answers four things: current state and data-access route, scope boundaries, who owns definitions, and an itemised list of deliverables. Plans that cannot usually talk about architecture without ever stating who does what next week. Another quick test: does it name concrete tables and fields, and does it state what is explicitly out of scope?
- How should acceptance criteria be written?
- Replace adjectives with measurable terms: state the test data range, the judgement method and the pass line. Instead of "good recognition results", write "on the 500 samples confirmed by both sides, field extraction accuracy is no lower than the agreed level, checked by randomly sampling 30 per batch". Both sides confirm the numbers and the test set is archived.
- What must a contract state explicitly?
- Three items are most often missed: who operates it afterwards (model updates, interface changes, server maintenance); who owns business definitions (the company decides, the vendor registers and reconciles); and exit terms (how data is exported, accounts returned and the system shut down at the end). Omit them and the problems simply wait for year two.
- Should a plan list what is excluded?
- For internal assessment yes, but an external document need not enumerate it. For the buyer, the right move is to require clear scope boundaries and keep the excluded list in the internal version, so acceptance cannot be argued on the basis of a promise never made. What matters is whether boundaries are stated at all.