In this guide
The first useful AI project begins with a familiar task and a person who knows what a good result looks like.
Look for something your business does repeatedly: turning approved information into a short explanation, organizing a set of public details, or preparing a general response template.
Choose a task small enough to check from beginning to end. Give the trial a clear purpose, a named reviewer, and a way to decide whether it is worth continuing.
Here is a practical way to begin.
Choose a task you can explain and check
Imagine a business that regularly prepares short FAQs when a product, service, or event changes. Someone gathers approved public details, drafts answers, checks them, and prepares the final version.
The source information and expected result can be defined, so a reviewer has something concrete to check.
Choose a task where a mistake can be caught before anyone relies on it. Keep the first trial away from decisions about individual customers, employees, payments, or safety.
If you are unsure where repetition occurs, following one customer inquiry through your business can help you see the work around replies and handoffs.
Fix the input and the output
Write a short description of the job before opening a tool.
For the FAQ example:
- Input: an approved, current description containing only public, non-sensitive information.
- Output: three draft questions and answers, each answer under 60 words, with the supporting source sentence identified.
- Boundary: no added prices, availability, policies, guarantees, or commitments.
- Missing information: flag it for a person to resolve.
Use an AI tool your business has approved for this purpose. Understand who can access the account and how the provider handles your inputs. Keep real customer personal data, customer messages, passwords, trade secrets, and confidential business information out of this trial.
The UK's National Cyber Security Centre advises excluding sensitive information from queries to public AI language tools. NCSC guidance on information in AI tools.
A starter instruction could be:
“Using only the approved information below, draft three FAQs in plain language. Keep each answer under 60 words. Identify the source sentence supporting each answer. Flag missing information. Add no new promises. These are drafts for human review.”
Treat those instructions as a standard to check against. They do not guarantee the tool will follow every boundary.
Name the reviewer and define the checks
Choose someone who understands the offering and has authority to approve the wording. Give them the source information alongside the draft.
Their checklist should cover:
- Facts: Is every statement supported by the approved source?
- Context: Does the answer fit the question and the actual offering?
- Tone: Does it sound like your business and treat the reader with care?
- Commitments: Has it introduced or changed a promise, policy, price, or deadline?
- Completeness: Is an important condition or limitation missing?
NIST identifies confidently incorrect output as a generative AI risk and recommends verifying generated information. A fluent answer still needs checking. NIST's Generative AI Profile.
Keep the trial in a separate draft document. Connect it to no sending or publishing system. A person reviews and approves every final answer before manually sharing or publishing it.
For public-facing language, making your existing strengths visible offers a useful companion exercise in describing the business accurately.
Record the usual approach
Before the trial, time a few ordinary batches done manually. Note the source length, difficulty, total working time, and corrections needed to reach an approved result.
Use comparable batches for the AI trial and apply the same review standard. Keep unusual cases separate so they do not distort the comparison.
Record the total effort for both approaches. Include gathering the information, drafting, checking, correcting, and preparing the final version.
Track one-time setup separately from the work needed each time. Include tool costs when deciding whether the task is worth continuing.
Run a small trial and compare
Try a handful of routine examples. Save the inputs, instructions, drafts, corrections, and final versions in a place the owner and reviewer can access.
For each batch, record:
- Total working time, including review and rework.
- Unsupported statements, omissions, or changed commitments.
- Whether the final draft met the agreed standard.
Compare those notes with the manual approach. Quick draft generation is only one part of the work. The useful question is whether the complete process makes sense for your business.
A small trial gives you a reason to continue, revise, or stop. It gives you limited evidence about this particular task and these examples.
Keep the work understandable and easy to stop
Write down who owns the task, who reviews it, which source is current, and how to return to the manual approach.
Pause if the task starts requiring sensitive information, the reviewer cannot verify the output, errors keep recurring, or review and rework remove the benefit. Return to the usual process while you decide what to change.
If you continue, keep the boundaries and review checks in place. Recheck the process when the tool, source information, or task changes.
The owner should be able to explain what goes in, what comes out, who checks it, and how to maintain or stop it. That understanding is part of a useful result.