You have a use case in mind, an approximate budget, and a vendor asking for "a specification". Three weeks later the document exists, it runs twelve pages, and nobody can say what will be delivered or how anyone will check that it works. The project starts anyway, on an interpretation. That is where scope creep, billed rework and output nobody dares to reject begin.
An AI project specification is not a technical dossier. It is a decision document: it fixes the problem, the expected outcome, the non-negotiable constraints, and the way everyone will agree the work is done. It runs two to five pages, and it is written before you ask for a price.
Key Takeaways
- An AI specification describes an outcome and acceptance criteria, not a technical solution: the tool belongs to the vendor, the problem belongs to the business.
- Seven blocks are enough: context and business objective, scope in and out, data, expected output and acceptance, constraints, costs and reversibility, governance.
- The block most often skipped is data. According to Gartner (2025), 63% of organisations either do not have, or are unsure whether they have, the right data management practices for AI.
- Acceptance criteria are written before the quote, as named test cases. Without them, delivery is judged on impressions, and impressions are negotiable.
- The document is written in-house, with the team that lives with the problem. A vendor can challenge it, not replace it.
A specification fixes an outcome, not a tool
The most common temptation in a small business is to start from the tool. "We would like an AI agent plugged into WhatsApp that sorts incoming requests." The sentence describes an intention and a channel, not a result. It leaves the vendor to guess what a well-sorted request looks like, how fast it must happen, what error rate is acceptable, and who fixes the sorting when it goes wrong.
An AI project is judged on three linked elements: the quality of the output, the time saved, and the running cost. If the specification says nothing about those three, the vendor will deliver what it knows how to do, within the schedule it controls, and the conversation about value will happen too late.
That vagueness is expensive. In a note published in July 2024, Gartner estimated that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, for four reasons: poor data quality, inadequate risk controls, escalating costs, and unclear business value. Three of those four are settled in the document you write before signing.
The right opening question is therefore not "which tool?" but "which decision becomes faster, or which task disappears?". The answer fits in one sentence, and that sentence becomes the first line of the specification. If you cannot write it, the scoping work is not finished: that is exactly the work covered by a scoping audit.
The seven blocks of the template, annotated
The skeleton below works for a conversational agent, a back-office automation, a document triage tool or a forecasting model. What changes from one project to the next is the content, never the structure.
1. Context and business objective. Describe where the problem shows up, how often, and who suffers from it. Measure the current situation with your own figures: requests per week, average handling time, observed error rate. This block is the baseline for acceptance. Without a starting measurement, no gain can be demonstrated, and the debate moves to opinions.
2. Scope: what is in and what is out. The "out" column matters most, and it is always the one people forget. An AI project expands by nature: once the agent sorts emails, someone asks it to answer them, then to follow up, then to update the CRM. Write down explicitly the uses, channels and languages that stay outside the scope. An explicit exclusion list beats a generous inclusion list.
3. Data and access. What data the system will read, where it lives, in which format, who authorises access, and how long it is retained. State the expected quality: mandatory fields, tolerated duplicates, scanned documents accepted or not. Add the anonymisation question whenever personal data enters the system.
4. Expected output and acceptance criteria. Describe what the user sees at the end: a draft reply in the inbox, a new row in the spreadsheet, a summary of a meeting. Then list the test cases, naming each one: simple request, request in a foreign language, out-of-scope request, unreadable attachment, duplicate customer record. Each case gets a verifiable expected result. This is the block that turns a project into a commitment.
5. Constraints. Technical (existing systems that must not be replaced, hosting in Europe, peak load), regulatory (GDPR, professional secrecy, retention of conversations) and human (who validates each output before sending, who uses the tool daily, who trains new joiners). Human constraints are the ones that sink the best-specified projects.
6. Costs, ownership and reversibility. Separate the build cost from recurring costs: licences, model consumption, hosting, maintenance, fixes. State who owns the deliverables, the prompts and the test sets. Finally, write the exit: how you recover the data and the configuration if you change vendor or stop the project. An AI project without an exit clause becomes a dependency.
7. Governance and acceptance. Name a single decision-maker on the business side, the person who arbitrates disagreements, and the acceptance schedule. Plan the procedure for gaps: another correction round, scope reduction, or stop. A project with no stop procedure has no success procedure either.
If the project produces an AI agent, add a short block on tone and answer boundaries: what the agent must never say, and who it hands over to.
Five formulations to rewrite before sending
Read a specification looking for sentences a vendor could interpret in two ways. Here are five, with their usable version.
| What you often read | What you should write |
|---|---|
| "Improve customer relations" | "Answer 90% of incoming requests within 4 business hours, with a draft validated by an adviser" |
| "An AI agent connected to the CRM" | "Read the customer and history fields, propose a reply, log every proposal and its author" |
| "Data available to the vendor" | "A 24-month export on a scope listed in annex, deleted 30 days after acceptance" |
| "Team training included" | "Two 3-hour sessions for 8 people, written material handed over, exercises on the company's real cases" |
| "Maintenance covered" | "Blocking defects fixed within 5 business days, hourly rate for out-of-scope work stated in the quote" |
The figures in that table are wording examples, to be replaced by your actual commitments. What matters is not their exact value but their shape: a threshold, a case, a deadline, an owner.
Data: the block that decides what follows
The same Gartner study quoted above puts a number on the risk: still according to Gartner (2025), organisations would abandon 60% of AI projects unsupported by AI-ready data through 2026. In other words, the model is almost never the breaking point. The breaking point is what you feed it.
In a small business, that translates into three concrete checks. First, availability: does the data exist in a usable form, or must it first be pulled out of a PDF export from an industry system? Second, consistency: do all teams fill the fields the same way? Third, ownership: who is allowed to move that data into an external tool, and under what conditions?
The lack of in-house expertise makes the exercise harder. In 2025, 18% of French companies with 10 or more employees declared using at least one AI technology, and among those using none, 54% cited a lack of expertise, according to Insee (2026). That is not an admission of delay, it is information to build into the document: plan who will be able to review the system's output in six months, and what happens if that person leaves.
An honest specification also mentions what the company does not know yet. A line such as "the quality of historical data has not been audited" is worth more than a reassuring claim the vendor will take at face value. That transparency shows up in the price.
Costs, ownership and exit terms
An AI project budget should be read over twelve months, not on the first invoice. Three items recur: the build, the usage (model consumption, licences, hosting) and maintenance. Ask the vendor to separate all three, and to state what varies with volume. A fixed price built on 500 requests a month does not hold when you handle 3,000.
Ownership deserves an explicit clause. Prompts, test sets, documentation and integration scripts must be listed as deliverables. Without that list, changing vendor means rebuilding everything, often at full price. The exit clause is the counterpart: export format, handover deadline, deletion of the copies the vendor holds.
This drafting work meets the quote, and the two documents often answer each other. To check that both versions tell the same story, what an AI agent quote must contain gives a useful reading grid.
Who writes it, and how long it takes
The specification is written on the business side, by the owner or the relevant manager, with the people who live the problem every day. A consultant can run the exercise, ask the questions and rephrase the answers, but cannot invent your constraints. When the document arrives fully drafted by the vendor, the company is buying a solution without having defined its need.
Allow two to five days of work spread over two weeks, mostly in short interviews: one hour with the team that lives with the problem, one hour with the person who holds the data, one hour with the person who will pay the invoice and therefore must arbitrate. The final document runs two to five pages. Past eight pages, it describes the architecture on the vendor's behalf and becomes a bargaining document.
The right moment is before the consultation, not after. A specification written after the quote serves to justify a decision already made. To place this work in the full sequence, the six stages of an AI project shows where scoping sits, and why it shapes everything that follows.
FAQ
How many pages should an AI project specification be?
Two to five pages for a small business project, excluding technical annexes. The annex can hold data schemas, the test case list and sample documents. The body must stay readable by an owner in twenty minutes, otherwise it will not be reopened when trade-offs are made.
Should the tool be named, for example ChatGPT or n8n?
Name a tool only when it is a real constraint: an existing system, a framework agreement, a hosting obligation. Otherwise, describe the expected function and the constraints, then let the vendor propose. That freedom is what lets you compare two offers on the outcome rather than on a brand.
My vendor says drafting the specification is part of its job. Who is right?
Both, provided the roles are separated. The vendor is legitimate for the technical specification, the architecture and the test plan. The company remains the owner of the objective, the scope, the acceptance criteria and the budget. A vendor that refuses to discuss those four points before quoting takes control of the project.
Does a specification guarantee the project will succeed?
No. It reduces interpretation gaps, makes acceptance enforceable, and forces you to state edge cases before paying. It replaces neither data quality, nor team availability, nor the decision to stop a project that misses its criteria. It is a steering instrument, not insurance.
What if no vendor answers the document point by point?
Treat the silence as information. Either the scope is still too vague to price, or the vendor does not want to commit to measurable criteria. In both cases, sending the document to a third vendor costs less than signing a partial answer. If you want to automate repetitive tasks without a full AI project, the scoping work is the same, with a shorter scope.
Conclusion
An AI project specification does three things: it decides what you want, it makes delivery verifiable, and it keeps control of the exit. The seven blocks of the template fit on two pages, and most overruns come from empty blocks, not from debatable technical choices.
If you are preparing a project and the document does not exist yet, start with the objective sentence and your own baseline measurements. If the document exists but feels vague, have it reviewed before sending: get in touch is enough to get an opinion on what is missing.
