Exitstrategie AI: houd de evaluatieset zelf

Een exitstrategie voor AI is geen clausule in het contract. Het zijn drie dingen die uw IT-organisatie zelf in handen houdt: de evaluatieset die vastlegt wat een goed antwoord is, de datacontracten die bepalen wat het systeem mag lezen, en het register van elke prompt en elke modelversie in productie. Wie die drie heeft, wisselt binnen enkele weken van AI-leverancier. Al het andere, te beginnen met de bouw, kunt u uitbesteden, en dat moet u ook doen.

Dit stuk is geschreven voor de IT-manager, IT-directeur of CIO van een organisatie met 250 tot 5.000 medewerkers die al een ICT-partner heeft en daarnaast nu een gespecialiseerde AI-leverancier binnenhaalt. Ik leid zo'n specialist. Lees het volgende dus in het besef dat het ingaat tegen de makkelijkste manier waarop een bedrijf als het mijne een klant vasthoudt. Ik vind dit toch de juiste grens, en ik trek hem liever nu met u dan dat u hem ontdekt tijdens een leverancierswissel.

Waarom is "de strategie houden, de bouw uitbesteden" de verkeerde grens?

Het advies dat de meeste IT-afdelingen krijgen, klinkt redelijk. Houd de strategie in huis en laat de specialist bouwen. Het gaat mis om een eenvoudige reden: een strategie is een document, en niets in productie toetst zichzelf ooit aan een document.

Of u bij een leverancier weg kunt, hangt niet af van wie de roadmap schreef. Het hangt af van wie op een dinsdagochtend kan aantonen dat het systeem nog doet wat het vorige maand deed. Bij een gewone applicatie zit dat bewijs in de specificatie en de testsuite, en uw ICT-partner beheert die al jaren. Bij een AI-systeem is de specificatie van nature vaag, is de uitkomst een oordeel en geen berekening, en is de enige eerlijke definitie van "het werkt" een verzameling echte gevallen met de antwoorden die u verwacht. Staat die verzameling bij de leverancier, dan staat de definitie van uw systeem daar ook.

In de meeste eerste gesprekken met een middelgrote IT-afdeling zie ik hetzelfde patroon. Op papier is de organisatie eigenaar van de broncode, het contract heeft een exitclausule en het architectuurplaatje staat in de CMDB. Dan vraag ik wie zou kunnen beoordelen of de versie van een nieuwe leverancier even goed is als de huidige, en het wordt stil. Niemand kan dat, want het bewijs van "even goed" is nooit van hen geweest.

Wat zeggen de uitfaseringen van OpenAI in juni 2026 over waar uw evaluaties staan?

Op 3 juni 2026 liet OpenAI ontwikkelaars weten dat het Evals-platform wordt uitgefaseerd. Volgens de uitfaseringspagina van OpenAI worden bestaande evals op 31 oktober 2026 alleen-lezen, en staat de sluiting van het Evals-dashboard en de API gepland voor 30 november 2026. Dezelfde dag kondigde OpenAI aan dat herbruikbare promptobjecten en de v1/prompts-API op 30 november stoppen, met het advies de promptinhoud naar uw eigen applicatiecode te verhuizen, en dat Agent Builder op diezelfde datum sluit.

Ik zie dat niet als een schandaal. Platforms stoppen met producten, OpenAI heeft de datums maanden vooraf gepubliceerd en wijst een migratieroute aan. Het punt is kleiner en bruikbaarder. De twee onderdelen die ik elke IT-afdeling zou aanraden zelf te beheren, de evaluatieset en het promptregister, zijn precies de twee die een grote modelleverancier vanaf eind november niet meer voor zijn klanten bewaart. Een team dat zijn testgevallen en beoordelingsregels alleen in het dashboard van een leverancier had staan, heeft nu een deadline die het niet zelf koos. Een team met de evaluatieset in de eigen repository leest de aankondiging, haalt de schouders op en gaat door.

Let ook op het advies zelf: zet de prompts in uw eigen code. De leverancier vertelt u waar ze altijd al thuishoorden.

Wat moet IT zelf houden bij een AI-leverancier?

Drie onderdelen. Voor geen ervan heeft u een datascientist nodig als eigenaar. Voor alle drie heeft u wel een benoemde eigenaar binnen uw eigen organisatie nodig.

1. De evaluatieset

Dit is een verzameling echte gevallen uit uw eigen proces, onder versiebeheer, elk met het antwoord dat u zou accepteren en een regel om dat te beoordelen. Voor een servicedeskassistent zijn dat echte tickets met de juiste routering. Voor een classificatiemodel voor documenten zijn dat echte documenten met het juiste label, de lastige incluis. De proceseigenaar in de lijn bepaalt wat goed is. IT bepaalt waar de set staat, wie hem mag wijzigen en hoe elke run wordt vastgelegd.

De evaluatieset is ook wat van een fout antwoord iets maakt waar uw servicedesk mee uit de voeten kan. Meldt een gebruiker dat de assistent het mis had, dan gaat dat geval de set in, en vanaf dat moment wordt elke wijziging van model of prompt daartegen getest. Waarom een fout antwoord buiten elke bestaande definitie van een incident valt, beschreef ik in AI-incident: wie is verantwoordelijk. De evaluatieset is het instrument dat dat gat dicht, en dat lukt alleen als u hem zelf in handen heeft.

2. De datacontracten

Een AI-systeem leest uit systemen die uw ICT-partner al beheert: het ERP, het documentarchief, het CRM, de ticketingtool. Een datacontract legt vast welke velden het AI-systeem mag lezen, uit welke bron, hoe actueel ze moeten zijn en wie vooraf moet worden ingelicht als het schema verandert. Het is een kort document met een controle die luid alarm slaat zodra het contract wordt geschonden.

Dit is het raakvlak tussen uw twee leveranciers, en een raakvlak hoort bij de partij die aan beide kanten zit. De AI-leverancier kan er geen eigenaar van zijn, want die heeft de bronsystemen niet in handen. De ICT-partner evenmin, want die weet niet waar het model van afhangt. U bent de enige die beide kanten ziet.

3. Het prompt- en modelregister

Elke prompt in productie, elk model en elke modelversie, elke instelling voor retrieval en elke parameter die het gedrag verandert, telkens met een datum, een auteur en een reden. Het is het wijzigingslog van het deel van een AI-systeem dat verandert zonder release. Voert een modelleverancier ongemerkt een upgrade door, of past uw AI-leverancier op vrijdagmiddag een prompt aan, dan ziet u dat in het register. De evaluatierun bij die regel vertelt u of het uitmaakte.

Voor een register heeft u geen product nodig. Een repository met één bestand per prompt en een logboek van evaluatieruns is voor de meeste organisaties genoeg om te beginnen. Waar het om gaat, is dat uw wijzigingsproces het kan zien.

Is eigenaar zijn van de broncode dan niet genoeg?

Eigenaar zijn van de code telt, en het hoort in het contract. In AI-consultant lock-in betoogde ik dat een leverancier code, documentatie en eigendom van de data vanzelfsprekend hoort over te dragen. Maar in een AI-systeem is de code het minst specifieke deel. Een bekwame nieuwe leverancier bouwt de koppeling in een paar weken opnieuw. Wat hij niet opnieuw bouwt, is twee jaar opgebouwde kennis over welke antwoorden uw organisatie accepteert, welke velden het model afgelopen voorjaar lieten ontsporen en waarom de prompt zegt wat hij zegt. Die kennis zit in de drie onderdelen, of in het hoofd van iemand bij de oude leverancier.

Wat kan een gespecialiseerde AI-leverancier in handen hebben zonder dat het u schaadt?

Vrijwel al het andere. De bouw en de integratie. De modelkeuze en de afwegingen daarachter. Het ontwerp van de retrieval, het bijstellen en het dagelijkse verbeterwerk. De monitoringtooling, en zelfs het draaien van het systeem als u dat wilt, mits elke wijziging tegen uw evaluatieset wordt getest en in uw register wordt vastgelegd.

Hier ben ik het oneens met de neiging om AI-capaciteit volledig naar binnen te halen. De meeste organisaties van deze omvang hebben geen eigen machinelearningteam nodig om grip te houden. Of een eigen team commercieel zinvol is, is een aparte vraag, die we uitwerken in AI-bureau of eigen team. Wat ze wel nodig hebben, is het vermogen om het werk te beoordelen, en dat is iets kleiners en iets heel anders. Het lijkt meer op de rol van een goede opdrachtgever bij een bouwproject dan op die van de aannemer.

Hetzelfde geldt voor uw ICT-partner. Die blijft verantwoordelijk voor het IT-landschap, het identiteitsbeheer, het netwerk en het wijzigingsproces dat hij al beheert. Deze grens vraagt niet van hem dat hij een AI-bedrijf wordt, en evenmin van de AI-leverancier dat die een ICT-partner wordt.

Wat leerde de Nederlandse overheid over oordeelsvermogen in huis houden?

Nederland heeft dit experiment al eens op grote schaal gedaan, in het openbaar. Op 15 oktober 2014 bracht de tijdelijke commissie ICT van de Tweede Kamer, de commissie-Elias, haar eindrapport uit: Naar grip op ICT. De conclusie was dat de rijksoverheid projecten met een belangrijke ICT-component niet onder controle had. De aanbevelingen gingen onder meer over de ICT-kennis bij de rijksoverheid zelf, en over aanbesteding en contractmanagement. De bekendste aanbeveling werd het Bureau ICT-toetsing, dat in juli 2015 werd opgericht om rijksprojecten boven vijf miljoen euro te toetsen voordat ze starten. De opvolger, het Adviescollege ICT-toetsing, heeft sinds 1 juli 2024 een permanente wettelijke basis.

De les die ik daaruit trek, is bescheiden en, denk ik, blijvend. De overheid is nooit gestopt met het uitbesteden van de bouw van systemen, en dat zou ook niet verstandig zijn. Wat ze kwijt was geraakt en in tien jaar weer opbouwde, was het vermogen om zelf te beoordelen of wat ze kocht zou werken. Ze bouwde een toetser, geen softwarehuis.

De vergelijking gaat maar tot op zekere hoogte op. Uw AI-assistent is geen meerjarig overheidsprogramma, en de commissie-Elias schreef over ICT in het algemeen, niet over AI. Het is bovendien een Nederlands verhaal: Vlaamse lezers hebben hun eigen geschiedenis met overheids-ICT en moeten dit niet als hun eigen verhaal lezen. Maar het patroon is hetzelfde als wat ik nu bij IT-afdelingen in het bedrijfsleven zie. De bouw wordt uitbesteed, terecht. Het oordeel gaat per ongeluk mee.

Van AI-leverancier wisselen: hoe weet u of het kan?

Eén test, en u kunt hem deze week doen. Kunt u uw evaluatieset, uw datacontracten en uw register op maandag aan een andere leverancier geven, zodat die op vrijdag aantoont dat zijn versie minstens even goed presteert als de huidige, op uw gevallen en volgens uw beoordelingsregel?

Is het antwoord ja, dan heeft u een exitstrategie, wat er ook in het contract staat. Is het antwoord nee, dan is de contractclausule een wassen neus. Drie vragen aan uw huidige AI-leverancier maken het gat snel zichtbaar:

• Waar staat de evaluatieset van ons systeem, en kunnen wij hem zonder u draaien?
• Van welke datavelden hangt het systeem af, en wat gebeurt er als er één verandert?
• Laat ons elke wijziging van prompt en model uit de afgelopen negentig dagen zien, met het evaluatieresultaat per wijziging.

Een goede leverancier beantwoordt alle drie zonder aarzelen en is blij dat u het vraagt. Houdt een leverancier de evaluatieset liever bij zich, dan vertelt hij u waar hij zijn marge verwacht. Dezelfde vragen gelden als u ooit van een beheerd agentplatform naar een eigen stack overstapt, de technische variant van dit probleem, die we behandelen in managed agent-API's.

Waarom zou een AI-leverancier tegen zijn eigen lock-in pleiten?

Omdat het alternatief een slechter verdienmodel is. Een leverancier die klanten vasthoudt door hun evaluatiebewijs te bewaren, moet een beetje bang zijn voor elk gesprek over kwaliteit. Een leverancier die het overdraagt, moet het werk steeds opnieuw verdienen. Ik zit liever in die tweede positie, en daar zitten we ook: aan het einde van een implementatie krijgt de klant de code, de modellen en de evaluatieset. Zo is ons werk als AI-implementatiepartner ingericht.

Voor u hangt er ook een prijskaartje aan, en dat moet ik noemen. Deze drie onderdelen bijhouden is een rol, geen afdeling, maar het is wel een echte rol. Iemand moet de mislukte gevallen toevoegen, het register nalopen en achter het datacontract aan gaan als een bronsysteem verandert. In de meeste organisaties van deze omvang past dat vanzelf bij een informatiemanager of een functioneel applicatiebeheerder die het proces al kent. Kunt u niemand aanwijzen, dan is dat op zich een bevinding, en die heeft u liever vóór de livegang dan na een leverancierswissel.

Waar begint een IT-afdeling dit kwartaal?

Begin bij het AI-systeem waar u het meest van afhangt, niet bij het nieuwste. Vraag uw leverancier om de evaluatieset en zet een kopie in een repository die u zelf beheert. Is er geen set, dan is dat uw eerste klus, en de proceseigenaar moet daarbij aan tafel zitten. Schrijf daarna het datacontract voor de twee of drie bronvelden waar het systeem niet zonder kan, en zet er een controle op. Leg tot slot het register aan: één regel per prompt en model in productie, en de afspraak dat er niets verandert zonder regel en evaluatierun.

Daarvoor is geen nieuwe tool nodig, geen nieuw team en geen nieuwe leverancier. Het vraagt om een besluit over welk deel van uw AI-landschap van u is, genomen voordat iemand ernaar vraagt. Voor het bredere beeld van hoe middelgrote organisaties toegepaste AI organiseren, zie toegepaste AI voor middelgrote bedrijven.

Geschreven door Tom Joseph, oprichter van Crux Digits. Gecontroleerd aan de hand van de uitfaseringspagina van OpenAI en de site van het AcICT op 28 september 2026.

Veelgestelde vragen