AI readiness is an operations question
Most operators evaluating AI are not skeptical of the technology. They are skeptical of the pitch. The pitch shows a demo on clean data. The pitch does not mention the tribal knowledge holding the process together, or the person who copies data between three tools every morning. Readiness is not a technology question. It is an operations question — and the inspection list is shorter than the vendor deck makes it sound.
#Why every stalled AI story is an operations story
Walk into ten companies that tried AI in the last two years and you will hear the same failure wearing three different costumes.
Someone bought a tool. It demoed beautifully. Six months in, three people use it, two stopped after a week, and the rest never logged in. The vendor blames adoption. The team blames the tool. Both are pointing at the surface.
Someone built a pilot. A real use case, a champion who cared, output that looked good in the review meeting. Then the pilot needed to scale. The workflow underneath had undocumented exceptions, four ways to handle the same case, and one person whose memory was the only source of truth. The pilot did not scale. It did not fail because the model was weak. It failed because the operation underneath was never ready to carry it.
Someone has ChatGPT open on three monitors and uses it as a personal productivity tool. It is useful. It is also invisible to the rest of the business. Nothing about how the company runs has changed.
All three stories share a root cause. The model is fine. In every case, the model is better than the workflow it was asked to plug into. The failure is upstream — in the data the AI needed and could not reach, in the process that varies too much to describe, in the absence of a person whose job it is to make the thing work, in the tools that do not exchange information without a human copying and pasting, in the decision the AI was supposed to improve that turns out not to be a real decision anyone was making.
Almost every "AI did not work for us" story is, on inspection, an operations story wearing AI clothes. The operation was not ready. The AI made that visible faster than usual.
#The Readiness Stack
The framework for evaluating readiness is five layers. Each layer depends on the ones below it. You cannot put a roof on without a foundation, and you cannot activate AI on top of a broken operation.
The five layers split into two tiers. The first three are foundation work — they have to exist before anything else holds weight. The last two are activation — they only matter once the foundation is solid.
Foundation tier
Layer 1 — Data. Does the information AI would need actually exist, somewhere a system can reach? Not in someone's head, not in an email thread, not in a folder on a laptop. Reachable.
Layer 2 — Process. Is the work consistent enough that you could describe the right answer to a smart outsider? Or is every case its own case?
Layer 3 — People. Is there one named person with authority to change how this workflow runs? Not a committee, not a vague collective. One person.
Activation tier
Layer 4 — Tools. Can the systems involved exchange information without a human copying and pasting?
Layer 5 — Decision. Is there a real business decision this AI is supposed to improve? Something that will be made differently because of what it produces?
The layers are ordered for a reason. If the data is not reachable, better tools will not help. If no one owns the workflow, no rollout will stick. If the AI output does not change a decision anyone makes, you have built theater — expensive, impressive, and irrelevant to how the business runs.
#What "ready enough" looks like in practice
Readiness is not a binary. You do not need perfection across all five layers before you start. You need honesty about which layer breaks first — and the discipline to fix that layer before you stack more on top.
Take support ticket triage at a fifty-person company. The AI pitch assumes the ticket text, CRM history, and billing status are all reachable. In practice, billing context lives in a export someone runs on Tuesdays, and the real routing rules live in the team lead's head. That is Layer 1 and Layer 2 breaking before Layer 4 gets a chance.
Most workflows fail at Layer 1, 2, or 3. Companies that skip straight to tool evaluation and model selection are starting at the roof.
Three tests you can run this week without a consultant:
Can you produce a CSV, JSON file, or API response with the relevant fields for any record in under five minutes, without asking a person? If no, the work is Data — not a better model.
Could a new hire follow written rules and get the right answer without asking someone? If exceptions live in memory instead of documentation, you have a habit, not a workflow. AI built on a habit exposes inconsistency with confidence.
Name the person — by name, not by title — who would decide the AI version stays or goes after ninety days. If you cannot name them, the rollout has no place to land.
| Layer | Honest test | If it fails |
|---|---|---|
| Data | Export relevant fields in under five minutes, no human | Fix reachability before buying tools |
| Process | New hire follows written rules without asking | Document exceptions, not memory |
| People | Name who keeps or kills the AI version at day ninety | Assign one owner with authority |
| Tools | Systems exchange data without copy-paste | Map and replace copy-paste steps |
| Decision | Someone's behavior changes because of the output | Name the decision or drop the use case |
For a full walkthrough of each broken layer — stall patterns, fixes, and a concrete invoice example — see fix the lowest broken layer first.
#Why this is good news for operators
If the bottleneck were the model, you would be waiting for someone else to ship a better one. That is a passive position.
If the bottleneck is your operation, you can do something about it. And the work is valuable even if you decide AI is not yet the right move. Documented processes, reachable data, named owners, real decision points — these make the company run better with or without AI.
The goal is not to convince you to adopt AI. The goal is to give you a way to look at your operation that tells you, honestly, where you are and what to fix first. AI works as a side effect of that operational work — not the other way around.
This is also why tool-first AI strategies stall. A new platform does not fix data trapped in inboxes. A copilot license does not create process documentation. An agent framework does not name an owner. Tools belong at Layer 4. They activate what the foundation already supports.
For a deeper walkthrough of each layer — including scorecard exercises and the smell of a layer that is not ready — see the Ready Enough field guide. The guide is designed to be used at your desk, not just read once.
#How readiness pairs with production AI
Readiness and production AI are not sequential projects with a handoff between them. They are the same project viewed from two angles.
From the readiness angle, you are asking: does the operation underneath support automation? From the production angle, you are asking: once the model runs, what system carries the result to a real decision?
The companies that get this right do readiness work and AI work in the same engagement. They do not close a six-month "digital transformation" phase and then start building agents. They pick one workflow, score it against the five layers, fix the lowest broken layer, and ship operational AI on top once that layer holds.
That pairing is what separates a pilot that dies quietly from a workflow that survives its first production failure. The production patterns — queued jobs, explicit state, audit logs, reviewer consoles — only work if the foundation underneath is solid. A reviewer console with no named owner is an empty screen. An audit log with no reachable data is a record of nonsense.
If you are stuck in pilot purgatory — pilots that work in demos but never scale — the problem is almost always a broken foundation layer, not a model limitation. Fix the lowest broken layer first before you fund the next pilot.
#Start with one painful workflow
Do not score the whole company. Take the job someone complained about in last week's leadership meeting — onboarding, close, escalations, whatever actually costs hours — and run the three tests above on it.
If two or more fail, you have your answer before you fund another pilot. Name the broken layer out loud with the person who runs the workflow, not the person who approved the software budget.
For a structured scorecard across all five layers, use the Ready Enough assessment. The discipline of scoring one real workflow honestly matters more than the format.
#When readiness is clear but decisions still stall
Sometimes the data is reachable, the owner is named, and the tools connect — but pilots still produce confident output on fuzzy criteria. That is a thinking-readiness gap, not a Layer 1 failure. The Expert in the Loop series walks the complementary work: visible criteria, accountable experts at control points, and workflow design that separates generate from decide before you add speed.