Bijna elke AI-implementatie waar ik bij word gehaald draait om één stille beslissing die de klant niet wist te nemen: bouwen of kopen. Na jaren van dit werk is mijn antwoord onromantisch. Koop de saaie tachtig procent die iedereen nodig heeft en niemand onthoudt. Bouw alleen de zeldzame twintig procent die echt van jou is. Zet die verdeling verkeerd en het project worstelt, hoe goed de techniek eronder ook is.
Bouwen of kopen is de keuze die je AI-implementatie stilletjes bepaalt
Op papier lijkt bouwen-of-kopen een voetnoot voor de inkoop, een vinkje dat iemand zet nadat de echte strategie klaar is. In de praktijk is het de dragende keuze van het hele project. De meeste mislukte implementaties die ik moet redden, mislukten niet op het model of de data science. Ze mislukten omdat een bedrijf iets bouwde dat het had moeten kopen en verzoop in het onderhoud, of iets kocht dat het had moeten bouwen en nooit die ene capaciteit kreeg die het onderscheidend had gemaakt.
Laat ik de termen definiëren zoals ik ze met een klant gebruik. Kopen betekent een bestaande tool of platform nemen en die inrichten op jouw proces. Bouwen betekent iets op maat laten maken — code, prompts, orkestratie — dat niet bestond voordat je ervoor betaalde. De werkelijkheid is bijna nooit zuiver. De interessante vraag is waar je de grens trekt, en de markt schuift stilletjes naar hetzelfde antwoord: een recente doorlichting van het veld vond dat zevenenvijftig procent van de organisaties nu kiest voor een gemengde bouw-en-koop-aanpak, tegen eenenvijftig procent een kwartaal eerder. Zuiverheid verliest. De mix wint. Het enige waar het nog over gaat, is de verhouding.
Wat goedkoop werd in 2026 — en wat niet
De reden dat deze keuze in 2026 anders voelt dan twee jaar geleden, is dat het leidingwerk goedkoop werd. Het Model Context Protocol ging van een niche-idee naar bijna een standaard: medio 2026 draaide ongeveer eenenveertig procent van de softwareorganisaties MCP-servers in productie, werden de SDK's zo'n zevenennegentig miljoen keer per maand gedownload, en waren er ruim negenduizend publieke servers om op aan te sluiten. Agent-frameworks zijn nu een commodity. Een model koppelen aan je tools, ooit een project op zich, is nu eerder een middag werk.
Hier zit de val die goedkoop leidingwerk zet. Het laat bouwen goedkoper en sneller lijken dan ooit, dus praten meer bedrijven zichzelf een bouwtraject aan. Maar wat goedkoop werd, was het verbindingsweefsel, niet het eigenaarschap. Gartner verwacht dat meer dan veertig procent van de agentic-AI-projecten voor eind 2027 wordt geschrapt, en de redenen die het noemt zijn geen leidingproblemen — het zijn oplopende kosten, onduidelijke bedrijfswaarde en gaten in governance. Die zitten in de delen van een bouwtraject die nooit goedkoop werden: het oordeel over wát je bouwt, en de jaren dat je het daarna bezit.
Koop de saaie tachtig procent
Mijn eerste reflex bij bijna elke capaciteit is kopen, en dat bedoel ik als compliment aan het werk, niet als een omweg eromheen. De regel is simpel. Als een capaciteit voor jou hetzelfde is als voor je concurrent, koop hem. Transcriptie is hetzelfde. Generieke documentextractie is hetzelfde. Een helpdeskassistent die de twintig meest gestelde vragen beantwoordt, is hetzelfde. Kant-en-klare tools dekken inmiddels zo'n zeventig procent van de use cases en staan in één tot drie weken live. Kiezen om die te kopen is geen genoegen nemen. Het is weigeren je eigen mensen te laten betalen om een wiel opnieuw uit te vinden dat al prima rolt.
Dit is het moment in het gesprek waarop oprichters soms leeglopen, omdat kopen minder indrukwekkend voelt dan bouwen. Ik snap die aantrekkingskracht. Maar niemand is ooit afgetroefd omdat zijn notulen werden getranscribeerd door een tool met andermans logo. Als we de processen van een bedrijf in kaart brengen met een AI-scan, is het meeste wat we vinden commoditywerk dat verkleed gaat als iets bijzonders. Het als commodity benoemen is juist het punt. Het maakt budget en aandacht vrij voor het handjevol zaken dat wél een maatwerkbouw verdient. Die herkadering — niet de code — is grotendeels waar een AI-consultant voor het mkb echt voor is.
Er is een tweede, stiller argument om te kopen dat oprichters missen. Als je koopt, betaalt iemand anders om het product te verbeteren. De hele business van de leverancier is om die transcriptie of dat helpdeskmodel elk kwartaal beter te maken, en jij krijgt die winst voor de prijs van een abonnement. Als je bouwt, is elke verbetering van jou om te financieren. Voor een commodity-capaciteit is dat een verloren race: je besteedt schaarse engineeringtijd om bij te blijven bij een bedrijf dat als enige bestaansreden heeft jou op precies die taak voorbij te streven. Koop het, en laat hun roadmap jouw roadmap zijn.
Bouw de zeldzame twintig procent
Wanneer bouw je dan wel? Ik gebruik drie toetsen, en de kandidaat moet er minstens één overtuigend doorstaan. Ten eerste eigen data: als het ding merkbaar beter wordt door data die alleen jij hebt, is dat een reden om te bouwen, want geen leverancier kan trainen op wat hij niet ziet. Ten tweede een echt eigenzinnige workflow: als jouw manier van werken om goede redenen afwijkt, een proces dat geen enkel standaardproduct modelleert omdat bijna niemand anders het zó doet, kan een bouw dat vangen. Ten derde data die je niet mag afstaan: banken bouwen deels hun eigen agents omdat transactiedata blootstellen aan een derde partij onacceptabel is, en een maatwerksysteem laat ze expliciete terugdraai-logica en strikte toegangscontrole houden.
Om die twintig procent concreet te maken: het is zelden een heel product en bijna altijd een splinter. Een logistiek bedrijf bouwt geen eigen chatmodel; het bouwt misschien dat ene stukje routeringslogica dat veertig jaar weten welke chauffeurs welke lastige adressen aankunnen in zich draagt. Een accountantskantoor bouwt geen eigen documentlezer; het bouwt misschien de laag die een rommelige klantmap op zijn eigen manier van archiveren afbeeldt. Het zeldzame deel is klein, specifiek en oninteressant om over op te scheppen, en juist daarom overleeft het de confrontatie met de catalogus van een leverancier. Als een concurrent jouw bouwkandidaat in dezelfde woorden zou beschrijven als jij, is het niet het zeldzame deel.
Wat je koopt als je bouwt, is niet alleen de functie. Je koopt de plicht om die te bezitten. Een basale maatwerkbouw kost al gauw zes tot vijftien weken voordat hij een euro verdient, en daarna draagt jouw team de optimalisatie, de evaluaties, de modelwissels en de trage drift van een systeem dat in maart accuraat was en in september stilletjes niet meer. Die plicht is het waard voor de twintig procent die je voorsprong is. Het is een slechte ruil voor de tachtig procent die dat niet is. Vóór elke bouw dring ik er nog steeds op aan om eerst een kleine proof of concept af te bakenen, zodat de plicht in het klein is bewezen voordat er op schaal voor wordt getekend.
De echte kosten zijn niet de bouw — maar het jaar erna
De meest gemaakte budgetfout die ik zie, is de bouw offreren en het jaar erna vergeten. De bouw is het goedkope deel. Wat echt geld kost, is alles wat gebeurt zodra het ding in productie staat: de evaluaties die je vertellen dat het nog klopt, de bereikbaarheidsdienst voor als het een klant iets vol overtuiging verkeerds vertelt, de hertraining als een model waarvan je afhankelijk bent wordt uitgefaseerd, en het kleine governance-apparaat dat de EU AI Act nu van je verwacht. Als mensen me vragen hoe lang en hoeveel een AI-implementatie eigenlijk kost, wijs ik ze op de totale eigendomskosten, niet op de factuur voor versie één — want die factuur is het kleinste getal in het verhaal.
Mensen onderschatten dit omdat software ze heeft geleerd dat af ook klaar betekent. Een brug staat er, eenmaal gebouwd, grotendeels gewoon. Een maatwerk-AI-systeem lijkt meer op een heg: laat het twee kwartalen met rust en het groeit wild. De modellen waarop het draait veranderen, de data drift weg, en de randgevallen die je in het testen nooit zag, arriveren in productie met de naam van een klant erop. Niets daarvan is een reden om nooit te bouwen. Het is een reden om het mee te tellen voordat je begint, zodat het onderhoud een beslissing is die je nam in plaats van een verrassing die je erfde.
Dit is ook waarom de bouwen-of-kopen-grens voor hetzelfde bedrijf in de tijd verschuift. Iets dat in 2024 de moeite van het bouwen waard was, kan in 2026 beter gekocht worden, omdat de markt is bijgetrokken en een leverancier het nu beter onderhoudt dan jij kunt. Een volwassen AI-praktijk herziet zijn eigen verdelingen. Het is niet gênant om een maatwerksysteem waar je ooit trots op was met pensioen te sturen. Het is gênant om er één te blijven onderhouden die de markt onder je vandaan al tot commodity heeft gemaakt terwijl je niet keek.
Hoe ik de bouwen-of-kopen-keuze met een klant doorloop
Het kader dat ik echt gebruik, past op een bierviltje. Schrijf de workflow in gewone taal op, zoals je die aan een nieuwe collega zou uitleggen. Vraag of het er bij je naaste concurrent hetzelfde uitziet; zo ja, dan is het kopen. Vraag of jouw eigen data of jouw manier van werken het merkbaar beter zou maken dan de versie van een leverancier; als het eerlijke antwoord nee is, dan is het ook kopen. Alleen als een capaciteit door beide poorten komt — anders dan de concurrentie én beter door iets wat uniek van jou is — praten we serieus over bouwen. De standaard is kopen, en een bouw moet zich uit die standaard verdienen.
Het meeste van de waarde in dit gesprek zit in het vertragen ervan. Als ik een kennismakingsgesprek snel afrond, is dat meestal omdat we in twintig minuten vaststelden dat alles op tafel een koop was en er geen eerlijk maatwerkproject te verkopen viel. Dat is een goede uitkomst, ook al is het een kleinere factuur. Soms is het juiste antwoord om helemáal niets op maat te doen, om drie tools te kopen, het team te trainen en over zes maanden terug te komen. Een consultant wiens enige product een bouw is, geeft je dat antwoord nooit — en het is het antwoord dat mijn klanten het meeste geld heeft bespaard.
Drie manieren waarop de bouwen-of-kopen-keuze misgaat
De eerste misser is bouwen voor het prestige. Een bedrijf bouwt zijn eigen versie van een commodity omdat “we hebben het zelf gebouwd” goed klinkt in een directievergadering, en onderhoudt vervolgens drie jaar lang een slechtere kopie van een tool die het had kunnen huren. De tweede is de onbedoelde bouw: een bedrijf koopt een platform en past het zo zwaar aan dat het nu een maatwerksysteem bezit zonder dat ooit besloten te hebben — alle onderhoudskosten van bouwen, geen van de helderheid. De derde, en de duurste, is de verkeerde kant op splitsen: het zeldzame kopen en het saaie bouwen. Je echte voorsprong aan een gedeelde leverancier geven terwijl je maatwerkbudget in transcriptie pompt, is hoe je eindigt met een project dat druk, duur en strategisch zinloos is.
Als ik zeg dat ik vaak weet dat een project gaat mislukken voordat het begint, is dit een van de signalen. Als een bedrijf niet in één zin kan zeggen welke twintig procent van het werk van hem is en waarom, is de verdeling niet gemaakt — en een niet-gemaakte verdeling verdwijnt niet. Ze wordt alleen slecht gemaakt, later, door wie het hardst roept. Bouwen-of-kopen goed doen is geen technische vaardigheid. Het is de discipline om eerlijk te zijn over welke delen van je bedrijf echt bijzonder zijn, en te weigeren een maatwerkbudget te besteden aan de delen die dat niet zijn.
Niets hiervan is tegen bouwen. Ik run een consultancy die voor de kost maatwerk-AI bouwt. Het is een pleidooi om met opzet te bouwen: de schaarse, dure inspanning van een echte bouw alleen te besteden waar die je iets oplevert dat de markt niet kan verkopen, en de rest zonder schaamte te kopen. In 2026, met het leidingwerk goedkoper dan ooit, is die discipline het hele spel.
Veelgestelde vragen
Moet ik AI zelf bouwen of kopen voor mijn bedrijf?
Kopen eerst, selectief bouwen. Kant-en-klare tools dekken zo'n zeventig procent van de use cases en staan in één tot drie weken live, dus kopen is de verstandige standaard voor alles wat bij je concurrent hetzelfde werkt. Reserveer maatwerk voor het kleine deel dat echt je voorsprong is, en bewijs dat zelfs dan eerst met een kleine proof of concept voordat je op schaal tekent.
Wanneer is maatwerk-AI wel logisch?
Maatwerk is logisch als de capaciteit minstens één van drie toetsen doorstaat: hij wordt merkbaar beter door data die alleen jij hebt, hij vangt een workflow die zo eigenzinnig is dat geen standaardproduct hem modelleert, of de data is te gevoelig om aan een derde af te staan. Ziet een capaciteit er bij je concurrent hetzelfde uit en zou jouw data hem niet beter maken, koop hem dan — dat is niet de twintig procent van de meeste bedrijven.
Waarom mislukken zoveel maatwerk-AI-projecten?
Omdat het dure deel nooit de bouw was, maar het bezitten van het resultaat. Gartner verwacht dat meer dan veertig procent van de agentic-AI-projecten voor eind 2027 wordt geschrapt, door oplopende kosten, onduidelijke waarde en gaten in governance. Teams offreren versie één en vergeten de evaluaties, hertraining, bereikbaarheidsdienst en compliance die erna komen. Het saaie commoditywerk bouwen in plaats van het zeldzame, onderscheidende werk maakt het erger.
Wat kost maatwerk-AI bouwen vergeleken met kopen?
Kopen is meestal een voorspelbaar abonnement met een opzet van één tot drie weken. Een maatwerkbouw kost al gauw zes tot vijftien weken voordat hij iets oplevert, en het echte getal is de totale eigendomskosten over de jaren erna, niet de factuur voor versie één. Beoordeel een bouw op die volledige levensduurkosten; voor concrete bedragen kijk je beter naar een aparte kostenopbouw dan naar één bouwofferte.
Kan ik met kant-en-klare AI beginnen en later bouwen?
Ja, en het is vaak de slimste route. Eerst kopen laat je met goedkope, omkeerbare tools ontdekken waar de echte wrijving zit voordat je je aan eigenaarschap bindt. Zodra een specifieke capaciteit bewijst dat het je voorsprong is — en de data of workflow erachter echt van jou is — bouw je precies dat stuk en blijf je de rest kopen. De grens verschuift in de tijd, dus herzie de verdeling regelmatig.