AI-consultancy versus zelf bouwen: wat is voor het MKB verstandiger?

Wat elk van de twee echt betekent

AI-consultancy inhuren betekent dat iemand van buiten meekijkt, de kansen benoemt en een plan oplevert. Zelf bouwen betekent dat je eigen mensen — of een nieuwe hire — het uitzoeken en in elkaar zetten. In beide gevallen is de vraag niet "wie is slimmer", maar "waar zit de kennis van jouw proces, en wie zet die om in iets dat werkt".

De denkfout is dat het een strikte keuze is. In de praktijk is de winnende opzet meestal een mengvorm: iemand met ervaring die het bouwt, samen met de mensen bij jou die het werk elke dag doen. De kennis van het proces zit bij jou; de kennis van het bouwen huur je in. Wie die twee uit elkaar trekt, betaalt voor de overdracht ertussen.

De verborgen kosten van zelf bouwen

Zelf bouwen lijkt goedkoop: geen bureau, geen uurtarief van buiten. De rekening komt later. Iemand intern bouwt iets dat draait zolang hij er is; vertrekt hij, dan heb je software die niemand meer begrijpt. Dat heet sleutelpersoonsrisico, en bij een bedrijf van twintig man is het echt.

Daarnaast onderschat bijna iedereen het onderhoud. Een koppeling die vandaag werkt, breekt zodra je boekhoudpakket een update krijgt. AI-modellen veranderen, leveranciers wijzigen hun API. Zelf bouwen is niet één project maar een verplichting die blijft.

• Sleutelpersoonsrisico: de bouwer vertrekt en niemand kent het systeem nog
• Onderhoud dat niemand had ingepland: updates, gewijzigde API’s, nieuwe modellen
• Leertijd: je eigen mensen doen het ernaast en maken de fouten die een ervaren bouwer al kent
• Geen tweede paar ogen op beveiliging, AVG en de EU AI Act
• Het werk dat blijft liggen terwijl je beste medewerker met AI zit te stoeien

De verborgen kosten van losse AI-consultancy

Advies apart inkopen voelt zuiver: eerst weten wat je moet doen, dan pas bouwen. Op papier klopt dat. In de praktijk zit tussen advies en uitvoering een overdracht, en daar gaat het meestal mis. De adviseur beschrijft wat er moet gebeuren in jouw woorden; de bouwer moet raden wat er bedoeld is en inventariseert alles opnieuw.

Je betaalt dat twee keer. En advies dat geschreven is zonder te weten hoe het gebouwd wordt, beschrijft vaak een duurdere oplossing dan nodig — wie nooit bouwt, merkt niet dat een koppeling die op papier één regel is, drie weken werk kost. Het klassieke eindresultaat is een adviesrapport in een la, omdat er bij jou niemand is die het een jaar lang bewaakt.

De derde weg: advies en bouwen bij één partij

Er is een tussenweg die de nadelen van allebei vermijdt: één partij die adviseert én bouwt, samen met jouw mensen. Geen overdracht tussen denken en doen, want het is dezelfde persoon. Geen sleutelpersoonsrisico, want het draait op standaardtechniek met documentatie en je krijgt de code en je data mee. En het advies is realistisch, want wie het straks zelf moet bouwen, verzint geen oplossing van drie weken waar één dag volstaat.

Het eerlijke nadeel: wie adviseert én bouwt, verdient aan de uitvoering. Dat maakt zo iemand niet onafhankelijk. Daarom zeggen wij ook "niet doen" als iets te weinig oplevert, en verwijzen we je naar een onafhankelijke adviseur wanneer je een oordeel nodig hebt dat niets te verkopen heeft — bijvoorbeeld voor een bank of een aanbesteding.

• Geen overdracht tussen adviseur en bouwer, dus je betaalt de inventarisatie één keer
• Realistisch advies, want dezelfde persoon moet het waarmaken
• Geen sleutelpersoonsrisico: standaardtechniek, documentatie, code en data zijn van jou
• Beveiliging, AVG en EU AI Act zitten in het bouwen, niet als factuur achteraf
• Klein beginnen, meten, uitbreiden — in plaats van een groot plan dat vooraf al vastligt

Wanneer zelf bouwen wél de juiste keuze is

Zelf bouwen is verstandig als je de kennis in huis hebt én houdt. Heb je een eigen ontwikkelaar of een IT-team dat er tijd voor krijgt en blijft, dan is intern bouwen vaak het beste: de kennis van je proces en de bouwkennis zitten dan op één plek, en je bent van niemand afhankelijk.

Het werkt ook voor iets kleins en afgebakends: een script dat één bestand omzet, een simpele koppeling die je met een standaardtool zelf klikt. Daar een bureau voor inhuren is zonde. De grens ligt bij "moet dit jaren blijven draaien en met mijn bedrijf meegroeien" — dan wordt onderhoud de echte vraag.

• Je hebt een eigen ontwikkelaar of IT-team dat tijd krijgt én blijft
• Het is klein, afgebakend en met een standaardtool zelf te klikken
• Het hoeft niet jarenlang mee te groeien met je bedrijf
• Je wilt bewust kennis opbouwen in je eigen team, en accepteert de leertijd

Hoe je de afweging voor jouw bedrijf maakt

Reken niet alleen het bouwen, maar drie jaar. Zet naast de bouwkosten het onderhoud, het risico als je bouwer vertrekt, en de tijd die je eigen mensen kwijt zijn. Dan valt de vergelijking vaak anders uit dan op het eerste gezicht.

1. 01Bepaal of dit iets eenmaligs is of iets dat jaren moet meedraaien en meegroeien.
2. 02Kijk of je de bouw- én onderhoudkennis in huis hebt en houdt, niet alleen nu.
3. 03Reken drie jaar door: bouwen plus onderhoud plus risico, niet alleen de eerste rekening.
4. 04Weeg mee wie de kennis van je proces heeft — die zit vrijwel altijd bij jouw eigen mensen.
5. 05Twijfel je, doe dan eerst de gratis AI-scan en een kernsessie; daarna weet je wat het is en beslis je met cijfers.

Veelgestelde vragen

Wat we hiervoor doen

Verder lezen

Andere onderwerpen

Twijfel je tussen inhuren en zelf bouwen?

Doe eerst de gratis AI-scan: vijf minuten, een score en een prijsindicatie. Daarna kijken we in een kernsessie van een dagdeel op je werkvloer wat het bij jou zou opleveren en of zelf bouwen, uitbesteden of samen bouwen het verstandigst is — met een eerlijk go of no-go.