Somewhere in your company there is an app you have never heard of, and it is doing real work. A sales coordinator built a quoting tool in an afternoon. Operations has a dashboard that pulls from three systems. Finance has an automation that files invoices. None of them went through IT. All of them were written with an AI coding tool by one person, and that person is the only one who knows how they work.
Shadow IT grew up
Shadow IT used to mean an unauthorised spreadsheet. The risk was a wrong formula. The fix was a conversation.
Now it means unauthorised software. A working system with a login, a database and a schedule, running a slice of daily operations. The AI tool did not change who is allowed to build. It changed who is able to, and ability wins every time.
That is mostly good news. The work gets done and the queue to IT gets shorter. The problem is not that these tools exist. The problem is that nobody has written down that they exist.
What happens when the builder leaves
The tool keeps running, which is the trap. Nobody notices anything for months. Then a third-party API changes, or the login expires, or someone needs one more field, and the tool stops.
The company does the sensible thing and brings in a developer. The developer opens the code and finds no README, no tests, no record of why anything is the way it is, and a pile of workarounds that made sense to one person on one afternoon. They will not touch it. They quote a rewrite.
I have been on the other side of that quote twice. Both were rebuilds off a no-code platform (the method), one with 13 screens, 17 tables and 24 automations. The product was fine. What could not be salvaged was the reasoning: which of those 24 automations carried a business rule and which were one-line conveniences. Of the 24, only the scheduled jobs and the webhook flows mattered. Working that out took longer than building.
The bus factor is exactly one
Engineers call it the bus factor: how many people can leave before the project is stuck. A team of ten with shared notes has a bus factor of several. A tool built by one person with an AI in a chat window has a bus factor of one, and the chat history is not a document.
The AI does not fix this. It drafted the code, but it remembers nothing between sessions. If the continuity plan is “ask the model how this fits together”, there is no plan.
What to do about it
You cannot ban it, and you should not try. The people building these tools are your most useful people. Ask for four things instead:
- A list. Every tool that runs part of the business, who built it, and what it touches. Put it where the company keeps its systems list, not in a chat.
- An owner who is not the builder. Someone who would be asked first if the builder left. They do not need to code. They need to know the tool exists and where the notes are.
- Four files in the repo. A README that says what it does and how to run it. A data map that says what it reads and writes. A deploy note that says where it runs and what keys it needs. A handoff draft the builder updates whenever something changes, written for the person who has never seen it.
- A rule for what counts. Anything a customer sees, anything that moves money, anything that would be missed within a week. Those need the four files. A personal script does not.
Done looks like a stranger with the four files taking the tool over in a day, not a rewrite.
The longer version, with the departure side and the quarterly drill, is in the standards and continuity playbook, alongside what a company keeps when the coder leaves.