AI automation requirements checklist for small businesses

An AI automation requirements brief describes the job a workflow must do before anybody chooses a model, buys a platform or connects business systems.

It does not need to be a technical specification. For a focused small-business workflow, a useful brief may be three to five pages. It should give an owner, employee, supplier or developer the same answers about the outcome, inputs, boundaries, review points, failure routes and definition of success.

Without that shared picture, teams tend to automate an imagined process. The demonstration works with a tidy example, but the real job includes missing information, unusual customers, last-minute changes, permissions, corrections and decisions that nobody assigned. Those are requirements, not details to discover after launch.

Use this checklist before building an AI-assisted workflow for marketing, research, reporting, knowledge retrieval, customer enquiries or administration. Apply more formal assurance and appropriate specialist advice where the system could materially affect people, money, access, contracts, safety, regulated activity or legal rights.

First ask whether AI belongs in the job

Do not begin the brief with “We need an AI agent”. Begin with the problem.

Write down:

what is happening now;
who experiences the problem;
how often it occurs;
what delay, rework, inconsistency or missed opportunity it creates;
what a better outcome would look like;
whether a simpler process, template, rule or conventional automation could solve it.

AI is useful where the task requires interpretation, drafting, classification, retrieval or handling variation. It may add little where the work is a fixed sequence of deterministic rules. A normal form, formula, scheduled report or integration can be cheaper and easier to verify.

The US National Institute of Standards and Technology (NIST) AI Risk Management Framework Playbook recommends determining whether an AI system achieves its intended purpose and whether development or deployment should proceed. Its guidance explicitly notes that AI is not necessarily the right answer to every business task.

If the opportunity is still uncertain, use a time-boxed AI pilot before commissioning a complete system.

Define the job in one sentence

Use this structure:

When [trigger] happens, help [user] turn [approved inputs] into [specific output or action], subject to [review or boundary], so that [measurable business result] improves.

For example:

When a weekly campaign cycle closes, help the marketing manager turn approved advertising and web analytics into a draft performance summary, subject to human review before circulation, so that reporting preparation takes less time without losing accuracy or context.

This is more useful than “build an AI reporting assistant”. It identifies the trigger, user, information, deliverable, control and result. Each can become a design decision and a test.

Keep the first version narrow. The UK Government’s current AI Risk Management Toolkit recommends narrow application scope because benefits and risks are easier to map. One dependable job is a better starting point than a general-purpose assistant with an unclear remit.

Map the real workflow before changing it

Follow one ordinary piece of work from start to finish with the people who actually perform it. Record:

the event that starts the job;
every source of information;
decisions, checks and approvals;
systems updated or messages sent;
waiting time, hand-offs and common rework;
exceptions and escalation routes;
the record that proves the work is complete.

Do not document only the happy path. Ask what happens when a field is blank, a source disagrees, an attachment will not open, a customer changes their request, an approver is absent or a connected service is unavailable.

Measure the current process before promising improvement. Useful baseline measures might include elapsed time, active staff time, jobs completed, correction rate, missed deadlines, customer response time or the percentage requiring escalation. Record how the measure was produced so the comparison remains fair after launch.

An AI readiness assessment can help identify whether the underlying information, systems and team capacity are ready for this work.

State what is in scope — and what is not

List the permitted cases precisely. Then add explicit exclusions.

For a campaign-report workflow, the brief might say:

In scope: prepare a draft weekly summary from named analytics accounts and the approved campaign plan.
Out of scope: change budgets, edit live campaigns, contact clients, infer revenue not present in the source systems or compare employee performance.

Boundaries prevent gradual expansion from “draft a report” to “manage the account”. They also help suppliers price the same job, reviewers test the right behaviour and staff recognise misuse.

Include:

intended users and affected people;
permitted business units, brands, accounts and regions;
approved use cases;
prohibited uses;
the decisions AI may support but not make;
the conditions that must stop the workflow;
who can approve a later scope change.

NIST’s Map guidance calls for intended purpose, users, deployment setting, assumptions, limitations and possible impacts to be understood and documented. The context matters as much as the model.

Specify inputs and their authority

“Use company data” is not a requirement. Name each source and what the workflow may trust it for.

For every input, record:

Field	Question to answer
Source	Which system, folder, form, mailbox, API or approved document supplies it?
Owner	Who is accountable for its quality and access?
Authority	Is it a system of record, guidance, an example or unverified context?
Required fields	What must be present before the job can proceed?
Freshness	How current must it be and how is that checked?
Sensitivity	Could it contain personal, confidential, financial or special-category information?
Quality rule	What makes it complete, valid and suitable for this use?
Conflict rule	What happens when two sources disagree?
Retention	Where may a copy persist, for what purpose and for how long?

Label facts, instructions and examples separately. An approved price list may be authoritative for prices but not for customer eligibility. A past proposal may demonstrate tone without being a current source of product facts.

If personal information is involved, assess the purpose, necessity, roles, risks and safeguards early. The Information Commissioner’s Office (ICO) says a data protection impact assessment is an appropriate way to demonstrate accountability for AI processing and to make clear how and why the data will be used. Its current AI accountability guidance is under review following changes in UK data law, so check its status for the live project.

Describe the output as a business deliverable

Define what the user receives, not merely what the model generates.

Specify:

format, sections and required fields;
audience, channel and accessibility needs;
permitted claims and required evidence;
tone and brand guidance;
links or citations that must accompany factual statements;
confidence, uncertainty or missing-data notices;
validation rules;
where the approved result is stored;
what event marks the job complete.

Include one or two acceptable examples and several unacceptable ones, with reasons. Examples make an abstract requirement observable, but do not let them silently become the whole specification. The workflow must handle the range of real work, not imitate one polished sample.

Create an action and approval matrix

Separate preparing information from changing the outside world. For each action, record what AI may prepare, what it may execute, the approval required and the evidence retained. For example:

Summarise approved analytics: AI may prepare the summary; a person reviews it before circulation; retain the source period and account IDs.
Draft a client email: AI may prepare but not send it; the account owner approves; retain the approved text and approver.
Update an internal task: AI may prepare the update and change only named low-risk fields; set approval by field; retain the before-and-after values.
Change a campaign budget: AI may neither prepare nor execute this action; use the existing authorised process and finance or platform record.

Use more than two states where necessary. A workflow might be allowed to create a draft, recommend an action, queue an action for approval, perform a reversible low-risk action, or never attempt the action.

For every permitted action, identify the account used, minimum access required, value or volume limit, approval point, confirmation returned and reversal method. The AI agent permissions checklist explains how to turn those boundaries into technical access controls.

Design the human role properly

“A human checks it” is incomplete. Name the role and the decision.

The brief should state:

who reviews the work;
what evidence they see;
what they must verify;
whether they can edit, reject, retry or escalate;
how much time they have;
who covers absence;
what competence or training they need;
how the decision is recorded.

Approval must happen before the consequence it is meant to control. A daily sample after messages have already been sent is monitoring, not pre-send approval.

Do not give a reviewer fifty low-value confirmations until clicking becomes automatic. Group related work, highlight exceptions and reserve explicit approval for decisions where judgement changes the outcome. Use the human-in-the-loop workflow guide to choose the right review pattern.

Write the exception paths before the happy path is automated

List realistic failure conditions and the required response. Include:

missing, stale or contradictory inputs;
low-confidence or unsupported output;
content outside the permitted scope;
personal or confidential information in the wrong place;
unavailable integrations or expired credentials;
an approval timeout;
a duplicate request or retry;
an external action that returns an uncertain result;
a suspected security or data-protection incident;
a request to correct, complain about or challenge the outcome.

For each one, choose: stop safely, ask for information, route to a named person, retry under controlled conditions, continue in reduced mode or use the manual process. Define what the user sees and what gets recorded.

The National Cyber Security Centre’s secure AI system development guidance treats security as a lifecycle requirement covering design, development, deployment and operation. Failure handling, logging, incident management and maintenance belong in the requirements, not in a later tidy-up.

Turn “good” into testable acceptance criteria

Use criteria that a reviewer can evaluate with representative cases.

Cover at least:

task quality: accuracy, completeness, relevance and required format;
evidence: correct sources, dates and traceability;
boundaries: prohibited requests are refused or escalated;
data handling: only approved data is accessed, logged and retained;
actions: permissions, limits, approvals and duplicate protection work;
exceptions: missing data, outages and ambiguous cases fail safely;
operations: owners can monitor, pause, correct and recover the workflow;
value: the agreed business measure improves without an unacceptable new cost or risk.

Avoid “the output should be accurate”. Write the observable rule: “Every number in the weekly summary must match the named source account and reporting period; missing accounts must be identified rather than estimated.”

Define the test set, pass threshold and critical failures before the final demonstration. A strong average score must not hide one unacceptable action. The AI agent testing checklist provides a full route from cases and acceptance criteria to a recorded go-live decision.

Include ownership after launch

A build is not finished when the first version works.

Assign named roles for:

business outcome and scope;
source information;
system administration and access;
output quality;
approval and escalation;
security, privacy or compliance advice where required;
supplier management;
monitoring, incidents and changes;
budget and renewal decisions.

Add operating expectations: service hours, acceptable delay, monitoring frequency, maintenance windows, support contact, evidence retained and maximum time to respond to important failures.

Define which changes require retesting or fresh approval. These may include a new model, prompt, knowledge source, integration, data type, user group, permitted action or supplier term. The live details should later move into an AI agent runbook, with a separate business continuity plan for priority work.

Record constraints before comparing suppliers

Give every proposed solution the same constraints:

existing systems it must work with;
data location or contractual needs;
authentication and access requirements;
audit, export and deletion capabilities;
accessibility and user-device needs;
maximum implementation and recurring cost;
internal time available for review and maintenance;
required handover, documentation and training;
portability and exit expectations;
target pilot and decision dates.

Price the complete operation, not only model usage. Include platform licences, integrations, implementation, review time, monitoring, support, training and likely change work.

Use the AI supplier due-diligence checklist after the brief is stable. A supplier should be evaluated against the required job; the available product should not quietly redefine the job.

A copyable AI automation brief

Use these headings for a focused first draft:

Problem and baseline: What happens now, who is affected and what does it cost in time, quality or opportunity?
Outcome: What should improve, by how much and by when?
Job statement: What trigger, user, input, deliverable, boundary and result define the workflow?
Scope: What cases are permitted, excluded and prohibited?
People: Who uses, reviews, owns, supports and may be affected by it?
Current workflow: What are the real steps, systems, hand-offs and exceptions?
Inputs: Which sources are approved, authoritative, current and suitable?
Outputs: What exact business deliverable is required?
Actions and approvals: What may be prepared, recommended, queued, executed or never attempted?
Data and access: What information and permissions are genuinely necessary?
Exceptions: When must the workflow stop, ask, retry, escalate or fall back?
Acceptance: Which representative tests and critical failures determine readiness?
Measures: How will value, quality, risk and operating cost be compared with the baseline?
Operations: Who monitors, supports, changes, pauses and retires it?
Constraints: What systems, budget, time, contract, handover and exit conditions apply?
Decision: Who can approve a pilot, live release, scope change or stop?

Mark unknowns openly. An unresolved question with an owner and due date is safer than an assumption hidden inside a build.

Run a 60-minute requirements workshop

Bring together the process owner, one person who performs the work, the intended reviewer and whoever manages the affected systems. Add privacy, security, legal or sector expertise where the use warrants it.

Use the hour like this:

10 minutes: agree the problem, baseline and desired outcome;
15 minutes: walk through one real case and one difficult exception;
10 minutes: agree sources, outputs and prohibited uses;
10 minutes: assign actions, approvals and escalation routes;
10 minutes: draft acceptance tests and success measures;
5 minutes: assign unknowns, owners and the next decision.

Do not try to solve product architecture in the room. The purpose is to make the business job clear enough that a technical approach can be proposed, challenged and tested.

Frequently asked questions

Do we need a requirements brief for a simple AI tool?

For casual, low-risk individual drafting, a short approved-use description may be enough. Write a fuller brief when the workflow uses business data, connects systems, repeats at scale, affects other people, creates records or can take an external action. The consequence and complexity should determine the effort.

Should we choose the AI platform before writing it?

Usually not. You can record known platform constraints, but define the job first. Otherwise, the team’s needs can shrink to whatever the first product demonstrates. A stable brief also makes supplier and build proposals easier to compare.

Is this the same as an AI policy or risk assessment?

No. An AI policy sets organisation-wide rules. A requirements brief defines one workflow. A risk assessment examines what could go wrong and the treatments required. They should refer to one another rather than duplicate each other.

When is the brief finished?

It is ready for a build or pilot when the job, inputs, outputs, boundaries, approvals, exceptions, owners and acceptance criteria are clear enough to test. Keep it under version control and update it when an approved change alters the workflow. It is a living control, not a document to archive after procurement.

The decision before the build

A useful AI system starts with a clearly bounded business job. Write the outcome before the tool, map the awkward cases as well as the ideal one, name the authority behind every input, limit every action and decide what evidence will count as success.

That brief gives everyone something better than enthusiasm to work from. It gives the business a basis for choosing a solution, rejecting a poor fit, testing the build and deciding whether it should go live at all.

Have a repeatable job but need to turn it into a buildable brief? Talk to Drop Jaw Studio about an AI agent system build grounded in your workflow, systems, safeguards and team.

Sources checked on 17 October 2026: the UK Government’s AI Risk Management Toolkit, NIST’s AI RMF Map and Manage guidance, the NCSC’s guidelines for secure AI system development, and the ICO’s AI accountability and governance guidance. This is practical business guidance, not legal, data-protection or security advice.