AI Readiness Checklist for Small Businesses

An AI readiness checklist should answer one operational question: is one specific workflow ready for a bounded AI pilot? A small business is ready when that workflow has a measurable result, usable evidence, a stable enough operating path, authorized data, a task that genuinely needs AI, explicit review and recovery controls, and an owner who can run what gets built.

Do not average a missing control into an impressive readiness score. If the business cannot authorize the data, define a correct result, assign responsibility for failures, or recover from a wrong action, fix that gap before testing AI.

The U.S. Small Business Administration advises businesses to start small and test whether an AI tool adds value. The checklist below turns “start small” into a workflow-level go/no-go decision.

What this AI readiness checklist measures

AI readiness is not a permanent badge for the whole company. The same business may be ready to test document classification and unready to automate a pricing decision. Readiness depends on the workflow, the proposed AI task, the data it will use, and the consequence when it is wrong.

This checklist assumes you already have one candidate workflow. It does not choose among a portfolio of possible projects. It also is not a legal, privacy, cybersecurity, safety, employment, financial, or regulatory audit. Use qualified specialists when those duties apply.

Work through seven gates. A “no” does not always kill the idea, but it should change the next step. Red-line gaps—unauthorized data, no accountable owner, no safe review for consequential actions, or no recovery path—stop the pilot until they are resolved.

Gate 1: Define the result and the workflow boundary

Start with the work, not the model. A workflow boundary must be specific enough that two people can agree when a case begins and when the business result is complete.

• The trigger is observable: an email arrives, a form is submitted, a document is uploaded, or a system event occurs.
• The completed result is a business outcome, not “the AI generated something.”
• The system of record for that result is named.
• The team knows who owns the result from trigger to completion.
• Success includes a quality or control measure, not speed alone.

Write the boundary in one sentence:

When [trigger] occurs, the workflow must produce [completed result], record it in [system of record], and keep [quality or control condition] within an agreed limit.

“Use AI for customer service” is not a boundary. “Classify a new support email, match it to an account, draft a response from approved sources, route exceptions, and record the reviewed outcome in the CRM” is much closer.

Stop condition: If the team cannot agree on what “done” and “correct” mean, the workflow is not ready for an AI pilot.

Gate 2: Prove the problem with workflow evidence

A pilot needs a baseline. Otherwise, a fluent demonstration can look successful even when it creates more review, correction, or downstream work.

• Recent real cases show the delay, repeated handling, rework, inconsistency, or capacity problem.
• The team can separate active employee time from waiting time.
• Common error and exception types are recorded.
• The current result can be measured using the same boundary planned for the pilot.
• The proposed improvement is tied to an operational consequence: time, quality, backlog, capacity, customer experience, cost, or control.

Do not require perfect analytics before learning anything. A small, representative case set and honest process evidence can be enough to design a bounded test. But “everyone says this is inefficient” is not a baseline.

If the current path is still unclear, use the operational-efficiency workflow audit first. It shows how to trace real cases, waiting, rework, handoffs, repeated touches, and exceptions before choosing an intervention.

Stop condition: If there is no observable problem or no way to compare the future state with the current state, pause the AI proposal.

Gate 3: Make the normal path and exception path explicit

AI cannot repair a workflow whose decisions live entirely in unwritten habits. The process does not need to be rigid, but it must be stable enough to identify normal work, bounded judgment, and genuine exceptions.

• The normal path is written from trigger to completed result.
• Required inputs, decisions, handoffs, and approvals are visible.
• Common exceptions have an owner and a next action.
• Policy disagreements are resolved or isolated from the pilot.
• The team knows which steps may change during the test and which controls must remain fixed.

Watch for “ask Maria” steps. The employee may be applying valuable judgment, but the workflow is not ready until the team understands what evidence Maria uses, which decisions she is authorized to make, and what happens when she is unavailable.

Stop condition: If similar cases do not have an agreed correct handling path, define the operating rule before asking AI to imitate inconsistent decisions.

Gate 4: Establish data authority, access, and permitted use

“We have the data” is not enough. Readiness requires an authoritative source, an accountable owner, a way to match the data to the correct business object, and permission to use it for the proposed task.

• Each required data element has a named source of truth.
• Customer, vendor, product, order, case, or employee records can be matched with a stable identifier.
• The owner of each source can authorize access and use.
• Sensitive, confidential, regulated, or contract-restricted data is identified before testing.
• Test cases represent normal work and difficult exceptions.
• Retention, deletion, and access rules are defined for prompts, files, outputs, and logs.
• The team can detect missing, stale, contradictory, or incorrectly matched information.

Do not copy production records into a free tool to “see what happens.” First determine what the vendor receives, stores, uses, and exposes; then apply the business’s security, privacy, contractual, and industry obligations.

Red line: If the business cannot authorize the proposed data use or safely limit access, the workflow is not ready for that AI design.

Gate 5: Confirm that the task needs AI

A workflow can be ready for improvement without being ready—or needing—AI. Use AI when bounded interpretation of unstructured information is the proven bottleneck. Use deterministic logic when the answer must follow exact rules.

• The proposed AI task is named: classification, extraction, matching, summarization, or drafting—not “automate everything.”
• Representative examples can be labeled or reviewed against an agreed standard.
• The team can define unacceptable output, not only ideal output.
• A fallback exists when the model is uncertain, unavailable, or outside scope.
• Native software features and deterministic rules have been considered first.
• The AI output will enter a complete workflow rather than create another copy-and-paste step.

Use native features first, integration second, and custom code last. Required-field validation, totals, identifiers, approval limits, permissions, and routing thresholds usually belong in rules or core systems. AI may help interpret a messy email, but it should not invent an account ID or decide who is allowed to approve a payment.

The NIST Generative AI Profile exists because generative systems add distinctive risks that organizations must identify and manage. Add AI only when its ability to handle the targeted ambiguity is worth the additional testing, monitoring, and recovery work.

Decision change: If the task is frequent but entirely rule-based, the workflow may be ready for automation—just not AI automation.

Gate 6: Design review, stop, and recovery before the pilot

The NIST AI Risk Management Framework is voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. For a small-business pilot, that principle becomes concrete only when each failure has a response.

• The consequence of a wrong output is documented.
• Human review is triggered by a defined condition: topic, value, confidence, missing evidence, customer impact, or action type.
• The reviewer receives the source, proposed output, reason for review, and permitted actions.
• Irreversible, financial, access-changing, legal, safety-related, or sensitive customer actions remain under appropriate authority.
• The workflow logs the input reference, output, reviewer or automated action, final result, and failure reason.
• Stop conditions are agreed before the test.
• Failed cases can be retried, corrected, rolled back, or routed to a known manual path.
• One person owns incident response and recovery.

“A human is in the loop” is not a control description. State which human, reviewing what evidence, at which point, with which authority, and what happens next. Our guide to human review in AI workflows explains how to design review as an operating state rather than a vague instruction.

Red line: If a bad output can create material harm and the team cannot reliably intercept or recover it, do not run the pilot in that action path.

Gate 7: Assign an operating owner and a value path

A pilot is not ready when everyone owns the idea but nobody owns the operating result.

• A workflow owner is accountable for the completed business result.
• A technical or system owner can address access, integration, logging, and outages.
• Reviewers have capacity and clear decision authority.
• Someone will monitor quality, exceptions, drift, and parallel work.
• Recurring software, review, maintenance, and support costs are visible.
• The business knows where released time or improved capacity will go.
• A decision date and decision-maker are set for expanding, changing, pausing, or retiring the pilot.

Released time is not automatically cash savings. The value may be faster response, lower rework, avoided hiring, reduced contractor work, higher throughput, or better control. Name the intended result and how management will act on it.

Stop condition: If no one can own monitoring, exceptions, and recovery after launch, the workflow is not production-ready even if the demo works.

Draw the AI task boundary

Before selecting a vendor, separate responsibility across AI, deterministic systems, and people. A shared-inbox workflow might look like this:

The boundary makes one point clear: an AI feature is not yet an AI workflow. A draft or classification creates value only when the surrounding systems, controls, people, and recovery path carry responsibility to the completed result.

Create a one-page Pilot Contract

Once the seven gates are clear, write a Pilot Contract before implementation. This is not a legal contract. It is a compact operating agreement that prevents the test from expanding silently.

This structure mirrors the practical logic of the NIST AI RMF Playbook: govern responsibility, map the context, measure behavior and risk, and manage what happens in operation. It does not turn a voluntary framework into a certification. It makes the pilot’s responsibilities testable. When those gates are clear, an AI implementation roadmap from pilot to production can turn the contract into staged evidence, operating ownership, and controlled expansion.

Make one of four readiness decisions

Do not reduce the checklist to a percentage. Use the evidence to choose the next action.

One red-line failure can outweigh six green gates. That is why a composite readiness score is less useful than a decision with an explicit reason.

Example: narrowing an AI inbox proposal

Imagine a small service business proposes: “Let AI answer every message in the customer inbox.” This is a hypothetical example, not a KelenAI client result.

The first readiness pass finds several gaps:

• customer identity is sometimes inferred from an email signature;
• approved answers are split across an old handbook, individual documents, and employee memory;
• complaints, pricing questions, and account changes require different authority;
• nobody owns messages the system cannot classify; and
• success is described only as “faster replies.”

That proposal is not ready. The next step is not to abandon AI; it is to narrow the boundary.

A bounded pilot could classify message intent and draft routine responses from one approved source. Deterministic logic would match the account and route the case. A person would approve complaints, pricing, unusual commitments, and account changes. Low-confidence or missing-source cases would move to an owned queue. The Pilot Contract would measure first-pass acceptance, corrections, response time, exception burden, and customer-impacting errors against the current path.

The business may now be ready for draft assistance on routine messages, but not autonomous customer communication. That narrower conclusion is the purpose of readiness work.

When not to run an AI pilot

Do not proceed merely because a vendor can demonstrate the feature. Pause when:

• the team is still deciding which workflow matters;
• the proposed task has no measurable business result;
• trusted data cannot be identified, matched, or used safely;
• policies and decision rights conflict;
• the work is too rare to test or operate responsibly;
• most cases require empathy, negotiation, or tacit judgment;
• reviewers cannot intercept consequential errors;
• there is no manual fallback, rollback, or incident owner;
• the ongoing review and maintenance burden would exceed the expected value; or
• a native feature or deterministic rule solves the actual problem with less risk.

You can still improve the workflow. Clarify the boundary, fix data, define authority, remove unnecessary steps, and establish a reliable source of truth. AI readiness often begins with non-AI work.

Frequently asked questions

What are the five pillars of AI readiness?

There is no single universal five-pillar standard. Many frameworks group readiness into strategy, data, technology, people, and governance. For an actual workflow decision, those categories are too broad on their own. This checklist uses seven gates so the result, baseline, process, data, AI task, control/recovery, and operating owner can each stop or reshape a pilot.

How do you measure AI readiness?

Measure readiness against evidence for one workflow, not a company-wide percentage. Confirm that red-line conditions are resolved, then record the baseline, data authority, test set, acceptance criteria, review triggers, stop conditions, recovery path, and accountable owner. The output should be a decision and a Pilot Contract, not just a score.

Does a small business need perfect data before using AI?

No. It needs data that is authoritative and representative enough for the bounded task, plus a way to detect missing, stale, contradictory, or incorrectly matched information. A narrow pilot can reveal data problems, but it should not expose unauthorized data or take consequential action based on unverified records.

What is the difference between AI readiness and an AI opportunity assessment?

An AI opportunity assessment compares workflows and decides which business problem is worth pursuing first. An AI readiness checklist begins after one candidate has been selected and tests whether its process, data, task, controls, recovery, ownership, and value path can support a bounded pilot.

How long does an AI readiness assessment take?

There is no responsible universal duration. A narrow workflow with clear evidence, one source system, stable rules, and low-consequence outputs may be reviewed quickly. A workflow involving sensitive data, several systems, disputed policy, external obligations, or high-impact decisions needs deeper specialist and stakeholder work.

Can AI readiness be improved without buying software?

Yes. Clarifying the completed result, removing duplicate work, assigning ownership, standardizing data, documenting exceptions, and designing review and recovery can improve readiness before a tool is chosen. Those changes also make it easier to decide that AI is unnecessary.

Submit one workflow, not your whole business

Choose one proposed workflow and write down its trigger, completed result, current tools, source data, common exceptions, proposed AI task, and the result you want to change. That is enough for an initial readiness conversation; it is not enough to certify an entire organization.

KelenAI’s free workflow consultation request starts with that short submission. We review the context first and follow up if a focused 30-minute conversation can help clarify the readiness gap, the safest pilot boundary, or a more practical non-AI next step. You can also review KelenAI’s workflow examples and implementation services to see how information, decisions, systems, exceptions, and human responsibility fit together.