Een AI-toepassing uitfaseren: data, modellen en afhankelijkheden netjes afsluiten

Veel organisaties richten hun pijlen volledig op de implementatie en opschaling van kunstmatige intelligentie. Toch komt er onvermijdelijk een moment waarop een AI-toepassing haar waarde verliest, verouderd raakt, of plaatsmoet maken voor een beter alternatief. Of het nu gaat om een specifieke chatbot, een interne classificatietool of een gekoppeld voorspellend model: het stopzetten van een AI-systeem vraagt om een zorgvuldige aanpak. Waar traditionele software zich laat de-installeren met het verwijderen van een database en een codebase, brengt kunstmatige intelligentie extra complexiteit met zich mee. Denk aan getrainde gewichten, API-koppelingen met externe leveranciers, verwerkte persoonsgegevens en ingesleten gebruikersgedrag. Een slordige exit kan leiden tot compliance-risico's, datalekken of onverwachte kosten. In dit artikel bespreken we hoe je een AI-toepassing beheerst en volledig uitfaseert, zodat je achterblijft met een opgeschoond en controleerbaar IT-landschap.

De aanleiding en de besluitvorming voor de exit

Voordat de technische afbraak begint, moet de organisatorische legitimatie helder zijn. Het besluit om een AI-toepassing te stoppen volgt meestal uit een evaluatie waarin de operationele kosten structureel hoger blijken dan de baten, of waarin de onderliggende datakwaliteit ernstig tekortschiet. Organisaties moeten vastleggen waarom het systeem verdwijnt en wie formeel akkoord geeft op dit besluit. Dit voorkomt dat weesprocessen ontstaan waarbij niemand meer eigenaar is, maar systemen op de achtergrond wel doordraaien en licentiekosten genereren. Het betrekken van stakeholders uit zowel de business als de IT-afdeling is hierbij cruciaal om te inventariseren welke processen geraakt worden. Wanneer je vooraf duidelijke criteria hanteert voor de levenscyclus van een model, wordt het besluit tot uitfaseren een zakelijke constatering in plaats van een emotionele discussie. Hierbij is het ook verstandig om vooraf te controleren of er juridische verplichtingen zijn om bepaalde functionaliteiten of rapportages juist te behouden voor de continuïteit van de bedrijfsvoering.

Bij het formuleren van de besluitvorming spelen vaak onverwachte factoren een rol, zoals verschuivingen in de markt of strengere wetgeving die de toepassing overbodig of risicovol maken. Het is belangrijk om deze argumenten zorgvuldig te documenteren in een exit-dossier. Hierdoor kan het management achteraf verantwoording afleggen over de gemaakte keuzes en worden misverstanden over het stopzetten van de investering voorkomen. Ook de financiële afdeling moet tijdig worden aangehaakt om de resterende boekwaardes van eventuele geactiveerde ontwikkelkosten correct te verwerken.

Contractuele verplichtingen en leveranciersafspraken

Zodra het besluit valt, vormt het contract met de leverancier of API-provider het eerste formele startpunt. Veel organisaties vergeten dat commerciële LLM-diensten en gespecialiseerde AI-platforms werken met opzegtermijnen, minimale contractperiodes en specifieke voorwaarden omtrent datasoevereiniteit. Voordat je de stekker eruit trekt, dien je na te gaan welke afspraken er zijn gemaakt over de transitieperiode. Wie helpt er bij het exporteren van data? En wat gebeurt er met de gelicentieerde software of ingekochte tokens? Het is aan te raden om de initieel opgestelde kaders rondom de exit opnieuw door te nemen. Wie meer inzicht wil krijgen in de risico's bij het inkopen van dergelijke technologie, kan de richtlijnen voor contracten en SLA's met een AI-leverancier raadplegen. Daarin staat beschreven welke clausules noodzakelijk zijn om te voorkomen dat je vastzit aan doorlopende verplichtingen na het stopzetten van de dienst.

Daarnaast is het cruciaal om te controleren of er automatische verlengingen in de algemene voorwaarden van de leverancier staan vermeld. Veel cloud- en AI-contracten worden stilzwijgend verlengd als de opzegtermijn niet exact wordt gerespecteerd. Het tijdig versturen van een aangetekende opzegbrief of het digitaal indienen via het officiële portaal voorkomt onnodige facturatie voor diensten die al offline zijn gehaald. Juridische en inkoopafdelingen moeten hierin nauw samenwerken om te borgen dat alle contractuele verplichtingen netjes worden afgedekt.

Data-retentie, opschoning en privacy

Een van de meest kritieke aspecten bij het uitfaseren van een AI-toepassing is het correct afhandelen van de opgeslagen en verwerkte data. AI-systemen verzamelen gedurende hun levensduur vaak grote hoeveelheden inputdata, prompts, gegenereerde outputs en fine-tuning-datasets. Volgens de wetgeving en intern beleid mag deze data niet oneindig bewaard blijven, zeker niet wanneer het persoonsgegevens betreft. Organisaties moeten een definitief besluit nemen over welke data vernietigd moet worden en welke data om audit- of compliance-redenen gearchiveerd moet blijven. Het is essentieel om te controleren of er modellen zijn getraind op gevoelige data, aangezien het 'ontleren' (unlearning) van specifieke informatie uit modelgewichten technisch complex is. Wie zeker wil weten dat het archiverings- en vernietigingsproces voldoet aan de geldende wet- en regelgeving, doet er goed aan om de AVG-privacy-checklist voor organisaties door te nemen om te borgen dat er geen datalekken ontstaan tijdens de sloopfase.

Bij het fysiek vernietigen van de data moet bovendien worden vastgelegd *hoe* de datasecurisatie heeft plaatsgevonden. Dit betekent dat logboeken van de vernietiging moeten worden opgeslagen voor eventuele audits door toezichthouders. Het simpelweg legen van een prullenbak in een cloudomgeving is onvoldoende; er moet cryptografische vernietiging of een gecertificeerde wipe worden toegepast op alle locaties waar de trainingsdata en cache-bestanden zich hebben bevonden.

Modellen, gewichten en de infrastructuur opruimen

Naast de operationele data moeten ook de technische componenten van de AI-toepassing systematisch worden ontmanteld. Dit omvat het opruimen van lokale modelgewichten, vector databases, embeddings en de bijbehorende orchestratielaag. Als de organisatie gebruikmaakt van externe API's, moeten alle actieve sleutels (API keys) direct worden ingetrokken en vernietigd om te voorkomen dat kwaadwillenden of vergeten applicaties alsnog kosten maken. Bij intern gehoste open-source modellen moeten de virtuele machines of container-omgevingen worden uitgeschakeld en gewist. Het is verstandig om een technische inventarisatielijst bij te houden waarin per component wordt afgetikt of deze offline is gehaald. Dit voorkomt dat 'zombie-containers' ongemerkt blijven doorlopen op cloud-omgevingen, wat onnodige kosten en veiligheidsrisico's oplevert. Ook de documentatie van het model, inclusief de evaluatierapporten en de architectuurschema's, moet op een veilige centrale plek worden gearchiveerd voor toekomstige referentie.

Een vaak over het hoofd gezien onderdeel bij de technische afbouw is het opruimen van tussentijdse testomgevingen en development-sandboxes. Ontwikkelaars laten regelmatig experimentele versies van modellen achter op afdelingsservers of persoonlijke cloud-accounts. Een grondige scan van het netwerk op actieve modelbestanden (zoals gigabytes aan .gguf of .safetensors gewichten) is noodzakelijk om te garanderen dat er geen restanten achterblijven die beveiligingsrisico's opleveren.

Het beheersen van operationele en technische afhankelijkheden

Een AI-toepassing staat zelden op zichzelf; het is vrijwel altijd verweven met andere systemen binnen het IT-landschap. Denk aan CRM-systemen die automatisch samenvattingen genereren, ERP-omgevingen die data aanleveren of interne intranetten waarop de chatbot als widget draait. Het abrupt uitschakelen van de AI-laag kan deze gekoppelde systemen direct laten vastlopen of foutmeldingen genereren bij eindgebruikers. Daarom is het noodzakelijk om alle API-koppelingen, webhook-integraties en frontend-elementen vooraf in kaart te brengen en gecontroleerd te ontkoppelen. Soms vraagt dit om het tijdelijk inbouwen van een fallback-mechanisme of een traditionele regelgebaseerde oplossing om de continuïteit te waarborgen. Organisaties die diepgaand inzicht willen in hoe leveranciers omgaan met datavernietiging en de technische afbouw van hun diensten, kunnen hiervoor de adviezen rondom retentiebeleid bij AI-leveranciers raadplegen om te borgen dat ook aan de kant van de externe partij alle sporen netjes worden gewist.

Het testen van het IT-landschap na het ontkoppelen van de AI-component is een onmisbare stap in de praktijk. Vaak zijn er stille achtergrondprocessen of geplande taken (cron jobs) die periodiek data naar het AI-model sturen. Als deze niet worden gestopt, leidt dit tot oneindige foutmeldingen in de serverlogboeken, wat op termijn de prestaties van andere bedrijfskritische systemen kan schaden.

Stakeholders, communicatie en verandermanagement

Technisch gezien kan een applicatie binnen een dag offline zijn, maar de menselijke kant van de uitfasering vraagt om meer begeleiding. Medewerkers die gewend zijn geraakt aan de ondersteuning van de AI-toepassing, kunnen weerstand ervaren of onterechtstreeks teruggrijpen op onveilige alternatieven wanneer er geen goed alternatief voor in de plaats komt. Het is belangrijk om tijdelijk en helder te communiceren waarom het systeem wordt gestopt en wat de alternatieve werkwijze wordt. Als de toepassing verdwijnt omdat een beter model of een centrale tool het overneemt, moet dat migratiepad proactief worden uitgelegd. Door gebruikers tijdig te betrekken en te trainen in de nieuwe situatie, voorkom je dat er zogenaamde 'shadow AI' ontstaat, waarbij medewerkers uit frustratie eigen, ongecontroleerde tools gaan inzetten. Duidelijke communicatie zorgt voor rust en begrip binnen de operatie.

Het betrekken van de directie en lijnmanagement bij deze communicatie is essentieel om de boodschap kracht bij te zetten. Wanneer leidinggevenden zelf uitleggen waarom een verouderd of te duur AI-systeem plaatsmaakt voor een betere standaardoplossing, wordt de acceptatiegraad onder medewerkers aanzienlijk hoger. Dit voorkomt geruchten en onzekerheid over de digitale strategie van de organisatie.

Due diligence op achtergebleven intellectueel eigendom

Bij het beëindigen van een AI-project moet ook worden gekeken naar het intellectueel eigendom (IE) dat gedurende de rit is opgebouwd. Denk hierbij aan zelfgeschreven prompts, fijn afgestemde instructiesets (fine-tuning datasets), evaluatiescripts en door het model gegenereerde content die in de bedrijfsvoering is opgenomen. Is het eigendom van deze assets contractueel goed vastgelegd? En moeten bepaalde gegenereerde werken expliciet worden overgedragen of juist worden vernietigd op basis van de afspraken met de leverancier? Wie grondig te werk wil gaan bij het beoordelen van contracten en leveranciersvoorwaarden rondom eigendomsrechten, kan ter inspiratie kijken naar de werkwijze beschreven in de gids over due diligence op AI-leveranciers. Dit helpt om juridische claims achteraf te voorkomen en zorgt voor een schone lei.

Het zorgvuldig documenteren van de resterende rechten op prompts en gegenereerde data voorkomt bovendien discussies met voormalige externe partners of consultants. Soms claimen leveranciers dat specifieke optimalisaties onder hun eigendomsrecht vallen. Door vooraf heldere afspraken te maken en deze in het exit-dossier vast te leggen, staat de organisatie juridisch sterk.

Stappenplan: De checklist voor het uitfaseren van een AI-toepassing

Om te zorgen dat geen enkel onderdeel wordt vergeten bij het afsluiten van een AI-systeem, kun je onderstaande praktische checklist hanteren. Dit overzicht helpt IT-managers, projectleiders en compliance-officers om het proces gestructureerd te doorlopen.

Door dit stappenplan streng te volgen, transformeert het uitfaseren van een AI-toepassing van een ad-hoc klus in een gecontroleerd beheerproces. Zo blijft het IT-landschap overzichtelijk, veilig en klaar voor de volgende generatie technologie.