AI Readiness and Operational Risk: The One Gap Most Companies Miss Before Going Live
- Maria Mor, CFE, MBA, PMP
- Jul 10
- 8 min read
The meeting had an agenda. Someone was there to share a framework, walk through what AI can do, and help the team figure out where it fits. The people in the room were paying close attention, because they were trying to answer one question: is my job safe?
That question tends to absorb all the oxygen in any AI conversation. It is understandable. According to McKinsey's 2025 workplace research, 35 percent of US employees cite workforce displacement as a concern about generative AI. One in three people in any given room is running that calculation quietly while the slides advance.
The Detail Nobody Flagged
But while everyone in the room was watching for job risk, a different and more immediate problem was sitting there unnoticed. And it had nothing to do with the technology.
In the meeting that prompted this post, one detail came up in passing. A single person handled all reporting for the leadership team. Everything the organization's leaders needed to see, understand, and act on ran through one person, described informally as a "chief of two."
That detail did not get flagged as a risk. It was mentioned as context for what the AI tool might help automate.
This is the pattern I observe across different industries, in organizations of all sizes. A critical function, usually something like reporting, billing reconciliation, close cycle oversight, or vendor management, lives entirely inside one person's knowledge and judgment. The organization has been running on that arrangement for long enough that it no longer looks like a risk. It just looks like how things work.
It is not how things work. It is how things are held together. And there is a significant difference between the two.
What Single-Person Dependency Actually Costs
Single-person dependency is an operational risk with or without AI. When one person holds the institutional knowledge, the judgment calls, and the exception-handling for a function the business depends on, that function is one absence away from stalling.
The financial consequences of this pattern are not always visible on a report, but they accumulate in consistent ways across organizations that carry it. The back office structure in these situations tends to produce observable signals:
Reporting cycles that only close correctly when a specific person is in the building, because the pull logic and exception adjustments live only in that person's process
Approval or escalation decisions that get held until one individual weighs in, because no one else carries the context to move them forward
Month-end close timelines that extend whenever coverage gaps occur, because the steps that depend on judgment are not transferable
Vendor or billing discrepancies that go unresolved during absences, because the relationship and reconciliation history live in one person's inbox
Onboarding of a replacement or backup that takes months rather than days, because the knowledge has never been embedded anywhere outside the person who holds it
Each of these signals looks manageable in isolation. Together they describe a function that is performing, but not in a way that is sustainable, auditable, or ready for anything to change.
The cash flow impact arrives quietly. Coverage gaps stretch timelines. Timelines affect close cycles. Close cycles affect decision-making. Decisions made on delayed data carry a dollar amount that rarely gets attached to the operational gap that caused them.
Where AI Readiness and Operational Risk Collide
The specific danger of ai readiness and operational risk appearing in the same conversation is that they tend to get addressed in the wrong order.
Most organizations assess readiness by asking what the AI tool can do, which processes it will touch, and what efficiency gains it is expected to deliver. Those are technology questions. The operational question, which processes are actually ready to be handed to a tool, sits underneath them and rarely gets asked with the same rigor.
Here is what that sequencing problem looks like in practice. An organization identifies the reporting function as an automation candidate. The timeline and efficiency case are clear. The AI tool gets scoped and selected. And then, during implementation, the project team discovers that the inputs feeding that reporting function are managed informally, that the exception handling involved is not documented anywhere, and that the one person who runs the function has never been asked to describe the full picture of what they actually do.
The tool gets trained on the version of the process that could be described quickly. That is not the same as the process that actually runs. The output looks correct. The judgment layer underneath it is missing. Six months later, the results are underwhelming and the diagnosis points at the vendor, the timeline, or the change management approach. The actual cause, a process that was never structurally ready to be handed to a tool, does not appear in any post-mortem.
This is what ai readiness and operational risk means in practice: not whether the technology is capable, but whether the operational structure underneath it can support what the technology needs to do its job.
What AI Cannot See Without You
There is a phrase worth holding onto: AI documents what you describe. It cannot see what you left out.
When the person who owns a reporting function sits down to describe their process to an implementation team, they describe what they know to describe. They capture the standard workflow. They walk through the steps in sequence. What they do not describe, often because they no longer think of it consciously, is the layer of judgment that sits underneath every step.
The adjustment they make every third month when the source data comes in with a known irregularity. The flag they send upstream when a vendor figure does not reconcile with the prior period. The informal check they run with a counterpart in another department before the numbers go to leadership. None of that enters the process map because none of it was ever written down, and the person doing it does not always recognize it as something the map should capture.
The institutional knowledge that lives in a single person's experience is not just the steps they take. It is the pattern recognition built from years of running the same process, watching where it breaks, and compensating for the gaps without ever naming them. That layer is what makes the function reliable. It is also what makes it completely non-transferable to a system that only knows what it was told.
When that knowledge does not get surfaced and embedded before an AI tool arrives, the tool inherits a dependency it cannot fill. The business process improvement work that produces durable results from any technology implementation begins here, before the tool is selected, with the structure the tool will need to run on.
Why This Gap Stays Hidden Until It Is Too Late
The leaders in that meeting were not being careless. They were trying to get ahead of something real. The framing around AI capabilities was accurate. The four-category framework was reasonable. Nothing about how the conversation was conducted was wrong.
What is hard to see from inside an organization is the distinction between a function that is performing and a function that is structurally sound. Those two things look identical from the inside when the person holding them is present and capable. The fragility only surfaces under pressure, and by the time the pressure arrives, the AI implementation is already underway.
This is not a failure of leadership judgment. It is a structural limitation of proximity. The institutional knowledge that accumulates in key people looks like operational strength from the inside. From the outside, it looks like the organization's most significant AI readiness gap.
An experienced outside perspective sees what proximity obscures. It sees the reporting function that depends on one person's pattern recognition and asks whether that pattern recognition can be described, transferred, and embedded before the automation layer is applied. It sees the gap between how the process is supposed to work and how it actually runs. It sees the risk that will not appear in any system audit but will show up in every implementation result.
Revenue comes from the front office. Profit is protected in the back office. The meeting that room was having was about the front office fear. The back office problem was sitting there the whole time, waiting for someone to name it.
Free Resource: AI Readiness Assessment
The most useful question before any AI initiative is not which tool to use. It is whether the operational structure underneath your processes is ready to support what the tool will need to do.
The AI Readiness Assessment is a free 7-minute diagnostic designed to show you where your business stands with AI, what is holding it back, and what to fix before investing in tools.
Frequently Asked Questions
What does ai readiness and operational risk mean for a growing business?
For a growing business, ai readiness and operational risk describes the gap between having a technology that is capable and having an operational structure that can support it. A business where critical functions are owned by individuals rather than embedded in repeatable systems carries operational risk before any AI tool enters the picture. The tool cannot resolve that risk. In most cases, it makes the risk visible faster, because the gaps that were manageable when one person was present become immediate problems when the tool tries to replicate what that person does.
What is single-person dependency and why does it matter for AI implementation?
Single-person dependency is the condition where a critical business function, such as reporting, billing reconciliation, close cycle management, or vendor oversight, relies on the knowledge, judgment, and pattern recognition of one individual rather than a documented, transferable process. It matters for AI implementation because the tool can only be trained on what can be described. The judgment layer that makes the function reliable, the adjustments, compensations, and informal checks the person has built over time, does not enter the system. The result is automation that performs correctly on the inputs it received, which were not the complete inputs the real process requires.
How is this different from the employee resistance problem in AI rollouts?
Employee resistance is a trust and communication problem that develops when people believe AI is being introduced to reduce headcount. Single-person dependency is a structural problem that exists before the AI conversation begins. Both can affect an implementation, but they have different causes and different solutions. Resistance is addressed through how the rollout is framed and managed. Dependency is addressed through operational structure work that surfaces and embeds institutional knowledge before the tool is scoped. This post addresses the structural problem. The trust dimension is a separate conversation.
How do you identify a single-person dependency before it affects an AI rollout?
The signals are consistent across industries and business sizes. A function has single-person dependency when the process only closes correctly when a specific person is present, when exceptions are managed through individual judgment rather than defined rules, when the steps that require context or pattern recognition cannot be described by anyone else on the team, and when onboarding a backup or replacement requires months rather than days. In practice, these functions are rarely identified proactively because they work when the person is present. The gap only becomes visible under pressure, which in an AI implementation typically arrives six months after the tool is deployed.
When should a business address operational structure before implementing AI?
Before tool selection, not after implementation struggles surface. Organizations that assess their operational structure before scoping an AI initiative, identifying where knowledge is concentrated in individuals, where exception handling is informal, and where the real process differs from the documented one, produce measurably more reliable implementation results than those that discover these gaps after deployment. The cost of addressing structural dependency before a tool arrives is a fraction of what it costs to retrofit the operational work after the tool has been running on an incomplete foundation.
Ready to Find Out Where Your Operations Actually Stand?
Most AI conversations start with what the tool can do. The more useful conversation starts with what the tool will run on.
If your organization is planning an AI initiative and has not yet assessed the operational structure underneath the processes you are planning to automate, that is exactly the right time for a diagnostic conversation.
The Back Office Brief
A weekly insight connecting back office operations to profit. For business owners running companies who want to stop leaving money in broken systems.
Comments