AI Readiness
Last updated
AI readiness is whether the underlying work is in a state where automating it will help. A process that is broken, undocumented, or highly variable does not improve when AI is applied to it, it gets faster at being broken.
What AI Readiness actually means
The usual readiness checklist is about infrastructure and governance: data access, model selection, security review, policy sign-off. Those are prerequisites for deploying safely. They say nothing about whether the thing being automated is worth automating in its current state, which is the question that decides whether the deployment produces a return.
Automating a broken workflow scales the breakage. If a process has forty variants, automation either encodes one of them and creates exceptions for the other thirty-nine, or it encodes the variance and becomes unmaintainable. If a step exists because an earlier step produces bad data, automating the step makes the bad data arrive faster. The automation performs exactly as specified and the outcome gets worse.
Genuine readiness has three components. Visibility, meaning a current and accurate picture of how the process actually runs rather than how it is documented. Enough standardization that there is a single process to automate rather than a family of them. And a captured baseline, so that after deployment the effect can be distinguished from the noise.
The order matters and it is frequently reversed. Programs that deploy first and investigate afterwards tend to discover the variance during rollout, when the cost of finding it is highest and the political cost of pausing is highest too. Establishing readiness first delays the first deployment and shortens everything after it.
Examples
Automating a process with forty variants
An approval workflow is automated against the documented path. Because thirty-nine other paths are in active use, most real cases route to an exception queue, and the exception queue becomes larger than the original manual workload.
Faster delivery of bad data
A validation step exists because an upstream system produces unreliable records. Automating the validation increases throughput of records that still need correcting later, moving the bottleneck rather than removing it.
Ready, and provably so
Before deployment a team records the current handling time, exception rate, and variant count for the target process. The automation ships against a known standard path, and the post-deployment comparison is a measurement rather than an argument.
Frequently asked questions
Related terms
Baseline
A baseline is the measured record of how a process ran before anything was changed, used as the reference point for whether a deployment improved it. A baseline that stops updating stops being a reference point.
Process Drift
Process drift is the gradual divergence between how a process is documented and how it is actually performed. It is why documentation goes stale almost immediately, and it is only visible against a baseline that keeps updating.
Unstructured Work
Unstructured work is the execution that happens outside the systems that log it: ad-hoc work in spreadsheets and email, project work that is not a linear process, exceptions handled manually, and legacy applications with no modern logs.
