AI Automation Readiness Checklist

Score the workflow before choosing tools

Give each dimension 0, 1, or 2 points: 0 means absent or unknown, 1 means partially defined, and 2 means documented and demonstrated with evidence. A maximum score is 16.

Dimension	Evidence for a score of 2
Process stability	Inputs, outputs, and transitions are documented and do not change weekly.
Acceptance criteria	A reviewer can distinguish an acceptable result from a plausible-looking failure.
Data access	Required data is available, permitted, current, and attributable to a source.
Exception handling	Common exceptions and an escalation owner are known.
Reversibility	Actions can be previewed, rolled back, or approved before commitment.
Evaluation set	Representative examples include normal, edge, adversarial, and failure cases.
Security boundary	Tools, credentials, users, and sensitive data have explicit access rules.
Economics	The value of an accepted outcome exceeds model, tool, review, and failure costs.

Interpret the total

13–16: ready for a bounded pilot. Start with one reversible path, a manual fallback, strict permissions, and a fixed evaluation set.
9–12: prepare first. Resolve the lowest dimensions before connecting production data or external actions.
5–8: redesign the process. Automation is likely to produce high review burden or unstable outcomes.
0–4: do not automate yet. Document the process and establish ownership before evaluating AI tools.

The total is not the only gate. A zero in security boundary, acceptance criteria, or reversibility blocks production use even when the total is otherwise high.

1. Process stability

Collect ten to twenty recent examples. Record which steps were actually performed, which systems were used, and where operators exercised judgment. If every case follows a different path, first standardize the process or narrow the automation to one repeatable subtask.

2. Acceptance criteria

Replace “good answer” with observable checks: required fields, supported citations, policy conditions, numerical tolerances, prohibited actions, or reviewer ratings. If two knowledgeable reviewers regularly disagree, document the disagreement and route uncertain cases rather than forcing automatic completion.

3. Data and permission access

List every source and account. Confirm ownership, retention, confidentiality, geographic, contractual, and user-permission constraints. The model should receive only the information required for the current step, not every document or credential available to the organization.

4. Exceptions and escalation

Sample failures before designing the happy path. Identify missing data, conflicting instructions, rate limits, stale records, unavailable services, and high-impact cases. Each exception needs a safe result: retry without side effects, ask for clarification, send to review, or stop.

5. Reversibility

Drafting and classification are easier pilots than sending, publishing, purchasing, deleting, or modifying permissions. Where an action cannot be reversed, require an explicit preview and human approval tied to the exact target and arguments.

6. Evaluation set

Create a versioned set of real and synthetic cases containing ordinary tasks, edge cases, adversarial inputs, and known failure modes. Store the expected outcome and review rule. Re-run it after model, prompt, tool, retrieval, or workflow changes.

7. Security boundary

Separate read, draft, and write permissions. Keep secrets out of prompts and logs. Treat web pages, email, documents, and retrieved content as untrusted data that cannot grant new authority to the system.

8. Economics

Calculate cost per accepted outcome, not cost per model request. Include retries, failed runs, external tools, infrastructure, monitoring, human review, and maintenance. Compare that total with the current manual process and the business value of faster completion.

Pilot contract

One named workflow owner.
One bounded task and one user group.
One versioned evaluation set.
One tool and data allowlist.
One stop control and manual fallback.
One budget, retry, and latency ceiling.
One weekly review of failures, corrections, and permission changes.

Limitations

This checklist is an editorial planning tool. It does not establish compliance with privacy, employment, financial, medical, safety, or sector-specific requirements. High-impact decisions need qualified domain, legal, and security review.

Next steps

Choose between retrieval, workflow, and agent architecture with RAG vs agents. If the workflow uses tools, apply the security checklist. Estimate the pilot with the cost model before selecting a framework from the AI tools research hub.