An AI readiness checklist for small businesses.

1. Define the business problem without naming an AI tool

Describe the current workflow, the people involved, the volume, the delays, the rework, the customer impact, and the decision that needs to improve. If the problem cannot be explained without starting with a product name, the opportunity is probably not defined well enough.

Establish a baseline before changing the process. Measure time, backlog, response speed, error or exception rates, handoffs, cost, or another signal that the business can compare after a pilot.

• Name the workflow owner and the people who perform or receive the work.
• Describe the desired operating change in plain language.
• Choose one or two metrics that can be measured consistently.

2. Decide whether AI is actually required

Many valuable improvements come from clearer forms, better routing, integrations, templates, validation rules, or ordinary automation. AI is most useful when a bounded step requires language understanding, summarization, classification, extraction, drafting, conversational interaction, or another probabilistic capability.

Map which steps must be deterministic and which may tolerate AI variation. Keep authentication, financial posting, record deletion, permissions, final approvals, and other consequential actions behind explicit controls appropriate to the risk.

The strongest solution may combine ordinary automation for control with AI for one carefully bounded task.

3. Evaluate information and data readiness

List the information required to perform the task, where it lives, who owns it, how accurate it is, and whether the business is allowed to use it for the proposed purpose. Review examples, edge cases, missing fields, duplicate sources, inconsistent terminology, and sensitive information.

Decide what the AI system may receive, retain, generate, and send. Avoid moving confidential, regulated, personal, client, employee, or proprietary information into a tool until data handling, contracts, configuration, access, and policy are understood.

4. Map systems and integration constraints

Identify the systems that trigger the workflow, provide context, receive results, store the record, notify people, and prove what happened. Check whether supported APIs, connectors, permissions, rate limits, data formats, and test environments exist.

Design for failed integrations, unavailable services, duplicate events, partial updates, and retries. The happy path is only one part of a production workflow.

5. Define human oversight, exceptions, and escalation

Specify which outputs require review, who may approve them, what confidence or condition triggers escalation, and what happens when the AI cannot answer reliably. A person needs enough context to understand and correct the result.

For customer-facing voice or chat, define identity disclosure, consent where required, recording practices, prohibited claims, transfer conditions, emergency or sensitive topics, and the route to a human.

6. Assess risk before selecting the pilot

Consider the harm from an incorrect output, omitted information, bias, data exposure, unauthorized action, customer confusion, employee overreliance, service interruption, or an unreviewed change. Risk depends on the use case, not on AI in the abstract.

• Identify legal, contractual, regulatory, privacy, security, and records obligations with qualified advisors where needed.
• Define prohibited inputs, outputs, actions, and destinations.
• Preserve logs and evidence appropriate to troubleshooting and accountability without collecting unnecessary sensitive information.

7. Prepare the people and operating model

Employees need to understand why the workflow is changing, what the system can and cannot do, how their role changes, how to review outputs, and how to report a problem. Include the people who perform the work in design and testing.

Assign ongoing ownership for prompts or instructions, source knowledge, integrations, access, incidents, quality review, vendor changes, cost, and improvement decisions.

8. Design a measurable, reversible pilot

Choose a narrow population, controlled data set, limited duration, and clear success and stop conditions. Preserve the existing process until the new path is dependable enough to expand.

Compare results to the baseline, review exceptions and employee feedback, estimate operating effort, and document what would need to change before broader adoption. A pilot should produce a decision, not merely a demo.

Readiness is demonstrated when the business can explain the workflow, boundaries, owner, risk, pilot, and measure of success—not when it has purchased an AI license.