Wat gebeurt er wanneer je AI-leverancier morgen verdwijnt?

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.