Business AI readiness starts with a defined task and a way to recognise a correct result. Choose one job, identify approved information sources and decide who reviews the output. If the correct answer is unclear inside the business, fix that information gap before automating the task.
Choose one task first
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.
Prepare the information sources
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.
Decide what AI can do without approval
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.
Check readiness before the pilot
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. |
Build realistic pilot questions
Illustrative pilot: an assistant drafts customer replies from approved support documents. Do not test only easy questions. Include a current policy question, one contradicted by an old document, a request with missing details and a question the sources cannot answer.
Write an acceptable answer and its source before running each test. Finding the right information is only part of the task: the assistant also needs to acknowledge missing information and hand off where required. The team can review all drafts during the initial pilot.
| Test case | Expected behaviour | If it fails |
|---|---|---|
| Answer exists in an approved document | Uses the correct information and source. | Review source selection. |
| Two documents disagree | Uses the current version or flags the conflict. | Remove obsolete versions. |
| Important details are missing | Asks a relevant follow-up question. | Improve the input and question flow. |
| The sources contain no answer | Acknowledges the gap and routes the request. | Fix out-of-scope behaviour. |
Compare the whole job, not just speed
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?