AI Project Requirements Document: Operator Template

A useful AI project requirements document is an acceptance contract, not a tool wishlist. It states the business problem and observable baseline, the workflow inside the boundary, explicit exclusions, permitted inputs and authoritative sources. It defines the expected output and the tests that make it acceptable. It also names the person who approves the result, the evidence and logs to retain, the cases that must stop the workflow, and the owner who maintains the document. The final section sets a review date and a clear deploy, revise or stop decision. A vendor can then propose an implementation, but cannot quietly redefine what success means.

Why is an acceptance contract better than a tool list?

A list of models, integrations and interface features says what someone wants to buy, not what the project must prove. An acceptance contract makes the observable result primary. It gives a business owner, a technical team and a supplier the same boundary against which to inspect a result.

The contract does not need to predict the entire implementation. It must make disagreement visible. If an input is forbidden, the document says so. If two approved sources conflict, the test says the workflow stops. If a draft requires approval, a polished screen cannot turn that draft into an authorised action.

The voluntary NIST AI Risk Management Framework is intended to help organisations include trustworthiness considerations in the design, development, use and evaluation of AI systems. Its Core uses Govern, Map, Measure and Manage. The related Playbook offers suggested voluntary actions and is neither a checklist nor a required ordered sequence. This article uses its own editorial template and makes no claim of certification, compliance or legal sufficiency.

What are the seven parts of the document?

Copy these seven headings into the working document and require a concrete answer under each one. A blank, vague or contested answer is information: the project is not ready for acceptance on that point.

1. Problem and current observable baseline. Describe the business problem without naming a solution. Record what can be observed in the current workflow and how the same observation will be made during review.
2. In-scope workflow and explicit exclusions. Name the event that starts the workflow, the point where it ends, the people or systems involved, and everything the project must not do.
3. Permitted inputs and source authority. List allowed input types and repositories. State which source prevails, and require a stop when authority is absent or sources contradict one another.
4. Output format and acceptance criteria. Specify fields, structure, language, required citations or references, prohibited content and the conditions a reviewer will use to accept or reject the result.
5. Test set. Include normal, missing, ambiguous, contradictory and sensitive cases. Give every case an expected result, including refusal or escalation.
6. Human approval, failure and evidence. Name the approval point, failure behaviour and stop route. State which input version, output, source, reviewer decision, exception and correction will be retained.
7. Owner and review decision. Name who maintains rules, sources and tests, set a review date, and record one decision: deploy within the tested boundary, revise the contract, or stop.

France Num's practical guidance recommends formalising objectives, roles and rules, testing before deployment, human supervision for sensitive tasks, traceability, and ongoing maintenance of instructions, configuration and documents. It is practical guidance, not binding law.

Which fields can you copy into a table?

The table below is the compact working artifact: one row per decision that must be inspectable. Add project-specific detail, but do not replace evidence with adjectives such as “smart”, “seamless” or “accurate”.

How should the test set be written?

Test the boundary and the refusal route, not only the polished normal case. Each case needs a supplied input, an expected output or stop behaviour, an actual result, a reviewer and a decision. Keep the cases stable enough to compare revisions of the project.

• Normal: complete permitted input from an authoritative source produces the specified output for human review.
• Missing: a required field or source is absent; the workflow identifies the gap and does not invent it.
• Ambiguous: the input supports more than one reading; the workflow asks for human judgment.
• Contradictory: permitted sources disagree; the workflow shows the conflict and stops.
• Sensitive: the case falls into the named sensitive category or outside the boundary; no unauthorised action occurs.

Where personal data is processed, the CNIL overview frames the work around defining purpose, establishing responsibilities and a legal basis, protecting data-subject rights, minimising and controlling data, and applying security measures. A personal-data project requires appropriate privacy and legal review; this template is not legal advice and does not prove GDPR compliance.

What does a completed fictional example look like?

The following internal request-routing workflow is hypothetical and makes no productivity promise. Its only purpose is to show what filled fields look like.

1. Problem and baseline. Internal requests arrive in a shared inbox. The observable baseline is a dated sample that records the request text, the category chosen by a person, and the destination team.
2. Scope and exclusions. The workflow begins when an internal request enters that inbox and ends with a routing proposal. It does not reply, change a record, assign work or route requests from outside the organisation.
3. Inputs and authority. Permitted inputs are the request text, the current approved category list and the current approved team directory. The directory controls destination names. If a category or destination is absent, the workflow stops.
4. Output and acceptance. The output is a draft with request identifier, proposed category, proposed destination, cited directory entry and a short reason. A reviewer accepts it only when every field is present and the proposal is supported by the supplied sources.
5. Tests. The set contains a clear facilities request; a request without a location; wording that could mean access or equipment; a category and directory that point to different teams; and a request marked sensitive. Expected results are respectively draft, stop for missing information, human judgment, conflict stop and sensitive-case stop.
6. Approval, stop and evidence. The inbox coordinator accepts, edits or rejects every proposal. Missing, ambiguous, contradictory, sensitive and out-of-scope requests cause no routing action. The retained record contains input and source versions, draft, decision, exception and correction.
7. Owner and review. The operations owner maintains categories, directory entries and tests. The review record names a date and concludes deploy within the tested boundary, revise, or stop.

This is narrower than the broader AI project examples and selection method. For the preceding workflow-selection step, use the business automation operator method.

Which red flags reveal a vendor wishlist?

A requirements document is weak when the product vocabulary is precise but acceptance remains vague. These signs warrant a rewrite before a proposal is compared:

• the document opens with a model, platform or integration instead of the problem and baseline;
• scope is described as a department-wide ambition with no explicit exclusions;
• inputs are called “company data” without permitted sources or authority;
• the output is “high quality” without format or pass and fail criteria;
• the test set contains only favourable examples;
• human review is mentioned without naming the approver or the decision point;
• logging is requested without saying which evidence must be retained;
• failure means retrying, while stop and handoff cases are absent;
• no person owns source changes, tests, maintenance or the review date.

How do you decide to deploy, revise or stop?

The gate is short because the evidence has already been defined.

• Deploy: every required test has an inspectable result, acceptance criteria are met, stop cases stop, human approval works, and the owner accepts deployment only inside the tested boundary.
• Revise: the problem remains valid, but a rule, input, source, output criterion, test or approval route is incomplete. Update the contract and test again.
• Stop: the required inputs or authority cannot be established, the output cannot be judged against written criteria, stop behaviour fails, or no owner accepts responsibility.

A deployment decision does not approve an expanded scope. A new input, source, output or action changes the contract and needs corresponding tests and review.

FAQ: AI project requirements documents

How do you write an AI project requirements document? Write it as an acceptance contract. Define the baseline, scope and exclusions, permitted inputs, expected output, test set, human approval, stop behaviour, retained evidence, owner and review decision.

What are its main components? Use seven parts: problem and baseline; scope and exclusions; inputs and source authority; output and acceptance criteria; test cases; approval, stops and evidence; ownership, maintenance and review.

What are the stages of an AI project? For this operator template, write the contract, assemble the test set, test within the boundary, review the evidence, then decide to deploy, revise or stop. This is an editorial sequence, not a universal framework.

Does the template prove privacy or legal compliance? No. According to the CNIL overview, projects involving personal data require appropriate privacy and legal review. The template is an operating document, not legal advice or proof of compliance.