The architecture outlives the team that built it
Even the best-resourced laboratories are losing senior people faster than they were three years ago. If retention is difficult there, an enterprise AI programme has to be designed on the assumption that the people who built it will not be there to explain it.
The risk register for an AI programme has a line about key person dependency. It is rated medium, the mitigation is documentation, and nobody has checked whether the documentation exists. It is the most reliably ignored entry on the register and it is the one that most often decides whether a system is still operable in three years.
The reason to raise it now is that the labour market has stopped being a background condition. Reporting in August 2026 on movement between the frontier laboratories put Google DeepMind’s ratio of arrivals to departures in the relevant senior roles at roughly two to one, down from about twelve to one three years earlier — Fortune’s account of the data gives the comparison across laboratories.
The claim: if an organisation with that much capital, equity and research prestige cannot hold senior AI staff, an enterprise programme should not be designed as though it can.
What actually leaves with a person
It is rarely the code. The code stays, in a repository, and someone can read it.
- Loss 01 Why it is like this The alternatives considered and rejected, and the constraint that decided it. Nowhere in the code.
- Loss 02 What good looks like The judgement about whether an output is acceptable, held as expertise rather than as a test.
- Loss 03 What was tried and failed The successor repeats it, usually twice.
- Loss 04 Which parts are fragile The workaround, the thing nobody touches, the manual step before every release.
- Loss 05 Who to ask The relationships across the business that made the system work operationally.
The second row is the expensive one and it is the one that has a mechanical remedy. A team’s judgement about output quality, written down as a labelled evaluation set, survives the team. Held as expertise, it leaves with them — and the successor cannot even tell whether a change made things worse, because the standard the previous team was working to was never externalised.
That is the strongest practical argument for the evaluation set, stronger than the model-migration argument: it is the only artefact that transfers the organisation’s own definition of quality between people.
Designing for the departure
The last line is the structural one. A system whose only continuous accountability sits inside the delivery team disappears when the delivery team does, and it is remarkable how many production AI systems have no owner outside the group that built them. The finance system has an owner in finance. The assistant that drafts customer correspondence frequently has an owner in engineering and nobody else.
The version of this that is a commercial argument
Organisations respond to this in one of two ways. Some try to build a permanent in-house team with frontier-level capability, which means competing on compensation with employers who are themselves losing people. Some outsource the whole thing, which transfers the knowledge problem to a supplier and adds a commercial dependency to it.
The third option is the one we are in the business of, so read this with that in mind: keep the accountability and the decision record inside the organisation, and buy the architecture judgement as a continuing relationship rather than as a permanent hire. What makes that work is not the arrangement. It is that the artefacts — decision records, evaluation sets, reproducible pipelines — stay with the client and are readable by whoever comes next, including a successor adviser.
An advisory relationship that makes an organisation dependent on the adviser has solved the same problem in the same wrong direction. The test is simple and it is worth applying to us as well as to anyone else: if this supplier stopped returning calls, what would we be unable to do.
What this does not tell you
The figures above describe movement between frontier research laboratories. They are not a measurement of enterprise AI teams, whose retention picture is different and much less well documented, and it would be sloppy to present them as one. What they support is a directional claim — senior capability in this field is mobile — not a rate that applies to your organisation.
Nor is documentation a complete answer. Written decision records go stale, and a system nobody has operated for a year is not made operable by a document about it. The durable artefacts are the executable ones: the evaluation set that runs, the pipeline that reproduces, the trace that explains. Prose helps. It is not the control.
The reader who should act is whoever owns the AI risk register. Take the key person line and make it specific: name the systems that only one person understands, and for each, name the artefact that would have to exist for that to stop being true. It is usually three or four systems and one artefact each — and it is a great deal cheaper to produce them now than during a notice period.