Your one AI expert is hiding a problem you can’t see.

Most leadership teams love their AI person. Things ship fast, the demos impress the board, and every automation request gets handled within a week. What they do not see is the risk hiding underneath that speed. Their one AI expert is hiding the cracks in the system.

So when they leave, or even when they take two weeks off, AI work does not just slow down. It stops. That is not a personal performance issue. It is a structural one, and it quietly threatens every company that let one person become the entire AI capability.

The hidden risk of the AI person

In most teams, one person ends up owning every prompt, every automation, every integration with the model provider. Leadership celebrates them, points to them in board updates, and quietly stops asking how any of it actually works, because the person handling it never seems to need help.

That silence is the risk. Every prompt lives in their head or their personal notes. Every workaround for a provider quirk was never written down, because writing it down felt slower than just fixing it again next time. Every architecture decision, why this model and not that one, why this data flows here and not there, exists only as something they remember, not something the organisation owns.

A system that only one person can operate is not a system. It is a dependency wearing a job title.

Why it stays invisible until it breaks

Key-person risk does not show up in a dashboard. Everything looks fine right up to the moment it does not: the person is unreachable, a provider changes an API and only they know which of the six integrations depends on the old behaviour, or they simply move on, and the organisation discovers that “how AI works here” was never written anywhere it could be found without them.

By the time it is visible, it is expensive. Rebuilding institutional knowledge from scratch, under pressure, with a system already in production, costs far more than documenting it would have cost along the way. The risk was there the entire time. It was just quiet.

What actually reduces the risk

Not hiring a second person to shadow the first, and not asking the expert to slow down and explain everything once. Both feel like solutions and neither survives contact with a real deadline. What reduces the risk is making documentation a byproduct of the work itself, not a separate task competing for the same hours.

Architecture choices, workarounds and the reason behind them get written down at the moment they are made, not reconstructed afterwards from memory. Prompts and system instructions live in a repository with a history, not in a personal notes app. Every non-obvious decision carries the date and the reason, so someone reading it in six months understands not just what was chosen but why, and can safely change it when the reason no longer holds.

That is slower in the moment. It is the only version of fast that survives the person who built it taking a holiday.

The ODB Way

At ODB Growth, every engagement leaves behind more than working software. Architecture choices, workarounds and the decisions made along the way are written down while they are made, with the reason and the date, so whoever takes it over in three months can read what happened and why, without needing the person who built it in the room.

That is not a report handed over at the end. It is the working method throughout, because a system only one person can explain is not finished, no matter how well it works today.