Assess AI readiness through the task, data, ownership and evaluation approach. Use decision gates to choose a practical first pilot for your business.
The number of AI tools your company uses does not tell you whether it is ready for an AI project. A more useful question is whether you can define the work to improve, the information the system will use and how you will judge its output. Your business may be ready for one use case and unprepared for another. Assess a specific workflow rather than giving the whole organisation a single readiness score.
1. Choose a job to improve before choosing a tool
Replace “introduce AI into the business” with a repeatable task. Examples include routing incoming enquiries, drafting answers from approved documents or turning meeting notes into follow-up actions. Describe who does the work, which information they use and how often it occurs. Speed, consistency, access to information and workload are different problems; they should not automatically lead to the same solution.
Consider whether a simpler change would resolve the issue. Improving a form or introducing a clear routing rule may be enough. If you can explain where AI adds value, you can define a more useful scope. For a first project, favour a task with an inspectable output, a named owner and a result the business can check.
2. Establish the source, owner and boundaries of the information
A folder full of documents is not necessarily a prepared knowledge base. Check whether the material is current, whether documents contradict one another and who approves changes. Prices, product specifications and operating policies need a source of truth and an update owner. Passing a question to a system does not resolve uncertainty that already exists inside the business.
Identify which information can be used and which people should be able to access it. Customer records, internal documents and public content may need different boundaries. Evaluate the selected provider's handling of data, access controls and retention settings against its actual documentation and commercial terms with the responsible people. Make those decisions before introducing the data into the proposed workflow.
3. Separate suggestions, actions and human decisions
Drafting a reply and sending it to a customer require different authority. Classifying an enquiry is also different from setting a price. Define what the system may suggest, what it may execute and when a person must take over. Requiring approval at every trivial step can defeat the purpose; place review at the decisions that materially affect the outcome.
NIST's AI Risk Management Framework is a voluntary resource addressing trustworthiness in the development, use and evaluation of AI systems. The decision table here is a practical aid for selecting an initial business project, not a certification or compliance assessment.
Name both an operational and a technical owner. When an incorrect output appears, someone needs to investigate, someone needs to repair the information or workflow, and the team needs an existing way to continue the work if necessary. Without those arrangements, a polished demonstration can become an unsupported dependency in daily operations.
4. Use decision gates instead of an average score
Complete the table for one proposed task. Record evidence or a specific gap against each row: a sample input, an approved document, a named owner or an evaluation checklist. Do not let strength in one area hide a critical weakness in another. An impressive demonstration does not resolve unclear data use or an unowned process.
The outcome should be a decision to start a narrow pilot, complete defined preparation first or choose another approach. If you defer the project, say what would make it ready for reconsideration. That might be resolving conflicting documents or assigning an operational owner. A readiness exercise should produce a next action, not leave the idea in indefinite discussion.
| Gate | Evidence needed for a pilot | If it is missing |
|---|---|---|
| Purpose | A bounded task and a documented current problem | Map the workflow with its users. |
| Information | Approved sources and an update owner | Remove contradictions and organise the sources. |
| Authority | Permitted actions, approvals and handover rules | Assign operational and technical ownership. |
| Evaluation | Representative examples and acceptance criteria | Prepare test cases and error categories. |
| Continuity | Monitoring, correction and an existing fallback process | Define responsibility for daily operation. |
5. Test difficult cases as well as convincing answers
Consider a hypothetical professional services team that wants help finding information in approved service documents. An initial internal pilot could draft answers for staff to review, with the underlying sources available for checking. Missing or conflicting information would be routed to the relevant owner. This describes a possible project design, not a reported client result.
Include incomplete requests, outdated material, out-of-scope questions and ambiguous language in the evaluation set. Fluent wording alone is not evidence of a correct answer. Check whether the output agrees with the source, avoids unsupported claims and hands over appropriately. Categorise the errors you find, then reuse the relevant examples after changes before extending the pilot's authority.
6. Evaluate the benefit alongside review and maintenance
A first draft may be faster to produce while requiring more time to inspect and repair. Assess the total effort, the usability of the result and the amount of repeat work. Include information updates, monitoring and support in the operating plan as well as usage charges. Otherwise, a pilot can appear efficient while moving unmeasured work onto another team.
At the review point, decide whether to continue, narrow the scope, rework it or stop. Use the same business problem and criteria that justified the pilot. A successful pilot does not have to lead immediately to a company-wide rollout. Expanding to one team or document group may be easier to evaluate. Revisit information access, authority and ownership whenever the scope changes.
- Are the current task and improvement objective documented?
- Do sources have owners, update rules and usage boundaries?
- Is there a person to handle requests outside the scope?
- Are representative evaluation examples ready?
- Can you measure the work required for review, upkeep and support?