The Person Who Set Up Your AI Just Quit. Now What?
It usually starts with one enthusiastic person. Maybe it's your operations manager, a marketing coordinator, or your most tech-forward salesperson. They started experimenting with AI tools — ChatGPT, a workflow automation, a custom chatbot — on their own initiative. They figured out what worked. They built something useful. You noticed the output was better and quietly started depending on it.
Then they hand in their notice.
Suddenly you're staring at a set of tools you don't fully understand, accounts you may not have access to, and processes that lived entirely inside one person's head — or worse, inside one person's personal subscription.
This isn't a technology problem. It's a business continuity problem, the same one you'd have if your only bookkeeper walked out mid-quarter, or if the one person who knew the alarm code went on unexpected medical leave. AI just makes the version of this risk newer, quieter, and easier to miss until it bites you.
Why AI Creates Unusual Key-Person Risk
Traditional key-person risk is visible. The one person who manages payroll, or the salesperson with all the client relationships — you know they exist, you worry about them, you plan around them.
AI key-person risk tends to be invisible right up until the moment it isn't. Here's why:
The tools are personal by default. Most consumer AI tools — ChatGPT, Claude, Perplexity, even many automation platforms — are designed for individual accounts. Your employee signed up with their personal email, put in their personal credit card, and built months of work inside that account. Legally and practically, that account belongs to them, not to you.
The value lives in the configuration, not the tool. A subscription to an AI writing assistant is worth $20/month. The custom prompts, the refined instructions, the specific workflow that person built over six months — that's where the value is. And if it lives in their account or their notes, it leaves with them.
Nobody documented it. They built it organically, iteratively, in spare moments. There was never a project with a brief and a handover plan. The process exists; the documentation does not.
Shadow AI compounds the problem. Many employees are using AI tools their employer doesn't officially know about — and that means there's no IT visibility, no account management, and no offboarding process. If you haven't mapped what AI tools your team actually uses day-to-day, you may not know what you're depending on until it's gone. This is closely related to the broader challenge of employees using AI tools outside official channels, which quietly undermines even well-intentioned AI strategies.
Run This Inventory This Week
You don't need a crisis to do this. You need twenty minutes and a document. Go through each AI tool your business uses — or that any team member uses for work — and answer five questions:
1. Which AI tools are we actually depending on?
Not just the ones you pay for centrally. Include anything a team member uses regularly to produce work output: drafting emails, summarizing meetings, building reports, managing customer communications, running automations. The tools that, if they disappeared tomorrow, someone would notice.
2. Whose name and payment card are they in?
For each tool, who owns the account? Is it a company account on a company card, or a personal account that your business happens to benefit from? This matters both for continuity and for data: if your customer information has passed through an account you don't control, you have a privacy and offboarding problem, not just a workflow problem.
3. Where do the prompts, instructions, and configurations live?
This is where most businesses find the gap. The custom instructions in a ChatGPT account. The system prompt for your chatbot. The Zapier or Make workflow that connects your CRM to your email tool. The specific prompt someone uses every week to turn raw notes into a client report. If you can't point to where that lives in writing, in a place the business controls, it doesn't reliably belong to the business.
4. What breaks tomorrow if this person is unavailable?
For each dependency, assume the person who built it is unreachable — sick, resigned, or on leave. What stops working? What produces wrong output because nobody knows how to run it? What does a colleague have to skip or do manually? This forces you to name the actual operational risk, not the theoretical one.
5. Who else has run it end to end, even once?
Not "who could figure it out." Who has actually done it, with the current setup, in a way that would let them do it again without help? If the answer is nobody, that's your priority.
The Fixes, In Order of Effort
The good news: none of this is technically hard. It's the same kind of unglamorous operational housekeeping that separates businesses that scale from businesses that stay fragile.
Start with account ownership — before the exit interview, not at it.
Migrating accounts at the point of departure is painful and sometimes impossible. Do it now, while everyone is still around and cooperative. Company tools should be on company email addresses and company payment methods. For tools where individual logins are unavoidable, make sure a company administrator has access to the account and that credentials are stored somewhere the business controls (a shared password manager, not a sticky note on one person's monitor).
The data-access issue is real and often overlooked. If a departing employee has an account — even a personal one they used partly for work — that contains your customer information, you have an exposure. Most AI tools log conversations. Some retain uploaded documents. Knowing which tools hold what data is the first step to managing that risk appropriately. The broader question of what happens to your data inside these tools is worth understanding clearly, and your data privacy obligations when using AI tools apply regardless of whether the account is personal or corporate.
Get the prompts and process notes into a shared place.
This doesn't require a sophisticated system. A shared Google Doc, a Notion page, a folder in your shared drive — anything the business controls and any authorized person can find. The goal is to capture:
- The exact prompt or instruction set someone uses regularly
- Any custom configuration in the tool itself (custom instructions, system prompts, personas)
- The inputs the process needs and the output it produces
- Any gotchas: things to check, things that go wrong, things the person learned the hard way
You're not writing a technical manual. You're writing the two-page handover note you'd want if you were the one picking this up cold. Using AI to help document these processes is actually one of the better applications of the technology — if you haven't tried having your team narrate their own workflows aloud and then turn that into structured documentation, AI is genuinely useful for turning tribal knowledge into written processes.
Have a second person run it once, in full, while the first person watches.
Documentation is necessary but not sufficient. The person who built the process should watch someone else run it, start to finish, at least once before they leave. This is where the gaps in the documentation surface — the step that seemed obvious to the author but isn't, the judgment call nobody wrote down, the tool login that requires an extra authentication step.
One full rehearsal, observed, closes more gaps than a week of writing.
Write the two-paragraph "when it breaks" note.
Every AI-dependent process should have a brief note that answers: what are the signs this is producing wrong output, and what does someone do first if it stops working? Not a full troubleshooting guide — just the thirty-second intervention that handles 80% of failure cases. "If the output looks wrong, check X. If the tool is unavailable, use Y as a stopgap and flag to [name]." That's it. It takes five minutes and it's the thing people actually need at 4pm on a Thursday when something isn't working.
A Word on Getting the Balance Right
There's a version of this response that goes wrong: locking down all AI experimentation, requiring approval for every new tool, making the enthusiastic tinkerers feel like a liability.
That would be a mistake.
The person who built your AI setup is an asset. Their initiative, their curiosity, their willingness to figure things out is genuinely valuable and not easy to replace. The goal here is not to stop them from tinkering — it's to make sure their work survives them. Those are very different things.
What you want is an environment where someone can experiment freely, and where the things that turn out to be useful get captured in a form the business can keep. That means normalizing documentation as part of the work, not as a bureaucratic add-on. It means making shared accounts and shared credential storage the default from the start, not a retrofit at departure. And it means having a conversation with your most AI-active team members now — not to audit them, but to understand what they've built and make sure it's owned jointly.
The same conversation you'd have about anyone who's built something the business depends on.
The Departure Moment
When someone who has been running AI tools does leave, run a short exit checklist alongside your standard offboarding:
- Transfer or copy all accounts they managed to company ownership
- Export any stored prompts, custom instructions, or configuration files
- Revoke their access to company data in any tool where they had it — including personal accounts they used for work purposes
- Walk through any active automations with their replacement before their last day
- Have them do a live run of anything complex with the next owner in the room
None of this is punitive. You're doing the same thing you'd do with any proprietary process: making sure it stays with the business when the person who built it moves on.
The Underlying Point
Most small business AI risk conversations focus on the tools: which one to pick, what it costs, whether it's accurate. Key-person risk doesn't come from the tool — it comes from the gap between what the business depends on and what the business actually controls.
If your AI setup works because one person is holding it together, you don't really have an AI capability. You have a person with a capability, and a fragile one at that.
The fix isn't complicated. It's the same unglamorous work that makes any part of a business resilient: document it, share it, and make sure it lives somewhere the business owns.
If mapping your AI dependencies, getting accounts under company control, and building the handover processes is the kind of work you'd rather do with someone who's seen what breaks and what holds — book a strategy call and let's take a look at where you actually stand.