Wanneer een bedrijf besluit AI in te zetten, is de eerste impuls doorgaans dezelfde: neem een data scientist aan. Begrijpelijk — de data scientist geldt als de iconische rol van het AI-tijdperk. In de praktijk zien wij echter dat precies deze aanwerving de eerste fout is die het project vertraagt of tot stilstand brengt.
De juiste teamsamenstelling hangt af van wat u precies bouwt: een RAG-systeem op bedrijfsdocumenten verschilt van een voorspellend anomaliemodel op een productielijn, dat op zijn beurt verschilt van een autonome agent in de klantenservice. Elk van deze projecten vereist een andere mix van mensen — en voor sommige heeft u überhaupt geen intern team nodig.
Waarom een data scientist niet het eerste antwoord is
Een data scientist richt zich traditioneel op exploratieve data-analyse, statistisch modelleren en experimenteren. Ze zijn waardevol wanneer u niet weet wat u in de data zoekt — bij voorspellende analytics, het ontdekken van patronen in historische data, bij A/B-testen.
De meeste AI-projecten die bedrijven werkelijk nodig hebben, gaan echter niet over patroonontdekking. Het zijn systeemintegraties: een LLM gekoppeld aan de bedrijfsdocumentatie, een agent die bestellingen controleert in het ERP, automatisering van e-mailtriage. Daarvoor hebt u iemand nodig die productieklare software kan bouwen — niet exploratieve analyse.
In de praktijk ziet dit er zo uit: het bedrijf neemt een data scientist aan, die mooie experimenten uitvoert in een Jupyter-notebook, de resultaten zien er veelbelovend uit. Dan komt de vraag: "Wanneer zetten we dit in productie?" — en het blijft stil. Een data scientist is geen software-engineer, kent Docker, CI/CD, API-ontwerp en monitoring van productiesystemen niet. Het project strandt in de prototype-fase.
Rollen die u werkelijk nodig hebt
ML/AI engineer — kern van het team
Dit is de rol die de meeste bedrijven onderschatten, maar die cruciaal is voor productie-AI. De ML/AI engineer combineert twee competenties: hij begrijpt modellen (fine-tuning, embedding, inference, prompt engineering) én kan deze mogelijkheden inpakken in robuuste software (API, queue-systemen, monitoring, testen).
In de praktijk: een ML engineer stelt een RAG-pipeline op met hybride zoeken, kiest het juiste embedding-model, stemt de retrieval af en stelt het resultaat beschikbaar als productie-API met observability. Een data scientist zou de eerste stap voor zijn rekening nemen; een software-engineer zonder ML-context de laatste. Een ML/AI engineer beheerst allebei.
Voor bedrijven die bouwen met frontier-modellen via API (Claude, GPT, Gemini) is de rol van ML/AI engineer nog belangrijker — hier gaat het minder om training en meer om orkestratie, prompt engineering, tool calling en integraties. Meer over wat kosten en betrouwbaarheid beïnvloedt, leest u in het artikel Kosten van een AI-agent in productie.
Domeinexpert — zonder hem gaat het project nergens naartoe
Dit is de rol die bedrijven het vaakst weglaten, terwijl het ontbreken ervan de op één na meest voorkomende oorzaak van mislukking is (na slechte datakwaliteit).
Een domeinexpert is iemand die het proces dat u automatiseert diepgaand begrijpt. In de praktijk gaat het om een ervaren operator, afdelingshoofd, technicus of vakspecialist. Deze persoon weet niets van LLM, maar weet precies: - Welke antwoorden correct zijn en welke alleen correct lijken - Waar de randgevallen, uitzonderingen en situaties liggen waarbij het systeem faalt - Hoe een "goed resultaat" eruitziet vanuit bedrijfsperspectief — niet vanuit een accuraatheidsmetriek
Zonder domeinexpert optimaliseert de ML engineer een metriek, geen werkelijke waarde. Het resultaat is een systeem dat er op de demo geweldig uitziet en in productie steeds dezelfde fouten herhaalt.
De domeinexpert hoeft geen fulltime teamlid te zijn. Vier tot acht uur per week voor het beoordelen van outputs, het kalibreren van evaluaties en feedbackrondes volstaat.
Data engineer — alleen wanneer u een dataprobleem hebt
Als uw AI-project afhankelijk is van datapipelines — opschonen, transformeren, streamen van machine-events, integratie van meerdere bronnen — hebt u een data engineer nodig. Dit profiel bouwt de infrastructuur die AI betrouwbaar van data voorziet.
Als u echter een RAG-systeem bouwt op bestaande documenten of een agent die bestaande API's aanroept, is een data engineer in de eerste fase niet kritisch. Overschat de behoefte aan deze rol niet — voeg hem toe wanneer u werkelijk een dataprobleem oplost, niet preventief.
MLOps engineer — vanaf een bepaalde schaal
MLOps omvat het deployen van modellen, het monitoren van drift, versiebeheer en retraining-pipelines. Het is een kritische rol, maar pas wanneer u modellen in productie hebt die onderhouden en bijgewerkt moeten worden.
Voor eerste projecten vervult de ML engineer deze functie doorgaans zelf — het is overbodig een dedicated MLOps-specialist te hebben zolang er niets te beheren valt. Voeg hem toe wanneer u meer dan drie tot vijf productiemodellen beheert of retraining-cycli moet verwerken.
Product owner — onderschatte maar onmisbare rol
Elk AI-project heeft iemand nodig die verantwoordelijk is voor welk probleem u oplost en hoe u succes meet. Zonder deze rol optimaliseert de ML/AI engineer technisch interessante zaken, geen bedrijfswaarde.
De product owner (of AI product manager) definieert succesmetrieken vóór de start, prioriteert use-cases naar ROI en verzorgt de communicatie tussen het technische team en de stakeholders. Deze rol kan worden ingevuld door een interne projectmanager met voldoende technisch inzicht — het hoeft geen AI-specialist te zijn.
Minimaal functioneel team voor het eerste project
Op basis van praktijkervaring voor een typisch eerste productie-AI-project (RAG-systeem, agent, LLM-integratie):
- 1× ML/AI engineer (fulltime tijdens implementatie)
- 1× domeinexpert (parttime, 4–8 uur/week)
- 1× product owner / bedrijfsverantwoordelijke (parttime, 2–4 uur/week)
Dit is het minimaal functionele team. Minder dan drie mensen in deze samenstelling is een risicovolle configuratie — ofwel ontbreekt de technische competentie, ofwel ontbreekt de verbinding met de werkelijke bedrijfscontext.
Voor een complexer project (multi-agent systeem, fine-tuning van een eigen model, integratie met meerdere systemen) breidt u uit met een data engineer en een MLOps-specialist. Wanneer fine-tuning van een model zinvol is, behandelen wij in het artikel RAG vs. fine-tuning — beslissingsframework.
Intern team vs. partner — wanneer wat
Dit is een vraag die bedrijven te laat stellen — doorgaans pas wanneer het wervingsproces vastloopt of het project stagneert.
Bouw een intern team wanneer: - AI de kern is van uw product of een belangrijke concurrentievoordeel (niet ondersteuning voor een bestaand proces) - U een langetermijnhorizon hebt (12+ maanden) en een stabiel product waarop AI wordt gebouwd - U volledige controle nodig hebt over data, modellen en pipeline (gereguleerde omgeving, GDPR-kritische systemen) - U snel en in korte cycli wilt itereren — een extern beheerd team is daarin trager
Schakel een externe partner in wanneer: - U aan uw eerste of tweede AI-project werkt en nog geen interne competentie hebt opgebouwd - U een snel resultaat nodig hebt (3–6 maanden) — werven en inwerken van een intern team duurt doorgaans 4–9 maanden - De use-case goed gedefinieerd is en na de lancering alleen onderhoud nodig heeft, geen actieve doorontwikkeling - U kennisoverdracht wilt — een goede partner levert niet alleen de oplossing, maar leert ook het interne team ermee te werken
Over de keuze tussen eigen implementatie en een kant-en-klare oplossing schreven wij uitgebreider in het artikel Build vs. buy AI-oplossing.
Het hybride model werkt goed: een externe partner levert het eerste project, het interne team leert mee en neemt de verantwoordelijkheid voor onderhoud en doorontwikkeling over. Essentieel is dat de partner deze overdracht actief ondersteunt — en niet alleen levert en vertrekt.
Veelgemaakte fouten bij teamsamenstelling
U zoekt een "AI-expert" — en vindt er geen
Een algemene AI-expert bestaat niet. Elke werkelijk ervaren specialist heeft een specialisatie: inference en serving, fine-tuning, agentorkestratie, RAG-architectuur. Zoek iemand met concrete relevantie voor uw use-case — geen universeel genie.
U onderschat de tijdsinvestering van de domeinexpert
Bedrijven plannen doorgaans "een paar uur per maand voor consultaties". In de praktijk heeft een kwalitatief AI-project regelmatige, consistente betrokkenheid van de domeinexpert nodig — geen eenmalige kickoff aan het begin en een aftekening aan het eind.
U verwisselt experimenteren met productie-expertise
Een kandidaat die u indrukwekkende prototypes in een Colab-notebook toont, heeft daarmee nog niet bewezen dat hij ervaring heeft met productiedeployment. Vraag naar concrete voorbeelden: wat heeft u precies in productie gedraaid? Hoe hebt u monitoring aangepakt? Hoe reageerde u op een regressie in kwaliteit? De antwoorden onderscheiden een experimentator van een engineer.
U schaalt op vóór u de use-case valideert
We zien het regelmatig: een bedrijf neemt een volledig team aan (drie tot vijf mensen), koopt GPU-infrastructuur en ontdekt na zes maanden dat de use-case niet waardevol genoeg was voor productiedeployment. Valideer eerst met een minimaal team en een externe oplossing; scale-up volgt wanneer u weet wat werkt.
Signalen dat het team de verkeerde samenstelling heeft
Op basis van praktijkervaring — waarschuwingssignalen die wij bij klanten zien:
- Het project zit langer dan drie maanden vast in de prototype-fase — doorgaans ontbreekt een ML/AI engineer met productie-ervaring of een product owner die exitcriteria definieert
- Het systeem "werkt niet in de praktijk" ondanks goede benchmarks — de domeinexpert ontbreekt in de evaluatiecyclus
- Het team kan de vraag "hoe meet u succes" niet beantwoorden — er is geen product owner, of de metrieken zijn puur technisch gedefinieerd (accuracy, F1) zonder bedrijfsverband
- Werving duurt 6+ maanden zonder resultaat — het profiel is te algemeen of de salariseisen sluiten niet aan op de markt; overweeg een externe partner voor de eerste fase
Hoe te beginnen als u net start
Als u aan uw eerste AI-project begint en geen intern team hebt, raden wij aan:
- 1.Definieer de use-case en succesmetrieken vóór elke wervingsactiviteit — zonder deze stap weet u niet wie u zoekt
- 2.Identificeer intern een domeinexpert — dit is een rol die u niet van buiten kunt inhuren
- 3.Overweeg een externe partner voor de eerste fase — snellere start, lager risico, mogelijkheid tot kennisoverdracht
- 4.Start parallel met de pilot met het werven van een ML/AI engineer — het team is op het juiste moment klaar om het project over te nemen
Meer over hoe u de eerste 90 dagen van een AI-project structureert, leest u in het artikel Hoe te beginnen met AI in uw bedrijf.
Veelgestelde vragen
Heb ik een data scientist nodig voor een AI-project met LLM?
In de meeste gevallen niet — althans niet als primaire rol. Een data scientist is waardevol bij exploratieve analyse en statistisch modelleren. Projecten gebouwd op LLM (RAG, agents, integraties) hebben in de eerste plaats een ML/AI engineer nodig die zowel modellen als productiesoftware begrijpt. Een data scientist kan het team later aanvullen — bijvoorbeeld bij evaluatie of outputanalyse.
Hoeveel mensen zijn er minimaal nodig voor een productie-AI-project?
Op basis van praktijkervaring zijn drie rollen het minimum — een ML/AI engineer (fulltime), een domeinexpert (parttime) en een product owner/bedrijfsverantwoordelijke (parttime). Een team van één persoon of zonder domeinexpert heeft een aanzienlijk hoger risico op mislukking of vastlopen in de prototype-fase.
Is het beter een team aan te nemen of met een externe partner te werken?
Dat hangt af van uw horizon en waar u nu staat. Voor het eerste project raden wij een externe partner of hybride model aan — dat is sneller en verlaagt het risico van kostbare werving vóór validatie van de use-case. Een intern team is zinvol wanneer AI de kern is van uw product en u een langetermijninvesteringshorizon hebt.
Hoe herken ik of een kandidaat productie-ervaring heeft en niet alleen prototype-ervaring?
Vraag naar concrete deployments: wat draaide er precies in productie? Wat was het datavolume of het aantal gebruikers? Hoe loste u monitoring en foutieve situaties op? Hoe reageerde u toen de kwaliteit achteruitging? Prototypisten antwoorden algemeen; productie-engineers beschrijven concrete beslissingen en afwegingen.
Moet de domeinexpert AI begrijpen?
Nee — en dat is ook niet wenselijk. De domeinexpert moet het proces begrijpen dat u automatiseert: kunnen beoordelen of de output correct is, randgevallen identificeren en definiëren wat een "goed resultaat" is vanuit bedrijfsperspectief. Technische AI-kennis is hier geen vereiste.
*Werkt u aan de teamsamenstelling voor een AI-project of overweegt u wat u intern bouwt en wat u aan een partner overlaat? We plannen graag een gratis kennismakingsgesprek in. We helpen u beoordelen welke rollen u werkelijk nodig hebt — en wanneer externe samenwerking meer oplevert dan werven.*