AI readiness is local to the workflow

An enterprise can have an AI strategy, approved platforms, a governance committee and hundreds of trained employees—and still be unready to deploy an agent in a particular workflow. Another team in the same enterprise may be ready to use a bounded agent today.

The difference is local. Readiness depends on the data, decisions, systems, authority, people and consequences of the work being changed. An organization-wide score can guide shared investment, but it cannot answer the release question.

NIST makes context central to AI risk management: intended purpose, users, setting, skills, costs, benefits, oversight and risk tolerance should be mapped for the application (AI RMF Core). Treat readiness in the same way. Assess a defined workflow against the operating mode being proposed.

Define the readiness envelope

A readiness envelope states the conditions under which a workflow can operate acceptably. It is not a permanent declaration that the organisation is “AI ready.” It has boundaries:

• the cases and users included;
• the systems and data available;
• the actions the agent may take;
• the people responsible for review and operation;
• the controls and monitoring in force;
• the environment in which evidence was collected; and
• the assumptions that would invalidate the conclusion.

For example, a support workflow may be ready for an agent to retrieve account history and draft a resolution for review. It may not be ready for the agent to issue credits, modify entitlements or communicate final decisions. The same model and interface sit inside different readiness envelopes because the authority and consequence changed.

Assess seven dimensions at workflow level

Use seven dimensions and record evidence, gaps and the operating consequence of each gap.

Dimension	Readiness question	Useful evidence
Outcome	Is the intended result observable and worth pursuing?	baseline, outcome measure, benefit hypothesis
Process	Are normal paths, exceptions and handoffs understood?	workflow map, case sample, exception catalogue
Data	Are required inputs available, permitted, timely and fit?	provenance, quality checks, access tests
Authority	Can permissions, approvals and prohibitions be enforced?	authority map, policy tests, credential scopes
Technology	Can integrations, state and recovery support the workflow?	architecture, sandbox tests, failure exercises
People	Can users, reviewers and operators perform their changed roles?	role design, usability evidence, exercises
Assurance	Can performance, impacts and incidents be measured and managed?	evaluation plan, telemetry, incident route

Avoid averaging these into one reassuring percentage. A workflow with strong data and weak authority is not “mostly ready” for external action. A critical dependency sets the ceiling for that operating mode.

Distinguish enterprise foundations from local proof

Shared foundations matter. Identity services, approved model gateways, data platforms, procurement terms, security patterns and evaluation tooling can reduce duplicated work. They are enabling capabilities, not proof of workflow readiness.

For each enterprise control, ask how it applies locally. An approved model does not prove that retrieval sources are current. A central logging platform does not prove that a business outcome can be reconstructed. A generic human-oversight policy does not establish that the reviewer has enough time, evidence or authority in this process.

The GAO AI accountability framework organizes practices around governance, data, performance and monitoring. Those enterprise themes become concrete only when a team can show who governs this workflow, which data it uses, what acceptable performance means and how live behaviour will be monitored.

Test the joins between dimensions

Failures often occur at the joins rather than within one capability. Data may be accurate but arrive after the decision. An authorisation service may work, but the workflow may not preserve the delegating principal. A reviewer may be trained, but the interface may hide the evidence needed to challenge the agent.

Test scenarios that cross dimensions:

• an input changes after the agent creates a recommendation;
• a reviewer’s approval expires before an action is dispatched;
• an integration commits an external change but loses the response;
• a high-volume period compresses review time;
• a policy update makes earlier examples invalid;
• a user rejects the agent’s proposed path; or
• an operator must disable one tool without stopping the whole service.

These exercises reveal whether the readiness envelope is an operating system or a collection of documents.

Match readiness to the proposed authority

Readiness is not binary. Define graduated operating modes:

1. Observe: run on historical or shadow cases without influencing work.
2. Assist: produce information or drafts for a person who performs the task.
3. Recommend: propose a decision with evidence and confidence for approval.
4. Act within limits: execute permitted low-consequence actions with monitoring.
5. Coordinate: choose and sequence multiple actions inside explicit budgets and gates.

Evidence for one mode does not automatically justify the next. Moving from recommendation to action changes required identity, authorisation, recovery, incident handling and outcome verification. Treat it as a new decision, not a feature toggle.

The GAO technology-readiness guide describes readiness assessment as a systematic, evidence-based examination of maturity in relation to integration and program objectives (GAO). The same principle prevents a model-level demonstration from being mistaken for an operational conclusion.

Make workforce readiness role-specific

“AI literacy” is too broad to establish operational readiness. The OECD’s work on an AI-ready public workforce distinguishes needs across leaders, general employees and digital or data specialists. A workflow assessment should go further and define proficiency by role.

The initiator may need to know what information the agent requires. The reviewer needs to detect unsupported reasoning and understand the decision boundary. Operations needs to reconcile state and handle incidents. The product owner needs to interpret performance and decide whether to narrow, improve or stop. Executives need to own risk decisions rather than delegate accountability to the technical team.

Test proficiency through realistic work. Completion of general training is evidence of exposure, not evidence that someone can safely handle an ambiguous case.

Convert gaps into bounded choices

A readiness finding should lead to one of four choices:

• proceed within the tested envelope;
• reduce scope, data, action or authority to fit current controls;
• improve a named capability and retest it; or
• stop because the value does not justify closing the gap.

Suppose supplier data is inconsistent, reviewer capacity is limited and authorisation cannot distinguish recommendation from commitment. The response is not “readiness: 62%.” A useful response is: keep the experiment read-only, restrict it to preparing evidence packs, repair supplier master data, implement an approval-bound action token, and retest reviewer workload before considering external action.

Maintain readiness after launch

The envelope changes. Models, suppliers, policies, data, user behaviour and connected systems evolve. Monitor leading indicators such as missing inputs, overrides, escalations, permission denials, stale-source detection, review time and unresolved incidents alongside outcome measures.

Trigger reassessment when the team adds a tool, widens the user group, changes a model, introduces new data, increases authority or sees performance move outside its validated range. The Service Standard emphasizes responsibility for the whole user problem and joined-up journey; local readiness must therefore include upstream and downstream dependencies, not merely the AI component.

Enterprise readiness is a portfolio concern. Workflow readiness is a deployment decision. Keeping the two distinct lets central teams build reusable foundations while holding each operating workflow to evidence that matches its actual authority and consequence.