Automating your key-person risk does not remove it, it changes whose head it lives in

The first week looks like a win. Interruptions to the partners drop. Junior staff stop queuing outside an office to ask what the policy is on a fee write-off. Then the tool starts being confidently wrong. It answers using an old policy, because that is the version that made it into the training material. It fills a gap in its knowledge with something plausible. Nobody notices immediately, because the whole point of the tool was that people stopped checking with the partners. Someone on r/Entrepreneur described exactly this after building an assistant for a family accounting firm: "Got calls about stuff the AI got wrong. One was a billing question where it cited an OLD policy. Another time it made up a client name that didn't exist." The failure is not that the model hallucinated. Models do that. The failure is that the firm removed the human check without adding any other check. Before the tool existed, a wrong answer got caught because a partner heard the question. After the tool existed, a wrong answer went straight to a client.

Every automation moves a dependency. It does not delete one. The question worth asking before you build anything is not what this will save us, but who becomes load-bearing when it exists. The same builder on r/Entrepreneur put it plainly: "Instead of "everything lives in partners' heads" it's now "everything lives in this AI I built and I'm the only one who knows how to fix it when it breaks."" And more bluntly: "Tried to solve one single point of failure by creating a different single point of failure." This is not an argument against building the thing. It is an argument for being honest about the ledger. You had one dependency. Now you have a different one, and the new one is often worse, because the partners at least know they are the bottleneck. A quiet internal tool that mostly works hides its dependency until the person who built it takes annual leave. Before the tool, knowledge lived in two partners' heads, wrong answers got caught in conversation, and the bottleneck was visible and complained about. After the tool, knowledge lives in a system plus its builder's head, wrong answers go out unchecked, and the bottleneck is invisible until something breaks.

Here is a test we use. Pick a person. Assume they are uncontactable for three weeks. Then walk through the question honestly: what silently degrades? Not what breaks loudly. Loud breakage is fine, because someone fixes it. Silent degradation is the dangerous category: the sync that fails quietly, the prompt that drifts out of date, the exception nobody knows is an exception because the person who used to handle it is not there to handle it. Run the test on the tool's builder. Run it on the operations manager. Run it on the person who has been there eleven years and has never written anything down. The output should be a written list of things that would go wrong, ranked by how long it would take anyone to notice. Anything that takes more than a week to notice is a real risk, not a hypothetical one. Anything that only one person can restore is a documentation task before it is a technology task. The list is useful because it changes what you fix first. Often the new tool is not the most fragile thing on it.

An AI assistant answers from what it was given. If your process only exists as habit in someone's head, the tool is being fed a partial, out-of-date sketch of it. It will answer from that sketch anyway, in complete sentences, with no signal that it is guessing. Undocumented process was already a liability. What AI adds is speed and confidence. A person with an incomplete picture hesitates. A model with an incomplete picture does not. This is why the departure of a long-serving person is still painful in a small firm, whatever tools it has bought. A post on r/Bookkeeping, from someone who took a part-time accounting job and then found out it included a cleanup: "Their previous accounting person of many years retired and there’s no documentation for procedures and they’re not around to ask." No assistant would have saved that firm, because there was nothing to train it on. Write the process down, then automate it. Automating first just produces a fast, articulate version of a process nobody has agreed on. There is a fair counter-argument. Documenting everything before you build is how firms end up documenting nothing, because it is dull work with no visible payoff. The practical compromise is to document the workflow you are about to automate, at the moment you automate it, as part of the same piece of work. Not the whole firm. Just the slice in front of you.

Four things, none of them technical. First, the process exists in writing before the tool does. One page per workflow: inputs, steps, exceptions, who to ask when it does not fit the pattern. If you cannot write it, you do not understand it well enough to automate it. Second, two people can maintain the tool. Not two people who have watched a demo. Two people who have independently changed something in it and seen the change work. Third, the tool tells you when it does not know. An assistant that returns a plain "this is not covered in the current policy, ask the partner" is more valuable than one that answers everything. Design for refusal. Fourth, wrong answers have a route back. Someone owns reviewing what it got wrong, on a schedule, with a place to log it. Without this, you learn about errors from clients. The builder in that r/Entrepreneur thread arrived at the same place: "Currently spending this week documenting how I built it so I'm not the bottleneck. Which is ironic because that's literally the problem I was trying to solve in the first place."

Yes, with the ledger open. The mistake is not building. The mistake is counting the interruption savings and not counting the new dependency. The version that works is boring. You pick one workflow that is genuinely repetitive. You write it down. You build something small. You train a second person to maintain it. You review its errors monthly. The productivity gain is smaller than the demo suggested and it survives someone leaving. The version that fails is the impressive one, built quickly by one capable person, that becomes load-bearing before anyone documents how it works. This is the reasoning behind how buildAutomation is structured. Two or three of your own staff learn to diagnose, map and build the workflows, so the capability stays inside the firm rather than sitting with an agency or with one clever internal builder. The transferable skill is process diagnosis, not node-dragging.

Does an internal AI assistant reduce key-person risk? Not by itself. It moves the dependency from the person who held the knowledge to the person who built and maintains the system. Risk only drops when the underlying process is documented and at least two people can maintain the tool independently. How do we work out who our real key-person risks are? Try the three-week leave test described above. Assume one person is uncontactable for three weeks, then list what silently degrades. Loud failures get fixed. Quiet ones do not. Anything that would take over a week for anyone to notice, or that only one person can restore, is a genuine key-person risk. Should we document our processes before automating them? Document the specific workflow you are automating, as part of the same job. Trying to document the whole firm first usually stalls. Automating an undocumented process produces a fast, confident version of something nobody has agreed on. Why did our AI assistant start giving wrong answers after working well? Usually because the source material aged and nobody owned updating it, and because the human check disappeared. When people stop asking a senior person, wrong answers no longer get caught in conversation. They go straight to clients instead. Who should own an internal AI tool in a small firm? Two named staff, not one, and neither of them should be the busiest partner. Ownership means having changed something in the tool and seen it work, not having sat through a handover session. One owner is the same problem in a new place. Is it better to hire an agency to build internal tools? An agency removes the internal bottleneck and creates an external one. The dependency still exists, it just sends invoices now. Capability transfer to your own staff is slower to start, but it leaves people inside the firm who can maintain the tool.

Quotes are reproduced verbatim and attributed to the subreddit they appeared in, not to individuals. r/Entrepreneur, thread on making an accounting firm less dependent on partners' knowledge: https://www.reddit.com/r/Entrepreneur/comments/1rwxc9r/tried_to_make_my_uncles_accounting_firm_less/ and r/Bookkeeping, thread on cleanup rates versus data entry: https://www.reddit.com/r/Bookkeeping/comments/1v4yrsc/cleanup_rates_vs_data_entry/ No statistics are cited in this article. The patterns described are drawn from the quoted discussions and are not claimed to be Australian-specific or survey-backed.