Voor een proof of concept is dat vervelend. Voor een toepassing die je productie ondersteunt, is dat een bedrijfsrisico. Daarom denk je best al vóór de aankoop na over wat er gebeurt als de leverancier morgen niet meer levert wat je nodig hebt.
Leveranciersrisico is meer dan faillissementsrisico
Wanneer je nadenkt over wat er met je AI-leverancier kan gebeuren, denk je waarschijnlijk in eerste instantie aan een faillissement. In de praktijk zien we dat het risico veel breder ligt. Je leverancier kan gewoon blijven bestaan terwijl de oplossing die je vandaag gebruikt, onbruikbaar of onbetaalbaar geworden is. Prijzen kunnen sterk stijgen zodra je afhankelijk bent, gebruikslimieten kunnen wijzigen, de leverancier kan de ondersteuning stilaan afbouwen, integraties kunnen wegvallen en je data kan plots niet meer in jouw regio staan. Functionaliteit die je vandaag inzet kan verdwijnen, het onderliggende model is misschien niet meer beschikbaar, de leverancier verlegt zijn focus naar grote klanten, de contractvoorwaarden schuiven op of de beveiliging voldoet niet meer aan de eisen van jouw sector. Elk van die scenario's leidt tot hetzelfde resultaat: je zit vast aan iets dat niet meer past.
Welke onderdelen kun je verliezen
Wat er in een AI-toepassing zit, is doorgaans veel meer dan software. Naast de bedrijfsdocumenten die je zelf aangeleverd hebt, vind je er ook opgeschoonde datasets, configuraties, prompts, koppelingen met andere systemen, gebruiksgeschiedenis, correcties die je medewerkers gemaakt hebben, eigen classificaties, rapporten, evaluatieresultaten en de proceskennis die je gaandeweg opgebouwd hebt. Een export van je originele documenten volstaat dan zelden om ergens anders opnieuw te starten. Alles wat het systeem rond die documenten geleerd of gegenereerd heeft, dreigt te verdwijnen zodra de stekker eruit gaat.
Vraag wie eigenaar is van wat
Nog vóór je iets tekent, leg je best contractueel vast wie eigenaar is van welk stuk. Voor de bedrijfsdata die je zelf aanlevert, is dat vaak duidelijk. Voor de verrijkte of opgeschoonde versie van die data, voor de configuraties en het maatwerk, voor de prompts, voor de gegenereerde resultaten, voor de feedback en correcties van je medewerkers en voor de technische documentatie is dat lang niet altijd zo. Let vooral op de afgeleide data. Als je team duizenden resultaten gecontroleerd, verbeterd en geclassificeerd heeft, dan zit daar een schat aan kennis die je nergens anders terugvindt. Die feedback is waardevol en je wil niet dat ze bij de leverancier hangen blijft zodra jullie uit elkaar gaan.
Controleer of je werkelijk kunt exporteren
De zin dat je data kan exporteren, klinkt geruststellend maar zegt op zich weinig. In welk bestandsformaat gebeurt dat, blijven de relaties tussen entiteiten behouden, gaat de metadata mee, zijn de configuraties zelf ook exporteerbaar, hoe lang duurt zo'n export, wat kost hij en houd je na beëindiging van het contract nog even toegang tot je omgeving? Kan een andere partij die export effectief inlezen en verder gebruiken? Een stapel pdf's of csv-bestanden is niet noodzakelijk voldoende om een AI-toepassing elders weer op poten te zetten.
Zorg dat kritieke data buiten het platform bestaat
Je leverancier mag nooit de enige bewaarplaats zijn voor essentiële informatie. Je kritieke brondata en de belangrijkste resultaten hou je best in systemen die je zelf beheert of die je eenvoudig kan overdragen: je ERP, je CRM, je datawarehouse, je DMS of je cloudopslag. Een AI-toepassing mag die informatie verwerken, samenvatten, verrijken of interpreteren. Ze hoeft er niet de enige eigenaar van te zijn.
Vermijd onnodige technische afhankelijkheid
Volledige onafhankelijkheid haal je zelden. Wat je wel kan doen, is de afhankelijkheid beperken tot wat echt nodig is. Kies waar mogelijk voor standaardkoppelingen in plaats van maatwerkintegraties, hou je bedrijfslogica buiten het AI-model zodat een ander model die logica ook kan draaien, documenteer je prompts en configuraties zodat ze niet enkel in het hoofd van de leverancier zitten en hou de modelkeuze vervangbaar. Bewaar je data in gangbare formaten, zorg dat je integraties niet aan één leverancier vasthangen en monitor systematisch hoe de toepassing zich gedraagt, zodat je niet pas tijdens een crisis ontdekt hoe ver je meegegaan bent.
Documenteer wat de oplossing precies doet
Als enkel de leverancier weet hoe je systeem in elkaar zit, is elke migratie duur en traag. Documenteer daarom van bij de start het doel van de toepassing, de databronnen die ze aanspreekt, de beslisregels, de gebruikte prompts, de uitzonderingen, de integraties, de controlestappen, de autorisaties, de prestatie-indicatoren en de bekende beperkingen. Die documentatie heb je niet alleen nodig op het moment van een exit. Ze helpt je ook bij audits, bij incidenten en bij een interne overdracht wanneer een collega het dossier overneemt.
Voorzie een noodprocedure
Stel jezelf de vraag wat er maandagochtend gebeurt als de toepassing niet beschikbaar is. Voor elk kritisch AI-proces heb je een tijdelijke werkwijze nodig. Bepaal welke taken je manueel kan overnemen, welke gegevens daarvoor beschikbaar moeten zijn, hoeveel capaciteit je vrij kan maken, wie beslist om over te schakelen op de noodprocedure, welke processen je tijdelijk uitstelt en hoe je de achterstand later inhaalt. Een noodprocedure hoeft niet even efficiënt te zijn als je AI-toepassing. Ze moet je onderneming operationeel houden tot de situatie zich stabiliseert.
Beoordeel de leverancier breder dan de functionaliteit
Een demonstratie zegt weinig over de continuïteit. Onderzoek daarom ook de financiële stabiliteit, de eigendomsstructuur, welke onderleveranciers de leverancier gebruikt, hoe hij beveiliging en beschikbaarheid regelt, hoe zijn ondersteuning en incidentprocedures eruitzien, welke verzekering en aansprakelijkheid hij draagt, hoe zijn roadmap eruitziet en welke exitondersteuning hij contractueel voorziet. Bij een jonge leverancier hoeft het antwoord op elk van die vragen niet negatief te zijn. Het moet wel zichtbaar en beheerd zijn.
Leg de exit vast vóór je tekent
Tijdens de aankoopfase heb je de grootste onderhandelingsruimte. Gebruik ze. Leg vooraf vast wat de opzegtermijnen zijn, hoe de data-export verloopt, hoe de leverancier je data verwijdert of configuraties overdraagbaar zijn, welke migratie-ondersteuning je krijgt, wat de exitkosten zijn of je na beëindiging tijdelijk toegang houdt, wat er gebeurt bij een faillissement of overname, hoe de leverancier back-ups vernietigt en hoe hij die vernietiging bevestigt. Wachten tot de samenwerking effectief stopt, maakt dat gesprek een pak moeilijker.
Maak onderscheid tussen kritiek en niet-kritiek
Een AI-hulpmiddel dat marketingteksten oppoetst, heeft een andere impact dan een toepassing die je productieorders plant, je prijzen berekent of je cashflow voorspelt. Hoe belangrijker het proces, hoe strenger je eist rond beschikbaarheid, documentatie, exporteerbaarheid, vervangbaarheid, beveiliging en noodprocedures. Voor een randtool volstaat vaak een lichtere aanpak. Voor de kern van je operationele werking neem je geen halve maatregelen.
Conclusie
De vraag stellen wat er gebeurt als je AI-leverancier morgen verdwijnt, is geen pessimisme. Het is bedrijfscontinuïteit. Een goede AI-oplossing laat je toe om morgen van leverancier, van model of van platform te veranderen zonder dat je je data, je kennis en je processen kwijtspeelt. Denk daarom vóór de aankoop na over eigenaarschap, over exportmogelijkheden, over documentatie, over technische afhankelijkheid en over noodprocedures. De beste exit is er één die je nooit nodig hebt maar die je op elk moment kan uitvoeren.
Wil je AI-lock-in vermijden voor je tekent?
De SEMANU Analyse test elke AI-leverancier op eigenaarschap, exportformaten, documentatie en noodprocedures en levert de exitvoorwaarden die je vóór de handtekening beter afdwingt. Eenmalige investering vanaf 4400 euro.
Veelgestelde vragen
Wat betekent lock-in bij een AI-leverancier concreet?
Dat je data, prompts, configuraties en correcties enkel binnen het platform bestaan en niet exporteerbaar of overdraagbaar zijn. Een prijsverhoging, een strategiewijziging of een overname vertaalt zich dan meteen naar een bedrijfsrisico, omdat je niet snel kan overstappen zonder proceskennis te verliezen.
Welke exitafspraken moet je contractueel vastleggen?
Opzegtermijnen, exportformaten of configuraties en prompts meekomen of je na beëindiging tijdelijk toegang houdt, wat de exit kost, hoe de leverancier de verwijdering bevestigt en wat er gebeurt bij faillissement of overname van de leverancier. Vóór de ondertekening heb je de grootste onderhandelingsruimte.
Wat als je AI-leverancier morgen niet failliet gaat maar zijn prijzen verdubbelt?
Dat is even goed een lock-in-scenario. Als je proces afhankelijk is van dat platform en overstappen betekent maanden werk aan data en configuratie, dan heeft de leverancier de facto het prijszettingsvermogen in handen. Documentatie, portabele formaten en een tweede-optie-onderzoek beperken dat risico.
Wat hoort in een noodprocedure voor een kritisch AI-proces?
Welke taken je tijdelijk manueel kan uitvoeren, welke data daarvoor beschikbaar moet zijn, hoeveel capaciteit je nodig hebt, wie beslist om over te schakelen en hoe je de achterstand later inhaalt. De procedure hoeft niet even efficiënt te zijn als de AI-toepassing, ze moet je onderneming operationeel houden.
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.
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. Prices can shoot up once you're dependent, usage limits can change, support can quietly wind down, integrations can be discontinued, and your data can suddenly no longer sit in your region. Features you use today can disappear, the underlying model may no longer be available, the vendor pivots toward larger accounts, contract terms shift, or 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, write down contractually who owns each piece. Ownership of the business data you contributed is usually clear. Ownership of the enriched or cleaned version of the configurations and customisation of the prompts of the generated results of the feedback and corrections from your staff and of the technical documentation is rarely obvious. 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, and 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. In what file format? Do the relationships between entities survive? Does the metadata come along? Are configurations exportable too? How long does an export take, what does it cost, and 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, and keep the model choice replaceable. Store data in common formats, make sure your integrations aren't tied to a single vendor and monitor how the system behaves so you don't discover during a crisis that you've drifted too far 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 you 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 and 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. Investigate financial stability, ownership structure, which sub-suppliers the vendor depends on, how security and availability are organised, how support and incident procedures look, 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 any of 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, on how data export works, on how the vendor deletes your data, on whether configurations transfer, on the migration support you get, on exit fees, on temporary access after termination, on what happens in case of bankruptcy or acquisition, on how backups get destroyed and on 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.
Want to avoid AI lock-in before you sign?
The SEMANU Analysis tests every AI vendor on ownership, export formats, documentation and fallback procedures, and delivers the exit terms you're better off enforcing before you sign. One-off investment from 4400 euros.
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 translates directly into a business risk, because you can't switch quickly without losing process knowledge.
Which exit terms should you lock down contractually?
Notice periods, export formats, whether configurations and prompts come with you, whether you keep temporary access after termination, what the exit costs, 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 tomorrow but doubles their prices?
That's just as much a lock-in scenario. 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 second-option study 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.
Für einen Proof of Concept ist das ärgerlich. Für eine Anwendung, die Ihre Produktion stützt, ist es ein Geschäftsrisiko. Deshalb überlegen Sie am besten schon vor dem Kauf, was passiert, wenn der Anbieter morgen nicht mehr liefert, was Sie brauchen.
Anbieterrisiko ist mehr als Insolvenzrisiko
Wenn Sie darüber nachdenken, was mit Ihrem KI-Anbieter passieren kann, denken Sie zunächst wahrscheinlich an eine Insolvenz. In der Praxis ist das Risiko deutlich breiter. Ihr Anbieter kann weiter bestehen, während die Lösung, die Sie heute nutzen, unbrauchbar oder unbezahlbar geworden ist. Preise können stark steigen, sobald Sie abhängig sind, Nutzungslimits können sich ändern, der Anbieter kann den Support leise zurückfahren, Integrationen können eingestellt werden, und Ihre Daten liegen plötzlich nicht mehr in Ihrer Region. Funktionalitäten, die Sie heute einsetzen, können verschwinden, das zugrunde liegende Modell ist möglicherweise nicht mehr verfügbar, der Anbieter richtet sich auf Großkunden aus, Vertragsbedingungen verschieben sich, oder die Sicherheit erfüllt nicht mehr die Anforderungen Ihrer Branche. Jedes dieser Szenarien führt zum gleichen Ergebnis: Sie sitzen fest an etwas, das nicht mehr passt.
Was Sie verlieren können
Was in einer KI-Anwendung steckt, ist meist deutlich mehr als Software. Neben den Geschäftsdokumenten, die Sie selbst geliefert haben, finden sich dort bereinigte Datensätze, Konfigurationen, Prompts, Verbindungen zu anderen Systemen, Nutzungshistorie, Korrekturen Ihrer Mitarbeiter, eigene Klassifikationen, Berichte, Bewertungsergebnisse und das Prozesswissen, das Sie im Laufe der Zeit aufgebaut haben. Ein Export Ihrer Originaldokumente reicht selten aus, um woanders neu zu starten. Alles, was das System rund um diese Dokumente gelernt oder erzeugt hat, droht in dem Moment zu verschwinden, in dem der Stecker gezogen wird.
Fragen Sie, wem was gehört
Bevor Sie etwas unterschreiben, halten Sie am besten vertraglich fest, wem welcher Baustein gehört. Für die Geschäftsdaten, die Sie selbst liefern, ist das oft klar. Für die angereicherte oder bereinigte Fassung dieser Daten, für die Konfigurationen und die Anpassungen, für die Prompts, für die erzeugten Ergebnisse, für das Feedback und die Korrekturen Ihrer Mitarbeiter und für die technische Dokumentation ist das selten selbstverständlich. Achten Sie besonders auf abgeleitete Daten. Wenn Ihr Team Tausende von Ergebnissen geprüft, verbessert und klassifiziert hat, steckt darin ein Wissensschatz, den Sie sonst nirgendwo finden. Dieser Wert ist beträchtlich, und Sie möchten nicht, dass er beim Anbieter hängen bleibt, sobald Sie sich trennen.
Prüfen Sie, ob Sie wirklich exportieren können
"Die Daten lassen sich exportieren" klingt beruhigend, sagt aber für sich genommen wenig aus. In welchem Dateiformat? Bleiben die Beziehungen zwischen Entitäten erhalten? Kommen die Metadaten mit? Sind auch die Konfigurationen exportierbar? Wie lange dauert ein Export, was kostet er, und behalten Sie nach Vertragsende noch eine Weile Zugriff auf Ihre Umgebung? Kann eine andere Partei diesen Export tatsächlich einlesen und weiterverwenden? Ein Stapel PDFs oder CSV-Dateien reicht nicht zwangsläufig, um eine KI-Anwendung woanders wieder aufzubauen.
Halten Sie kritische Daten außerhalb der Plattform
Ihr Anbieter darf niemals der einzige Aufbewahrungsort für wesentliche Informationen sein. Speichern Sie kritische Quelldaten und wichtige Ergebnisse in Systemen, die Sie selbst verwalten oder leicht übergeben können: Ihr ERP, Ihr CRM, Ihr Data Warehouse, Ihr DMS oder Ihr Cloud-Speicher. Eine KI-Anwendung darf diese Informationen verarbeiten, zusammenfassen, anreichern und interpretieren. Sie muss nicht der alleinige Eigentümer sein.
Vermeiden Sie unnötige technische Abhängigkeit
Vollständige Unabhängigkeit ist selten realistisch. Was Sie tun können, ist die Abhängigkeit auf das wirklich Notwendige zu begrenzen. Bevorzugen Sie Standardschnittstellen gegenüber Maßanfertigungen, halten Sie Ihre Geschäftslogik außerhalb des KI-Modells, damit ein anderes Modell sie ebenfalls ausführen kann, dokumentieren Sie Ihre Prompts und Konfigurationen, damit sie nicht nur im Kopf des Anbieters existieren, und halten Sie die Modellwahl austauschbar. Speichern Sie Daten in gängigen Formaten, sorgen Sie dafür, dass Ihre Integrationen nicht an einen einzigen Anbieter gebunden sind, und überwachen Sie systematisch, wie sich das System verhält, damit Sie nicht erst im Krisenfall bemerken, dass Sie zu weit mitgegangen sind.
Dokumentieren Sie, was die Lösung genau tut
Wenn nur der Anbieter weiß, wie Ihr System funktioniert, wird jede Migration teuer und langsam. Dokumentieren Sie deshalb von Anfang an den Zweck der Anwendung, die genutzten Datenquellen, die Entscheidungsregeln, die verwendeten Prompts, die Ausnahmen, die Integrationen, die Kontrollschritte, die Berechtigungen, die Leistungsindikatoren und die bekannten Einschränkungen. Diese Dokumentation brauchen Sie nicht nur beim Ausstieg. Sie hilft Ihnen auch bei Audits, bei Vorfällen und bei internen Übergaben, wenn ein Kollege das Dossier übernimmt.
Planen Sie den Notfall
Fragen Sie sich, was am Montagmorgen passiert, wenn die Anwendung nicht verfügbar ist. Für jeden kritischen KI-Prozess brauchen Sie eine vorübergehende Vorgehensweise. Legen Sie fest, welche Aufgaben Sie manuell übernehmen können, welche Daten dafür verfügbar sein müssen, wie viel Kapazität Sie freischaufeln können, wer entscheidet, auf den Notfallplan umzuschalten, welche Prozesse Sie vorübergehend zurückstellen und wie Sie den Rückstand später aufholen. Ein Notfallplan muss nicht so effizient sein wie Ihre KI-Anwendung. Er muss Ihr Unternehmen betriebsfähig halten, bis sich die Lage stabilisiert.
Beurteilen Sie den Anbieter über die Demo hinaus
Eine Demonstration sagt wenig über die Kontinuität. Untersuchen Sie deshalb auch die finanzielle Stabilität, die Eigentümerstruktur, welche Unterlieferanten der Anbieter nutzt, wie Sicherheit und Verfügbarkeit geregelt sind, wie Support- und Vorfallverfahren aussehen, welche Versicherung und Haftung er trägt, wie seine Roadmap aussieht und welchen Exit-Support er vertraglich zusichert. Bei einem jungen Anbieter muss die Antwort auf keine dieser Fragen negativ sein. Sie muss aber sichtbar und gesteuert sein.
Regeln Sie den Ausstieg, bevor Sie unterschreiben
Während der Anschaffungsphase haben Sie den größten Verhandlungsspielraum. Nutzen Sie ihn. Vereinbaren Sie im Voraus, welche Kündigungsfristen gelten, wie der Datenexport abläuft, wie der Anbieter Ihre Daten löscht, ob Konfigurationen übertragbar sind, welche Migrationsunterstützung Sie erhalten, welche Exit-Kosten anfallen, ob Sie nach Vertragsende vorübergehend Zugriff behalten, was bei Insolvenz oder Übernahme passiert, wie Backups vernichtet werden und wie der Anbieter diese Vernichtung bestätigt. Zu warten, bis die Zusammenarbeit tatsächlich endet, macht dieses Gespräch deutlich schwieriger.
Unterscheiden Sie zwischen kritisch und nicht kritisch
Ein KI-Werkzeug, das Marketingtexte aufpoliert, hat eine andere Auswirkung als eine Anwendung, die Ihre Produktionsaufträge plant, Ihre Preise berechnet oder Ihre Cashflow-Prognosen erstellt. Je wichtiger der Prozess, desto strenger Ihre Anforderungen an Verfügbarkeit, Dokumentation, Exportierbarkeit, Austauschbarkeit, Sicherheit und Notfallverfahren. Für ein Randwerkzeug reicht oft ein leichterer Ansatz. Für den Kern Ihres Betriebs gibt es keine halben Sachen.
Fazit
Die Frage zu stellen, was passiert, wenn Ihr KI-Anbieter morgen verschwindet, ist kein Pessimismus. Es ist Geschäftskontinuität. Eine gute KI-Lösung erlaubt es Ihnen, morgen den Anbieter, das Modell oder die Plattform zu wechseln, ohne dass Sie Ihre Daten, Ihr Wissen und Ihre Prozesse verlieren. Denken Sie deshalb vor dem Kauf über Eigentümerschaft, Exportmöglichkeiten, Dokumentation, technische Abhängigkeit und Notfallverfahren nach. Der beste Ausstieg ist einer, den Sie nie brauchen, aber jederzeit durchführen können.
Wollen Sie KI-Lock-in vermeiden, bevor Sie unterschreiben?
Die SEMANU-Analyse prüft jeden KI-Anbieter auf Eigentümerschaft, Exportformate, Dokumentation und Notfallverfahren und liefert die Ausstiegsbedingungen, die Sie besser vor der Unterschrift durchsetzen. Einmalige Investition ab 4400 Euro.
Häufig gestellte Fragen
Was bedeutet Lock-in bei einem KI-Anbieter konkret?
Dass Ihre Daten, Prompts, Konfigurationen und Korrekturen ausschließlich innerhalb der Plattform bestehen und weder exportierbar noch übertragbar sind. Eine Preiserhöhung, eine Strategieänderung oder eine Übernahme übersetzt sich dann sofort in ein Geschäftsrisiko, weil Sie nicht schnell wechseln können, ohne Prozesswissen zu verlieren.
Welche Ausstiegsvereinbarungen müssen Sie vertraglich festhalten?
Kündigungsfristen, Exportformate, ob Konfigurationen und Prompts mitgehen, ob Sie nach Vertragsende vorübergehend Zugriff behalten, was der Ausstieg kostet, wie der Anbieter die Löschung bestätigt und was bei Insolvenz oder Übernahme des Anbieters passiert. Vor der Unterschrift haben Sie den größten Verhandlungsspielraum.
Was, wenn Ihr KI-Anbieter morgen nicht insolvent geht, aber seine Preise verdoppelt?
Das ist ebenso ein Lock-in-Szenario. Wenn Ihr Prozess von dieser Plattform abhängt und ein Wechsel monatelange Neuaufbauarbeit an Daten und Konfiguration bedeutet, hat der Anbieter faktisch die Preisgestaltung in der Hand. Dokumentation, portable Formate und eine Zweitoptionsprüfung begrenzen dieses Risiko.
Was gehört in ein Notfallverfahren für einen kritischen KI-Prozess?
Welche Aufgaben Sie vorübergehend manuell erledigen können, welche Daten dafür verfügbar sein müssen, wie viel Kapazität Sie benötigen, wer über die Umstellung entscheidet und wie Sie den Rückstand später aufholen. Das Verfahren muss nicht so effizient sein wie die KI-Anwendung; es muss Ihr Unternehmen betriebsfähig halten.
Pour un proof of concept, c'est ennuyeux. Pour une application qui soutient votre production, c'est un risque d'entreprise. Réfléchissez donc avant l'achat à ce qui se passe si le fournisseur ne livre plus ce dont vous avez besoin.
Le risque fournisseur va au-delà du risque de faillite
Quand vous réfléchissez à ce qui peut arriver à votre fournisseur d'IA, la faillite est probablement le premier scénario qui vous vient à l'esprit. Dans la pratique, le risque est bien plus large. Votre fournisseur peut continuer à exister alors que la solution que vous utilisez aujourd'hui est devenue inutilisable ou hors de prix. Les tarifs peuvent grimper dès que vous êtes dépendant, les limites d'utilisation peuvent changer, le support peut se réduire discrètement, les intégrations peuvent être arrêtées, et vos données peuvent soudainement ne plus se trouver dans votre région. Des fonctionnalités que vous utilisez aujourd'hui peuvent disparaître, le modèle sous-jacent peut ne plus être disponible, le fournisseur peut se recentrer sur les grands comptes, les conditions contractuelles peuvent évoluer, ou la sécurité peut ne plus répondre aux exigences de votre secteur. Chacun de ces scénarios mène au même résultat: vous êtes coincé avec quelque chose qui ne convient plus.
Ce que vous pouvez perdre
Ce qui se trouve dans une application d'IA est presque toujours bien plus que du logiciel. Au-delà des documents d'entreprise que vous avez fournis vous-même, on y trouve des jeux de données nettoyés, des configurations, des prompts, des connexions vers d'autres systèmes, un historique d'utilisation, les corrections faites par vos collaborateurs, des classifications propres, des rapports, des résultats d'évaluation et la connaissance des processus que vous avez accumulée au fil du temps. Un export de vos documents originaux ne suffit que rarement pour redémarrer ailleurs. Tout ce que le système a appris ou généré autour de ces documents risque de disparaître au moment où l'on débranche la prise.
Demandez qui est propriétaire de quoi
Avant de signer quoi que ce soit, fixez de préférence par contrat qui est propriétaire de chaque brique. Pour les données d'entreprise que vous fournissez vous-même, c'est souvent clair. Pour la version enrichie ou nettoyée de ces données, pour les configurations et les développements sur mesure, pour les prompts, pour les résultats générés, pour les retours et corrections de vos collaborateurs et pour la documentation technique, c'est rarement évident. Faites particulièrement attention aux données dérivées. Quand vos collaborateurs ont vérifié, corrigé et classifié des milliers de résultats, il y a là une richesse de connaissance que vous ne retrouverez nulle part ailleurs. Cette valeur est importante et vous ne voulez pas qu'elle reste chez le fournisseur au moment de la séparation.
Vérifiez que vous pouvez réellement exporter
La phrase "les données peuvent être exportées" a l'air rassurante mais dit peu en soi. Dans quel format de fichier? Les relations entre entités sont-elles préservées? Les métadonnées suivent-elles? Les configurations sont-elles également exportables? Combien de temps prend un export, combien coûte-t-il, et gardez-vous accès à votre environnement pendant un certain temps après la fin du contrat? Une autre partie peut-elle réellement lire et réutiliser cet export? Une pile de PDF ou de fichiers CSV ne suffit pas nécessairement pour remonter une application d'IA ailleurs.
Conservez les données critiques en dehors de la plateforme
Votre fournisseur ne doit jamais être le seul dépositaire d'informations essentielles. Conservez vos données sources critiques et vos résultats clés dans des systèmes que vous maîtrisez vous-même ou que vous pouvez facilement transférer: votre ERP, votre CRM, votre datawarehouse, votre DMS ou votre stockage cloud. Une application d'IA peut traiter, résumer, enrichir et interpréter ces informations. Elle n'a pas besoin d'en être le seul propriétaire.
Évitez une dépendance technique inutile
L'indépendance totale est rarement réaliste. Ce que vous pouvez faire, c'est limiter la dépendance à ce qui est vraiment nécessaire. Privilégiez les connecteurs standards aux intégrations sur mesure, gardez votre logique métier en dehors du modèle d'IA pour qu'un autre modèle puisse également l'exécuter, documentez vos prompts et vos configurations pour qu'ils ne vivent pas seulement dans la tête du fournisseur, et gardez le choix du modèle remplaçable. Stockez vos données dans des formats courants, veillez à ce que vos intégrations ne soient pas liées à un seul fournisseur et surveillez systématiquement le comportement du système, afin de ne pas découvrir en pleine crise que vous êtes allé trop loin.
Documentez ce que fait réellement la solution
Si seul le fournisseur sait comment votre système fonctionne, chaque migration devient coûteuse et lente. Documentez donc dès le départ l'objectif de l'application, les sources de données mobilisées, les règles de décision, les prompts utilisés, les exceptions, les intégrations, les étapes de contrôle, les autorisations, les indicateurs de performance et les limites connues. Cette documentation n'est pas seulement utile au moment de la sortie. Elle vous aide aussi lors des audits, des incidents et des transferts internes quand un collègue reprend le dossier.
Prévoyez une procédure d'urgence
Posez-vous la question de ce qui se passe lundi matin si l'application n'est pas disponible. Pour chaque processus IA critique, vous avez besoin d'un mode de fonctionnement temporaire. Déterminez quelles tâches vous pouvez reprendre manuellement, quelles données doivent être disponibles pour cela, combien de capacité vous pouvez libérer, qui décide de basculer sur la procédure d'urgence, quels processus vous reportez temporairement et comment vous rattraperez le retard plus tard. Une procédure d'urgence n'a pas besoin d'être aussi efficace que votre application d'IA. Elle doit maintenir votre entreprise opérationnelle jusqu'à ce que la situation se stabilise.
Évaluez le fournisseur au-delà de la démo
Une démonstration ne dit presque rien de la continuité. Étudiez donc aussi la stabilité financière, la structure de propriété, quels sous-traitants le fournisseur utilise, comment la sécurité et la disponibilité sont organisées, à quoi ressemblent le support et les procédures d'incident, quelle assurance et quelle responsabilité il porte, à quoi ressemble sa feuille de route et quel accompagnement de sortie il garantit contractuellement. Chez un jeune fournisseur, la réponse à chacune de ces questions n'a pas besoin d'être négative. Elle doit être visible et maîtrisée.
Fixez la sortie avant de signer
Pendant la phase d'achat, vous avez la plus grande marge de négociation. Servez-vous-en. Fixez à l'avance les délais de préavis, la manière dont l'export des données se déroule, la manière dont le fournisseur supprime vos données, la transférabilité des configurations, l'accompagnement à la migration que vous obtenez, les frais de sortie, l'accès temporaire après résiliation, ce qui se passe en cas de faillite ou de rachat, la manière dont les sauvegardes sont détruites et la manière dont le fournisseur confirme cette destruction. Attendre que la collaboration s'arrête effectivement rend cette conversation beaucoup plus difficile.
Distinguez critique et non critique
Un outil d'IA qui embellit vos textes marketing n'a pas le même impact qu'une application qui planifie vos ordres de production, calcule vos prix ou prévoit votre trésorerie. Plus le processus est important, plus vos exigences en matière de disponibilité, de documentation, d'exportabilité, de remplaçabilité, de sécurité et de procédures d'urgence doivent être fortes. Pour un outil périphérique, une approche plus légère suffit souvent. Pour le cœur de votre activité, les demi-mesures ne conviennent pas.
Conclusion
Poser la question de ce qui se passe si votre fournisseur d'IA disparaît demain n'est pas du pessimisme. C'est de la continuité d'activité. Une bonne solution d'IA vous permet de changer demain de fournisseur, de modèle ou de plateforme sans perdre vos données, votre savoir et vos processus. Réfléchissez donc avant l'achat à la propriété, aux possibilités d'export, à la documentation, à la dépendance technique et aux procédures d'urgence. La meilleure sortie est celle dont vous n'aurez jamais besoin, mais que vous pouvez exécuter à tout moment.
Vous voulez éviter le lock-in IA avant de signer?
L'Analyse SEMANU teste chaque fournisseur d'IA sur la propriété, les formats d'export, la documentation et les procédures d'urgence, et fournit les conditions de sortie que vous avez tout intérêt à faire acter avant la signature. Investissement unique à partir de 4400 euros.
Questions fréquentes
Que signifie concrètement le lock-in avec un fournisseur d'IA?
Que vos données, vos prompts, vos configurations et vos corrections n'existent qu'à l'intérieur de la plateforme et ne sont ni exportables ni transférables. Une hausse de tarif, un changement de stratégie ou un rachat se traduit alors immédiatement en risque d'entreprise, parce que vous ne pouvez pas changer rapidement sans perdre la connaissance de vos processus.
Quels engagements de sortie faut-il fixer par contrat?
Les délais de préavis, les formats d'export, la reprise ou non des configurations et des prompts, le maintien d'un accès temporaire après résiliation, le coût de la sortie, la manière dont le fournisseur confirme la suppression et ce qui se passe en cas de faillite ou de rachat du fournisseur. Avant la signature, c'est le moment où vous disposez de la plus grande marge de négociation.
Et si votre fournisseur d'IA ne fait pas faillite demain mais double ses tarifs?
C'est tout autant un scénario de lock-in. Si votre processus dépend de cette plateforme et que changer signifie des mois pour reconstruire données et configuration, le fournisseur détient de fait le pouvoir de fixation des prix. La documentation, les formats portables et l'étude d'une seconde option limitent ce risque.
Que doit contenir une procédure d'urgence pour un processus IA critique?
Les tâches que vous pouvez reprendre temporairement à la main, les données qui doivent être disponibles pour cela, la capacité dont vous avez besoin, la personne qui décide de basculer et la manière dont vous rattraperez le retard plus tard. La procédure n'a pas besoin d'être aussi efficace que l'application d'IA; elle doit maintenir votre entreprise opérationnelle.