Waarom intern bouwen vaker misloopt dan verwacht
De redenering is begrijpelijk: eigen mensen kennen het proces, er is geen leveranciersafhankelijkheid, en op papier lijkt het goedkoper. Maar wat de berekening mist, is de opportunity cost. Een goed ingenieur die acht maanden bezig is met het bouwen van een documentverwerkingspijplijn, doet dat ten koste van iets anders. En als die ingenieur halverwege vertrekt, of als het probleem complexer blijkt dan gedacht, heb je een half systeem en een leeg plekje in het team. Intern bouwen werkt goed als je al een team hebt met relevante ervaring in het specifieke domein, als het systeem geen operationele afhankelijkheden heeft die snel moeten draaien, en als je een tijdshorizon van meer dan een jaar kunt accepteren. Is dat niet het geval, dan is de interne route vaak duurder dan het lijkt.
Wanneer is uitbesteden juist de verkeerde keuze?
Uitbesteden heeft een eigen valkuil: je koopt een oplossing voor een probleem dat de externe partij nooit zo goed begrijpt als jijzelf. Dat is geen verwijt aan de leverancier, het is een structureel gegeven. Generieke AI-bureaus of projectbureaus leveren dikwijls een systeem op dat werkt in de demo-omgeving maar vastloopt zodra het echte data ziet, echte uitzonderingen tegenkomt, en echte collega's het moeten bedienen. De vraag die je moet stellen voordat je uitbesteedt: wie wordt eigenaar van de code, de data en het systeem na oplevering? Als het antwoord 'de leverancier' is, of 'dat regelen we later', loop je het risico van lock-in zonder dat je het doorhebt. Een goede externe partij werkt toe naar eigenaarschap bij jou, niet bij zichzelf.
Wat maakt een domein-specifiek AI-project anders dan een generiek one?
Veel AI-projecten mislukken niet door de techniek, maar doordat de techniek los staat van de operatie. Een transportplanner die een AI-systeem krijgt dat orders groepeert op gewicht maar nooit op rijtijd, gebruikt het systeem na twee weken niet meer. Een inkoper die een documentverwerker krijgt die 90% van de facturen goed leest maar de 10% uitzonderingen weggooit zonder signaal, heeft meer werk dan zonder systeem. Domein-specifieke AI vraagt om mensen die het domein kennen en de techniek snappen, of om een externe partij die bereid is lang genoeg in de operatie te zitten om het verschil te leren. Dat is iets anders dan een standaard implementatie van een bestaand pakket.
Operating partner, projectbureau of intern team: wat zijn de echte verschillen?
Een projectbureau levert een project op en vertrekt. Een intern team bouwt maar heeft zelden de breedte om zowel domeinkennis als AI-architectuur te combineren. Een operating partner blijft betrokken totdat het systeem draait, en draagt dan over. Het verschil zit niet in de contractvorm maar in wie verantwoordelijkheid neemt voor het resultaat in productie, niet voor de oplevering op papier. Bij een operating partner hoort ook eerlijkheid over wanneer het mis kan gaan: een go/no-go per mijlpaal, geen megacontract met een vaste scope die na zes maanden niet meer klopt. Die mijlpalenaanpak beschermt de klant, niet de leverancier.
Hoe maak je de keuze concreet?
Stel jezelf drie vragen. Eerste: heb ik intern iemand die dit domein én AI-architectuur begrijpt, en heeft die persoon tijd? Als het antwoord nee is op een van beide, is intern bouwen een risico, geen voordeel. Tweede: hoe domein-specifiek is het probleem? Gaat het om standaard documentverwerking of tekstclassificatie, dan zijn er kant-en-klare oplossingen die het werk doen. Gaat het om een proces dat sterk afhangt van jargon, uitzonderingen en werkwijzen die alleen in jouw sector bestaan, dan is maatwerk vrijwel altijd nodig. Derde: wie wordt eigenaar van code en data? Als de externe partij die vraag ontwijkt, is dat een signaal. Een partij die bouwt voor jouw eigenaarschap, geeft je de code, de documentatie en de overdracht, ook als de samenwerking stopt. Dat is de basisvoorwaarde voor een gezonde uitbestedingsrelatie.