An organisation is not ready for AI because it has access to a model. It is ready when it can define a useful task, supply trustworthy context, manage uncertainty and learn from real use.
Tool access is not readiness
AI can produce an impressive answer in seconds and still be unusable inside an organisation. A demonstration happens in a clean moment. Operational value has to survive incomplete information, unusual cases, permissions, handoffs, review and accountability.
That is why an AI strategy built as a list of tools ages quickly. Models change. Prices change. Capabilities converge. The durable work is identifying where probabilistic assistance belongs in the operating system and what must surround it for people to trust the result.
Readiness has six layers
A useful assessment tests more than data availability. It looks at whether the problem is defined, whether the workflow is stable enough to intervene in, whether outputs can be reviewed and whether somebody has the authority to change the process after the pilot.
- Problem — a specific task or decision with a meaningful current cost.
- Information — accessible, relevant context with known gaps and ownership.
- Workflow — a place for the output to enter, be reviewed and affect action.
- Risk — clear limits on what the system may do and when a person must intervene.
- Ownership — a team responsible for adoption, correction and continued improvement.
- Economics — a credible comparison between the present process and the complete cost of the new one.
Choose a first use case that can teach you something
A strong first use case is frequent enough to generate evidence, bounded enough to control and legible enough for a person to judge. It reduces effort without transferring an unacceptable decision to the model.
Examples often live in preparation rather than final authority: finding information, classifying material, drafting a first version, checking consistency, summarising a known corpus or routing work for review.
A weak first use case carries high consequence, ambiguous truth and no reliable feedback loop. If the team cannot agree what a good output looks like, the model cannot solve that disagreement for them.
Design the pilot as an operating test
Measure the current process before introducing the model. Narrow the task. Decide what information the system may use, what it must record and who reviews the result. Run the old and new approaches closely enough to compare quality, effort and failure patterns.
Treat corrections as product data. They reveal missing context, unclear rules and the edge cases the workflow must learn to manage. At the end of the pilot, decide whether to expand, redesign or stop. Stopping a weak use case is a successful result if it prevents a larger mistake.
- Establish a baseline before the pilot begins.
- Keep the task narrow and the review path explicit.
- Log corrections, exceptions and reasons for rejection.
- Compare the whole workflow, not just model output speed.
- Expand only when the evidence supports a wider role.