Usually one curious person on your team builds the first version of your company’s AI, and it is good work. The problem isn’t the work. It is where the work lives. In my latest video I cover four things your company should own, so that work keeps running when the person who built it is out, and the one test that proves you actually own it.
It grows in one person’s head
Here is how it usually happens. Someone gets curious and builds one helper, then a few more. It works, so it grows, but it grows in one person’s head. Only they can see what is running, what it connects to, and how it actually works. Everyone else just sees that it works. Then they take two weeks off, or get sick, or get promoted, and something breaks that only they can fix.
The fix is a principle: your AI should belong to the company, not the person who built it. That protects the business and the builder, because nobody wants a work call on vacation. In the video I follow Grace’s forty-person civil engineering firm, where a project engineer named Owen taught himself to build and now the firm runs on three of his creations, with two of the accounts sitting on his own card.
This is not a rare story. At more and more small companies, the software the business runs on gets built by whoever was curious enough to try, outside any formal process. Most of it is good, useful work. It just needs an owner that isn’t a single person.
Four things the company should own
Move every account into the company’s name on a company email, with one executive as the top admin and the two-step login codes off any single person’s phone. Put the code, and the written instructions for the AI employee, in a company repository, so a workflow that breaks or gets changed by mistake rolls back to last month’s version in minutes.
Keep a one-page runbook for each job. Four lines is enough: what it does, what it touches, who to call, and how to restart it. And give each system its own key, kept in a company vault built for keys, so if one needs to change you swap that one and the rest keep running. A personal key stops working the day that person is removed, which is exactly the surprise you are trying to avoid.
The drill is the only real proof
A document doesn’t prove you own it. A handover does. Pick someone who isn’t the builder, and while you watch, have them swap one key and restart one job using only the company accounts, the vault, the repository, and the runbook. When Grace ran this, her operations lead got stuck once, the runbook had skipped a step, so Owen added it, and the second try worked. Run it every quarter, after any big change, and before anyone with access leaves.
Two last things for the owner. Ask yourself what it does to the value of your business if your best systems depend on one person. And check that your agreements say the work people build on the job belongs to the company, contractors most of all. That one is for your lawyer. This is the other half of owning the employee instead of renting it, and the same reason to plan for when your best person leaves. When we build, the rule is the same: you own everything, and we hold no keys. If you want help getting there, that is what a free assessment is for.