Het volledige advies van Jamal over de GreenFox AI-assistent — inclusief marktbewijs, bouwvolgorde en de leer-lus.
Beste Renzo,
Dank voor de heldere opdracht. De afgelopen dagen heb ik drie dingen gedaan voordat ik dit definitieve advies schreef. Ik heb jullie vraag gecombineerd met wat Hamza en Marcella de afgelopen weken hebben verteld. Ik heb me verdiept in jullie wereld — social return, subsidies, de cao's, de systemen waar jullie mee werken — omdat ik vind dat je een bedrijf pas goed kunt adviseren als je de branche snapt, net zoals ik mijn eigen vak van binnenuit ken. En ik heb onderzocht wie dit soort dingen al heeft gebouwd, en wat daarvan te leren valt.
Het resultaat lees je hieronder, inclusief een werkende demo die je nu meteen zelf kunt proberen. Eén ding vooraf: mijn eerste versie van dit advies was te enthousiast. Deze versie is bewust kritischer, met meetpunten en zelfs een stopcriterium. Dat is geen gebrek aan vertrouwen — het is precies hoe ik zou willen dat iemand mij zou adviseren.
Wat mij het meest opvalt: de echte drijfveer achter dit project is niet gemak, maar risicospreiding. Marcella benoemde het zelf: een groot deel van jullie kernproces hangt aan één persoon, en als die onverwacht wegvalt heeft GreenFox direct een probleem. Dat besef stuurt mijn hele advies. Maar precies daarom moet ik het ook eerlijk brengen: dit wordt geen slimme bot die indruk maakt. Het moet een gecontroleerd werksysteem worden, met duidelijk eigenaarschap, meetbare doelen en harde grenzen. Zonder dat is het over een jaar weer een nieuw éénpersoonsrisico — alleen dan verstopt in een systeem in plaats van in een hoofd.
Praten over een kennisbot is abstract. Daarom heb ik er een gebouwd, gevuld met fictieve voorbeeldstof in de structuur van jullie Proceshuis (Sales, Werven & Selecteren, Ontwikkelen, Plaatsen):
Typ zelf een vraag en let op drie dingen, want dit zijn precies de gedragingen waar het om draait:
1. Antwoord mét bron. Vraag bijvoorbeeld "hoe snel moet ik een kandidaat voorstellen na een vacature-intake?" — je krijgt het antwoord plus de bronvermelding uit de kennisbank.
2. Eerlijk "weet ik niet". Vraag iets dat níet in de kennisbank staat (bijvoorbeeld de opzegtermijn bij fase C) — de bot zegt eerlijk dat hij het niet weet en verwijst naar een collega, in plaats van iets te verzinnen.
3. Harde privacygrens. Vraag iets over een kandidaat — de bot weigert vriendelijk: hij heeft geen toegang tot persoonsgegevens, en dat blijft zo.
Dit is een illustratie van de werking, geen kant-en-klaar product. Alle data is verzonnen. Hamza bouwt de echte versie na op jullie eigen server, met jullie echte Proceshuis. Maar het laat zien dat de kern — citaatplicht, scope-weigering, privacygrens — geen theorie is maar gewoon werkt.
Bestaat wat jullie willen al ergens? Kort antwoord: de losse onderdelen wél, het geheel niet. En ik wil de cijfers eerlijk brengen: veel komt van de leveranciers zelf. Het zijn aannemelijke aanwijzingen, geen garantie dat het bij GreenFox ook zo uitpakt.
De sterkste voorbeelden:
https://openai.com/index/moderna/
https://www.ibm.com/case-studies/ibm-askhr
https://blog.dust.tt/malt-customer-support/
En de keerzijde: het complete concept dat jullie voor ogen hebben — kennisbot, ochtendbriefing, conceptmails en contractbewaking, allemaal per medewerker persoonlijk — heb ik nergens als geheel gedocumenteerd gevonden. Dat kan betekenen dat jullie voorlopen. Het kan ook betekenen dat het te complex of te lastig beheerbaar is om in één keer te bouwen. Mijn inschatting is het eerste — maar de manier om dat te bewijzen is klein beginnen, niet alles tegelijk bouwen.
Het volledige marktonderzoek, met per voorbeeld een kritische beoordeling van hoe hard de cijfers zijn: /marktonderzoek.html
Ik heb me de afgelopen dagen verdiept in jullie wereld: het onderscheid tussen uitzenden, detacheren en werving & selectie, de subsidies (LKV, loonkostensubsidie, jobcoach-vergoeding, het doelgroepregister), PSO 30+, de ABU/NBBU-cao's, en jullie systeemlandschap (Carerix als frontoffice, Easyflex als backoffice, WIZZR voor de SROI-verantwoording). Vier inzichten daaruit veranderen het ontwerp:
1. GreenFox is vier bedrijven tegelijk — de bot moet dat respecteren. Een gewone recruiter hoeft vooral de juiste persoon te vinden. Jullie moeten tegelijk: kandidaten vinden, doelgroepstatus en subsidies snappen, begeleiding organiseren, én alles verantwoorden richting opdrachtgevers. Dat betekent: één generieke bot die "alles een beetje" weet gaat teleurstellen. De kennisbank moet vanaf dag één langs jullie procesrollen gestructureerd zijn — precies zoals het Proceshuis dat al doet.
2. De verantwoordingskant is minstens zo belangrijk als de matchkant. In jullie niche telt niet alleen óf iemand geplaatst is, maar of het dossier klopt en aantoonbaar is richting elke individuele opdrachtgever — elke gemeente hanteert eigen drempels en eigen invullingsregels. Den Haag hanteert bijvoorbeeld een richtlijn van 5 procent vanaf een opdrachtwaarde van €216.000 (https://www.denhaag.nl/nl/ondernemen/regeling-social-return-den-haag-help-werkzoekenden-aan-een-baan/ ), terwijl het regionale beleid Rijnmond 2023-2027 met een drempel van €50.000 en waarderingsmogelijkheden in plaats van een vast percentage werkt (https://lokaleregelgeving.overheid.nl/CVDR749463/1 ). Jullie kennen die verschillen beter dan wie ook — mijn punt is wat dit betekent voor de bot: regels per opdrachtgever moeten als aparte, gedateerde blokken in de kennisbank, nooit als één algemene waarheid.
3. Subsidieregels wijzigen, dus de kennisbank moet versiebeheer hebben. Een voorbeeld uit dit jaar: het loonkostenvoordeel voor de doelgroep ouderen is per 1 januari 2026 afgeschaft, terwijl het LKV banenafspraak voor nieuwe instroom juist structureel is gemaakt — en de precieze voorwaarden verschillen per doelgroep en blijven in beweging. Een bot die vorig jaar goed antwoordde, geeft dit jaar een fout antwoord als niemand de kennis bijwerkt. Daarom is de governance-vraag (wie is eigenaar van welke kennis, wie werkt bij, met datum en versie) geen bureaucratie maar de kern van betrouwbaarheid.
4. De regelgevingsdruk op jullie branche neemt toe — dat maakt dit project waardevoller. Vanaf 1 januari 2027 geldt de Wtta: uitleners moeten toegelaten zijn door de nieuwe toezichthouder, met eisen aan loonbetaling, aangiftes en een waarborgsom. Daarnaast handhaaft de Belastingdienst sinds 2025 weer actief op schijnzelfstandigheid (Wet DBA). Meer regels betekent meer kennis die iedereen paraat moet hebben — precies waar een goed onderhouden kennisassistent zijn waarde bewijst.
https://ondernemersplein.overheid.nl/wetswijzigingen/uitzendbureaus-moeten-gecertificeerd-zijn/
Bouw het als een interne webapplicatie binnen jullie Microsoft-omgeving, geen app-store-app. Hamza beheert Intune volledig en kan telefoons met één druk resetten, dus een webapp achter jullie eigen inlog is veilig bereikbaar op elke laptop en Fairphone die jullie al beheren.
Over de hardware: ik had eerder stellig geadviseerd om voor Apple-hardware met unified memory te kiezen boven een RTX-videokaart. Dat trek ik terug tot een aanname. Wat het beste werkt hangt af van welk model je draait, hoeveel mensen tegelijk vragen stellen en wie het beheert. Laat Hamza eerst een kleine benchmark draaien met de twee kandidaten en dezelfde testvragen, en beslis daarna. Een voorkeur is geen feit.
Werk in twee sporen voor het model zelf. Spoor één: bouw en test snel met een API van een grote aanbieder, in een EU-regio, zonder dat er ooit kandidaat- of klantgegevens in gaan. Spoor twee: draai parallel een lokaal of Europees model (Mistral is het bekijken waard) op de eigen server voor het gevoelige werk, zodat je nooit van één Amerikaanse partij afhankelijk bent.
De architectuur: één centrale motor, met daaromheen niet meteen persoonlijke bots per medewerker, maar eerst twee gedeelde assistenten. Dat is een bewuste bijstelling van mijn eerste advies. Begin met een kennisassistent (vraag-en-antwoord op het Proceshuis) en een schrijfassistent (conceptmails, nog niet per persoon). Pas als beide bewezen waarde leveren, ga je personaliseren per medewerker. Dat voorkomt dat je complexiteit bouwt voordat je weet of de basis werkt.
Eén belangrijke check vooraf, die ik nog niet eerder benoemde: laat Hamza vroeg in kaart brengen wat jullie systemen (Carerix, Easyflex, WIZZR, de Microsoft-omgeving) via hun API's daadwerkelijk toestaan — welke data leesbaar is, met welke rechten, en wat er gelogd wordt. Voor fase 1 is dat bewust niet nodig: de kennisassistent en schrijfassistent draaien volledig op het Proceshuis en een testmailbox, zonder één systeemkoppeling. Maar de latere contract- en subsidiebewaking staat of valt met wat die leveranciers technisch toelaten, en dat wil je weten vóórdat je het belooft — niet erna.
Zet het Proceshuis om naar kleine, adresseerbare blokken: één pagina per processtap, met eigenaar, systeem, termijn, versie en datum. De vijftien kernregels staan apart, als harde laag boven alles, nooit afhankelijk van of de bot toevallig het juiste stukje tekst terugvond. Alle getallen en termijnen in tabellen, niet in lopende tekst. En zoals hierboven benoemd: opdrachtgever-specifieke regels als aparte, gedateerde blokken.
Citaatplicht en scope-weigering blijven de kern: alleen antwoorden uit de kennisbasis, altijd met bron, en eerlijk "dit weet ik niet" als het antwoord er niet in staat. Je hebt in de demo gezien hoe dat er in de praktijk uitziet. Maar dat is niet genoeg. Voeg een derde regel toe: wanneer stuurt de bot iemand door naar een mens in plaats van te weigeren of te gokken? Bijvoorbeeld bij tegenstrijdige regels, bij een vraag die net buiten de letterlijke tekst valt maar wel binnen het onderwerp, of bij twijfel over een bedrag of termijn. Zonder die regel loopt de bot vast tussen "ik weet het" en "ik weet het niet", terwijl de praktijk vaak grijs is.
Regel ook governance: wie mag de kennisbasis wijzigen, en wie is eigenaar van de waarheid als het Proceshuis, de cao, de praktijk van een ervaren collega en een teamlead het onderling niet eens zijn? Zonder een aangewezen eigenaar per proces krijg je een bot die netjes klinkt maar op termijn verouderde of tegenstrijdige antwoorden geeft — en in jullie branche, waar subsidieregels jaarlijks schuiven, gaat dat sneller dan je denkt.
Bouw een testset vóórdat je vertrouwt, en breder dan alleen goed-fout: veertig vragen met het juiste antwoord en bron, tien strikvragen waarvan het antwoord bewust ontbreekt, en daarnaast een kleine set grensgevallen (vragen die net anders geformuleerd zijn dan de brontekst) en conflictvragen (twee bijna-tegenstrijdige regels tegelijk). Herhaal deze testset bij elke wijziging, als een vaste regressietest, niet als eenmalige keuring. Leg bij elke versie van kennis, prompts en profielen vast welke versie actief was toen een antwoord werd gegeven — dat is je enige manier om achteraf te reconstrueren wat er misging als een antwoord niet klopte.
Begin met één GreenFox-brede stijl en toon voor de schrijfassistent, niet meteen met een profiel per medewerker. Als je daarna gaat personaliseren: bouw dat met echte voorbeeldmails, niet met een beschrijving. Maar let op een risico: stijl en inhoud zijn niet hetzelfde. Als je alleen op toon traint, kan de assistent ook iemands minder goede gewoontes overnemen — te lange mails, of het vermijden van lastige boodschappen. Beoordeel daarom niet alleen "klinkt dit als deze medewerker", maar ook apart "is dit ook gewoon een goede mail".
En een tweede risico, rechtstreeks uit het gesprek met Marcella: medewerkers voelen zich snel gecontroleerd. Spreek daarom niet alleen af, maar bouw ook technisch af, dat een assistent nooit gebruiksgegevens per persoon naar een leidinggevende stuurt. Een afspraak is een intentie, een technische beperking is een garantie. Beide heb je nodig, want ook een teamlead met de beste bedoelingen kan dit anders gaan gebruiken zodra het kan.
Eerst de kennisbasis en de bredere testset. Dan de kennisvragen-functie met citaatplicht en de escalatieregel. Daarna, niet per medewerker maar gedeeld, de schrijfassistent voor conceptmails. Dan pas, als beide functies aantoonbaar gebruikt worden, de contract- en subsidiebewaking als apart traject: begin daar met alleen signaleren, read-only, gezien de zakelijke waarde en het risico dat daar samenkomen. Personaliseren per medewerker komt als laatste, niet als eerste.
Meet vanaf dag één, niet alleen "gebruikt hij het uit zichzelf" maar concreet: tijdwinst per taak, hoeveel conceptmails zonder aanpassing worden verstuurd, hoe vaak de assistent terecht escaleert naar een mens, en hoe medewerkers het vertrouwen beoordelen. En spreek vooraf een stopcriterium af: bijvoorbeeld, als na zes weken minder dan een vooraf afgesproken percentage van de antwoorden bruikbaar is, of de assistent nauwelijks gebruikt wordt, stoppen jullie of bouwen jullie het opnieuw, in plaats van door te blijven investeren in iets dat niet aanslaat.
Fase 2, het meeluisteren via Plaud, blijft geparkeerd tot fase 1 bewezen is.
Tot slot de zakelijke kant, want een advies zonder kostenplaatje is half werk. De techniek van fase 1 is bewust goedkoop gehouden: API-kosten voor tekstgebruik op deze schaal zijn verwaarloosbaar (tientallen euro's per maand, geen honderden), en de eventuele eigen server is een eenmalige aanschaf die je pas doet na de benchmark. De echte investering zit in uren: die van Hamza voor de bouw en het beheer, en die van de kenniseigenaren voor het bijhouden van het Proceshuis. Reken daar eerlijk mee, want dát is wat dit project kost. En wijs één iemand aan die eindverantwoordelijk is voor adoptie — niet voor de techniek, maar voor de vraag "gebruiken mensen het echt, en zo nee, waarom niet". Zonder die eigenaar wordt het stopcriterium nooit eerlijk toegepast.
Dat is een goed startpunt maar niet voldoende. Leg voor de bouw begint ook vast: wie is verwerker en wie verwerkingsverantwoordelijke voor dit specifieke kanaal, welke logging jullie aanhouden en hoe lang die bewaard blijft, of de gekozen modelaanbieder op verzoek geen trainingsdata van jullie prompts gebruikt, wat de doelbinding is van elk stukje kennis dat je deelt, en of er subverwerkers zijn waar je vooraf toestemming voor nodig hebt. Dit hoeft geen zwaar traject te zijn, maar wel een bewuste keuze per punt, gedocumenteerd, in plaats van een aanname.
Nu ik jullie branche beter snap, zie ik een paar uitbreidingen die niet in jullie oorspronkelijke vraag zaten, maar die logisch voortbouwen op dezelfde motor. Ik noem ze bewust als whiteboard-lijst: de discipline van dit hele advies is klein beginnen, dus niets hiervan hoort in fase 1. Maar het is goed om te weten waar dit naartoe kan groeien:
1. Automatische impactrapportage per opdrachtgever. Een periodiek rapport per klant: geplaatste kandidaten, duurzame uitstroom, ingevulde SROI-waarde — in gewone taal, klaar om te versturen of te gebruiken bij een audit. Jullie klanten (gemeenten, grote aannemers) moeten hun eigen social-return-verplichting kunnen aantonen; dit is dus niet alleen intern gemak maar een zichtbaar verkoopargument.
2. Een subsidie-checklist bij elke plaatsing. Bij elke nieuwe kandidaat automatisch de checklist: doelgroepregister, LKV, loonkostensubsidie, jobcoach-vergoeding. Als beslis-ondersteuning voor de backoffice — nadrukkelijk niet als systeem dat zelf subsidierecht "bepaalt", want dat oordeel blijft mensenwerk. Een gemiste regeling kost direct geld; dit zit dus dicht op jullie verdienmodel.
3. Een SROI-bewijsdossier-bewaker. Automatisch signaleren welke bewijsstukken per plaatsing ontbreken, met een checklist per opdrachtgever (want de eisen verschillen per gemeente) en een waarschuwing als een plaatsing waarschijnlijk niet meetelt voor de verplichting. Dit sluit direct aan op de verantwoordingskant die jullie werk onderscheidt van gewone recruitment.
4. Een warme check-in voor geplaatste kandidaten. Jullie begeleidingscyclus (dag 3, 10, 17, maand 1, kwartaal) is al vaste methodiek. Een automatisch, vriendelijk berichtje op die momenten — met een seintje naar de jobcoach bij een zorgelijk antwoord — zorgt dat niemand tussen wal en schip valt omdat een jobcoach het druk had. Voorwaarde: altijd met menselijk vangnet, en met expliciete toestemming van de kandidaat, want dit is een kwetsbare doelgroep.
Mijn rol in dit traject is die van coach en adviseur; het productiesysteem bouwen jullie zelf, met Hamza als bouwer. Om te zorgen dat dit ook zonder mij blijft werken, hoort daar wat mij betreft bij: dat Hamza bij elke stap een korte beheerhandleiding bijhoudt naast de code, dat er een eenvoudig incidentproces is voor als de assistent een keer duidelijk fout antwoordt, en een fallback: wat doet een medewerker als de assistent een dag niet beschikbaar is. Dat hoort niet bij de techniek, maar bepaalt of dit iets wordt waar GreenFox zelfstandig op kan bouwen.
Van mijn kant is de eerste stap al gezet: de demo-kennisbot staat live (link hierboven), inclusief de drie kerngedragingen die de echte versie ook moet hebben.
Van jullie kant: Hamza stuurt de Proceshuis-hoofdstukken Plaatsen en Ontwikkelen plus de vijftien kernregels, alleen methodiek, en zet een testmailbox met fictieve gegevens klaar. Spreek met elkaar af wie namens GreenFox eigenaar is van welk kennisonderdeel, en prik het vaste wekelijkse moment voor de coaching-vraag.
Zodra ik de hoofdstukken heb, lever ik binnen een week het uitgebreide testset-format (inclusief grensgevallen en conflictvragen), zodat Hamza dat daarna zelf onderhoudt.
Groet,
Jamal
Onderliggend onderzoek, voor wie dieper wil: