Zelf bouwen, kopen of uitbesteden: AI-systemen

Voor wie? CTO’s, IT-managers en architecten die een AI-initiatief moeten positioneren: zelf bouwen, een SaaS-product kopen, of het uitbesteden aan een partner.

Kort: De klassieke make-vs-buy-logica gaat ervan uit dat capaciteiten stabiel zijn. Bij AI-systemen zijn ze dat niet, en dat verandert de afweging fundamenteel. Dit artikel geeft je vier dimensies om de beslissing te structureren. De workshop voor leaders werkt dit door aan de hand van je eigen use cases.

Zes maanden geleden heeft een team iets gebouwd. Ze hadden een use case: interne documentenverwerking, eerste screening van klantvragen, iets in die richting. Er was geen kant-en-klare oplossing, dus ze hebben het zelf gebouwd. Twee maanden engineering, een werkend systeem, trots gevoel.

Vorige week verscheen een SaaS-product dat hetzelfde doet voor €80 per maand.

Of de omgekeerde situatie: een organisatie heeft een SaaS-tool ingekocht. Mooie demo, snelle integratie, redelijke prijs. Drie maanden later bleek dat de tool de domeinspecifieke terminologie niet aankan. Alle data stroomde via servers buiten Europa, en het contract sloot modeltraining op ingevoerde data niet uit.

Beide situaties komen vaker voor dan ze zouden moeten. Ze komen voort uit hetzelfde probleem: de klassieke make-vs-buy-logica gaat ervan uit dat capaciteiten stabiel zijn. Bij AI-systemen zijn ze dat niet.

Wat zes maanden geleden niet kant-en-klaar bestond, bestaat vandaag misschien als SaaS. Tegelijk veroudert zelfgebouwde infrastructuur sneller als de onderliggende modellen doorontwikkelen. De vendor-afhankelijkheid is groter dan bij klassieke software. AI-leveranciers verwerken je data via API-koppelingen, hanteren contractuele voorwaarden met juridische gevolgen, en staan verder af van het “je koopt een licentie”-model.

Dat vraagt om een beslissingskader dat verder gaat dan prijs en snelheid.

Vier dimensies die de keuze bepalen

Strategische differentiatie. Is de AI-functionaliteit deel van je kerncompetentie, of is het ondersteunend? Als je product of dienst rechtstreeks gebouwd is op een AI-systeem (bijvoorbeeld een geautomatiseerde beoordeling die je marktpositie bepaalt), dan geeft zelf bouwen je de controle die je nodig hebt. Voor ondersteunende use cases (samenvatting van interne documentatie, standaard IT-vragen), zijn kopen of uitbesteden efficiënter. Valkuil: teams die elke use case als strategisch beschouwen en alles zelf bouwen, ook waar dat niet loont.

Data en privacy. Welke data verwerkt het systeem? SaaS-oplossingen verwerken data op servers van derden. Voor gevoelige gegevens (klantdata, juridische documenten, financiële records) heeft dit GDPR- en EU AI Act-implicaties. Veel SaaS-aanbieders gebruiken ingevoerde data standaard voor modelverbetering (contractuele uitsluiting vereist). Lokale of private cloud-opstellingen geven meer controle, maar vereisen meer infrastructuur. Dit rechtvaardigt niet automatisch zelf bouwen, maar het is een due-diligence-punt dat vóór aankoop moet worden onderzocht.

Aanpasbaarheid. Hoe domein-specifiek zijn je vereisten? Voor generieke taken (samenvatten, classificeren, standaardvragen beantwoorden), volstaan SaaS-oplossingen doorgaans. Voor domein-specifieke taken (juridische analyse, medische documentverwerking, technische engineeringsbeslissingen) volstaan generieke modellen minder. Aanpassing vereist fine-tuning, retrieval-augmented generation, of architectuurkeuzes in de orchestrationlaag. Dit zijn vormen van zelf bouwen, ook met ingekochte basismodellen.

Interne capaciteit. Heeft je team de kennis om een AI-systeem te bouwen én te onderhouden? Onderhouden wordt vaak onderschat: evaluatie, monitoring, updates bij modelwijzigingen. Ontbrekende kennis rechtvaardigt niet automatisch uitbesteding. Soms is interne investerering beter. Uitbesteding zonder intern begrip creëert duur lock-in, zowel financieel als besluitvormingstechnisch.

De drie opties uitgewerkt

Zelf bouwen is aangewezen als de use case strategisch differentiërend is, je team de capaciteit heeft, en de vereisten domein-specifiek zijn. Kosten zijn hoog aan het begin (engineering, infrastructuur, evaluatie-tooling) maar dalen per use case op schaal. Teams onderschatten vaak productiegereedheid. Een prototype dat intern indruk maakt, is geen productiesysteem. Evaluatie, foutafhandeling, monitoring en modelupdates vragen elk hun eigen investering. Begin met een prototype dat je zelf kunt beoordelen voordat je productiebudget vrijmaakt.

Kant-en-klaar kopen werkt goed voor generieke use cases waarbij snelheid prioriteit heeft en data-privacy-eisen beheersbaar zijn. Kosten zijn voorspelbaar, maar schaalbaarheid kan onverwacht duur worden. Vraag twee dingen vooraf: gebruikt de vendor je data voor modeltraining, en wat zijn de exitkosten? Lock-in in AI-SaaS zit zelden in de licentie; het zit in data-afhankelijkheid en de integraties die je opbouwt.

Uitbesteden is relevant als de use case afgebakend is, je team de kennis niet heeft en je die ook niet intern wil opbouwen. Risico: eindigt de relatie, dan heb je geen intern begrip van het systeem. Zorg dat het contract kennisoverdracht omvat en dat je zelf de werking van het systeem kunt beoordelen, niet alleen de uitkomsten.

De hybride aanpak: hoe het er in de praktijk uitziet

De meeste organisaties die AI-systemen serieus inzetten, werken niet met één van de drie opties. Ze stapelen ze.

Het fundament (groot taalmodel) kopen ze in via OpenAI, Anthropic of Google — dat is kopen. Bovenop dit fundament bouwen ze hun eigen orchestration: de logica voor informatieflow, toolgebruik en evaluatie. Dat is zelf bouwen. Specifieke deeltaken (PDF-extractie, berichtclassificatie) worden met kant-en-klare tools of uitbesteding opgelost.

Het resultaat is een gestapeld systeem waarbij elke laag zijn eigen make-vs-buy-beslissing heeft. De fout die teams maken: die beslissing impliciet laten in plaats van expliciet. Ze kopen het fundament en bouwen de orchestration. Later merken ze pas dat ze voor een specifieke deeltaak een vendor hebben gekozen die hun data exporteert naar systemen buiten hun controle.

EU AI Act: deployers zijn verantwoordelijk

Eén aspect dat in de beslissing mee moet: je bent als “deployer” verantwoordelijk voor compliance onder de EU AI Act (de leverancier als “provider” voor systeemdocumentatie). Vraag leveranciers om conformiteitsdocumentatie vóór je koopt, niet achteraf. Voor high-risk toepassingen (HR, kredietverlening, kritieke infrastructuur, wetshandhaving) gelden aanvullende verplichtingen ongeacht je keuze.

Beslissen

De make-vs-buy-vs-outsource-beslissing verdient meer aandacht dan een éénmalige afweging. Capaciteiten verschuiven, afhankelijkheden zijn complex, juridische context evolueert. Organisaties die per use case en per systeemlaag nadenken, bouwen een aanpasbare portfolio. Organisaties die de beslissing impliciet laten, merken later dat ze in afhankelijkheden gevangen zitten die ze nooit bewust hebben gekozen.

Eén ding om vooraf te weten: “uitbesteden” hierboven is de systeembouw zelf. We leveren dat niet. We helpen bij aanpak, playbook en technische due diligence, niet implementatie. Wie bouwt, heeft belang bij bepaalde keuzen. Dat willen we niet hebben.

De workshop voor leaders helpt je dit kader toepassen op de AI-initiatieven in je organisatie: welke use cases kopen, welke bouwen, en hoe je de governance inricht voor wat je uitbesteedt.