AI Strategie
Wat als je AI-leverancier omvalt, verandert of gehackt wordt?
AI-leveranciersrisico in het mkb: je AI-tool verdwijnt, wordt duurder of raakt gehackt. Vijf scenario's, een risicotabel en maatregelen die je vooraf regelt.
AI WorkTalent Redactie · · 10 min leestijd
AI-leveranciersrisico is het risico dat jouw bedrijfsproces vastloopt doordat de AI-dienst waarop het draait wegvalt, verandert of onbetrouwbaar wordt. Veel mkb-bedrijven bouwen zo'n proces op een dienst van een externe partij: een chatbot voor klantvragen, een hulpmiddel dat facturen uitleest, een koppeling (API) die teksten samenvat. Wat vaak ontbreekt, is een antwoord op één vraag: wat doe je als die dienst het laat afweten? Dat is geen ver-van-je-bedscenario. Op 29 januari 2025 maakte beveiligingsbedrijf Wiz Research bekend dat het een publiek toegankelijke database van AI-aanbieder DeepSeek had gevonden, die niet met een wachtwoord was beveiligd. Hieronder lees je welke vijf scenario's er zijn, en vooral: wat je zelf vooraf regelt.
AI-leveranciersrisico: vijf scenario's die vaker voorkomen dan je denkt
Leveranciersrisico bij AI is niet één scenario. Het is een verzameling van op zichzelf staande situaties die stuk voor stuk kunnen gebeuren, en die elk om een andere maatregel vragen:
- Het model wordt uitgefaseerd of gedraagt zich anders na een update. Leveranciers vervangen onderliggende modellen, passen instructies aan of schakelen een oudere versie uit. De functionaliteit blijft vaak intact, maar de uitkomst kan merkbaar veranderen.
- De prijs gaat omhoog. Veel AI-diensten zijn nog relatief nieuw geprijsd, en verdienmodellen verschuiven nog. Een tool die nu goedkoop is, hoeft dat over een jaar niet meer te zijn.
- De leverancier wordt overgenomen of gaat failliet. Dit risico is vooral reëel bij kleinere, gespecialiseerde AI-tools — vaak juist de tools die het beste op jouw proces zijn toegesneden. Een overname kan de voorwaarden, het beleid rond data of de continuïteit van de dienst in één keer veranderen.
- Er is een storing. AI-diensten zijn net zo kwetsbaar voor uitval als andere clouddiensten. Draaien er meerdere klanten op dezelfde leverancier, dan raakt een storing ook jou — zonder dat je daar zelf iets aan kunt doen.
- Er is een beveiligingsincident bij de leverancier of ergens in de toeleverketen. Niet alleen bij de aanbieder zelf, ook bij een onderaannemer, een subverwerker of een platform waarmee de tool is geïntegreerd.
Dat laatste scenario is de aanleiding voor dit artikel. Wiz Research ontdekte bij DeepSeek één publiek toegankelijke ClickHouse-database, bereikbaar via twee adressen en zonder wachtwoord. Daarin stonden meer dan een miljoen loggegevens: chatgeschiedenis in leesbare tekst, API-sleutels en interne systeeminformatie. Wiz meldde de kwetsbaarheid direct en verantwoord bij DeepSeek, dat de blootstelling vervolgens heeft verholpen. Het is niet bekend of iemand anders de database heeft gevonden voordat DeepSeek hem afsloot, en evenmin hoelang hij open heeft gestaan (TechCrunch, Engadget). Toch laat de kwetsbaarheid zelf iets belangrijks zien: ook een grote, snelgroeiende AI-leverancier kan dezelfde basale beveiligingsfouten maken als elke andere clouddienst. Voor een mkb-bedrijf is de les niet dat je bepaalde leveranciers moet mijden, maar dat je vooraf regelt wat je doet als het bij wie dan ook misgaat.
Waarom een AI-koppeling anders is dan gewone software
Bij een normale software-integratie is een storing meestal duidelijk: een API geeft een foutcode, een koppeling valt uit, iemand krijgt een melding. Bij AI ligt dat anders. Een taalmodel is niet-deterministisch: het beantwoordt dezelfde vraag soms net iets anders. Bovendien kan een leverancier het onderliggende model vervangen, bijwerken of bijstellen zonder dat de koppeling zelf breekt. Het systeem blijft antwoorden geven — alleen zijn die antwoorden misschien iets minder nauwkeurig, iets anders van toon, of net naast de vraag.
Dat is het venijnige onderdeel van AI-leveranciersrisico: er is geen moment waarop iets zichtbaar "kapot" gaat. De kwaliteit verschuift geleidelijk, en je merkt het pas als je er structureel op let, of als een klant, medewerker of controle achteraf een fout opmerkt. Voor een proces dat je hebt uitbesteed aan een AI-tool zonder menselijke controle, betekent dit dat je kwaliteitsbewaking nodig hebt die losstaat van de leverancier zelf. Denk aan een steekproef, een vaste testset waarmee je periodiek vergelijkt, of gewoon een medewerker die af en toe meekijkt.
Een voorbeeld uit de praktijk
Ter illustratie: een administratiekantoor laat inkomende facturen automatisch categoriseren door een AI-tool van een kleine, gespecialiseerde leverancier, gekoppeld aan de boekhoudsoftware. Maandenlang werkt dit goed — de nauwkeurigheid ligt hoog en het scheelt uren handmatig werk per week. Dan wordt de leverancier overgenomen door een grotere partij. De functionaliteit blijft bestaan, maar op de achtergrond wisselt het onderliggende model. De nauwkeurigheid van de categorisering zakt merkbaar, zonder dat er een storing of foutmelding is. Niemand bij het kantoor merkt dit meteen, want het systeem blijft gewoon resultaten leveren. Pas bij de kwartaalafsluiting, als de accountant een ongewoon aantal verkeerd geboekte posten tegenkomt, wordt duidelijk dat er iets is veranderd. Had het kantoor een vaste steekproef gedraaid op een vaste testset facturen, dan was de verschuiving veel eerder opgevallen. Dan was er ook op tijd ruimte geweest voor een gesprek met de nieuwe eigenaar, of voor een overstap naar een alternatief — in plaats van pas achteraf.
Wat je regelt voordat een AI-leverancier onmisbaar wordt
De meeste leveranciersrisico's zijn met een paar vragen vooraf al voor een groot deel af te dekken. Loop dit na bij elke AI-tool die een vast onderdeel van je proces wordt:
- Waar staan je data, en kun je ze exporteren? Vraag concreet na in welk formaat en op welke termijn je je data terugkrijgt als je stopt. Test dit bij voorkeur één keer, voordat het nodig is.
- Krijg je bericht als de leverancier het model wijzigt of uitfaseert? Vraag welke termijn hij daarvoor aanhoudt, en of je een bepaalde versie kunt vastzetten zolang je je eigen test nog niet hebt gedraaid.
- Wie is verwerker, en staat dat in een verwerkersovereenkomst? Verwerkt de tool persoonsgegevens, dan is de aanbieder meestal verwerker in de zin van de AVG en is een verwerkersovereenkomst verplicht. Vraag ook waar je gegevens worden verwerkt, en of dat buiten de Europese Economische Ruimte gebeurt.
- Traint de leverancier op jouw data? Worden je invoer, documenten en klantgegevens gebruikt om modellen te verbeteren, en kun je dat uitzetten? Gebruikt hij jouw invoer voor eigen doelen, zoals het verbeteren van zijn modellen, dan is hij voor dat deel zelf verantwoordelijk en dekt een verwerkersovereenkomst dat niet af. Praktisch betekent dat: zet die optie uit, of stuur er geen gevoelige gegevens doorheen.
- Welke opzegtermijn en prijsafspraken gelden er? Een maandelijks opzegbaar abonnement zonder vaste prijsafspraak geeft de leverancier alle ruimte om morgen de prijs te verhogen. Bij een kritiek proces wil je weten wat je opzegtermijn is en of er een prijsplafond of -garantie is afgesproken.
- Zijn je instructies aan het model overdraagbaar naar een andere leverancier? Zijn de instructies, prompts en eventuele voorbeelden die het systeem sturen ergens gedocumenteerd buiten de tool zelf? Dan kun je bij een overstap grotendeels hetzelfde gedrag reconstrueren bij een andere leverancier. Zit die logica volledig verstopt in het platform van de leverancier, dan begin je bij een overstap vrijwel bij nul.
- Heb je een handmatige terugvaloptie? Voor het kritieke deel van het proces is het de moeite waard om te weten hoe het zonder de AI-tool zou gaan, ook al gaat dat trager. Dat hoeft niet voor het hele proces te gelden — dat is het verschil tussen een vervelende week en een proces dat stilvalt.
Bouw je een nieuw proces rond AI, neem deze vragen dan vanaf het begin mee — niet pas als het al draait. Zie het stappenplan voor AI in het mkb. Een systeem dat goed werkt in een demonstratie of eerste proef, is nog geen systeem waarop je een kritiek proces durft te bouwen. Zie waarom een AI-pilot in productie vaak vastloopt voor wat daar nog bij komt kijken.
Risico per scenario, en de maatregel ertegenover
| Scenario | Wat er gebeurt | Maatregel |
|---|---|---|
| Model uitgefaseerd of gedragsverandering na update | Resultaat verschuift geleidelijk, zonder foutmelding | Vaste testset bijhouden en periodiek steekproefsgewijs controleren |
| Prijsverhoging | Kostprijs van het proces stijgt buiten je controle | Prijsafspraak en opzegtermijn vastleggen, alternatief vooraf in beeld |
| Overname of faillissement van de leverancier | Dienst verandert van eigenaar, voorwaarden of verdwijnt | Weet vooraf waar je data staan en of je die kunt exporteren |
| Storing | Proces valt tijdelijk stil, buiten jouw invloed | Handmatige terugvaloptie voor het kritieke deel van het proces |
| Beveiligingsincident bij leverancier of in de keten | Data mogelijk blootgesteld of ontvreemd, ook bij subverwerkers | Verwerkersovereenkomst met meldplicht, zicht op ingeschakelde subverwerkers |
Wat je zelf afdekt, en wat je alleen kunt accepteren
Niet elk leveranciersrisico is met een goed contract op te lossen. Het is nuttig om onderscheid te maken tussen de twee:
- Zelf af te dekken: of je data exporteerbaar zijn, of er een verwerkersovereenkomst ligt, welke opzegtermijn en prijsafspraken gelden, of je promptlogica gedocumenteerd is, en of er een handmatige terugvaloptie bestaat. Dit zijn keuzes die je vooraf maakt. Ze maken het verschil tussen soepel overstappen en volledig vastzitten.
- Alleen te accepteren: dat ook een grote, gevestigde AI-leverancier een storing, een beveiligingsincident of een strategiewijziging kan hebben. Dat risico verdwijnt niet door een contract. Een verwerkersovereenkomst regelt bijvoorbeeld wat er moet gebeuren als er een datalek is, maar voorkomt het datalek zelf niet. Wat je hier wel kunt doen, is het risico bewust benoemen. Vraag jezelf af: wat is de impact als deze specifieke leverancier uitvalt? En hoe groot is dat risico in verhouding tot de tijd of het geld dat de tool je bespaart?
Gaat het om een proces met écht grote impact — een kernproces waarvan de continuïteit van je bedrijfsvoering afhangt? Dan is het verstandig om afhankelijkheid van één enkele externe partij te vermijden, of in elk geval een reëel alternatief achter de hand te houden. Twijfel je hoe je dat aanpakt voor een specifieke tool of koppeling, dan helpt het om dit vooraf met een onafhankelijke specialist door te nemen, voordat je het proces kritiek maakt.
Leveranciersrisico bij AI is niet te vermijden, maar wel te beperken. Weet waar je data staan, leg opzegtermijn en prijsafspraken vast, houd promptlogica overdraagbaar en zorg voor een terugvaloptie voor het kritieke deel van je proces. Wil je hier onafhankelijk naar laten kijken, dan helpt een AI-expert inhuren je verder, of vind je op AI WorkTalent specialisten die dit soort afwegingen vaker hebben gemaakt.
De beschrijving van het beveiligingsincident bij DeepSeek is gebaseerd op de publicatie van Wiz Research van 29 januari 2025. Het praktijkvoorbeeld van het administratiekantoor is een illustratie en geen beschrijving van een bestaand bedrijf. Dit artikel is algemene informatie, geen juridisch of financieel advies; laat contractvoorwaarden met een specifieke AI-leverancier zo nodig beoordelen door een jurist.