Waarom Custom AI vaak een dure fout is in recruitment

Het begint altijd met goede bedoelingen

‘We bouwen het zelf. Dan hebben we volledige controle.’ Het klinkt logisch. Jouw recruitmentproces is uniek. Jouw datastructuur is specifiek. Jouw klanten verwachten een bepaald format. Dus waarom zou je niet je eigen AI bouwen die precies doet wat jij nodig hebt?

Omdat het bijna altijd fout gaat. Niet door gebrek aan ambitie of talent, maar door een systematische onderschatting van de complexiteit, de kosten en de doorlooptijd. Het begint als een project van drie maanden en eindigt als een black hole die talent, tijd en budget opslokt.

Er is een tweede versie van dezelfde vergissing, en die is populairder: bouw de AI niet zelf, maar plak er een op het ATS dat je al draait. Dat klinkt goedkoper en pakt meestal slechter uit, want je erft elke beperking van een systeem dat is ontworpen voordat dit allemaal bestond — en je hebt nu twee leveranciers die naar elkaar wijzen zodra een veld niet gevuld wordt.

In dit artikel leg ik uit waarom zelf recruitment-AI bouwen in 95% van de gevallen een dure vergissing is, waarom er een plakken niet de veilige tussenweg is die het lijkt, en in welke 5% bouwen wél klopt.

De complexiteit die je onderschat

‘We pakken een speech-to-text API, hangen er een samenvattingsprompt aan, en schrijven het weg in ons systeem.’ Zo simpel lijkt het op papier. In een demo van een developer die het in een weekend bouwde, ziet het er indrukwekkend uit. Laten we de werkelijke complexiteit doorlopen.

Probleem 1: Spraakherkenning is moeilijker dan je denkt

Ja, er zijn speech-to-text API’s. Whisper, Google, Azure. Ze werken prima. In het Engels. In een stille omgeving. Met één spreker. Op een goede verbinding.

Maar in recruitment:

• Bel je in het Nederlands, Duits, Frans of een mix. Midden in een zin switcht de kandidaat naar Engels. Of de opdrachtgever gooit er een Duits woord tussendoor.
• Bel je vanuit de auto met wegruis, wind en tunnels.
• Praten twee mensen door elkaar in een Teams-vergadering. Of de kandidaat heeft kinderen op de achtergrond.
• Spreekt de kandidaat met een accent, een dialect of heel zacht.
• Zijn er namen, plaatsnamen en bedrijfsnamen die er goed uit moeten komen. ‘Van der Linden-Pietersen’ is niet triviaal voor een model.

De basisaccuratesse van een speech-to-text API is 85-90%. Voor recruitment heb je 95%+ nodig. Die 5-10% kost maanden werk aan domeinwoordenlijsten, foutcorrectie en evaluatie. En dan heb je nog steeds geen systeem dat zich over alle kanalen en omstandigheden consistent gedraagt.

Probleem 2: Samenvattingen zijn niet ‘even een prompt’

‘Maak een samenvatting van dit gesprek.’ Die prompt schrijft iedereen. In een demo ziet het er fantastisch uit. Maar een bruikbare recruitmentsamenvatting is veel meer dan dat:

• Het format moet passen bij het gesprekstype. Een intake is geen salesgesprek. Een opdrachtgeversgesprek levert andere informatie op dan een vervolggesprek met een kandidaat.
• Het moet specifieke velden herkennen en uitlezen. Niet ‘de kandidaat wil 55.000 verdienen’, maar het getal 55000 in het veld salarisverwachting, met het juiste datatype.
• Het moet inconsistenties signaleren. De kandidaat zegt eerst ‘3 jaar ervaring’ en later ‘5 projecten in 4 jaar’. Wat klopt er? Het systeem hoort zijn hand op te steken in plaats van er een te kiezen.
• Het moet weten wanneer het niets moet zeggen. Kwam de opzegtermijn niet ter sprake, dan blijft dat veld leeg — want een plausibel verzonnen getal is erger dan een leeg veld, en dat soort fouten komt pas bij een opdrachtgever aan het licht.
• Het moet omgaan met ruis. Smalltalk, herhalingen, ‘sorry, ik stond op mute’. Eruit gefilterd zonder dat er iets relevants sneuvelt.
• En het moet in te stellen zijn per klant, per team, per recruiter, want opdrachtgever X wil een andere vorm dan opdrachtgever Y.

Eén prompt bouwen die dat allemaal doet, kost weken testen en itereren. Het onderhouden ervan, terwijl klanten veranderen en wensen zich opstapelen, kost maanden per jaar. En bij elke update van het onderliggende model mag je opnieuw testen.

Probleem 3: Wegschrijven in andermans systeem is een beest

Hier stranden de meeste projecten — of je nu zelf bouwt of iets erop plakt. Data wegschrijven in een bestaand ATS of CRM is niet ‘een API-call maken’. Het is een integratieproject dat niet ophoudt:

• De veldstructuur lezen. Welke velden bestaan? Welk type zijn ze? Welke opties zitten in de keuzelijsten? Welke validatieregels gelden?
• Data matchen met het juiste veld. ‘Fulltime’ matchen met de waarde ‘FT’ in een keuzelijst. ‘Beschikbaar per mei’ matchen met een datumformat.
• Omgaan met validatieregels. Datumformats die per omgeving verschillen. Numerieke velden die geen tekst accepteren. Verplichte velden die niet altijd beschikbaar zijn.
• Error handling. Wat als een veld niet bestaat? Wat als de API een fout teruggeeft? Wat als het systeem offline is? Wat als er een conflict is met een waarde die iemand net wijzigde?
• Meer dan één systeem ondersteunen. Bullhorn werkt fundamenteel anders dan de volgende leverancier. Elke integratie is een apart project met een eigen releasecyclus.

Eén native integratie bouwen kost 3-6 maanden. Vijf? Reken op 18 maanden en meer. Daarna onderhoud je ze, want API’s bewegen, velden veranderen en er komen nieuwe versies uit. Het is geen project, het is een doorlopende verplichting.

En hier zit de wending die de meeste kopen-of-bouwen-artikelen missen. Die moeilijkheid is geen argument om iemand in te huren die er al doorheen is gegaan. Het is een argument over architectuur: de pijn komt voort uit twee systemen die allebei denken dat zij de waarheid bevatten. Elke reconciliatiebug, elk conflict, elk ‘waarom staat dit veld leeg in het andere systeem’ komt uit die ene ontwerpkeuze. Daarom doet Simply het ook niet — data wegschrijven betekent hier een wijziging voorstellen op een dossier in hetzelfde systeem, die een mens goedkeurt. Er is geen tweede kopie die je bij moet houden.

Probleem 4: Gesprekken vastleggen over alle kanalen

Recruitment gebeurt niet in één kanaal, dus vastleggen moet online gesprekken, telefoongesprekken en het gesprek aan tafel dekken. Elk daarvan is een eigen engineeringprobleem:

• Online gesprekken native vastleggen via Google en Microsoft betekent leven binnen hun API-eisen, en die veranderen. Een update aan hun kant kan de jouwe op een dinsdag breken.
• Het met een meetingbot doen is makkelijker te bouwen en slechter in gebruik: hij verschijnt in het deelnemersoverzicht, en het eerste dat een kandidaat vraagt is wat dat account is.
• Telefoon en fysieke gesprekken vastleggen betekent desktop- en mobiele software uitbrengen en onderhouden, en dat is een ander vak dan een webapplicatie bouwen.
• Regels over toestemming, melding en bewaartermijn verschillen per land, en dat verkeerd doen is geen bug maar een juridisch risico.

Dit is geen weekendproject. Dit is een heel product, met eigen compliance-eisen, eigen onderhoud en eigen expertise.

De werkelijke kosten

Laten we realistisch zijn over het geld. Een custom AI-oplossing voor recruitment bouwen vereist minimaal:

• 2-3 AI/ML engineers (minimaal 18 maanden): €300.000 - €600.000 per jaar
• 1-2 backend developers voor integraties: €150.000 - €250.000 per jaar
• 1 product manager die het project stuurt: €100.000 - €150.000 per jaar
• Cloudinfrastructuur en opslag voor audio: €30.000 - €80.000 per jaar
• Speech-to-text API-kosten: €20.000 - €50.000 per jaar (afhankelijk van gespreksvolume)
• Model-API-kosten bij OpenAI of Anthropic: €10.000 - €40.000 per jaar
• QA en testen: €50.000 - €100.000 per jaar

Totaal eerste jaar: €660.000 - €1.270.000. En dat is conservatief. De meeste projecten gaan 30-50% over budget en 6-12 maanden over tijd. Dat is geen pessimisme, dat is het basispercentage van softwareontwikkeling.

Vergelijk dat met een licentie per gebruiker per maand. Core is €79 en Professional €99 per gebruiker per maand bij jaarlijkse facturatie, zonder creditsmodel en zonder opslag op je AI-verbruik — je koppelt je eigen sleutel en je provider factureert je rechtstreeks. Bij een team van twintig recruiters betaal je een fractie van wat bouwen kost, je draait volgende maand in plaats van over 18 maanden, en het onderhoud ligt bij iemand anders.

De verborgen kosten die niemand noemt

Naast de directe kosten zijn er de kosten die zelden in de businesscase staan:

• Afhankelijkheid van individuen. Als je lead engineer vertrekt — en dat gebeurt — heb je een systeem dat niemand anders begrijpt.
• Technische schuld. Snelle fixes tijdens de bouw worden permanent. Na een jaar zit je in een codebase die duur is om te veranderen.
• Training en documentatie. Je moet je eigen team opleiden, de documentatie schrijven en de support bemensen. Dat is voorgoed iemands werk.
• Beveiliging en certificering. ISO 27001 komt er niet als bijproduct bij. Dat is een apart traject van maanden en tienduizenden euro’s, en je moet het onderhouden, niet één keer halen.

Wanneer custom AI wél zin heeft

Er zijn echte uitzonderingen. Bouwen kan zinvol zijn als:

• Je een zeer specifieke use case hebt die geen enkel bestaand product dekt en die je met configuratie niet bereikt.
• Je 500+ recruiters hebt, waardoor schaalvoordelen tegen de kosten beginnen op te wegen.
• Je AI als core business ziet en er een product van wilt maken dat je aan anderen verkoopt.
• Je al een AI-team van vijf of meer engineers hebt met de expertise in huis.

Voor 95% van de recruitmentbedrijven geldt geen van deze punten. En zelfs dan is het vaak slimmer om een product te nemen dat al werkt en dat via een API of maatwerkintegratie uit te breiden voor het deel dat echt van jou is. Waarom de saaie 90% opnieuw bouwen om bij de interessante 10% te komen?

Het alternatief: kopen en configureren

De slimste aanpak voor de meeste bedrijven is: koop iets bewezens en configureer het. Niet bouwen, configureren. Maar dat woord betekent alleen iets als je kunt zeggen wát er configureerbaar is, dus hier de concrete versie.

Met Simply betekent dat:

• Je eigen datamodel inrichten. Objecten, velden en relaties zijn metadata in plaats van code, dus een veld toevoegen is een instelling. Het bereikt de parser, de filters, de documenten, de rapportage en de API zonder release. Dit is het deel dat ‘we hebben maatwerk nodig want ons proces is anders’ overbodig maakt.
• Samenvattingsformats instellen die passen bij je gesprekstypen en je klanten. Configuratie, geen code.
• De zes kant-en-klare koppelingen aanzetten — Gmail, Outlook, Google Calendar, Zoom, Slack en HubSpot. Eén OAuth-flow per workspace, en de tokens worden voor je ververst.
• Je eigen AI-sleutel koppelen, zodat je provider je rechtstreeks factureert en er structureel geen marge is om op te leggen. In het product zie je wat elk model en elke actie kostte, in euro’s in plaats van in tokens of credits.
• De rest op de publieke API bouwen, met eigen sleutels en ondertekende webhooks, voor de 5% die echt maatwerk is.

Dat kost geen 18 maanden en geen miljoen euro. Dat kost een dag inrichten en een uur per aanpassing, en iemand anders onderhoudt, update en verbetert het. Veertien dagen, het volledige product, zonder creditcard, als je de claim eerst wilt testen.

De opportuniteitskost

Het meest onderschatte argument tegen bouwen is de opportuniteitskost. Elke euro en elk uur dat je aan AI bouwen besteedt, besteed je niet aan:

• Het werven van meer kandidaten. Meer gesprekken, meer plaatsingen, meer omzet.
• Het verbeteren van je dienstverlening. Betere service, hogere tevredenheid, meer herhaalopdrachten.
• Het trainen van je recruiters. Betere gesprekstechniek, meer plaatsingen per persoon.
• Het laten groeien van je bedrijf. Nieuwe markten, nieuwe klanten, nieuwe diensten.

De vraag is niet: ‘Kunnen we dit bouwen?’ De vraag is: ‘Is dit de beste besteding van onze tijd en ons geld?’ Voor recruitmentbedrijven is het antwoord bijna altijd nee. Je bent een recruitmentbedrijf, geen softwarebedrijf. Focus op wat je goed kunt.

Het ‘we willen controle’ argument

Het meest gehoorde argument voor bouwen is controle. ‘We willen niet afhankelijk zijn van een externe leverancier.’ Begrijpelijk. Maar bedenk:

• Je bent al afhankelijk van je ATS-leverancier. Van je telecomprovider. Van Microsoft of Google voor je mail. Afhankelijkheid is onvermijdelijk in technologie; de enige vraag is welke soort je kiest.
• Bouwen creëert andere afhankelijkheden. Van je developmentteam. Van specifieke engineers. Van een codebase die alleen jij begrijpt, onderhouden door mensen die je moet zien vast te houden.
• De controle die je wint door te bouwen (aanpasbare code) verlies je aan complexiteit: moeilijker te onderhouden, trager te updaten, elk jaar duurder.

Echte controle zit niet in het bezitten van de code. Het zit in drie concrete dingen: een datamodel dat jij zelf inricht in plaats van een dat een product manager voor je koos, een rechtenmodel dat je aan een opdrachtgever kunt uitleggen, en een exportroute die je data eruit haalt onder dezelfde regels die binnen gelden — geen gijzeling, geen apart extractietraject.

Waar Simply zit: het is het bronsysteem

Even helder, want dit is het tegenovergestelde van wat de meeste tools in deze categorie zeggen. Simply is geen laag bovenop je ATS. Simply ís het ATS — het bronsysteem, de plek waar de kandidaat staat.

Dat heeft gevolgen die je moet meewegen voordat je het ermee eens bent:

• Er is geen terugschrijven en geen tweewegsynchronisatie met Bullhorn, Carerix of iets anders in die categorie. Van een ander systeem komen is een eenrichtingsmigratie van ongeveer vier weken, inclusief een veldmappingsessie waarin elk huidig veld een beslissing krijgt.
• Zes koppelingen, bij naam: Gmail, Outlook, Google Calendar, Zoom, Slack en HubSpot. Alles daarbuiten loopt via de publieke API.
• ISO 27001, met het certificaat op verzoek. Geen SOC 2-audit en geen externe pentest — dat schrijven we liever hier op dan dat een security-review het zelf ontdekt.
• Het platform en je kandidaatdata staan in Nederland, op infrastructuur die wij beheren. AI-verwerking is een apart feit en blijft apart: die draait in Europese regio’s, of op je eigen sleutel bij je eigen provider, en de modellen komen van OpenAI en Anthropic.

Niets daarvan is een reden om zelf te gaan bouwen. Het is de vorm van de beslissing: je voegt geen AI toe aan het systeem dat je hebt, je kiest een ander bronsysteem en richt dat in in plaats van het te programmeren. De eerlijke vergelijking met wat je vandaag draait is de volgende stap, en pleit die tegen overstappen, dan weet je dat liever nu dan in maand vier.

Wil je zien hoe dat in jouw omgeving landt? Lees hoe AI integreren in je ATS er echt uitziet, of neem contact op voor een demo met je eigen data op tafel.