Your team spends hours answering the same questions, sorting incoming requests or copying information between systems. An AI demonstration makes the work look simple. But before you pay for a build, you need to know whether the tool can use your information, fit your process and fail in a way your team can handle.
Use this AI readiness checklist to assess one business task before choosing a development partner. It is written for owners and operations managers: you do not need to select a model or design an architecture. You do need evidence for what the work involves and what a useful result would look like.
What does AI readiness mean for a small business?
AI readiness means having a defined task, usable and authorized information, people responsible for the result, and a practical way to test the proposed system. It is specific to the task. A business may be ready for an internal draft-writing assistant while being unready for an agent that changes customer orders.
The NIST AI Risk Management Framework describes voluntary risk-management work across governance, context, measurement and ongoing management. The checklist below is our practical planning aid, not a NIST assessment or certification.
Complete it with the person who does the work, the person who owns the process and whoever controls access to the relevant information. For each answer, record yes, partly or no, along with an example, a gap owner and a next action.
1. Can you define one task and the result you need?
Replace “we need AI in customer service” with a task such as “draft replies to delivery-status questions using approved order information.” Write down what starts the task, what information is available, who receives the output and what counts as complete. Also list what the tool must not do.
Evidence to bring: a short process map and several recent examples, including an awkward exception. If two staff members describe different processes, investigate why before choosing one version. The difference may reflect a legitimate customer or operational need.
2. Is there a measurable reason to improve this task?
Record the volume of work, the time it takes and the cost of errors or delays. A daily task does not automatically justify custom software; a rare but expensive task can still be worth improving. Compare the likely benefit with setup, integration, review, support and usage costs.
Evidence to bring: a baseline from a representative period and one primary success measure, such as total handling time including review, or fewer incomplete requests. Avoid measuring only how quickly the AI produces a draft.
3. Does the task need AI, ordinary automation or a simpler fix?
Rules-based work may need a form, an integration or a workflow change. AI may help when the task involves interpreting varied language, retrieving information or preparing drafts. Even then, compare the proposed approach with a simpler alternative before commissioning a custom build.
For a comparison of rule-based approaches, read our guide to workflow automation. Ask a partner to explain why AI adds value to this particular task.
4. Can you locate current, relevant source information?
List the systems and documents the tool would need: approved policies, product records, tickets, emails or transaction data. Identify the source of truth when two records disagree. Check ownership, revision dates, missing fields and common exceptions rather than assuming a large data folder is ready to use.
Evidence to bring: a small, permitted sample with the correct expected answers. Include normal cases, incomplete requests, conflicting records and questions that should receive no answer. Keep some examples aside for testing rather than using all of them to configure the system.
5. Are access, sharing and retention decisions clear?
Being able to export a file is not the same as having permission to share it with an AI provider. Identify sensitive fields, who may access them, where processing would happen and how long copies and logs would remain. Establish whether inputs may be reused for training and how deletion requests would be handled.
Evidence to bring: a documented approval path and a minimal sample that is safe to use. Start discovery with synthetic or appropriately redacted examples when access is unresolved. Ask your responsible data or security lead to approve the proposed handling before connecting live records.
6. Can the system fit into the actual workflow?
Check how information enters and leaves each business system. Is there an API, an approved export or a manual review step? Who controls access? Where would a draft appear, and how would someone correct it? Separate read access from permission to send messages or change records.
Evidence to bring: a list of systems, their owners and the actions a pilot would need. A demonstration using copied text does not establish that live integration will work. Ask for a technical discovery step when this is uncertain.
7. Is one person accountable, with time from the right reviewers?
Name a business owner who can resolve questions and accept or reject the result. Identify the staff who will test it and the specialists needed for access, risk or purchasing decisions. Shared input is useful, but someone must be accountable for closing decisions.
Evidence to bring: named roles, a review schedule and an escalation contact. Protect time for testing and feedback. If nobody can check the output during the pilot, the project is not ready for live use.
8. Is the budget based on the full operating cost?
Plan for discovery, data preparation, integration, evaluation, training and ongoing operation. Ask how usage is charged, what happens if volume grows and who pays for correcting failures. Include the time staff spend reviewing drafts and maintaining source documents.
Evidence to bring: an approved discovery or pilot budget, a spending limit and a decision date. Request a cost range with explicit assumptions instead of treating an early fixed quote as proof that every dependency is understood.
9. Have you defined unacceptable errors and human approval?
List realistic failures: an invented policy, a wrong customer record, a missed exception or a message sent to the wrong person. A meeting summary can also cause harm if it invents a commitment, so assess consequences in context rather than labeling whole categories of output harmless.
Evidence to bring: actions that require approval, a named person who can intervene and a way to stop the system. During an initial pilot, draft-only or read-only operation may be appropriate. Do not rely only on the model saying it is confident or asking for help.
10. Can you test success, monitor failures and stop the pilot?
Agree acceptance criteria before building. Compare the system against current practice on representative examples, including difficult cases and requests outside its scope. Record incorrect answers, omitted information, reviewer changes, time spent and total cost.
Evidence to bring: a test set, documented pass criteria, a person who reviews failures and a fallback process. A successful demo is not permission to roll out broadly. Decide who can authorize a limited launch and what would trigger rollback.
How to score your AI readiness checklist
Give each answer 1 point for yes, 0.5 for partly and 0 for no. Only award yes when you can show the evidence described above. The total is a discussion aid, not a validated maturity score or a prediction of return on investment.
8–10: Consider a tightly scoped pilot once the critical conditions below are met. The score does not authorize production use.
5–7.5: Plan discovery first. Assign owners to the missing evidence before agreeing to a full build.
Below 5: Clarify the task and gather evidence. You can still seek advice, but committing to implementation now would leave major assumptions unresolved.
Critical conditions override the total. Do not start a live-data pilot without approved data access, accountable ownership, appropriate review and a way to test and stop it. A high total cannot compensate for a missing safeguard. Synthetic-data discovery can help resolve gaps without exposing live records.
Example: assessing an AI assistant for customer inquiries
Illustrative scenario: a distributor wants AI to draft answers to routine delivery questions. Staff currently read each email, check the order system and write a response. The proposed pilot prepares drafts only; a staff member checks and sends them.
The team can show the task, baseline, sample questions and source documents. It has a budget and a business owner. But access approval is unresolved, and the test set does not yet include cancelled orders or conflicting delivery dates. Even if the other answers score well, those gaps need attention before live customer records are connected.
The next step is specific: approve the permitted fields, add the missing exceptions to the test set and measure review time as part of the pilot. That gives the vendor a usable brief and gives the business a basis for deciding whether to continue.
Related reading: Data Readiness for AI: A Practical Checklist for Your Business · Free AI readiness audit
What to give an AI development partner
Task and boundaries: the trigger, expected output, intended users and actions excluded from the pilot.
Evidence: permitted source samples, current process steps, known exceptions and the baseline measure.
People: the business owner, reviewers, system owners and approval contacts.
Acceptance and cost: pass criteria, the budget range, review time and expected operating volume.
Controls and exit: required approvals, logging, fallback, data return or deletion, documentation and ownership terms.
Ask the partner to distinguish what they have verified from what still needs discovery. Request a demonstration using your approved examples, including a case the system should decline or escalate. Agree what will be delivered at the end of discovery even if you decide not to build.
Explore our AI automation services to discuss the task, source information and review process before selecting a solution.
Ready to review your answers? Contact iTechnoSol with your process outline and the gaps you found. Start with a decision about the smallest useful pilot, then decide whether a larger build is justified.
