Why a checklist helps
When a team wants to try a new AI tool, the conversation tends to jump between excitement and vague worry. A checklist turns that into a set of concrete questions that get asked every time, in the same order, by whoever happens to be reviewing. It will not catch everything, but it reduces the chance that an obvious problem is missed because nobody thought to ask.
The goal is not paperwork for its own sake. A good checklist is short enough that people actually complete it, and flexible enough that a low-stakes use gets a quick pass while a high-stakes one gets a closer look. It is general guidance, and organizations in regulated fields should adapt it with qualified advice.
Start with the purpose
Before anything technical, write one or two sentences answering these questions.
- What task will the tool do, and who asked for it?
- What problem is it meant to solve? Teams that skip problem definition often adopt tools that do not fit.
- Who is affected by the output: only staff, or also customers, applicants, patients or the public?
- What happens if the tool is wrong, slow or unavailable?
The answer to the last two questions largely sets the level of scrutiny. An internal brainstorming aid and a tool that influences decisions about people belong in different categories.
Data questions
Next, look at what information goes in.
- What data will be entered or uploaded? Does it include personal, confidential or regulated information?
- Is all of that data actually needed for the task?
- Where is it stored, for how long, and who can access it? The provider’s terms on data retention are worth reading closely.
- Is it used to improve the vendor’s service, and can that be turned off?
- Do any contracts or laws limit where this data can go?
If you cannot get clear answers, treat that as a finding rather than a gap to fill with optimism. A set of vendor questions can help you press for specifics.
Accuracy and reliability
- How will you know whether the output is right? Who has the expertise to check it?
- What kinds of errors are likely, such as invented details, outdated facts or misread documents?
- Has the tool been tried on realistic samples of your own work, ideally in a small pilot project, before wider use?
- Are there tasks where it should not be used at all?
Write down the failure modes you expect. A reviewer who knows what to look for will catch more.
Fairness and impact on people
- Could the tool treat groups of people differently, for example by scoring, ranking, filtering or prioritizing them?
- Does it touch employment, credit, housing, health, education or similar areas where mistakes are costly?
- Could someone affected by an outcome ask for an explanation or a human second look?
If the answer to the second question is yes, consider whether the use should go ahead at all without specialist input.
Oversight and accountability
- Who owns this use inside the organization, by name?
- What does the human reviewer check, and do they have the time and authority to reject the output?
- Is there a way to log what the tool was used for?
- What is the path for reporting a problem, and who decides when to pause the tool?
An unowned tool tends to drift. Naming one person makes decisions and follow-ups much more likely to happen.
Transparency and legal checks
- Do customers or colleagues need to be told that AI is involved?
- Are there intellectual property questions, such as who owns the output or whether inputs include third-party material?
- Does the use fall under any sector rules, internal policies or contractual commitments?
You do not have to resolve every legal question yourself, but you should know which ones to bring to someone who can.
Cost and exit
- What is the full cost, including setup, training time and review effort, not just the subscription?
- How easily can you export your data and leave if the tool is poor or the vendor changes its terms?
Reviewers often forget the exit question until it is urgent.
Scoring and deciding
You can keep the outcome simple. For each section, mark it as clear, needs follow-up, or a concern. Then choose one of a few decisions.
- Approve for the stated purpose.
- Approve with conditions, such as limiting the data or requiring review of every output.
- Pilot first on a small scale.
- Decline for now.
Record the decision, the date and the conditions. The aim is not a numerical score, which can create false precision, but a written trail showing the questions were asked.
Keeping it alive
A checklist is only useful if it is reused. Revisit approved tools periodically, since vendors change their terms and features, and staff find new ways to use them. Update the checklist itself after any incident or near miss: if a problem slipped through, add the question that would have caught it. Over time, the list becomes a record of what your organization has learned.