Build vs buy: zelf een AI-oplossing bouwen of kopen?

Op een overleg met een productiedirecteur valt een vraag die we bij bijna elk bedrijf horen dat vandaag over AI nadenkt: "Kopen we een kant-en-klare tool, of moeten we het zelf bouwen?" De vraag klinkt eenvoudig, maar in werkelijkheid combineert ze drie afzonderlijke beslissingen — over differentiatie, over data en over kosten in de tijd. Wie die vraag in de eerste vijftien minuten van het overleg beantwoordt, beantwoordt hem doorgaans verkeerd.

Dit artikel biedt een raamwerk dat we in de praktijk hebben gevalideerd op tientallen implementaties. Het gaat niet om een geloofsoorlog tussen "buy everything" en "build everything" — beide zijn extremen, beide zijn verkeerd. Het gaat erom te weten welke laag van elke concrete oplossing je moet kopen, welke je moet bouwen en waar de grens ligt waarboven het ene of het andere niet meer loont.

De basis van het raamwerk — drie lagen van elke AI-oplossing

Elke productie-AI-oplossing is op te splitsen in drie lagen:

1. 1.Model en inferentie — LLM, embedding-model, serving-infrastructuur. Dit is een commodity. OpenAI, Anthropic, Google, of open-weight modellen zoals Qwen 3, Mistral, Llama 4 — allemaal bieden ze een solide basis die honderden miljoenen dollar heeft gekost om te ontwikkelen, en die u voor een fractie van die prijs afneemt.
2. 2.Orkestratie en retrieval — RAG-pipeline, agentlogica, memory, tools, guardrails. Dit is de laag die de kwaliteit van de output bepaalt. Ze is deels commodity (frameworks zoals LangGraph, LlamaIndex, vectordatabases zoals Qdrant zijn open-source en volwassen), maar de specifieke invulling van uw implementatie — uw data, uw processen, uw edge cases — vereist eigen werk.
3. 3.Domeinlaag — prompts, datasets, fine-tuning, evaluaties, UI, integratie met systemen. Dit is waar differentiatie ontstaat. Niemand anders heeft uw productiedata, uw SOP-documenten of uw klanthistories. Deze laag kunt u niet kopen — u kunt haar alleen bouwen.

Simpel gezegd: koop laag 1 en een deel van laag 2, bouw laag 3 en de rest van laag 2. Het probleem ontstaat wanneer een bedrijf laag 1 koopt bij een vendor die laag 2 én laag 3 inpakt in een propriëtair platform — en het bedrijf niet beseft wat het tekent.

Wanneer kopen

Kopen is zinvol als de use case commodity is — dat wil zeggen dat uw probleem ook door vijftig andere bedrijven wordt opgelost en er een volwassen markt van oplossingen bestaat. Voorbeelden:

• Klantenondersteuning met FAQ (Zendesk AI, Intercom, Freshdesk AI) — standaardtaak, kant-en-klare integraties, snelle onboarding.
• Meeting-samenvatting en transcriptie (Otter.ai, Fireflies, Microsoft Copilot) — geen differentiërende waarde, leveringssnelheid is cruciaal.
• Code-assistent voor het team (GitHub Copilot, Cursor, Codeium) — generieke use case waarbij individuele fine-tuning marginale verbetering oplevert tegen onevenredige kosten.
• HR-screening van de eerste ronde (er bestaan meerdere volwassen platformen) — commodity-probleem, gereguleerde markt, kant-en-klare compliance.

Naast commodity geldt: koop als snelheid naar productie belangrijker is dan prestatie. In bepaalde gevallen is een 80%-oplossing die morgen beschikbaar is beter dan een 95%-oplossing die over acht maanden beschikbaar is.

Het laatste argument voor kopen: als uw bedrijf nu niet beschikt over, en in de nabije toekomst ook niet zal beschikken over een AI-team met de benodigde competenties, zal de onderhoudskost van een eigen oplossing hoger uitvallen dan een SaaS-abonnement — zowel qua kosten als qua onbetrouwbaarheid.

Wanneer bouwen

Bouwen is zinvol in drie situaties:

Differentiatie via data. Als u data hebt die niemand anders heeft — productielogboeken van machines, klachtenhistorie, interne technische normen, meetresultaten — en als die data een betere prestatie kunnen opleveren dan de concurrentie, moet u bouwen. Een kant-en-klare oplossing integreert die data niet; wie er een koopt, betaalt voor generieke kwaliteit. Fine-tuning of RAG op eigen data maakt van een generiek model een domeinspecialist — maar dat vereist uw eigen werk.

Veiligheid en regulatoire vereisten. Als u actief bent in een sector waar data het netwerk niet mag verlaten (gezondheidszorg, energie, defensie, financiële instellingen met NDA-data), vallen SaaS-oplossingen simpelweg af. Het antwoord is hier on-prem LLM — lokale inzet van een open-weight model met vLLM of Ollama, waarbij inferentie op uw eigen hardware draait en geen enkele token het netwerk verlaat. Dit is niet alleen een technische keuze — het is een compliance-vereiste.

Processpecifieke eisen die een kant-en-klaar product niet ondersteunt. Als uw use case niet-standaard stappen bevat — bijvoorbeeld integratie met een ouder SCADA-systeem, verwerking van een propriëtair documentatieformaat, of een multi-step agentworkflow die specifiek aansluit op uw productieprocessen — dekt geen enkel kant-en-klaar platform dit zonder uitgebreide maatwerk. En die maatwerk leidt u naar hetzelfde werkniveau als een eigen oplossing, maar dan met andermans code eronder.

Het hybride model — de realiteit van de meeste productie-implementaties

In de praktijk hebben we zelden een puur build- of puur buy-implementatie gezien. Een typische architectuur die werkt:

• Kopen: LLM API (Claude Sonnet, GPT, Gemini Flash) of open-weight model via vLLM op eigen server; vectordatabase (Qdrant is de de-facto standaard voor de Belgische en Nederlandse markt — EU-hosted, Apache 2.0); embedding-model (de open-weight BGE-familie is productiebewezen).
• Bouwen: RAG-pipeline met specifieke retrieval-strategieën voor uw type documenten; promptlaag die bedrijfsprocessen en terminologie weerspiegelt; fine-tuning op domeinvocabulaire als het kwaliteitsverschil meetbaar is; integratie met ERP/SCADA/MES-systemen; evaluatie en prestatiemonitoring in productie.

Deze hybride aanpak geeft u de snelheid van commerciële lagen (model en database zijn klaar op dag één) én de differentiatie van eigen lagen (domeinlogica blijft van u). Tegelijk verlaagt het het lock-in-risico — als er morgen een beter model uitkomt, wisselt u de API-aanroep zonder de hele oplossing te herschrijven.

Total cost of ownership — waar de berekening kantelt

De meest voorkomende fout bij de build vs buy-beslissing is het vergelijken van de SaaS-abonnementsprijs met de eenmalige ontwikkelkosten. De juiste berekening moet de totale eigendomskosten (TCO) over 3–5 jaar omvatten:

SaaS / buy TCO: - Maandelijks abonnement (schaalt met aantal gebruikers of datavolume — houd dit in de gaten) - Onboarding en integratie (zelden gratis) - Downtime door API-wijzigingen of servicevoorwaarden (we hebben tariefverhogingen van 40–80 % gezien bij contractverlenging) - Verborgen kosten: data verlaat het bedrijf → privacyrisico → potentiële compliance-kosten

Build TCO: - Initiële ontwikkeling (doorgaans de dominante post in jaar 1) - Hardware bij on-prem (GPU-server — indicatief €15–60k voor een productie-implementatie afhankelijk van de vereisten, afgeschreven over doorgaans 3 jaar) - Personeelskosten voor onderhoud en iteratie (niet nul — realistisch berekenen) - Afhankelijkheid van interne kennis (vertrek van een sleutelingenieur = risico)

Cruciale observatie: SaaS lijkt voordelig in jaar 1, bouwen loont vanaf jaar 2–3. Als de use case tijdelijk is (pilotproject, hypothesetest, seizoensgebonden), koop. Als hij strategisch en langdurig is, heeft build doorgaans een lagere TCO en meer controle.

Lock-in — het risico dat onderschat wordt

Vendor lock-in heeft in een AI-context drie vormen die erger zijn dan klassieke software lock-in:

Data lock-in. Wanneer uw bedrijfsdata (documenten, histories, annotaties, feedback) uitsluitend op het platform van de vendor leven, is migratie pijnlijk tot onmogelijk. Verifieer vóór aankoop altijd: kan ik 100 % van mijn data exporteren in een standaardformaat? Zo niet, dan zit u in lock-in vanaf dag één.

Model lock-in. Als u promptlogica, een fine-tuningset of evaluaties hebt gebouwd voor één specifiek model (bijv. GPT-4-klasse), vereist migratie naar een ander model herschrijven, ook als het nieuwe model beter is. Oplossing: een abstractielaag in de orkestratie, waarbij het model een configuratie is en geen hardcode.

Integratie lock-in. Sommige platformen bieden connectors voor uw systemen — ERP, CRM, SCADA. Als die connectors propriëtair en ongedocumenteerd zijn, wisselt u van platform alleen tegen de prijs van het herschrijven van integraties. Geef altijd de voorkeur aan open API's en standaardprotocollen.

Goed nieuws: open-weight modellen (Llama 4, Qwen 3, Mistral — de meeste onder Apache 2.0 of een vergelijkbare commerciële licentie) hebben de model lock-in de afgelopen twee jaar aanzienlijk verminderd. Frontier-prestaties zijn lokaal bereikbaar zonder gebondenheid aan een specifieke provider.

Beslissingskaart — 5 vragen vóór de conclusie

Loop vóór de definitieve beslissing met het team door deze vijf vragen:

1. 1.Is de use case commodity? Als tientallen bedrijven in dezelfde sector hetzelfde probleem op dezelfde manier oplossen, is een kant-en-klare oplossing waarschijnlijk efficiënter.
2. 2.Zijn onze data een bron van differentiatie? Zo ja, moet u bouwen — een kant-en-klaar product verwerkt ze niet zodanig dat ze u voordeel opleveren.
3. 3.Mogen data het netwerk verlaten? Zo niet, dan is build/on-prem de enige optie.
4. 4.Hebben we (of kunnen we verzekeren) een team voor bouwen en onderhoud? Bouwen zonder competent team is slechter dan kopen — de samenstelling van het team voor een AI-project is een apart onderwerp dat parallel moet worden aangepakt.
5. 5.Hoe lang plannen we deze oplossing te gebruiken? Tot 12 maanden of als de use case onzeker is → koop. 2+ jaar met duidelijke resultaten → build of hybrid pakt beter uit.

Wanneer de antwoorden op deze vragen geen duidelijke winnaar aanwijzen, gaat het doorgaans om een hybride geval — basale lagen kopen, domeinspecialisatie bouwen.

Veelgemaakte fouten die we zien

De volledige stack kopen bij één vendor zonder te verifiëren of elke laag werkelijk best-in-class is. Platformen die alles doen, doen niets uitstekend. Steeds meer succesvolle productie-implementaties combineren componenten van verschillende providers: model-API van de ene kant, vectordatabase open-source, orkestratie eigen.

Bouwen zonder gedefinieerde use case. "We willen AI, dus we bouwen het zelf" is een expeditie zonder kaart. De meeste projecten die we hebben zien mislukken, hadden vóór de start geen succes-metric gedefinieerd — en dus ook geen manier om te weten of wat ze bouwen waarde heeft. ROI van AI-projecten moet vanaf dag één worden gemeten.

Onderschatting van de kosten van data. Voordat u kunt bouwen, moet u over data beschikken — schoongemaakt, gestructureerd, beschikbaar in een formaat dat een LLM kan verwerken. Volgens de Cisco AI Readiness Index beoordeelt slechts ~34 % van de bedrijven hun data-gereedheid als voldoende. Als u bij de overige 66 % hoort, is de datapipeline uw eerste project, niet de AI zelf.

Het EU AI Act negeren. Vanaf augustus 2026 gelden concrete verplichtingen voor bedrijven die AI-systemen inzetten in gereguleerde contexten. Als u een platform koopt, controleer dan of de vendor compliance-documentatie levert. Als u bouwt, is de compliance-documentatie uw eigen verantwoordelijkheid. Dit aspect nu negeren kan betekenen dat u de oplossing later moet omschrijven.

Veelgestelde vragen

Is het zinvol een kant-en-klare oplossing te testen als proof-of-concept en die daarna te vervangen door een eigen oplossing?

Ja, maar met een voorwaarde: de pilot moet uw concrete use case testen, niet een generieke demo. Als de pilot met een gekochte oplossing aantoont dat de use case waarde heeft, beschikt u over bewijs voor de investering in een eigen build. Belangrijk is dat de pilotarchitectuur de datalogica scheidt van het platform — migratie verloopt dan eenvoudiger.

Wat betekent "open-weight model" vanuit licentie- en commercieel gebruik?

Modellen zoals Qwen 3 of Mistral zijn uitgebracht onder de Apache 2.0-licentie — u kunt ze commercieel gebruiken zonder licentiekosten. Llama 4 heeft een eigen licentie (gratis commercieel gebruik tot een bepaald maandelijks actieve gebruikers-limiet). Controleer altijd de actuele licentievoorwaarden van het specifieke model en de specifieke versie vóór inzet.

Is on-prem implementatie realistisch voor een bedrijf zonder groot IT-team?

Ja, als de use case afgebakend is. Eén GPU-server met Ollama en een kleiner open-weight model (bijvoorbeeld Qwen 3 8B of Phi-4 14B) kan een ervaren ingenieur in een dag uitrollen. Veeleisender is een productie-implementatie met hoge beschikbaarheid, monitoring en CI/CD — dat vergt meer. De juiste keuze voor een bedrijf zonder AI-team is doorgaans een beheerd on-prem-oplossing met externe ondersteuning, niet self-managed infrastructuur.

Wanneer is fine-tuning onderdeel van een "build"-strategie en wanneer niet?

Fine-tuning is zinvol wanneer u het model wilt specialiseren op uw taalregister, terminologie of outputformaat — en wanneer u over voldoende kwalitatieve trainingsdata beschikt (indicatief 5 000+ paarvoorbeelden voor een basale SFT). Als u geen data heeft, of als het probleem goed oplosbaar is met een goed ontworpen RAG-pipeline, is fine-tuning een vroegtijdige optimalisatie. Meer over deze beslissing in het artikel RAG vs fine-tuning.

Wat is de meest voorkomende oorzaak van budget-overschrijding bij build-projecten?

Uit onze praktijk: onderschatting van evaluatie en iteratie. De eerste versie bouwen duurt voorspelbaar lang — maar meten of het werkt, identificeren waar het faalt en dat repareren duurt opnieuw even lang. Projecten die hier vanaf het begin rekening mee houden, leveren op tijd en binnen budget. Projecten die ervan uitgaan dat de eerste versie productie-gereed is, niet.

*MP Industrial Solutions helpt bedrijven bij de build vs buy-beslissing met cijfers in de hand — van het in kaart brengen van use cases via TCO-berekeningen tot de eerste productie-implementatie. Als u voor deze beslissing staat, beoordelen wij graag samen uw concrete situatie.*