How to Write an AI Requirements Document That Can Be Accepted

The purpose of an AI requirements document is not to ask for “an intelligent system.” It is to agree on the business problem, the inputs the system receives, the result it must deliver, the boundaries within which it operates, and the evidence that will count as acceptance. Without that agreement, the delivery team has to guess and the business can judge only by how the demo feels.

The document may be shorter than a conventional product requirements document, but it must pay more attention to uncertainty. A deterministic program follows prescribed paths; AI output varies with input quality, context, and model capability. Requirements must therefore describe both the intended result and what happens when the result is uncertain: who decides, where the work is handed to a person, and how the original process is restored.

Begin with a one-page decision brief about the business problem

Do not begin with “connect a large language model,” “add intelligent Q&A,” or a feature menu. The first page should let someone outside the project answer five questions: who encounters what problem in which process, how the process works today, what observable consequence the problem creates, which step this project intends to change, and what is explicitly out of scope. This page defines the decision boundary, not the aspiration.

“Customer service replies are too slow” is still too vague. A more useful statement would say that after-sales agents search across several documents for warranty rules and first responses queue during peaks; the project will recommend an answer and source to authenticated agents, but will not send messages to customers or decide refunds. The problem, user, process step, target action, and exclusions are now visible, so later decisions share the same object.

The baseline need not be perfectly measured on day one, but it must be measurable. Record current volume, waiting time, manual steps, rework categories, and data sources. If reliable data does not exist, mark the item “sampling required” and name the sampling window and owner. Map the end-to-end business path before placing AI at a node; What to Map Before You Automate explains that exercise. Where there are many candidate nodes, use the framework in Which Tasks Fit AI Automation to remove tasks with non-digital inputs, outputs that are difficult to verify, or irreversible errors.

Define inputs and outputs so they can be tested against real samples

“Read company material” is not an input definition. Write an input contract: which system or directory supplies the material; which file types and fields appear; how language and length vary; whether scans, images, empty fields, duplicate records, and historical versions exist; and who may provide and update it. Attach a set of de-identified samples containing both ordinary cases and several awkward ones. Requirements reviewed without samples tend to mistake ideal data for real data.

The output cannot stop at “generate an answer” either. An output contract identifies the recipient, format, mandatory fields, supporting evidence, and next action. A support-answer suggestion might return the cited passage, document version, reason it cannot decide, and destination queue. A form-extraction output might require fixed fields, source locations, and exception flags. Clear structure makes automated checks possible and reduces dependence on one person's stylistic preference.

The sample set should include normal, boundary, and refusal outcomes. Normal samples describe the intended path. Boundary samples test incomplete information, contradictory statements, and unusual formats. Refusal samples establish that the system stops when it sees unauthorised material, an unverifiable question, or a high-risk action. Fixing these samples during requirements work lets developers, testers, and business reviewers use the same ruler.

Express capability boundaries as allowed, prohibited, and human-gated

The line most often missing from an AI requirement says what the system must not do. Describe every capability in three tiers: actions it may complete automatically, actions that require human confirmation, and actions it may never perform. Reading an approved product manual and drafting an internal reply may fit the first tier. Changing an order or promising compensation may require an authorised approver. Reading restricted material across departments may be prohibited altogether. The actual boundary must follow company policy and scenario risk, not this example.

Boundaries cover data, users, tools, and actions. The document must say who may submit a task, which fields the system may see, which interfaces it may call, how long results may be retained, and whether it can write to a business system. For company material, use Four Data Boundaries to Set Before Using AI on Company Material to examine classification, authorisation, external disclosure, and retention. Permissions are part of the requirement, not an account switch to add before launch.

Human handoff needs a real destination. “Send to a person” without a queue, priority, notification route, and expected pickup time merely hides the failure. Specify triggers such as missing information, conflicting sources, insufficient confidence, a user's request for a person, or an action beyond the system's authority. Then decide whether the human resolution is written back and whether it updates a rule or future test set.

Exceptions, not the happy path, are the centre of the requirement

The happy path often takes one sentence: receive a request, retrieve material, generate a result, obtain confirmation. What determines whether the system survives daily use is everything beside that path. At each input, decision, system call, and output, ask what happens if the item is unavailable, unreadable, contradictory, or fails to execute, and put the answer back into the document.

• When an input is incomplete, corrupted, or outside the supported range, decide whether to reject it, ask a follow-up question, or route it to a queue.
• When two valid sources conflict, resolve by version, effective date, or a named owner; do not let the model choose whichever answer sounds more plausible.
• When an upstream system is unavailable, an interface times out, or a write-back fails, define retry behaviour, duplicate-prevention, and the point at which the manual process resumes.
• When quality is insufficient, evidence is missing, or a sensitive action is involved, stop the automated path and retain the original input and handling record.
• When a user edits an AI suggestion, decide whether the final version, reason for the edit, and approving person are logged, and who may inspect those records.

Every exception needs a detection method, handling owner, recovery path, and audit requirement. An error message alone is not a handling plan. “The system retries automatically” is not enough either, because the retry count, duplicate-execution risk, and eventual owner remain unknown. Once exceptions are explicit, the delivery team can identify the protection layers to build and the business can estimate the real operating workload.

Acceptance must cover quality, efficiency, and operating health

“Accurate answers,” “better efficiency,” and “satisfied users” are not directly testable. A valid criterion carries a sample, measurement rule, threshold, owner, and time window. Who prepares the test set? What enters the denominator? Who judges citation correctness separately from answer usefulness? Did weak results reach the human queue successfully? How long does the pilot run before a decision? Writing Pilot Acceptance Criteria That Can Actually Be Checked provides a fuller method.

Quality should not collapse into one average accuracy score. Different errors have different business consequences: a missing required field can be repaired, while an incorrect customer price may need immediate blocking. List critical errors as separate stop conditions, then use broader quality measures for the remaining outcomes. Efficiency must include human preparation, review, rework, and exception handling as well as generation time; otherwise the system can become faster while the end-to-end process becomes slower.

A third group of criteria covers operating health: availability, failure alerts, complete logs, permission tests, and a rehearsed fallback. There is no universal number to insert here. Let business risk set the bar. A low-risk internal suggestion tool can be corrected while in use; an action that sends externally, writes to a core system, or affects customer rights needs stricter human gates and stop conditions.

Rewrite one bad request into a deliverable scenario

The original sentence fails because nobody can judge it

Suppose the original request is one sentence: “Build an AI customer-service bot that answers automatically and has high accuracy.” It defines neither the customer nor the supported question range, identifies no source material, says nothing about automatic sending versus agent assistance, and leaves “high” without a sample or reviewer. A supplier can produce an impressive demo from it, but cannot estimate data preparation, integration, testing, or long-term operations.

The rewritten version closes one scenario before expanding

A deliverable version might read as follows: provide warranty-policy answer suggestions to authenticated after-sales agents; accept a customer question, product model, and the current approved policy library; return a suggested answer, cited source, applicability conditions, and an unable-to-decide flag; initially cover only a confirmed set of frequent questions; require an agent to approve every outbound message; route conflicting sources, missing product models, and out-of-scope questions to a named queue; accept the pilot using both a frozen test set and a period of live operation, recording review, rework, and takeover time.

That paragraph is still not the full document, but it already exposes a data inventory, user interface, permissions, test set, exception queue, and operating owner. Field, interface, and interaction details can now deepen a shared boundary. If the team cannot agree on this scenario, moving straight to a prototype or purchase only postpones the disagreement until it is more expensive.

Review order determines whether the document becomes a feature list

Review in the order of business problem, user process, data availability, risk boundary, technical approach, and acceptance method. The business owner confirms that the problem merits work and the scope is right. Front-line users test the real inputs and exceptions. Data, IT, security, and compliance roles confirm access and constraints. Only then should the technical team and supplier settle the implementation path. Use Enterprise AI Roles and Responsibilities to name who prepares each input and who makes each final decision on the document's first page.

Requirements change, but each change needs a business reason, affected scope, and approver. Adding a source can add permission and quality testing. Adding automated write-back can change the risk tier. Expanding the user population also expands training and operations. A change record puts those consequences on one page so the team can accept the work now, defer it, or choose a substitute.

A strong AI requirements document does not eliminate every unknown. It routes unknowns into manageable treatment: verify what can be verified with samples, put unresolved assumptions into a pilot, keep explicit human gates where judgement is needed, and make failures recoverable and traceable. Once the work is reviewable, reversible, and accountable, “we want something intelligent” has become a deliverable project.