An AI implementation brief template

Direct answer

An AI implementation brief names the task, the data and the owner before anyone chooses a tool. Most disappointing AI projects start from the tool ('we should use an agent') rather than from a described piece of work, and the result is a demo that nobody owns. The brief below has eight sections. Fill them in plainly. If you cannot describe the task, the users and the way you will judge the result, no vendor can either, and the useful next step is to sharpen the brief, not to buy software. A brief cannot promise outcomes, and neither can a proposal that answers it: results depend on your data, your process and the review you put around it. For sequencing, see the AI implementation roadmap.

1. Task and users

Describe one task, in the present tense, as it is done today: who does it, how often, from what input to what output, and where it goes wrong. Then say who would use the AI-assisted version and who would see its output. Choose a task narrow enough to describe on a page. If your description contains the word 'everything', split it.

2. Data sources and sensitivity

List every source the task would read: documents, emails, records, spreadsheets, web pages. For each, note who owns it, where it is kept, how current it is, and how sensitive it is. Mark anything personal, confidential or covered by a contract. Which of it may be sent to an external service is a decision to take with your legal or compliance adviser, not something a vendor should assume. Also note the state of the data, since inconsistent or outdated sources limit what any tool can do.

3. Systems touched

Say which systems the AI would read from and which it would write to. Reading and writing are very different risks: a tool that drafts text for a person is not the same as one that updates a customer record. List each system, its administrator and what access exists today. Connections are scoped per project via API or webhook after technical review, so note what each system offers and on which plan.

4. Permissions

State what the AI is allowed to do and what it must never do. Prompts:

• Which records may it read, and for which users?
• May it change anything, or only suggest changes?
• May it send messages outside the company?
• What happens if a user asks for something they are not entitled to see?
• Who can switch it off, and how quickly?

5. Human review points

Decide where a person looks at the output before it has an effect. For each review point, name the reviewer, what they check and what they do when it is wrong. Reviews that are too frequent are ignored and reviews that are absent let errors through, so choose them according to the cost of a mistake at each step. Note what evidence the reviewer needs in order to check quickly, such as the sources the answer was based on.

6. Success test

Write down how you will judge whether it works, before you build. Use a set of real examples from your own work with known good answers, and say what counts as acceptable, unacceptable and 'send to a person'. Define the thresholds yourself; nobody outside your business can set them for you, and we do not promise results. Include the failures you care about most, such as a wrong figure or an invented source. Decide who runs the test and how often it is repeated.

7. Constraints

List what limits the solution: budget owner, deadlines with a reason, policies on data leaving the company, required languages, systems that cannot change, and rules from customers. Check these against your AI usage policy. Also note what you will do if the answer turns out to be that AI is not the right tool for this task, which is a legitimate finding.

8. Attachments

Attach what lets a vendor understand the work without guessing: a handful of anonymised examples of inputs and correct outputs, the current written procedure if there is one, a screenshot or export of each system involved, and the names of the people who can answer questions. Remove or mask personal data before sharing. The examples double as your test set later.