Writing the Requirements Spec for an AI Project

You have identified an AI use case inside your company. You are ready to talk to vendors. Before you send the first email, you need a structured AI project requirements spec. Not to cover your bases bureaucratically, but because a well-prepared document radically changes the quality of the proposals you will receive.

At Tensoria, we receive dozens of inbound briefs every year. The difference is obvious immediately: an executive who arrives with a clear document gets precise, comparable proposals. One who sends two vague lines gets quotes that bear no resemblance to each other, cover different scopes, and are impossible to evaluate seriously.

This guide gives you the operational structure of an AI spec for an SMB: why it differs from a classic IT spec, what it must contain, the mistakes that sabotage vendor consultations, and the real questions to ask before you sign anything.

If you have not yet identified your use case precisely, start with our guide on AI audits for SMBs before writing anything.

Why an AI spec is not a classic IT spec

A requirements spec for an ERP or a website can describe expected features, data flows, and business rules precisely. You know what you want, you ask a vendor to build it. The outcome is deterministic.

An AI project is different on four fundamental points.

Performance uncertainty is structural

When you commission a billing module, you know it will calculate VAT correctly. When you commission an automatic clause-extraction system for your contracts, nobody can promise you an exact accuracy rate before testing on your real data. AI model performance varies with the quality, volume, and representativeness of the data. That is the nature of the technology.

The consequence for your spec: you must plan for a validation phase on real data (a proof of concept) and define your acceptance criteria in operational terms, not in abstract metrics.

Data is the real asset, not the code

In an IT project, data is an input. In an AI project, data is the raw material of the solution. A model trained on poor-quality data will produce poor-quality results, regardless of how sophisticated the code is. The quality of your AI spec depends heavily on your ability to describe your data: its volume, format, degree of structure, and history.

The process is iterative, not linear

A classic IT project follows a plan: specs, development, acceptance testing, deployment. An AI project is refined through iterations. The first version of the model will not be the right one. Field teams will surface cases the system handles badly. You will need to adjust, retrain, and improve. Your spec must account for this reality and must not demand a perfect result at initial delivery.

ROI is measured differently

An ERP has a purchase cost and an ROI calculated on operational productivity gains. An AI project has a more complex ROI to measure: you must include the cost of ongoing maintenance, indirect gains (quality, error reduction, freeing up skilled time), and the long-term strategic value. Your spec should lay the groundwork for this measurement from day one.

Standard structure of an AI requirements spec for an SMB

An effective AI spec for an SMB does not need to be a novel. Between 8 and 15 well-structured pages is enough to generate serious, comparable proposals. Here are the essential sections.

• Section 1: company context and the business problem to solve
• Section 2: project scope, expected deliverables, and acceptance criteria
• Section 3: available data, GDPR constraints, and data sovereignty
• Section 4: indicative budget, desired timeline, and post-project governance
• Appendices: sample documents, screenshots, examples of cases to handle

What is missing from 80% of the specs we receive: the data section and the governance section. Yet these are the two that make the biggest difference between a project that succeeds and one that stalls.

Section 1: business context and the problem to solve

This is the most important section. A competent AI vendor reads this section before anything else. If it is vague, the rest of the spec is useless.

What this section must contain

Introduce your company in 3 to 5 lines: industry, size, core activity. Then describe the problem you are trying to solve in concrete operational terms. Not "improve our productivity," but:

• "Our sales team spends an average of 3 hours per week reading and sorting responses to inbound tender invitations to decide whether to bid. We want to automate this initial qualification."
• "Our technicians fill in maintenance reports manually after each site visit. Data entry takes 45 minutes per report. We want to generate a first draft from their voice notes."

Also describe the current process step by step: who does what, with which tools, how often, what volume is processed per week or per month. This level of detail lets a vendor assess the real complexity of the project from the spec alone.

Provide the decision context

State whether you have already done an AI audit, whether you have already spoken to other vendors, and what has blocked you so far. This context avoids repetition and shows that you have already thought about the topic. It also gives the vendor elements to calibrate their proposal.

Section 2: scope, deliverables, and acceptance criteria

This is the section where misunderstandings between client and AI vendor are most common. Be precise about what you want, and explicit about what you do not want.

Define scope without over-specifying the technology

Describe what the system must do functionally. Do not prescribe the technology unless you have a real constraint (hosting on your own infrastructure, integration with a specific tool). Avoid formulas like "we want a fine-tuned LLM on our data" if you are not certain that is the right approach. Let the vendor propose the architecture. That is their job.

On the other hand, be precise about:

• The system inputs: what type of documents, emails, files, or data streams
• The expected outputs: a summary note, a structured file, a classification, an alert
• The mandatory integrations: connection to your CRM, ERP, or email system
• The desired autonomy level: does the system decide on its own or submit to human review

Deliverables: what you are paying for

List the expected deliverables at each stage. For an AI project, typical deliverables include:

• A technical feasibility report after analysis of your data (before development begins)
• A POC version tested on a representative sample of your real data
• The solution deployed to production with user documentation
• A performance monitoring dashboard (automated handling rate, error rate)
• A maintenance and model update plan

Acceptance criteria: the real performance contract

This is the part that almost every SMB spec omits, and it is the one that protects both parties the most. Define measurable criteria on real data, not on synthetic datasets.

Concrete example: instead of "precision above 95%," write "the system correctly handles at least 85% of cases in a batch of 300 documents representative of our real activity, without human intervention." Add performance criteria (processing time), reliability criteria (behavior on error), and adoption criteria (team usage rate after 30 days).

Also include a 3-month review clause: the first weeks in production will surface cases the POC did not cover. That is normal. Build it into your contract.

Section 3: available data, GDPR, and data sovereignty

This is the most underestimated section. Yet it determines the feasibility of the project. A serious vendor will ask these questions anyway. Better to anticipate them.

Describe your data precisely

For each data source, specify:

• The nature: emails, PDFs, Excel spreadsheets, CRM data, scanned handwritten notes
• The volume: how many documents per month, going back how many years
• The state: structured, semi-structured, or unstructured; annotated or raw; in English, French, or multilingual
• The quality: poorly scanned documents, heterogeneous formats, incomplete data
• The accessibility: data immediately available, requiring extraction from an ERP, or requiring prior cleaning

This description lets the vendor assess whether a model can be trained or fine-tuned on your data, or whether a RAG (Retrieval-Augmented Generation) approach is more appropriate.

GDPR constraints and data sovereignty

Clearly state the sensitivity level of your data. For each category of data involved in the project:

• Is it personal data under GDPR?
• Is it confidential data (trade secrets, financial data, sensitive client data)?
• Do you have sector-specific obligations (medical confidentiality, professional secrecy, classified data)?

Then specify your location requirements: hosting exclusively in France, in the EU, or acceptance of US hosting with prior pseudonymization. If you have strong sovereignty constraints, state them explicitly. Sovereign architectures using open models exist and allow sensitive data to be processed without sending it to foreign servers.

Always request a DPA (Data Processing Agreement) from the vendor and specify that your data must not be used to retrain third-party models. A serious vendor will propose this clause without you having to demand it.

Section 4: budget, timeline, and governance

State a budget, even an indicative one

Many executives hesitate to state a budget in their spec, fearing vendors will automatically anchor to it. That is a mistake. The absence of a budget forces vendors to propose different scopes, making comparison impossible.

State a realistic range. To help you calibrate: a simple automation project sits between 5,000 and 20,000 euros. A more complex business project (RAG assistant, structured document analysis) sits between 15,000 and 50,000 euros. Our guide on AI project costs for SMBs details these ranges by project type.

Separate your budget into:

• The development and deployment budget (fixed cost, one-time)
• The operating budget (APIs, hosting, monthly variable costs)
• The maintenance and evolution budget (often forgotten, yet critical)

A realistic timeline

State your deadline constraint if you have one (a commercial event, a planned audit, the end of an existing contract). Also specify your internal availability: how many days per month can you mobilize a business lead for scoping workshops, testing, and sign-offs? A vendor needs your time, not just your budget.

For a standard-size project, expect the following timelines:

• Scoping and data analysis: 2 to 3 weeks
• POC development: 3 to 6 weeks
• Validation and adjustments: 2 to 3 weeks
• Production deployment: 1 to 2 weeks

Post-project governance

This is the section most frequently absent from specs, and one of the most important for long-term value. An unmaintained AI model degrades over time. Data changes, processes evolve, performance drops. Specify in your spec:

• Who is responsible for internal performance monitoring (a named point of contact)?
• What model update frequency do you want (monthly, quarterly)?
• Do you want a maintenance contract with the vendor or an in-house handover?
• What level of documentation do you require to allow a third party to take over?

Raising these questions in the spec avoids becoming locked into a single vendor for every system change.

Classic mistakes that sabotage an AI spec

After receiving and processing dozens of consultations, here are the mistakes that come up consistently.

Over-specifying the technology instead of the need

This is mistake number one. A spec that asks for "a fine-tuned LLM on GPT-4 with a React interface" before even describing the business problem is a spec that will steer vendors toward a pre-selected solution, not the best one. Describe what you want to achieve, not how you think it should be built. The technology choice should come after analysis of your real context, not before.

Forgetting to describe the data

A spec that says "we have data" without describing it forces every vendor to ask the same questions during the first meeting. You waste time. Worse: some vendors discover mid-project that the data is not usable as-is (poor quality, insufficient volume, unusable format). The project stalls, the budget is consumed. Invest 2 hours to describe your data sources precisely. It will save you weeks.

Requesting a POC without a production deployment budget

This is the classic "let's test and see" trap. A POC costs money. A production deployment costs more. If your total budget is 10,000 euros and you spend 8,000 on the POC, you will not have the means to deploy. From the spec stage, plan a budget that covers both phases. Otherwise you end up with a prototype that works in test conditions but that nobody uses day to day.

Setting unrealistic acceptance criteria

Demanding "100% precision" or "zero errors" in an AI project reveals a misunderstanding of the technology. All AI systems make mistakes. The relevant question is not "how many errors?" but "what error level is operationally acceptable?" A vendor who accepts 100% criteria without pushback is either dishonest or incompetent.

Not budgeting for maintenance

An AI system without maintenance degrades over time: data changes, formats evolve, user behaviors adapt. Include an annual maintenance envelope in your budget, generally between 15% and 25% of the initial development cost. A vendor who offers a "turnkey project with no future costs" is selling you something that will stop working within 18 months.

The real questions to ask AI vendors

The spec attracts vendors. The first interview lets you evaluate them. Here are the questions that reveal the real quality of an AI vendor, beyond the sales pitch.

On feasibility and data

• "After reading our spec, what are your doubts about feasibility?" A good vendor identifies risks and articulates them clearly. A bad vendor tells you everything is feasible without nuance.
• "Do you need to analyze our real data before making a firm proposal?" The honest answer is almost always yes for a complex business project.
• "What data volume do you consider necessary to achieve acceptable results?"

On method and commitments

• "How do you define the POC acceptance criteria?" The vendor should talk about operational metrics, not only technical ones.
• "What happens if the POC does not meet the acceptance criteria?" Look for a vendor who plans clear exit clauses.
• "Show me an example of a project similar to ours that you have deployed to production." The key word is "production." Undeployed POCs do not count.

On governance and long-term viability

• "How is the system documented to allow a third party to take over?"
• "Who maintains the model if your data changes in 12 months?"
• "What are your GDPR and EU AI Act compliance practices for this type of project?" EU AI Act compliance is a regulatory reality in 2026. A vendor who discovers the topic during your question is a warning signal.

On the commercial relationship

• "What portion of the budget do you plan for maintenance in the first 12 months?"
• "Who will be the day-to-day technical contact on this project?" Verify that it is the competent person you are meeting, not a salesperson who will hand off to a remote team.

If you are looking for guidance on how to choose an AI vendor, our dedicated article complements this with in-depth selection criteria.

FAQ: AI project requirements spec

Further reading

• AI Audit for SMBs: Method, Cost, and Deliverables: read this before writing your spec if you have not yet identified your use cases
• How to Choose an AI Vendor: the selection criteria that actually matter
• AI Project Costs: Budget Guide: to calibrate your budget envelope before consultation
• Enterprise RAG Use Cases and ROI: to build your internal business case before approaching vendors
• RAG: Retrieval-Augmented Generation Explained: so you are not lost when vendors talk architecture
• Production RAG: 5 Failure Modes: the pitfalls to anticipate in your spec
• EU AI Act Compliance Guide: the regulatory requirements to integrate into your spec now
• Workflow vs AI Agent: When to Use Which: helps you scope the right type of solution for your use case
• AI audit service: structured review of your use case to define the right architecture before you build
• AI agents service: end-to-end deployment of production AI automation systems