Before You Automate: Define One Workflow and Its Approval Points

Before connecting an AI tool to a business process, write down one workflow from start to finish. A short, concrete description helps you decide what the tool may do, where someone must review its work and how the business will continue if it fails.

The objective is a process the owner can inspect. “Use AI to save time” is not yet a workflow.

NIST’s AI Risk Management Framework provides voluntary guidance for managing AI risks. Its Playbook offers suggested actions rather than a mandatory checklist to complete in full. The working questions below are BSH’s practical synthesis for a small, bounded task; they are not a NIST compliance assessment. NIST AI RMF, NIST Playbook

1. Name the trigger and the finished output

Specify the event that starts the work and the result someone expects to receive. Identify who uses that result and what happens next. This follows the basic need to understand an AI system’s intended purpose and context before deciding how to use it. NIST Playbook, MAP 1.1

For a fictional small workshop, the task might be: “Each Friday, prepare a draft list of consumable supplies that appear to need replenishment.” The output is a reviewable list. Ordering supplies is a separate action.

2. Identify the inputs and their limits

Name the source records, who maintains them and how recent they must be. State what should happen when a required input is missing or inconsistent.

In the workshop example, the permitted inputs are a checked stock-count sheet and the owner’s current minimum-stock list. A blank count means “needs review,” not zero stock. The draft should identify the records it used so the reviewer can trace a suggested item back to its source.

Use synthetic or appropriately sanitized inputs when first testing the workflow. Access to a tool does not establish permission to provide it with every business record.

3. Separate preparation from permission to act

List allowed actions as verbs: read the specified sheet, compare counts, prepare a draft and flag missing information. Then identify consequential actions that require an owner decision.

For this example, the tool may prepare the list. It may not place an order, change a supplier’s details or send the draft outside the business. Those boundaries should be enforced through the tool’s available permissions and controls, rather than relying on wording in a prompt alone.

Name the person responsible for reviewing the result and what that review covers. NIST’s oversight guidance emphasizes defined human and AI roles and responsibilities; “a human is involved” is not a complete description of an approval process. NIST Playbook, GOVERN 3.2

4. Decide how failure will be handled

Write a response for ordinary failures before connecting the process to live work. An unreadable sheet, an unexpected format or an uncertain result should produce an understandable review request.

The workshop owner could require the draft to stop when the stock sheet is out of date, preserve the last checked input and identify which item needs attention. The existing manual process remains available. If a later version can submit orders, its retry behavior would need a separate check to prevent repeated orders.

Also name who can stop the workflow and how changes will be reviewed. NIST’s management guidance includes monitoring, override, incident response, recovery and change management. NIST Playbook, MANAGE 4.1

5. Define evidence of a useful result

Choose checks that relate to the actual task. In the fictional example, the owner can compare suggested items with the source counts, look for missed items, record corrections and measure review time.

A faster first draft may still create more work if someone must repair it. Compare the whole reviewed task with the current process. Include missing-input and unusual-item cases in the local trial, not just one orderly example.

Set a review point before expanding permissions. Consistent draft preparation is evidence about draft preparation; it is not permission to start buying supplies.

A workflow brief the owner can review

For one proposed workflow, complete these seven lines:

• Trigger: the event and frequency that start the task.
• Inputs: the permitted records, their owner and freshness requirement.
• Output: the exact draft or result someone will inspect.
• Allowed actions: what the tool can do within this scope.
• Approval: who decides before a consequential action and what they check.
• Failure and recovery: when to stop, whom to notify and how to continue manually.
• Acceptance: the results, corrections and review effort that will determine whether the trial is useful.

A clear brief makes the next technical decision smaller: implement this bounded task, revise its assumptions or leave it manual.

Explore the BSH AI Operations Consultation for a focused discussion of one operating problem and a concise written follow-up. The consultation does not include independent tool research, a full assessment or implementation.

Sources and context

The linked NIST guidance supplies the context, oversight and recovery principles. The workshop example and seven-line brief are original explanatory material. This article does not establish regulatory compliance, system security or a promised financial return.