AI Automation Readiness Checklist:
Workflow, Data, Risk,
and Human Review

A workflow is not ready for AI automation merely because a model can produce a convincing example. Readiness depends on whether the process, data, permissions, failure consequences, human controls, and operating evidence are clear enough to test safely.

Use this checklist before funding a proof of concept or connecting an AI system to real tools. It follows the risk-management logic of the NIST AI Risk Management Framework: understand the context, measure behavior, manage risk, and keep governance active throughout the lifecycle.

1. Start with the workflow, not the model

Map the trigger, inputs, decisions, actions, exceptions, handoffs, and final outcome. Identify who performs each step today and why. If the underlying process changes every week or depends on undocumented judgment, automate only after stabilizing the workflow.

Define the baseline: current volume, handling time, error rate, delay, cost, and escalation burden. Without a baseline, a faster demo can still create more rework.

2. Define one measurable outcome

Choose the narrow result the system should improve, such as reducing classification time, drafting a first response, finding relevant documents, or routing a request. State the acceptable quality, latency, cost, and review effort.

Avoid “use AI for customer support” as a project boundary. A testable boundary is “suggest a category and draft for approved ticket types, with an agent approving every reply.”

3. Inventory data and access

• Which sources are authoritative, current, and legally available for this use?
• Does the workflow include personal, confidential, regulated, or client-owned data?
• Who can approve access, retention, transfer, and deletion?
• Can representative test data be created without exposing production records?
• How will outdated, conflicting, or missing information be detected?

Do not copy production data into an unapproved model, vector store, or evaluation tool merely to accelerate a prototype.

4. Classify the consequence of a wrong result

Separate low-consequence suggestions from actions that affect money, access, safety, employment, legal rights, production systems, or customer commitments. Record who is harmed, how quickly the harm can occur, and whether it can be reversed.

The higher the consequence and the harder the reversal, the stronger the evidence and human approval required before any action.

5. Choose assistive or autonomous behavior

An assistive system proposes content or decisions for a person to review. An autonomous system can execute an action. Start with the least autonomy that still improves the workflow, especially when data quality and failure patterns are not yet known.

Define which outputs require approval, who can approve them, what context the reviewer sees, and how disagreement is captured for later evaluation.

6. Limit tools, permissions, and scope

Give the system only the tools and permissions required for the approved task. Restrict which records it can read, which actions it can take, the parameters it may send, and the number or value of operations it may perform.

OWASP describes excessive agency as risk created by unnecessary functionality, permissions, or autonomy. Its guidance favors minimized extensions and permissions, server-side authorization, and human approval for high-impact actions. See OWASP: Excessive Agency.

7. Build an evaluation set before the demo

Collect representative normal cases, ambiguous inputs, missing data, adversarial instructions, and known failure cases. Define expected behavior and acceptance thresholds before tuning the system against them.

Measure false positives and false negatives separately. The more harmful error may not be the more frequent one. Keep a holdout set so the team can distinguish improvement from memorizing examples.

8. Design the integration for retries and partial failure

Decide what happens when the model, database, queue, third-party API, or approval step times out. Use identifiers and idempotent operations where duplicate actions would be harmful. Preserve enough context to investigate failures without logging secrets.

Every external action should have an auditable request, authorization decision, result, and owner.

9. Define fallback, override, and shutdown

Document how work returns to the manual process, how a reviewer corrects a result, how pending actions are contained, and who can disable the feature. Test the fallback before rollout rather than assuming operators can improvise during an incident.

10. Plan monitoring and change control

• Quality and acceptance rates by workflow segment.
• Latency, cost, retry, timeout, and fallback rates.
• Human corrections, overrides, and escalations.
• Security events and unauthorized tool attempts.
• Model, prompt, retrieval, policy, and data-version changes.

Assign an owner who can interpret these signals and decide whether to continue, narrow, roll back, or retrain the system.

11. Bound the proof of concept

A useful PoC answers a decision: whether a defined approach can meet agreed quality, latency, cost, and control thresholds on representative data. It should not quietly become a production service.

Specify the timebox, dataset, environment, permitted integrations, evidence package, and stop conditions. Then use From AI Proof of Concept to Production to assess the work still required after a successful demo.

Readiness decision

Proceed when the workflow and outcome are bounded, data use is approved, failure consequences are understood, evaluation cases exist, permissions are limited, human controls are explicit, and an owner can operate the system. If these conditions are missing, the next deliverable is discovery—not automation.

The practical readiness rule

Automate only the part of the workflow whose outcome, evidence, permissions, failure path, and accountable owner can be stated clearly.