How to choose your first AI-assisted workflow

Begin with the work that already exists

Choosing a first AI-assisted workflow is easier when the team starts with a task it understands. Describe what happens today before deciding which tool to try. A useful description names the input, the person doing the work, the output and the person who uses it next. That gives the pilot a boundary and makes it possible to compare an assisted approach with the existing process.

“Use AI in operations” leaves too many decisions open. “Prepare a draft internal summary from approved meeting notes for a manager to review” is specific enough to examine. It identifies the material and the draft's destination. It also makes clear that generating text is one step inside a larger process. Collecting the notes, checking the summary and sharing the result still need an owner.

The examples in this guide are illustrative planning exercises. The aim is to choose a test that produces useful evidence, with a scope small enough for the team to understand and control.

Make a short list of candidate tasks

Ask the people who do the work where they spend time arranging, summarizing or reformatting information. Write down several candidate tasks without committing to one. For each, record how often it occurs, who handles it and what makes a result acceptable. A task that frustrates a manager may be difficult for reasons unrelated to drafting speed. Missing information or unclear approval rights can create delays that a new tool will not solve.

Separate the task from the whole job. Preparing a first draft of an internal note differs from sending a message to a customer. Sorting a small set of approved documents differs from deciding what a contract requires. The team may find that the useful opportunity sits in a preparatory step, where a person can inspect the result before it affects anyone else.

Avoid selecting a task only because a tool demonstration makes it look easy. A demonstration usually uses convenient inputs and a single successful output. The team's process will include unclear, incomplete and unusual examples. The first pilot should be chosen with those examples in mind, because they reveal how much judgment and checking the workflow requires.

Use five questions to compare the candidates

First, can the team define a good output? If reviewers cannot agree on what the task should produce, begin by improving the template or instructions. A pilot needs an evaluation target. For an internal summary, that might mean preserving decisions, assigning actions correctly and distinguishing open questions from settled ones.

Second, are the inputs available and approved for the proposed use? Confirm where they come from, who can authorize access and whether the chosen tool is appropriate for them. If that answer is unresolved, pause selection of the task or use approved practice material. Do not treat technical access as permission to submit information.

Third, can a person check the result with reasonable effort? A short summary with accessible source notes is easier to inspect than a conclusion built from many documents the reviewer has not read. Verification cost matters. The pilot should consider how much time people spend confirming and correcting the output, not only how quickly a draft appears.

Fourth, what happens if a mistake is missed? A flawed practice note has a different consequence from a wrong instruction sent to a customer. Prefer a first test where the output remains a draft and the team can catch errors before acting. If the consequences require specialized review, bring the appropriate person into the scope or choose another task.

Fifth, can the team stop or reverse the change? A small pilot with manual review is easier to pause than an integration that automatically changes records or sends messages. A clear stop path lets the team learn without committing to broad use before it understands the result.

Work through a comparison

Imagine a service business considering three tasks: drafting internal meeting summaries, responding to customer complaints and ranking prospective hires. The summary task uses approved internal notes and produces a draft for a manager. The complaint task can affect a customer relationship and requires careful handling of commitments. The hiring task involves decisions about people and raises questions beyond a simple drafting exercise.

For this illustrative team, the internal summary may be the better first candidate because the output can stay within a controlled review process. That is a judgment about the stated example, not a rule that every summary task is low risk. If its notes contain sensitive material, or if staff use the summary as the only record of a decision, the team needs to account for those conditions.

Write the selection rationale in a few sentences. The chosen task has accessible source material, an agreed format and an identified reviewer. Its output remains a draft until approved. The other tasks are outside this pilot. Recording that rationale prevents the scope from drifting when someone asks why the team is not automating more steps at once.

Write a pilot scope people can follow

A useful scope names the process owner and the participants. It specifies the permitted inputs, the draft format and where review occurs. It also states what the tool may not do. In the summary example, it may prepare text from the approved notes, while sending the summary and changing the project plan remain separate human decisions.

Choose a small evaluation set with enough variation to be informative. Include a routine example, an incomplete example and one that contains a likely source of confusion. The exact number depends on the task and the time available. The set should expose the questions the team cares about, rather than consist only of easy examples that make the approach look successful.

Before testing, define the checks. Does each action match the source? Are names and dates preserved? Are open questions still marked as open? Does the draft add a claim that the notes do not support? Reviewers should use the same checks for the existing method and the assisted method, so the comparison reflects the work rather than a change in standards.

Connect the test to responsibility

NIST’s AI RMF Core includes roles, responsibilities and human–AI oversight as part of its treatment of AI risk management. For a small pilot, those concerns can become straightforward questions: who is responsible for the workflow, who checks the output and who can decide to continue? The team should answer them before beginning the test.

The NIST AI Risk Management Framework is voluntary and aims to support trustworthiness in the design, development, use and evaluation of AI. It is a helpful reference for organizing further questions. Using a few of its concerns in a pilot does not mean the organization has completed a full framework assessment. Keep the claim about the pilot as narrow as the work actually done.

Measure the complete task

Record preparation, drafting, review and correction separately. An assisted draft may reduce one stage and increase another. If a manager spends longer checking unclear output, the apparent drafting gain may not produce a useful improvement. The team should also record whether the final result meets the agreed criteria and which types of errors recur.

A simple observation sheet can include the example identifier, method used, review findings, corrections and final decision. Add short notes where an issue cannot be captured by a yes-or-no check. If a draft is accurate but difficult to scan, that is relevant to the workflow. If an output needs a person to reconstruct the source, record that effort.

Do not convert a handful of pilot observations into a company-wide savings claim. State what happened in the tested task, with the tested inputs and the agreed review process. That is enough to support a decision about the next stage.

Set the stop conditions in advance

A pilot should pause if it exposes information outside the agreed boundary, produces unsupported commitments or makes checking harder than the team can manage. It should also pause if the process owner or reviewer becomes unavailable. Write down how participants report an issue and where the existing method remains available.

At the end, choose one of three outcomes: continue within the same scope, revise and test again, or stop. A useful pilot can show that a task is a poor fit. It can also reveal that the team needs a clearer template before an assisted method is worth trying. Both outcomes improve the next decision.

The next step is a one-page pilot scope with an owner, approved inputs, evaluation examples and stop conditions. Choosing that manageable piece of work gives the team a concrete way to learn what helps and what still needs a person's judgment.