Choose an AI automation candidate by starting with one repeated, observable workflow that has a named owner, known inputs, a verifiable output, and a safe exception path. Do not begin with a model or a promise of savings. Establish the current baseline, define what a correct result means, and test a review-only version before granting the system authority to change business records.
That approach follows the governance, data, performance, and monitoring concerns in the U.S. Government Accountability Office AI accountability framework. The NIST AI Risk Management Framework likewise treats measurement and ongoing management as part of the system, not as work to add after launch.
A strong automation candidate
A process is worth investigating when most of these statements are true:
- It happens often enough that delays, re-entry, or review queues are visible.
- Staff can show the normal path and name the exceptions rather than relying entirely on tacit judgment.
- Each important field has a known source of truth.
- A reviewer can determine whether the output is correct without repeating all of the work.
- Failure can be contained through a queue, approval, reversal, or manual fallback.
- One person owns the workflow after release, including exceptions and source changes.
Common candidates include document intake, record matching, draft generation, request routing, status synchronization, and reconciliation. Some need machine learning; others are better implemented with deterministic rules, forms, or a conventional integration. Discovery should compare those options.
When automation is not the first move
Pause when the process changes from person to person, the data is unreliable, the desired outcome is disputed, or a mistake would create a consequence that cannot be reviewed or reversed. A low-volume task can also be a poor candidate when a checklist, template, product setting, or clearer ownership would remove the same friction.
Automation does not repair an unclear operating model. It can make that model harder to inspect because inconsistent decisions become embedded in code, prompts, or routing rules. Map and simplify the process first; automate only the stable remainder.
Define the work before selecting technology
Write a short workflow brief with these fields:
- Trigger: What event starts the work?
- Inputs: Which records or documents are required, and who owns them?
- Output: What observable artifact or system state marks completion?
- Rules: Which checks are deterministic, and which require judgment?
- Exceptions: What should stop, retry, or route to a person?
- Authority: May the system read, draft, create, update, send, or approve?
- Evidence: Which logs or source references let someone reconstruct what happened?
If systems communicate through APIs or events, document the contract rather than relying on an informal field map. The OpenAPI Specification provides a machine-readable way to describe HTTP interfaces, while the CloudEvents specification defines a common event envelope. Neither guarantees reliability, but both make expectations easier to test and hand off.
Start with a narrow authority boundary
A useful release sequence is:
- Observe: run on historical or copied inputs without affecting live work.
- Draft: prepare a result for a person to review.
- Queue: create a pending record or task with validation and duplicate protection.
- Act: perform a specific reversible action under explicit permissions.
- Expand: add another action only after the existing one meets its release criteria.
This sequence is a control model, not a promised schedule. The work may stop at any level if the evidence does not support broader authority. For consequential decisions, human review may remain a permanent system requirement.
Measure the workflow, not the demonstration
Record a baseline using the same definition you will use after release. Depending on the workflow, that may include:
- completed items and unresolved exceptions;
- correct extraction, classification, or routing;
- correction and override reasons;
- end-to-end cycle time rather than model response time;
- duplicate, missing, or stale records;
- unit operating cost, including review and support;
- incidents, access violations, and recovery events.
A fluent example is not an evaluation. Build a representative set containing normal cases, edge cases, malformed inputs, and known failure conditions. Keep it as a regression gate when prompts, models, data sources, or integrations change. Our methodology explains how we separate measured results from estimates and illustrative scenarios.
Decide whether the result justifies operation
The relevant comparison is the complete operating system before and after the change. Count discovery, integration, testing, review, monitoring, vendor usage, exception handling, and maintenance—not only the model call. Also count any new work created by false positives, unclear handoffs, or staff checking outputs that cannot be trusted.
Proceed when the evidence supports the workflow objective and the team can own the controls. Narrow the scope when only part of the process performs reliably. Stop when a simpler change produces the same operational value or the residual risk is not acceptable.
For a broader implementation model, see our business automation service. If the workflow genuinely requires multi-step reasoning or tool use, compare it with the stricter authority model described in AI agent development. A useful first conversation starts with a real workflow and sample exceptions, not a predetermined technology.
