The Levels of AI Readiness

Every week brings another possibility. One employee uses AI for nearly everything; another tried it once, got a poor answer, and went back to their previous routine. Leaders encourage experimentation, but people are unsure which problems deserve their time.

This is a useful learning phase. Problems arise when the organization treats the volume of experimentation as evidence that the business is improving, or expects employees to learn entirely on their own.

Evidence at this level is often personal and incomplete. A person can demonstrate the tool, but the team cannot yet explain the result against a baseline. The same work may be measured differently by different employees. Costs such as checking, setup, and rework may be invisible.

The missing evidence is more important than the label. If you have never inspected the workflow, mark it as unassessed. Lack of information does not establish that a team is inexperienced.

Start with the business outcome. Where is work getting delayed, becoming expensive, or failing to meet a useful standard? Trace the process far enough to see the constraint. An AI tool that accelerates an upstream task may simply create a larger queue at the next step.

Be especially careful when capacity is not the constraint. If a business needs more customers, producing the same work faster may have limited value unless the change reduces cost, improves quality, or frees people to help generate demand. “We saved time” leaves an important question unanswered: What did that enable?

Then inspect the immediate barrier. If people cannot use the tools well, arrange supported practice on their real work. Give them access, examples, time, and someone to ask for help. If they can already use the tools but are choosing low-value problems, another introductory workshop will not resolve the priority question.

There is something real to point to. The work moves more quickly, mistakes decrease, or people can do something useful that was previously impractical. Others want access.

But the questions keep returning to the same person. Which documents should I upload? Which prompt did you use? Why did this answer change? Is this version of the spreadsheet current?

The builder often absorbs these questions without recording how much work they create. From a distance, the workflow looks ready to scale. Up close, one person is holding several pieces together.

You should be able to identify the workflow, its baseline, the useful change, the quality conditions, and the person accountable for the result. You should also be able to explain the boundaries: which inputs and cases the evidence covers, and which it does not.

Then inspect the dependencies. How much interpretation, troubleshooting, and undocumented correction does the original builder supply? Can another person tell when the output is wrong? What happens to the output at the next handoff?

Sharing a prompt is a start. A useful handoff also explains the purpose of the work, the required inputs, the authoritative sources, the steps people and systems perform, the quality checks, and the exceptions that need help.

This is where context becomes an operating problem. People may be using different copies of a policy, different definitions of an active customer, or different assumptions about who can approve a refund. Putting those documents in one folder does not resolve the disagreement.

Establish the relevant source of truth. State who maintains it, which definition applies, who can read it, and who may change it. Keep the scope practical: fix the context this workflow needs before attempting to reorganize all company knowledge.

Access also needs a boundary. An assistant may be allowed to retrieve a customer's history without being authorized to change the customer's contract. Make the approval explicit in the workflow.

The AI workflow is part of how people get work done. A new colleague can learn it. Other teams ask whether they can use a similar approach. More requests come in for integrations, improvements, and additional use cases.

The risk shifts. A pilot can quietly stop working with few consequences. A workflow that several people depend on can create confusion and delays when it fails.

Meanwhile, useful work accumulates. Nobody intended to create a software estate, but the team now has assistants, automations, data connections, and shared instructions. Each has something that can become outdated.

Look for evidence of a real handoff, with comparable quality and a useful outcome. A training session or a shared template alone does not demonstrate repeatability. Someone else needs to have done the work.

For the next boundary, inspect what happens when conditions change. Who notices a stale source? Who receives an error? Who decides whether an answer can be used? Who can pause the workflow? How does the team continue when the system is unavailable?

Assign responsibility for the business result and responsibility for keeping the system working. In a small team, one person may do both. In a larger business, they may sit in different functions. An implementation partner may provide technical maintenance. The important point is that everyone can identify the owner and understand what the owner is expected to do.

Make room for the work. A person cannot reliably maintain several business-critical automations as an invisible addition to an already full job. Specify the expected support, review, and maintenance effort, and include it in the economics.

Set a review rhythm that matches how quickly the workflow's conditions change and what failure would cost. Identify events that require an immediate check: a policy revision, a data change, a new model or integration, or a change in who has access.

Shared foundations can help here. A maintained knowledge source, common definitions, and consistent access rules can make several workflows easier to operate. Build those foundations around observed needs. A large platform project is hard to justify when the immediate problem is one ambiguous handoff.

AI becomes less dependent on a few exceptional enthusiasts. People have a way to suggest improvements and a way to evaluate them. They can tell the difference between a promising experiment and a workflow ready for wider use.

There is also more willingness to stop. A workflow can be retired because the business changed, a simpler approach became available, or its maintenance burden outgrew its benefit. Nobody needs to defend it merely because the team spent time building it.

Leaders can discuss AI investments in terms of the business: better service, lower cost, more useful capacity, faster learning, or new demand. They can also explain what remains uncertain.

Look for a record of useful operation, actual changes handled, known exceptions resolved, and continuing review of results and costs. Look for a working arrangement that survives an ordinary handoff or absence.

Keep the claim proportional to the evidence. One well-maintained support workflow demonstrates something about that workflow. Describing the support function requires evidence across the consequential work in that function. Describing the whole organization requires broader evidence again.

There is no permanent graduation. A reorganization, a departure, or a major system change can weaken the conditions that made the work dependable. The level describes what the team can demonstrate now.

Review the portfolio, not just individual systems. Several workflows can each be useful while collectively creating duplicated work, conflicting definitions, or too much support overhead. A new tool can be attractive without deserving another place in the stack.

Make learning reusable. When a test changes the team's understanding of a process, preserve the conclusion where other people can find and maintain it. A useful answer left in one person's chat history does little for the next person who faces the same decision.

This is a deeper form of organizational learning: the business gets better at doing the work, and that improvement survives beyond the person who discovered it. Shared context matters because it lets people build on one another's work. Its value depends on being current, understandable, accessible to the right people, and connected to clear responsibilities.