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 u vier dimensies om de beslissing te structureren. De workshop voor leaders werkt dit door aan de hand van uw 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 blijkt dat de tool de domeinspecifieke terminologie niet aankan, dat alle data via servers buiten Europa stroomt, en dat het contract modeltraining op ingevoerde data niet uitsluit.

Beide situaties komen vaker voor dan ze zouden moeten — en 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. En de vendor-afhankelijkheid is groter dan bij klassieke software: AI-leveranciers verwerken uw data via API-koppelingen, hanteren contractuele voorwaarden met juridische consequenties, en staan verder van het “u koopt een licentie”-model dan u misschien denkt.

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 uw kerncompetentie, of is het ondersteunend? Als uw product of dienst rechtstreeks gebouwd is op een AI-systeem — zeg, een geautomatiseerde beoordeling die uw marktpositie definieert — dan geeft zelf bouwen u de controle die u nodig heeft. Is de use case ondersteunend, zoals het samenvatten van interne documentatie of het beantwoorden van standaard-IT-vragen, dan is kopen of uitbesteden efficiënter. De 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 klantdata, juridische documenten of financiële records heeft dat implicaties onder GDPR en de EU AI Act. Veel SaaS-aanbieders gebruiken ingevoerde data standaard voor modelverbetering — tenzij u dat contractueel uitsluit. Lokale of private cloud-opstellingen geven meer controle, maar vereisen meer infrastructuurcapaciteit. Dit is geen reden om automatisch voor zelf bouwen te kiezen, maar het is een due-diligence-punt dat vóór aankoop beantwoord moet zijn.

Aanpasbaarheid. Hoe domein-specifiek zijn uw 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. Ze werken met de terminologie en regels van uw domein niet zonder aanpassing. Aanpassen kan door fine-tuning, door retrieval-augmented generation, of door architectuurkeuzes in de orchestrationlaag. Dat zijn allemaal vormen van zelf bouwen, ook als u een basismodel inkoopt.

Interne capaciteit. Heeft uw team de kennis om een AI-systeem te bouwen én te onderhouden? Onderhouden is het deel dat vaak wordt onderschat: evaluatie, monitoring, updates bij modelwijzigingen. Als die kennis ontbreekt, hoeft dat niet automatisch een reden te zijn om uit te besteden. Soms is het reden om intern te investeren. Uitbesteden zonder intern begrip van het systeem creëert een afhankelijkheid die later duur is om te doorbreken — niet alleen financieel, maar ook in beslissingsvermogen.

De drie opties uitgewerkt

Zelf bouwen is aangewezen als de use case strategisch differentiërend is, uw team de capaciteit heeft, en de vereisten domein-specifiek zijn. De kosten zijn hoog aan het begin — engineering tijd, infrastructuur, evaluatie-tooling — maar dalen per use case op schaal. Het risico dat teams onderschatten: productiegereedheid. Een prototype dat intern indruk maakt, is geen productiesysteem. Evaluatie, foutafhandeling, monitoring en modelupdates vragen elk hun eigen investering. Richtlijn: begin met een prototype dat u zelf kunt beoordelen voordat u productiebudget vrijmaakt.

Kant-en-klaar kopen werkt goed voor generieke use cases waarbij snelheid prioriteit heeft en data-privacy-eisen beheersbaar zijn. De kosten zijn voorspelbaar, maar schaalbaarheid kan onverwacht duur worden. Twee vragen voor aankoop: gebruikt de vendor uw data voor modeltraining, en wat zijn de exitkosten als u later overstapt? Vendor lock-in in AI-SaaS zit zelden in de licentie, maar in data-afhankelijkheid en de integraties die u opbouwt.

Uitbesteden is relevant als de use case afgebakend is, uw team de kennis niet heeft en u die ook niet intern wil opbouwen. Het risico: als de relatie eindigt, heeft u geen intern begrip van het systeem. Richtlijn: zorg dat het contract kennisoverdracht omvat en dat u 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 — een groot taalmodel — kopen ze in via een API van OpenAI, Anthropic of Google. Dat is kopen. Bovenop dat fundament bouwen ze hun eigen orchestration: de logica die bepaalt welke informatie het model krijgt, welke tools het mag aanroepen, hoe uitkomsten worden geëvalueerd. Dat is zelf bouwen. Specifieke deeltaken — data-extractie uit PDF’s, classificatie van inkomende berichten — lossen ze op met kant-en-klare tools of uitbesteding.

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. Dan kopen ze het fundament, bouwen ze de orchestration, en merken ze pas later dat ze voor een specifieke deeltaak een vendor hebben gekozen die hun data exporteert naar een systeem dat buiten hun controle valt.

EU AI Act: deployers zijn verantwoordelijk

Eén aspect dat in de beslissing mee moet: als u AI-systemen inkoopt of uitbesteedt, bent u als “deployer” verantwoordelijk voor compliance onder de EU AI Act. De leverancier is als “provider” verantwoordelijk voor systeemdocumentatie en conformiteitsbeoordelingen — maar de verantwoordelijkheid voor de inzet ligt bij u.

Praktisch betekent dit: vraag leveranciers om hun conformiteitsdocumentatie vóór u koopt, niet achteraf. Voor high-risk AI-toepassingen — waaronder systemen die worden ingezet in HR, kredietverlening, kritieke infrastructuur of wetshandhaving — gelden aanvullende verplichtingen die ongeacht uw make-vs-buy-keuze op u rusten.

Beslissen

De make-vs-buy-vs-outsource-beslissing verdient meer aandacht dan een éénmalige afweging aan het begin van een project. De capaciteiten verschuiven, de afhankelijkheden zijn complexer, de juridische context evolueert. Organisaties die hier per use case en per laag van het systeem over nadenken, bouwen een portfolio van keuzes dat aanpasbaar is. Organisaties die de beslissing impliciet laten, merken later dat ze gevangen zitten in afhankelijkheden die ze nooit bewust hebben gekozen.

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