What if your AI vendor disappears tomorrow?

An AI solution that runs fine today can be unavailable, unaffordable or unsupported tomorrow. Your vendor doesn't have to go bankrupt for that. An acquisition, a strategy shift, a price hike, a discontinued product or a technology the vendor swapped out is enough.

For a proof of concept, that's annoying. For an application that supports your production, it's a business risk. So before you buy, think through what happens if the vendor stops delivering what you need.

In short: Without upfront agreements, losing your AI vendor means losing access to your application and often to your own data and configuration. Vendor risk is also broader than bankruptcy: a product can be discontinued, become unaffordable or turn unusable while the company lives on. So before signing, establish who owns data and prompts, in which format you can export everything and what the notice periods are. You make an exit plan at the moment you don't need it.

How AI takes over real work in custom business software is explained on our service page.

Vendor risk is more than bankruptcy risk

When you think about what could happen to your AI vendor, bankruptcy is usually the first scenario that comes to mind. In practice the risk is much broader. Your vendor can keep operating perfectly well while the solution you rely on becomes unusable or unaffordable. A few scenarios:

• Prices shoot up once you're dependent.
• Usage limits or contract terms shift.
• Support quietly winds down or integrations are discontinued.
• Your data suddenly no longer sits in your region.
• Features you use today disappear or the underlying model is no longer available.
• The vendor pivots toward larger accounts.
• Their security stops meeting your industry's requirements.

Every one of those scenarios leads to the same place: you're stuck with something that no longer fits.

What you can lose

What lives inside an AI application is almost always more than software. Beyond the business documents you fed in, you'll find cleaned datasets, configurations, prompts, connections to other systems, usage history, corrections your staff made, custom classifications, reports, evaluation results and the process knowledge you built up over time.

Exporting your original documents rarely lets you restart somewhere else. Everything the system learned or generated around those documents is at risk of vanishing the moment the plug is pulled.

Ask who owns what

Before you sign anything, put in the contract who owns each piece. Ownership of the business data you contributed is usually clear. For these parts it rarely is:

• the enriched or cleaned version of your data
• the configurations and customisation
• the prompts
• the generated results
• the feedback and corrections from your staff
• the technical documentation

Pay particular attention to derived data. When your team has reviewed, corrected and classified thousands of results, that is a body of knowledge you won't find anywhere else. It's valuable. You don't want it stuck with the vendor the moment you part ways.

Check that you can actually export

"Data can be exported" sounds reassuring but says very little on its own. Ask further:

• In what file format does the export come?
• Do the relationships between entities survive and does the metadata come along?
• Are the configurations exportable too?
• How long does an export take and what does it cost?
• Do you keep access to your environment for a while after the contract ends?
• Can another party actually read and use that export?

A stack of PDFs or CSV files isn't necessarily enough to restart an AI application somewhere else.

Keep critical data outside the platform

Your vendor should never be the only home for essential information. Store your critical source data and your key results in systems you control yourself or can easily hand over: your ERP, your CRM, your data warehouse, your DMS or your cloud storage. An AI application can process, summarise, enrich and interpret that data. It doesn't need to be the sole owner.

Avoid unnecessary technical dependency

Complete independence is rarely realistic. What you can do is limit dependency to what's genuinely needed:

• Prefer standard connectors over bespoke integrations.
• Keep your business logic outside the AI model so another model can run it too.
• Document your prompts and configurations so they don't only live in the vendor's head.
• Keep the model choice replaceable.
• Store data in common formats and make sure your integrations aren't tied to a single vendor.
• Monitor how the system behaves. That way you don't discover during a crisis how far you've drifted in.

Document what the solution actually does

If only the vendor understands how your system works, every migration becomes slow and expensive. From day one, document the purpose of the application, the data sources it uses, the decision rules, the prompts, the exceptions, the integrations, the control steps, the authorisations, the performance indicators and the known limitations.

That documentation isn't only useful at exit. It also helps during audits, incidents and internal handovers when a colleague takes over the file.

Plan for the emergency

Ask yourself what happens on Monday morning if the application isn't available. For every critical AI process you need a temporary way to keep going. Decide:

• which tasks you can pick up manually
• which data must be available for that
• how much capacity you can free up
• who decides to switch to the fallback
• which processes you postpone temporarily
• how you catch up afterwards

A fallback procedure doesn't have to be as efficient as your AI application. It just has to keep the business running until things stabilise.

Judge the vendor beyond the demo

A demo tells you almost nothing about continuity. Also investigate financial stability, ownership structure, the sub-suppliers the vendor depends on, how security and availability are organised, what support and incident procedures look like, what insurance and liability they carry, what their roadmap looks like and what exit support they commit to contractually.

With a young vendor the answer to those questions doesn't need to be negative. It does need to be visible and managed.

Nail down the exit before you sign

During the buying phase you have the most negotiating room. Use it. Agree upfront on:

• notice periods
• how data export works
• how the vendor deletes your data
• whether configurations transfer
• the migration support you get
• exit fees
• temporary access after termination
• what happens in case of bankruptcy or acquisition
• how backups get destroyed and how the vendor confirms that destruction

Waiting until the relationship is actually ending makes that conversation much harder.

Separate critical from non-critical

An AI tool that polishes marketing copy has a very different impact than one that plans your production orders, calculates your prices or forecasts your cash flow. The more important the process, the stricter your requirements around availability, documentation, exportability, replaceability, security and fallback procedures. For a peripheral tool a lighter approach is usually fine. For the core of your operation, half measures don't cut it.

Conclusion

Asking what happens if your AI vendor disappears tomorrow isn't pessimism. It's business continuity. A good AI solution lets you switch vendor, model or platform tomorrow without losing your data, your knowledge and your processes. So before you buy, think through ownership, export, documentation, technical dependency and fallback procedures. The best exit is one you never need but can execute at any moment.

If you want to build this in from the start, begin with an AI roadmap that puts goals before tools.

Frequently asked questions

What does lock-in with an AI vendor mean in practice? It means your data, prompts, configurations and corrections only exist inside the platform and can't be exported or transferred. A price increase, a strategy shift or an acquisition then turns directly into a business risk, because you can't switch quickly without losing process knowledge.

Which exit terms should you put in the contract? Notice periods, export formats, taking configurations and prompts with you, temporary access after termination, the cost of the exit, how the vendor confirms deletion and what happens on bankruptcy or acquisition. Before you sign is when you have the most room to negotiate.

What if your AI vendor doesn't go bankrupt but doubles their prices? That's just as much lock-in. If your process depends on that platform and switching means months of rebuilding data and configuration, the vendor effectively holds the pricing power. Documentation, portable formats and a study of a second option limit that risk.

What belongs in a fallback procedure for a critical AI process? Which tasks you can temporarily handle manually, which data must be available for that, how much capacity you need, who decides to switch over and how you catch up afterwards. The procedure doesn't have to be as efficient as the AI application. It has to keep your business running.