One Engineer Holds Your AI Platform: Measuring and Fixing Key-Person Risk

Somewhere in your firm there is one engineer who can deploy the AI platform, roll it back, and explain why the retrieval layer does what it does. If that person resigns tomorrow, your AI program stops being a program and becomes an archaeology project. This is key person risk engineering: treating concentration of critical system knowledge as a measured exposure with fixes that have known costs, not as an anxiety you mention at offsites. This article is for CTOs and executives at regulated firms, roughly 100 to 2,000 employees, where the AI platform is run by one to four people. It covers the measurement, the cost model, four fixes ranked by what they actually transfer, and a continuity checklist you can run this week.

Key person risk engineering starts with a number, not a feeling

The industry name for this is the bus factor: the number of people whose departure would stall a system. It is measurable, and researchers have measured it. Avelino and colleagues at the Federal University of Minas Gerais estimated truck factors from git history across popular open source projects: 65% of the systems studied had a truck factor of 2 or lower (ICPC 2016 paper). Metabase reran the analysis on 1,000 GitHub projects and found the same shape: most projects sit at 1 or 2, fewer than 10% above 7 (Metabase, November 2022).

Open source projects are volunteer efforts, so the numbers flatter nobody. Your internal AI platform is structurally similar to a small open source project: one or two committers, sparse review, documentation that trails the code by months. The difference is that yours has a regulator, clients with SLAs, and a compliance file attached.

Four numbers give you the exposure in an afternoon:

Git gives you commit concentration for free. Deploy and rollback depth come from your CI and incident records. If you cannot answer these from data, that is itself a finding: you do not know who holds the keys.

In regulated industries this is not only an operations problem. The FFIEC's Business Continuity Management booklet expects covered institutions to plan for the loss of critical personnel, not just data centers (FFIEC IT Handbook). NIST SP 800-34 puts testing and exercises inside the contingency plan itself, ruling out the "we have a document somewhere" version of continuity (NIST, May 2010). An examiner asking "who else can operate this system" wants a name and evidence; "we would figure it out" is not evidence.

What the exposure actually costs

Run this model with your own numbers; the point is to make the estimate explicit instead of implicit.

Average AI engineer compensation passed $206,000 in 2025, and senior platform roles price above that (Solutions Review, April 2026). Time to fill runs months in this market (see ai-talent-gap-hiring-trends-2026). Add the components and a single departure on a two-person platform team lands between $400K and $600K before the external line. That is the number to compare against the cost of the fixes below, which is almost always smaller by an order of magnitude.

One nuance the table hides: the replacement inherits decisions nobody recorded, so the second departure, eighteen months later, is usually worse than the first. Key-person risk compounds.

Four fixes, ranked by what they actually transfer

Not all de-risking transfers the same thing. Explicit knowledge (commands, configs, credentials) is cheap to move. Tacit knowledge (why the eval threshold is 0.82, which client integration is fragile, what breaks when you scale the embedding job) only moves through shared work. Rank the fixes accordingly.

1. Runbooks, tested by a non-author. A runbook written by the person who knows the system and never executed by anyone else is a liability wearing documentation's clothes. The test that matters: someone who did not write it runs it, in a clean environment, within the last 90 days. Store runbooks as code, review them in PRs, and link them from alerts (see ai-incident-response-runbook). This transfers explicit knowledge and exposes what the author assumed everyone knew. It transfers almost no tacit knowledge on its own.

2. Pairing and rotation on the control plane. Pair programming transfers tacit knowledge faster than any other mechanism, because the second person watches the judgment calls, not just the keystrokes. Applied surgically, it is cheap: pair on the gateway, the eval gates, and the deployment path, not on every ticket. Rotate on-call so at least three people take pages for the control plane. Rotation is also a diagnostic: the person who dreads being paged is telling you where the knowledge gap is.

3. Game days where the owner is absent. Google's SRE organization has run Disaster Recovery Testing, DiRT, since 2006, deliberately breaking systems to find out what actually fails (O'Reilly, Chaos Engineering). The key-person variant is cheaper and more revealing: declare the primary owner unreachable for a day and have the second engineer execute a deploy, a rollback, and an incident walkthrough using only the runbooks. Every stall is a documentation gap or a credential gap. Fix it, then rerun in six months. This is the only fix that proves the others worked.

4. An external bench. For firms too small to staff depth internally, contract it: a named firm or senior engineer under NDA, with read access to the repos and runbooks, refreshed quarterly, who can step in within a week. This is not a vendor relationship; it is continuity insurance with a pulse. A fractional architect engagement that ends with documented decisions and trained operators fits here (see ai-platform-team-structure). So does hiring for breadth over narrow brilliance in the first place (see high-impact-ai-engineer-skills).

The continuity checklist

Score each item pass or fail. Three or more fails means your AI platform has a single point of human failure.

1. Every production AI system has at least two people who deployed it in the last 90 days.
2. Every production AI system has at least two people who have executed a rollback, not just read about one.
3. At least three people are in the on-call rotation for the gateway, eval gates, and audit trail.
4. Each critical runbook was executed by a non-author in the last 90 days, with gaps fed back into the document.
5. No critical repo shows a single author above 70% of commits over the last six months.
6. Cloud consoles, vendor portals, and API keys live in a shared vault, never in personal accounts or personal MFA devices.
7. An absence game day ran in the last six months; the findings were fixed, not filed.
8. Architecture decisions are recorded as short decision documents, so the why survives the who.
9. A named external bench exists: under NDA, repo access current, tested in the last quarter.
10. The departure protocol (access transfer, credential rotation, client notification) has been rehearsed, not just written.

Item 6 fails silently more than any other. The engineer leaves, and with them goes the only phone that can approve a login to the model provider's console. Discover that during an incident and the outage clock runs while you call the vendor's support line.

The case against de-risking your key people

The strongest opposing view deserves a fair hearing, because parts of it are right.

Specialists earn their keep. A senior engineer who has run your platform for two years ships in a day what a rotating cast ships in a week, and every pairing hour halves throughput on the surface. Documentation rots: written once, it drifts from the system within months, and teams know it, so nobody trusts the wiki. Tacit knowledge resists extraction by definition; the expert cannot fully articulate what they know, so runbooks capture the easy half. Key person insurance covers the catastrophic case, death or disability of a crucial employee (Vouch guide, June 2026). If the exposure is purely financial, insure it and keep the hero.

The counter is not that the skeptic is wrong about costs. Pairing does tax velocity. Documents do rot. The counter is about where the concentration sits. Insurance pays cash; it does not teach your surviving team why the eval gate exists, and most policies cover death and disability, not the resignation that is far more likely. Rotting documentation is a property of write-once documentation, which is why the checklist demands runbooks executed by a non-author and game days that break them on a schedule. And the throughput argument assumes the goal is this quarter's velocity. For a regulated firm, the control plane (gateway, audit trail, eval gates) is the system an examiner, a client auditor, or a court will ask about. Concentration there is not a productivity choice. It is an unpriced control failure.

Where the skeptic wins outright: non-critical systems, short-lived prototypes, and firms under two consuming teams where the honest answer is a thin platform plus an external bench, not a redundancy program. Redundancy is a spend. Spend it on the control plane first.

Our read

Treat key-person concentration on the AI control plane as a control failure, budgeted and remediated like any other. Measure the four numbers, price the exposure with the model above, and buy the fixes in order: tested runbooks, surgical pairing, absence game days, then an external bench if the headcount cannot carry depth. We would rather tell you to spend $40K a year on rotation and drills than watch a firm discover the exposure during a resignation, an incident, or an exam. The checklist is the assessment. Run it before someone else's resignation letter runs it for you.

What this means for you

• Finance: FFIEC continuity expectations cover personnel loss explicitly. Put names and evidence behind "who operates the AI platform" before your next exam cycle, and expect the auditor to ask for the game day record.
• Healthcare: The person who built your PHI-handling pipeline holds compliance knowledge, not just code. Prioritize pairing on the retrieval and access-control layer, where a wrong assumption becomes a breach report.
• Legal: Matter-level permission logic is classic single-author territory. Check commit concentration on that repo first; it is where client-confidentiality risk and key-person risk overlap.
• CPA/advisory: Busy season amplifies the risk because the platform team is smallest when demand peaks. An external bench contracted before October is worth three contracted in February.
• All firms: Run the continuity checklist this week. It takes one afternoon, and the three-or-more-fails threshold tells you whether you need a program or just a bench.

Book a free assessment: systemics.ai.

References

1. A Novel Approach for Estimating Truck Factors, Avelino et al., Federal University of Minas Gerais, ICPC 2016. https://www.dcc.ufmg.br/~mtov/pub/2016-icpc.pdf
2. Bus Factor of Top GitHub Projects, Metabase, November 2022. https://www.metabase.com/blog/bus-factor/
3. The Myth of Replaceability: Preparing for the Loss of Key Employees, SHRM, January 2025. https://www.shrm.org/executive-network/insights/myth-replaceability-preparing-loss-key-employees
4. Business Continuity Management IT Examination Handbook, FFIEC, accessed August 2026. https://ithandbook.ffiec.gov/it-booklets/business-continuity-management.aspx
5. Contingency Planning Guide for Federal Information Systems, NIST SP 800-34 Rev. 1, May 2010. https://csrc.nist.gov/pubs/sp/800/34/r1/final
6. Chaos Engineering, Chapter 5: Disaster Recovery Testing (Google DiRT, founded 2006), O'Reilly Media, 2020. https://www.oreilly.com/library/view/chaos-engineering/9781492043850/ch05.html
7. How to Attract, Retain, and Scale AI Talent in an Overheated Market, Solutions Review, April 2026. https://solutionsreview.com/how-to-attract-retain-and-scale-ai-talent-in-an-overheated-market/
8. What Is Key Person Insurance? A Complete Guide for Business Owners, Vouch, June 2026. https://www.vouch.us/blog/key-person-insurance