If You Pay Someone to Set Up AI, Make Sure You Keep It
Here is the short version: whatever someone builds for you is only worth what your own people can run, fix, and change after that person is gone. If the only one who understands it is the one who built it, you did not buy a thing. You rented a person.
We see this pattern more than any other. Not the tool failing. The tool usually works. What fails is the handover.
How it usually goes
A consultant or an agency comes in. They are sharp, the demo is impressive, and the thing they build does what they said it would. Then the handover is a meeting. Ninety minutes of screen sharing, a document, maybe a recorded video. Everyone nods.
A few weeks later something small changes. A vendor updates their software. You add a service to your menu. The person on your staff who sat in the meeting moves on. Now nobody in the building can adjust it. The change waits. Workarounds creep in. People stop trusting it. Six months on, it is switched off and you are back to doing the work by hand, minus what you paid.
Notice what did not fail. The AI did fine. What failed was the transfer of the ability to run it.
Why it happens
Most of the value in a build is not in the visible parts. It is in the reasons behind them. Why is this instruction worded this way? What breaks when the vendor changes something? Which outputs need a human to check before they go out, and which do not?
When the answer to every one of those questions is "ask the consultant," you are one lapsed contract or one unanswered email away from a system that quietly rots. Some builders do this on purpose, because a retainer rewards dependency. Most do it by accident, because nobody asked them to do otherwise.
What keeping it actually looks like
Ask for four things, and ask before the work starts, not at the end.
Written for your team, not for engineers. Plain instructions that say what to do when something looks wrong. If the document needs a second document to explain it, it is the wrong document.
Built in tools your people can open. Your accounts, your logins, software your staff can see. Not a private setup only the builder can reach.
The reasoning written down. Every instruction and every threshold has a reason. That reason should be on paper where you can find it, not in someone's head.
Someone on your staff who has already run it. Ran it, broke it, and fixed it before the last invoice. Not "could in theory." Did.
If a proposal does not cover those four, the handover is not part of the plan. Which means it will not happen.
Four questions to ask before you sign
Who holds the accounts? Every login, every subscription, every vendor relationship should sit in accounts you own. If it runs under the builder's accounts, you own a subscription to that person.
Can my team change it? Not "could they." Have they, during the project, with the builder watching? The first change should happen before the last payment.
What happens when a vendor changes something? Vendors update their software all the time. A build that is meant to be yours comes with a short list of the things most likely to change and what to do when they do.
Is the exit in writing? The deliverables should say, in plain words, that documentation, account transfer, and a trained person on your staff are part of the job, with a way to check that they happened. "Knowledge transfer session" is not a deliverable. "Your person runs it alone for two weeks before we close out" is.
The uncomfortable one to ask any builder is this: walk me through what my team does, without you, when this breaks on a Tuesday. A good builder has a specific answer. Someone selling dependency changes the subject.
When you do not want to run anything
Some owners genuinely do not want to operate anything, and that is a fair choice. The point is to choose it on purpose, not to slide into it because nobody told you the difference. If you want the marketing handled every day without hiring anyone, that is what MOCO™ is for, and the deal is written so you own your site, your domain, your content, and your Google Business Profile the whole time. If the work belongs on a machine in your own building, that is Maai® Machines.
Either way, the test is the same. Ask who keeps it. Then get the answer in writing.
Not sure which of these you are looking at? Ask us and we will tell you, including if the answer is that you do not need to build anything yet.