Hiring AI for your company carries a risk almost nobody asks about before signing: what happens the day you want to stop paying. It's not an uncomfortable question because it's about money, it's uncomfortable because the answer is usually "nothing good," and by then your process, your team, and sometimes your customers already depend on a system you don't control.
It's called lock-in: getting stuck with a provider not because they're the best, but because leaving costs more than staying. It already exists with regular software, but with AI it gets worse, and it's worth understanding why before you sign anything.
Why lock-in weighs more with AI than with regular software
With a traditional tool, if things go wrong with a provider, you can usually export your raw data (a CSV, a database copy) and rebuild the process elsewhere. Annoying, but possible.
With AI applied for real, two extra layers get trapped with the provider:
- The decision logic. It's not just the data, it's the rule that decides what to do with it: which price to apply, when to escalate an alert, how to validate an invoice. If that logic lives only inside the provider (in their prompts, their configuration, their "proprietary model"), losing it isn't losing a report, it's losing the judgment you operate with.
- The integration with your system. An agent that writes orders into your ERP or invoices on your behalf isn't a panel you check separately: it's plugged into your daily operation. Disconnecting it suddenly leaves a hole in a process that already depended on it.
It's the same idea we covered when we explained what "proprietary model" actually means: often the label hides exactly this, a black box designed so only the provider knows how to work inside it. Lock-in isn't a side effect, sometimes it's the business model.
The question that sums up the rest
Before getting into detail, one single question filters out half the providers: "If I stop paying you tomorrow, what do I keep?"
The typical answers from a provider with lock-in sound fine until you think about them twice: "don't worry, everything stays safe on our platform," "the code is our property, that's standard in the industry," "you can export your data whenever you want" (but not the rules that interpret it). None of them answer the real question, which isn't whether your data exists somewhere, but whether you can keep operating without that provider.
The 4 questions to ask before signing
| # | Question | Answer with lock-in (red flag) | Answer without lock-in (what to demand) |
|---|---|---|---|
| 1 | Where does the data live? | "On our platform, you get access through our panel" | In your own ERP, CRM, or database, with direct access for you |
| 2 | Can you export the configuration, not just the data? | "You can export the raw data whenever you want" | You can also take the business rules: prices, conditions, workflows |
| 3 | Who owns the code that acts inside your system? | "It's our property, not handed over or documented" | It's yours, or it's documented and auditable by a third party |
| 4 | How long would it take to rebuild it with another provider? | "You'd have to start from scratch" | Weeks, because the logic is documented and portable |
The first two questions are answered by looking at where the system lives. The other two, by looking at who actually understands how it works underneath.
Where the data lives matters more than it seems
When an industrial distributor's AI sales rep quotes prices over WhatsApp, it doesn't do it from a separate platform you have to learn and later export from: it lives inside its own ERP, validating customer, price, and stock against the company's real system, across a catalog of more than 50,000 products. If that client decides to switch AI providers tomorrow, the ERP is still theirs, with the entire history inside. There's no external platform to "shut down" and salvage what you can from.
That's the exact opposite of an assistant that only "talks" to your system from the outside, keeping its own state in a cloud you don't control.
Who understands the code matters as much as who owns it
Owning the code doesn't help much if nobody besides the original provider can read it. Question 3 isn't only about legal ownership, it's about whether the logic is written so another technical team could step in, understand it, and keep maintaining it. A provider who can only answer "we handle that ourselves" is describing lock-in without saying the word.
How we approach this
At AutoBoost we build custom software and AI directly inside the client's real system: their ERP, their CRM, their accounting. We don't set up a separate platform of our own that the client has to feed and then depend on forever. The business logic is documented, and the code that acts (the one that writes invoices, quotes orders, or classifies alerts) lives where the rest of the operation already lived.
It's not a promise that "we'll never part ways with a client on bad terms." It's the opposite: it's designing from day one so that if that scenario ever happens, it isn't a disaster for anyone.
Checklist: check this before you sign
- The data lives in a system that's yours, not just accessible through the provider's panel.
- You can request and receive a copy of the configuration and rules, not just an export of rows.
- You know what language or tool the code that acts inside your system is written in.
- Documentation of the business rules exists, not just the source code.
- Another technical team (internal or external) could maintain it if the original provider disappeared tomorrow.
If a provider can't check these five boxes with concrete facts, they're not selling you a tool that integrates into your business. They're selling you a mortgage with a monthly payment.
If you're evaluating a new AI project, or want to review one you already have with this list in hand, let's talk at AutoBoost.
