AI-ontwikkeling uitbesteden: wat je delegeert, wat je houdt

De meeste teams die AI-ontwikkeling willen uitbesteden verliezen tijd aan dezelfde twee fouten: ze delegeren het verkeerde deel, en ze nemen aan voor een onderzoeksprobleem terwijl ze een productprobleem hebben. Goed gedaan, zet uitbesteden van AI binnen weken een werkende feature voor gebruikers neer. Slecht gedaan, koop je een knap prototype dat nooit live gaat. Zo doe je het zodat je het eerste krijgt, van een team dat AI op zijn eigen producten bouwt en oplevert voordat het iemand bij een klant plaatst.

Bepaal wat je uitbesteedt, en wat je houdt

De reflex bij het uitbesteden van AI-ontwikkeling is om "de AI" in zijn geheel weg te geven. Dat is de stap die misgaat. De schonere scheiding is: houd de delen die jouw business zijn, en delegeer de delen die engineering zijn.

Houd in huis:

• De probleemdefinitie. Wat de feature voor je gebruikers moet doen, en waarom, is niet iets dat een leverancier je kan aanreiken.
• Beslissingen over datagovernance. Welke data gebruikt mag worden, waar die heen mag, en wie ervoor verantwoordelijk is.
• Je definitie van "goed". De lat waaraan het werk wordt afgemeten, bepaal jij.

Delegeer het bouwen, de integratie en het betrouwbaarheidswerk. Daar verdient een extern team zijn plek, en dat is het deel dat slecht schaalt als je het probeert te doen met mensen die je niet hebt. De eerste praktische vraag is niet "welke leverancier", maar "welke van deze houd ik zelf". Heb je dat verkeerd, dan kan zelfs een sterke partner het project niet redden.

Dit bepaalt ook wie je aanneemt. Zoals we behandelen in hoe je AI-engineers aanneemt, verbergt de functietitel vier verschillende banen, en de meeste teams laten de verkeerde doorgaan. Als je een AI-ontwikkelteam inhuurt, heb je bijna altijd productbouwers nodig, geen onderzoekers.

De meeste producten hebben RAG nodig, geen onderzoekslab

Dit is de duurste misvatting bij het uitbesteden van AI-ontwikkeling: dat je iemand nodig hebt om een model te trainen.

Een large language model is al getraind. De waarde zit in bijna elk product in het goed inbouwen van een bestaand model in je software, niet in het uitvinden van een nieuw model. De standaardmanier om het accuraat te maken op je eigen informatie is retrieval-augmented generation, die antwoorden tijdens de query baseert op je documenten en data. Fine-tuning, laat staan vanaf nul trainen, is zwaarder, kost meer onderhoud, en is zelden het eerste wat een product echt nodig heeft.

Dus als je AI-ontwikkeling uitbesteedt, koop je meestal oordeelsvermogen in productengineering, geen PhD. Een team dat naar fine-tuning grijpt voordat het goede prompting en retrieval heeft geprobeerd, is een team dat je budget uitgeeft aan iets bewijzen dat niet bewezen hoefde te worden. Besteed je specifiek machine learning-werk uit, vraag dan wat ze eerst zouden proberen, en luister of het antwoord begint bij jouw probleem of bij hun favoriete techniek.

Het model doet er minder toe dan het engineeringwerk eromheen

Een AI-demo werkend krijgen is makkelijk. Hem betrouwbaar, goedkoop en snel houden voor echte gebruikers is het echte werk, en dat is wat een prototype van een product onderscheidt.

Dat werk heeft een naam: MLOps. Evaluatie die je kunt vertrouwen, monitoring op kwaliteit en kosten, versiebeheer voor modellen en prompts, en de pipelines die updates veilig uitrollen. Vraag je een partner om AI-features in productie te bouwen, dan is dit wat je echt koopt. Hetzelfde geldt voor alles wat agentic is: een AI-agent die acties kan ondernemen, kan de verkeerde ondernemen, dus verschuift het engineeringwerk naar guardrails en observability.

Een nuttige test als je AI-ontwikkeldiensten beoordeelt: vraag hoe ze evalueren en monitoren wat ze opleveren, niet alleen welk model ze gebruiken. Leveranciers die met de modelnaam openen, verkopen het makkelijke deel. Leveranciers die met evaluatie openen, verkopen het deel dat blijft werken na de lancering.

Kies het juiste samenwerkingsmodel

Het uitbesteden van AI-ontwikkeling komt in twee vormen, en het verschil is wie het werk dagelijks aanstuurt, niet wie de code schrijft.

Staff augmentation plugt een of twee AI-engineers in je team. Ze sluiten aan bij je standups en je tech lead stuurt ze aan. Het is het juiste gereedschap als je een helder plan en een specifiek gat hebt. Een dedicated team neemt een deel van het werk op zich en brengt zijn eigen coördinatie mee, dus jij zet de richting en huurt het resultaat. We pluizen de afweging uit in staff augmentation vs een dedicated team, en de korte versie geldt ook voor AI: een paar mensen die een gat vullen is augmentation, een eenheid die de AI-feature bezit is een dedicated team.

De fout is het model kiezen op prijs in plaats van op wie deze mensen zou moeten aansturen. Is het eerlijke antwoord "wij niet", koop jezelf dan geen managementbaan waar je geen tijd voor hebt.

Wat het echt kost

Het uurtarief is het minst nuttige getal in het gesprek, en juist het getal waar elke vergelijking zich op blindstaart. Wat je echt uitgeeft om werkende AI op te leveren, is het tarief plus onboarding, plus de aansturingsoverhead, plus het herwerk dat uit miscommunicatie voortkomt. We zetten echte ranges en de verborgen rekensom in wat nearshore-softwareontwikkeling echt kost, en AI-werk volgt dezelfde curve, alleen met schaarsere, duurdere mensen aan de bovenkant.

Het talent is echt schaars. De seniors die een AI-idee naar productie kunnen brengen worden overal opgebod, een druk die zichtbaar is in de markt in onderzoeken als de jaarlijkse Stack Overflow Developer Survey. Precies daarom doet het ertoe waar je werft. Senior nearshore AI-talent met volledige overlap op Midden-Europese tijd wint meestal op totale kosten van een optie ver weg die per uur goedkoper lijkt en je daarna terugbetaalt in verloren dagen.

Tijdzone, taal, en wie verantwoordelijk is voor het werk

AI-ontwikkeling is van nature ambigu en iteratief. Je levert iets op, kijkt hoe het zich gedraagt op echte input, en corrigeert. Die lus werkt alleen op snelheid als de mensen die het doen wakker zijn wanneer jij dat bent.

Daarom komen we steeds terug op de klok. Een blokkade op een AI-feature die om 10:00 wordt gemeld, hoort vóór de lunch opgelost te zijn, niet 's nachts beantwoord, en zoals we betogen in nearshore vs offshore is volledige overlap binnen de werkdag wat een verspreid team als één team laat voelen. Voeg daar een persoon aan toe wiens naam je kent en die verantwoordelijk is voor het werk, en je hebt de meeste manieren weggenomen waarop AI-uitbesteding stilletjes mislukt.

Data, IP, en de exit

Het deel dat de leveranciersvriendelijke gidsen overslaan: de saaie clausules die jou beschermen.

• Datasecurity. Je geeft een derde partij toegang tot je data, dus sta op echte governance. Leveranciers die in lijn zijn met de AVG en certificeringen als ISO/IEC 27001 laten zien dat ze het serieus nemen.
• IP-eigendom. De modellen, prompts en code horen van jou te zijn, schriftelijk, voordat iemand begint.
• De exit. Weet hoe je het werk zou terugnemen en verder zou gaan als het niet werkt. Een partner die vertrouwen heeft in de relatie, deinst niet terug voor die vraag.

Wanneer je AI-ontwikkeling NIET moet uitbesteden

De eerlijke kanttekening die bijna niemand in de zoekresultaten je geeft: soms moet je het niet doen.

Is AI je kern, je verdedigbare onderscheid, en kun je de mensen om het te bouwen realistisch aannemen en behouden, bouw het dan in huis. Je belangrijkste capaciteit aan wie dan ook uitbesteden, hoe goed ook, is een strategisch risico, niet alleen een engineeringbeslissing. Besteed uit als je snel een of twee sterke mensen nodig hebt, als je een feature wilt opleveren zonder een heel team op te zetten, of als je een selectieproces nodig hebt dat al bestaat in plaats van er een te bouwen. Genoeg teams doen beide: een interne lead die de richting bezit, een uitbesteed team dat daartegen bouwt.

Dat is het model dat wij hanteren. De AI-engineers die we plaatsen via onze AI-ontwikkeling worden door een oprichter beoordeeld, tegen de norm hierboven, voordat ze ooit bij een klant komen, want de enige eerlijke manier om voor iemand in te staan is door diegene eerst op je eigen producten in te zetten. Wil je AI-ontwikkeling uitbesteden zonder de omweg van drie maanden, vertel ons dan wat je bouwt, en een oprichter zegt je eerlijk of wij de juiste keuze zijn, of dat je beter kunt aannemen. Het is dezelfde belofte die we overal doen: een team dat je zelf zou hebben aangenomen, geen plaatsing-en-succes-ermee. Zie hoe het werkt voor opdrachtgevers.

Bronnen: Stack Overflow Developer Survey, AVG, ISO/IEC 27001.