The New Key Person Risk: An AI Workflow Only One Employee Can Run

I have been thinking about a new kind of key person risk: the AI workflow that only one employee knows how to run. It rarely appears on an org chart or a continuity plan. It often begins as a useful personal experiment, becomes a repeated way of getting important work done, and turns into an operating dependency before the company realizes that anyone depends on it.

Two recent surveys show why this can happen so quietly. The Federal Reserve Bank of New York found that AI adoption had become widespread among businesses in its region, yet usage remained concentrated. Among companies using AI, the median share of workers using it was 17 percent at service firms and 7 percent at manufacturers. Eagle Hill Consulting found that 23 percent of senior leaders at larger organizations primarily rely on individual functions, teams, or employees to identify AI opportunities.

Those findings describe an environment where a small number of motivated employees can create a disproportionate amount of the company's practical AI capability. They learn which tool works, what context to provide, how to check the output, and where it should go next. Their workflows begin shaping decisions, customer deliverables, analysis, code, or internal operations. Then one of those employees changes roles, leaves the company, or simply goes on vacation. Can anyone else reproduce the work?

A workflow can become critical before it becomes official

Traditional key person risk is usually visible. A finance leader controls an important close process. An engineer is the only person who understands a fragile system. A salesperson owns a critical customer relationship. The company may not have solved the dependency, but leaders can usually name it.

AI workflows are easier to miss because they can live across ordinary tools. An employee may combine a paid chatbot, a personal prompt library, a spreadsheet, a browser extension, and a low-code automation. No single component looks critical. The dependency lives in the sequence: which source is trusted, which prompt supplies the context, which exceptions need human judgment, which output is safe to use, and which system receives the result.

The workflow may also be invisible in the systems leaders already review. Procurement can see the software subscription but not the process. Security can see an approved application but not the business decision it supports. A manager can see the final deliverable but not the steps that produced it. Finance can see a model invoice but not which recurring work depends on those tokens. Each group has a fragment, while the employee has the complete operating model in their head.

The hidden operating system in one person's head

The most important part of an employee-run AI workflow is often not the prompt. It is the accumulated judgment around it. The employee knows that one data source is incomplete, that a certain customer segment needs a different instruction, that the output must be checked against another system, and that a confident answer sometimes means the model misunderstood the request.

That knowledge is difficult to recover from a chat history. A replacement employee might find the tools and copy the prompt but still miss the review standard, the exception path, or the downstream expectation. The workflow appears to run until an edge case exposes everything that was never written down.

AI makes this risk more likely because useful workflows evolve quickly. Employees test new models, add files, connect new tools, and refine the process after seeing failures. A document written three months ago may describe the original experiment rather than the workflow the business now relies on. Continuity therefore requires more than a one-time procedure. It requires a current operating record.

Five questions every important AI workflow should answer

Before treating an employee-run AI workflow as operationally important, I would want five answers. These do not need to become a heavy approval process for every experiment. They are the minimum record for work the company would notice if it stopped.

• Who runs it? Name the person operating the workflow today and the business owner accountable for its result.
• Which tools and data does it depend on? Record the models, accounts, data sources, integrations, prompt assets, and downstream systems required to reproduce it.
• What process uses the output? Identify the decision, deliverable, customer interaction, or system action that makes the workflow matter.
• Who can run it as a backup? A backup should have access and should have successfully completed the workflow, not merely know that documentation exists.
• What happens if it stops? Define the manual fallback, acceptable interruption, escalation path, and point at which the business must intervene.

These questions expose different types of dependency. A workflow may have two trained operators but depend on a personal account. It may use approved tools but rely on a spreadsheet stored in the wrong place. It may have excellent documentation but no one who has tested the fallback. Resilience comes from seeing the whole chain, not checking one ownership box.

Continuity is not the same as ownership

Every important AI workflow should have an owner, but ownership alone does not make it durable. A name in a registry answers who is accountable. Continuity answers whether someone else can keep the work running when that person is unavailable. Those are related management controls, not substitutes for each other.

A durable workflow separates at least three roles. The operator understands how to run and review the work. The business owner understands why the workflow exists and what a good outcome looks like. The technical or control owner understands the tools, access, data, and policy boundaries. One person may fill more than one role in an early-stage process, but the responsibilities should still be explicit.

The company should also know which workflows deserve this treatment. A personal brainstorming prompt is not a continuity risk. A workflow that prepares customer advice, closes the books, changes production code, routes support cases, or feeds an executive decision might be. Criticality depends on the consequence of interruption or error, not on how technically sophisticated the workflow appears.

What a durable AI workflow looks like

The goal is not to freeze a successful employee invention into a rigid process. It is to make the parts that matter transferable. The workflow has a clear purpose, named owners, documented dependencies, an explicit review standard, and a tested backup. Changes to models, data sources, prompts, or downstream actions can be noticed and evaluated instead of silently altering the result.

A useful review looks at evidence from the work itself. Is the workflow still being used? Has its cost changed? Are people correcting more of the output? Did the business result improve? Has the backup operator run it recently? This turns continuity from a stale document into part of normal management.

At Proxon, we are building the management layer that connects AI usage with tools, agents, workflows, ownership, spend, adoption, and business outcomes. That operating view can help leaders identify important employee-run workflows, understand their dependencies, and decide which ones need a backup and a review cadence. It provides evidence for the continuity conversation. It does not replace the people who understand the work.

Companies already manage key person risk in finance, engineering, sales, and operations. Employee-run AI deserves the same attention. The practical question is not whether AI is embedded in important work. It is how many important AI workflows inside your company someone else could actually run today.