Your first AI automation workflow: choose a process you can test and stop

A suitable first workflow is a repeated task with clear inputs, checkable outputs, a process owner and a manual fallback. Avoid starting with an entire operation or high-stakes decisions. Map the trigger, steps, people responsible and points where data changes hands. Establish a baseline from actual work: case volume, handling time, waiting time, corrections and exceptions. Include difficult cases, not just clean examples. Specify what you want to improve and how you will compare outcomes. If the process changes every time or nobody owns it, clarify the work before commissioning automation.

Use deterministic rules for steps with explicit conditions and outcomes, such as routing a form by its selected service or flagging an empty required field. Consider AI for interpretation, such as summarizing free-text questions or suggesting categories. Ask the provider why each proposed AI step needs a model, what reference material it uses and what happens when the output is inadequate. Do not add AI to every step because the project has an AI label. If a better form or conventional integration addresses the problem, compare that simpler option before approving a proof of concept.

Prepare shareable input examples and expected outputs, then list what each tool may read or change. Use synthetic or redacted examples for the initial discussion; do not include passwords, tokens or confidential customer documents in the brief. Confirm the data owner's permission, intended use and required access approvals. Before using real records, review the provider's processing, retention and deletion terms with the responsible people. Limit permissions to the task. Permission to read a document does not authorize sending an email or writing to an operational system. Record these boundaries before choosing integrations.

Assign human review to a named role, define the checks and specify when processing must wait for a decision. Reviewers need the original input, proposed output and exception reason, not just an approval button. Decide what happens when data is missing, sources conflict or an answer cannot be verified: request clarification or return the case to a person. Treat text inside documents and messages as data, not permission to change instructions or expand access. Test misrouting, duplicates, integration failures and an unavailable reviewer. Count checking and correction time as work rather than hiding it from the evaluation.

Stop the pilot if data leaves its permitted scope, actions happen without approval, corrections exceed an agreed limit or the manual fallback cannot be restored. Set quality, usage-cost and review-workload limits before starting, not after seeing results. Run a bounded test with human approval before external actions, then compare the whole process with the baseline using comparable cases. Decide whether to continue, simplify or stop. Ask the proposal to separate the use-case audit, proof of concept, integration, evaluation, documentation and recurring tool costs. A polished demo is neither savings evidence nor a security guarantee. Expanding the scope needs a new decision.