Build, buy of partner:
wat past bij jouw situatie?

Wanneer kiest een organisatie bij AI voor build, buy of partner?

De keuze tussen build, buy of partner bij AI hangt af van vier vragen: is de toepassing onderscheidend, wat kost ze in jaar vijf, wie moet de uitkomst kunnen sturen en hoe verloopt de exit. Zelf bouwen past alleen bij wat een organisatie in de markt onderscheidt, kopen bij alles wat een commodity is, en een partner bij toepassingen waar sturing op de uitkomst nodig is zonder de techniek te bezitten. De opzet die het vaakst standhoudt is een mengvorm: de bouwstenen kopen, de laag met eigen kennis zelf bouwen en voor de implementatie een partner inschakelen.

Blijft zelf bouwen bij build, buy of partner goedkoop na jaar één?

Vaak keert de conclusie om wanneer het onderhoud vijf jaar wordt doorgerekend en met een licentie vergeleken: bij build, buy of partner is bouwen goedkoop in jaar één.

Is kopen bij twijfel tussen build, buy of partner de goedkoopste manier om te leren wat nodig is?

Bijna altijd: bij twijfel tussen build, buy of partner is kopen bijna altijd de goedkoopste manier om te leren wat werkelijk nodig is. Later bouwen kan alsnog, met een scherpere specificatie.

Bron: artikel van Dave Willemstein. Bijgewerkt: oktober 2026.

Waarom deze keuze zwaarder weegt bij AI

Bij klassieke software was build-or-buy vooral een kostenvraag. Bij AI komen er drie factoren bij die de afweging structureel anders maken.

Ten eerste verandert de onderliggende technologie sneller dan je afschrijvingstermijn. Een model dat je vandaag zelf fijnafstemt, kan over achttien maanden worden ingehaald door een generiek model dat het out-of-the-box beter doet en goedkoper is. Ten tweede is het onderhoud fundamenteel anders: modellen verslechteren stilletjes als de werkelijkheid verschuift, en dat vraagt permanente monitoring in plaats van incidenteel patchen. Ten derde zit de waarde vaak niet in het model maar in je data en je werkproces, en die twee koop je sowieso niet.

De vier vragen die de keuze bepalen

Vraag 1: Is dit onderscheidend, of is het een commodity?

De enige goede reden om zelf te bouwen is dat het je onderscheidt in de markt. Niet dat het leuk is, niet dat je team het kan, en niet dat het goedkoper lijkt.

Een harde toets: kan je belangrijkste concurrent hetzelfde resultaat morgen kopen bij een leverancier? Als het antwoord ja is, is het een commodity, hoe technisch interessant het ook is. Documentextractie, spraakherkenning, samenvatten, standaard classificatie: allemaal commodity. De manier waarop jij die bouwstenen combineert met je eigen data en processen: daar kan wél onderscheid zitten.

In de praktijk is hooguit tien tot twintig procent van wat organisaties willen bouwen werkelijk onderscheidend. De rest wordt gebouwd omdat het kan.

Vraag 2: Wat kost het in jaar vijf?

Bouwen is goedkoop in jaar één. Je hebt een team, het bouwt iets, het werkt. De kosten die daarna komen worden zelden meegerekend:

• Modelmonitoring en hertraining als de data verschuift
• Bijhouden van de onderliggende modellen en API-versies
• Beveiliging, logging en auditspoor
• Documentatie en kennisoverdracht bij verloop
• De opportuniteitskosten van engineers die dit onderhouden in plaats van iets nieuws bouwen

Een vuistregel uit de praktijk: het jaarlijkse onderhoud van een zelfgebouwde AI-toepassing ligt tussen de 20% en 40% van de oorspronkelijke bouwkosten. Reken dat vijf jaar door en vergelijk dat met een licentie. Vaak keert de conclusie om.

Vraag 3: Wie moet de uitkomst kunnen sturen?

Dit is de vraag die partneren rechtvaardigt. Er zijn toepassingen waarbij je geen behoefte hebt aan het bezitten van de techniek, maar wél aan invloed op hoe de uitkomst tot stand komt. Denk aan risicomodellen, prijsstelling, of iets wat richting klanten communiceert namens jouw merk.

Een standaardproduct geeft je die invloed zelden. Zelf bouwen geeft je volledige invloed maar ook de volledige last. Een partnerconstructie (waarbij een leverancier bouwt en beheert, maar jij de regels, drempels en evaluatiecriteria bepaalt) zit daar tussenin. Het werkt als je het contractueel goed regelt en het gaat mis als je het op vertrouwen doet.

Vraag 4: Hoe kom je er weer vanaf?

De exitvraag hoort in het ontwerp, niet in de verlengingsdiscussie over drie jaar. Bij elk van de drie opties ziet exit er anders uit:

• Build: exit betekent iemand vinden die jouw codebase begrijpt. Het risico zit in sleutelpersoonafhankelijkheid en ontbrekende documentatie.
• Buy: exit betekent je data en je geconfigureerde logica eruit krijgen. Leg vóór ondertekening vast in welk formaat en binnen welke termijn.
• Partner: exit betekent overdracht van bouw én kennis. Neem een overdrachtsclausule op met een concreet dossier, niet met een intentie.

De hybride vorm die het vaakst werkt

In de meeste trajecten die ik begeleid, is het antwoord geen van de drie in zuivere vorm. De opzet die het vaakst standhoudt:

• Koop de bouwstenen. Modellen, infrastructuur, standaardcomponenten. Dit is waar leveranciers schaalvoordeel hebben dat jij nooit haalt.
• Bouw de laag waar jouw kennis in zit. De regels, de prompts, de evaluatiesets, de koppeling met jouw processen. Dit is klein in omvang en groot in waarde.
• Partner voor de implementatie. Maar houd het eigenaarschap van de evaluatiecriteria bij jezelf.

Concreet: een organisatie die documentverwerking automatiseert, koopt het taalmodel en het platform, bouwt zelf de veldextractieregels en de testset met tweehonderd beoordeelde dossiers, en laat de integratie doen door een partner. De testset is het waardevolste onderdeel en kost het minste geld.

Drie situaties waarin de keuze duidelijk is

Bouw als het direct raakt aan waarom klanten voor jou kiezen, je de data exclusief hebt, en je een team hebt dat dit over vijf jaar nog steeds kan onderhouden.

Koop als er drie of meer serieuze leveranciers zijn, de functionaliteit stabiel is, en je voornaamste zorg time-to-value is.

Partner als de techniek volwassen is maar de toepassing gevoelig, en je wel wilt sturen op de uitkomst maar niet op de codebase.

Twijfel je nog? Dan is kopen bijna altijd de goedkoopste manier om te leren wat je werkelijk nodig hebt. Je kunt later alsnog bouwen, met een scherpere specificatie en zonder dat je een jaar hebt verloren.