Een werkmodel dat AI in de dagelijkse stroom van organisaties brengt, zonder de cultuur of het ambacht te beschadigen. Voor organisaties tussen 15 en 500 mensen.
In organisaties van vijftien tot vijfhonderd mensen blijft AI vaak hangen in losse tools en goede bedoelingen. De afstand tot de dagelijkse werkstroom blijft groot, en de winst die het zou kunnen opleveren wordt nauwelijks tastbaar. Dit document beschrijft een werkmodel dat die afstand wegneemt, op een manier die past bij het tempo en de schaal van zulke organisaties.
Het model is opgebouwd uit vier samenhangende keuzes. Geen ervan is op zichzelf revolutionair. De combinatie maakt dat AI inbedt in plaats van blijft zweven.
Voordat een tool wordt gekozen, brengen we per rol in kaart welke taken zich lenen voor automatisering, augmentatie, agent-uitvoering of bewust mensenwerk. Daarmee ligt de focus op de werkstroom van mensen die het werk doen, in plaats van op het aanbod van leveranciers.
Een bouwblok is een afgebakende skill of agent met een eigen outcome-definitie. Klaar betekent dat de output bruikbaar is in de dagelijkse stroom, niet dat een aantal uur is besteed. Een bouwblok staat op zichzelf, levert waarde op zichzelf en is in vijf tot zeven werkdagen werkend te krijgen.
Bouwen gebeurt in dagen, adoptie in weken. Tegelijk met de adoptie van bouwblok één wordt bouwblok twee al gebouwd. Wachten op een lineaire volgorde maakt van een traject van zes weken zonder reden een traject van drie maanden.
Strategie, klantrelatie, concept-keuzes, finale approvals en eindverantwoordelijkheid blijven in mensenhanden. AI versnelt productie, maar versterkt niet automatisch de kwaliteit van het inhoudelijke werk. Door dat onderscheid expliciet te maken houdt een organisatie haar eigenheid vast.
In de rest van dit document werk ik die vier keuzes uit. Eerst beschrijf ik waarom AI in middelgrote organisaties zo vaak blijft hangen. Daarna volgt het werkmodel zelf, met de rollenkaart en de zoom-in als kerninstrumenten. Vervolgens leg ik de bouwblokken en het ritme uit, gevolgd door vijf cases uit uiteenlopende sectoren. Tot slot ga ik in op wat menselijk blijft, en wat de invoering van dit model van een organisatie vraagt.
In gesprekken met founders, COOs en afdelingshoofden hoor ik vrijwel altijd hetzelfde beeld. De licenties zijn aangeschaft, een deel van het team probeert ChatGPT of Copilot, er is een interne kanaal waar mensen prompts delen. En toch verandert er weinig aan de manier waarop het werk dagelijks wordt gedaan. De winst die de meeste leveranciers in het vooruitzicht stellen blijft een gevoel, geen meetbaar resultaat.
De oorzaak ligt zelden in de tools en bijna altijd in de afstand tussen tool en werkstroom. Een AI-tool die los staat naast het bestaande proces is een nieuwe tab in de browser. Mensen openen hem als ze eraan denken, gebruiken hem voor losse vragen, en sluiten hem weer. Het werk zelf, met zijn vaste overdrachten, formats, deadlines en kwaliteitseisen, blijft onveranderd. De tool levert per individu een paar minuten winst per dag op. Voor de organisatie als geheel verschijnt die winst nergens in de cijfers.
De afstand zit zelden tussen mensen en technologie, en bijna altijd tussen tool-adoptie en werkstroom-verandering. Tool-adoptie is de fase waarin mensen leren wat ze met een tool kunnen. Werkstroom-verandering is de fase waarin het proces zelf opnieuw is ingericht, met de AI-component als vast onderdeel ervan. De meeste organisaties in de schaal van vijftien tot vijfhonderd mensen zijn ergens halverwege fase één blijven steken.
Een organisatie van vijftien tot vijfhonderd mensen heeft een lastige tussenpositie. Te klein om een eigen AI-team in dienst te hebben dat fulltime kan bouwen, te groot om met losse experimenten van enthousiaste medewerkers het hele bedrijf mee te trekken. De grote bedrijven hebben een central capability die kan investeren in bouwen, testen en uitrollen. De kleine bedrijven hebben weinig processen waar AI tegenaan kan landen en lossen veel ad hoc op. Daar tussenin ligt het lastigste gebied: voldoende complexiteit om winst te behalen, en onvoldoende slagkracht om hem zelf te organiseren.
De externe ondersteuning die in dit gebied beschikbaar is, sluit zelden aan op de schaal. Strategische consultancy levert lijvige rapporten die het probleem op slide vijftien hebben gevat en de implementatie aan de organisatie zelf overlaten. Implementatiepartners bouwen vanuit hun eigen stack en zien de werkstroom als een gegeven om in te passen, in plaats van als het ontwerp-vraagstuk dat het is. Beide aanpakken laten een organisatie achter met dezelfde gap die er voor de start ook al was.
De vraag in deze schaal is niet welke tool gekozen moet worden. De vraag is hoe het werk in de afdeling zelf opnieuw wordt ingericht, met AI als vast onderdeel van de stroom in plaats van als optionele tab ernaast.
Wanneer de tool-adoptie wel is gestart maar de werkstroom niet, ontstaan een aantal herkenbare patronen. Ik benoem ze hier omdat het herkennen ervan vaak het beginpunt is van een nuchter gesprek over wat er nodig is.
Het eerste patroon is dat AI-gebruik persoonsafhankelijk wordt. Enkele medewerkers gebruiken het intensief en behalen flinke winst op hun eigen werk, terwijl collega's in dezelfde rol nauwelijks iets aanraken. Het werk dat het bedrijf oplevert wordt daardoor inconsistent in plaats van consequent beter.
Het tweede patroon is dat productiviteitswinst niet te herleiden is. Mensen zijn ervan overtuigd dat ze sneller werken, maar de doorlooptijden in de operatie blijven gelijk. De winst lekt weg in extra rondjes, in tussenoutput zonder gebruik, of in tijd die ergens anders in het proces wordt verloren.
Het derde patroon is dat AI-gebruik vooral in productie landt en zelden in de keten ervoor of erna. De copywriter laat AI eerste drafts maken, maar de briefing die hij krijgt en de review die erop volgt zijn niet aangepast. Het bouwblok staat alleen, en de stroom eromheen klopt niet meer.
Het vierde patroon is dat AI vooral op losse taken landt en zelden op besluitvorming of regie. Daardoor ontstaan veel kleine optimalisaties zonder dat de bredere coördinatie verbetert. De afdeling wordt geen geheel beter, alleen optisch sneller op een paar plekken.
Wie deze patronen in zijn eigen organisatie ziet, hoeft niet te concluderen dat de adoptie is mislukt. Het betekent doorgaans dat de overgang van tool-adoptie naar werkstroom-verandering nog niet expliciet is gemaakt. Daar gaat de rest van dit document over.
Het werkmodel bestaat uit drie instrumenten die naast elkaar gebruikt worden. De vier lijnen geven richting aan waar AI in een organisatie landt. De rollenkaart maakt zichtbaar waar binnen rollen de mogelijkheden liggen. De zoom-in geeft de aanpak per rol concreet handen en voeten. Elk instrument is op zichzelf bruikbaar, en samen vormen ze de basis voor een werkstroom-verandering die haalbaar en meetbaar is.
AI landt in een organisatie van vijftien tot vijfhonderd mensen op vier samenhangende lijnen tegelijk. De lijnen lopen parallel en versterken elkaar wanneer ze gelijktijdig worden aangepakt.
In de praktijk kiest een organisatie zelden vier lijnen tegelijk om aan te pakken. Ik adviseer doorgaans één lijn als start, soms twee, met een duidelijke voorrang voor de lijn die in de huidige operatie het meest knelt. Dat is meestal productie of analyse. Sales en onboarding volgen vaak in de tweede ronde, optimalisatie als laatste, omdat die het meeste profiteert van de structuur die de andere lijnen opbouwen.
De rollenkaart is het tweede instrument en in de praktijk het meest besproken. Het is een eenvoudig overzicht van de rollen binnen een afdeling of organisatie, waarbij per rol de kerntaken worden geclassificeerd. Voor elke taak geldt een classificatie die aangeeft hoe AI op die taak kan landen.
De kaart heeft drie voordelen die haar in de praktijk waardevol maken. Allereerst maakt zij het gesprek tussen leiding en team concreet. In plaats van een algemene discussie over AI-mogelijkheden hebben we het over specifieke taken die mensen vandaag doen. Daarnaast scheidt zij de rollen die structureel veel winst kunnen halen van de rollen die nauwelijks raakvlak hebben. Tot slot levert zij een werkdocument op dat na een eerste invulling steeds verder verfijnd kan worden, in plaats van een rapport dat afsluit en vervolgens in een la verdwijnt.
Een rollenkaart wordt zelden in één sessie volledig ingevuld. De eerste versie ontstaat op basis van wat publiek zichtbaar is, eventueel aangevuld met enkele korte gesprekken. De tweede versie volgt na interviews met de rolhouders zelf, omdat de werkelijkheid altijd net iets anders blijkt dan wat de organogramwens. Vanaf de derde versie wordt de kaart een levend document dat tijdens het traject regelmatig wordt bijgewerkt.
De zoom-in is het instrument dat de rollenkaart koppelt aan concrete bouwblokken. Voor een gekozen rol wordt een gemiddelde werkweek in beeld gebracht, met de huidige tijdsbesteding per kerntaak. Vervolgens wordt diezelfde week opnieuw uitgerekend in een scenario waarin AI op de relevante taken landt. Het verschil dat dan zichtbaar wordt is de basis voor het gesprek over welke bouwblokken het meest opleveren.
De zoom-in heeft een specifieke functie binnen het werkmodel. Hij dwingt om niet over de hele organisatie tegelijk te praten, en het tegelijk concreet genoeg te maken om besluiten te nemen. Een afdelingshoofd ziet welke uren waar naartoe gaan, en welke uren mogelijk vrijkomen. Een teamlid herkent zijn eigen week en kan zelf aangeven waar de schoen wringt. Een directie ziet hoe één rol zich verhoudt tot de bredere capaciteit van de organisatie.
Niet elke rol is een logische start. Ik kies de rol waar de capaciteitsdruk het grootst is, het werk het meest zichtbaar uit deeltaken bestaat, en het bouwen van een eerste bouwblok in vijf tot zeven werkdagen realistisch is. Wat in de eerste rol blijkt te werken, blijkt vrijwel altijd ook in aangrenzende rollen waarde te hebben.
In de cases verderop in dit document is per voorbeeld een gekozen rol uitgewerkt. Daarin is te zien hoe de zoom-in concreet werkt: welke uren waar zaten, welk bouwblok daar als eerste op landt, en wat de outcome-definitie van dat bouwblok is. Bij de meeste cases blijkt het patroon herkenbaar te zijn, ook al verschillen de sectoren onderling sterk.
Een bouwblok is de kleinste vorm waarin AI in een werkstroom kan landen. Het is afgebakend, het heeft een eigen input en output, en het heeft een outcome-definitie die in concrete termen beschrijft wanneer het bouwblok klaar is. Door in bouwblokken te werken in plaats van in projecten of in tijdpakketten, ontstaat een ritme dat past bij hoe AI zich in werkelijkheid laat bouwen en hoe organisaties zich in werkelijkheid aanpassen.
Binnen het werkmodel gebruik ik twee vormen van bouwblokken, met een onderscheid dat in de praktijk belangrijk blijkt te zijn.
Het onderscheid lijkt klein, maar bepaalt veel. Een skill draagt het ritme van de mens. Een agent draagt zijn eigen ritme en vraagt dat de organisatie zich daaraan aanpast. Voor de meeste organisaties is het verstandig om met skills te beginnen, omdat ze in de bestaande werkstroom kunnen worden geplaatst zonder dat de stroom zelf hoeft te veranderen. Agents komen meestal in een tweede ronde, op het moment dat de organisatie heeft geleerd om met AI-output te werken en klaar is om delen van het werk zelf aan een agent over te dragen.
Een bouwblok wordt vooraf gedefinieerd op uitkomst, niet op tijdsbesteding. Voor elke skill of agent leg ik vooraf vast wat klaar betekent, uitgedrukt in concrete waarneembare termen. Voor een Ad Copy Generator is dat bijvoorbeeld dat tachtig procent van de gegenereerde copy zonder herschrijven inzetbaar is. Voor een Performance Digest dat hij elke ochtend op tijd staat en dat specialisten hun werk daadwerkelijk op die digest baseren. Voor een Contract Reviewer dat een standaard-NDA in vijftien minuten beoordeeld is met behoud van risico-detectie.
De keuze voor outcome-definitie heeft drie gevolgen die ik bewust opzoek. De organisatie betaalt voor een resultaat, niet voor de tijd die het kost om dat resultaat te bereiken. Het bouwblok komt onder druk te staan om bruikbaar te zijn in plaats van complete te lijken. En het gesprek tussen bouwer en organisatie wordt concreter, omdat er een gedeelde definitie is van wanneer een bouwblok zijn werk doet.
Ik verkoop geen tijdpakketten van drie, zes of twaalf maanden. Voor elk bouwblok wordt vooraf afgesproken wat klaar betekent. Een praktische tijdsindicatie is daarbij prima mogelijk, maar de afspraak gaat over de uitkomst, niet over de uren.
Het ritme van een traject wordt bepaald door twee snelheden die naast elkaar lopen en een verschillend karakter hebben. De ene snelheid is tech-gedreven, de andere mens-gedreven.
Het verschil tussen die twee snelheden bepaalt de cadans van het hele traject. Terwijl bouwblok één bij de specialisten in adoptie is, kan bouwblok twee al gebouwd worden. Wachten op een lineaire volgorde maakt van een traject van zes weken zonder reden een traject van drie maanden. Door de snelheden bewust parallel te laten lopen, blijft het tempo aansluiten op de absorptie-capaciteit van het team in plaats van op de bouwcapaciteit van de partner.
Binnen het werkmodel kent elk traject drie fases die elkaar volgen. Discovery is kort en gericht. Sprint is de fase waarin bouwblokken worden opgeleverd, in tempo. Borging loopt vanaf het eerste bouwblok mee in plaats van als afzonderlijke fase aan het einde.
De volgende vijf cases tonen het werkmodel in toepassing op uiteenlopende sectoren. Per case wordt de gekozen rol uitgelicht, een bouwblok beschreven dat als eerste landt, en een mini-zoom-in gegeven op het effect dat zo'n bouwblok heeft. De cases zijn samengesteld uit Mono-projecten, sectorgesprekken en publieke informatie. Ze illustreren het patroon, en zijn niet bedoeld als belofte van een identieke uitkomst in elke organisatie.
Een performance bureau leeft van geleverde uren tegenover gedragen verantwoordelijkheid voor klantresultaat. Iedere uur die productie kost is een uur die niet aan strategie, klantcontact of een aanvullend account besteed wordt. In deze case wordt de SEA-rol als ingang gekozen, omdat hier de capaciteitsdruk het grootst is en de platforms zelf al volop automatiseren binnen de discipline.
Het bouwblok dat als eerste landt is een Ad Copy Generator. De input bestaat uit een productbriefing, USP's, tone of voice en doelgroepomschrijving. De output bestaat uit dertig varianten responsive search ads, direct geschikt voor implementatie in Google Ads, aangevuld met tien display headlines. De SEA Specialist reviewt de varianten, kiest de top vijf en past waar nodig de laatste afstemming aan. Klaar betekent dat tachtig procent van de gegenereerde copy zonder herschrijven inzetbaar is.
Brainstorm, schrijfwerk, afwisselen tussen varianten, kwaliteitscheck en finale review door de specialist zelf.
Briefing aanleveren, dertig varianten beoordelen, top vijf kiezen, finale afstemming. De review verschuift van productie naar regie.
Met drie bouwblokken op de SEA-tak, ingezet door zes specialisten, ligt de bureau-brede winst rond 30 tot 48 uur per week aan capaciteit die nu naar productie gaat en straks naar regie, strategie en aanvullende accounts kan. Op jaarbasis komt dat neer op effectief één FTE aan capaciteit, zonder dat daar een nieuwe medewerker voor nodig is.
Een middelgroot advocatenkantoor draagt twee verschillende werkstromen tegelijk. Aan de ene kant het maatwerk dat in elk dossier weer anders is, en waar het vakmanschap van de juristen tot uitdrukking komt. Aan de andere kant een aanzienlijke hoeveelheid standaardwerk, met NDA's, geheimhoudingsbepalingen, simpele leveranciers-contracten en repetitieve clausules. Het standaardwerk landt vaak bij de Senior Associate, die de detail-controle uitvoert die een juridisch verantwoorde review vraagt. Drie kwartier per NDA is geen uitzondering.
Het bouwblok dat hier als eerste landt is een Contract Review Agent. De agent ontvangt het inkomende contract, vergelijkt het tegen een geannoteerde clausule-bibliotheek van het kantoor, markeert afwijkingen per categorie risico, stelt suggesties voor en levert een briefing voor de Senior Associate die de finale review doet. Klaar betekent dat een standaard-NDA in tien minuten beoordeeld is, met behoud van de risico-detectie zoals het kantoor die definieert.
Doorlezen, vergelijken met huisstandaard, markeren van afwijkingen, formuleren van wijzigingsvoorstellen.
Briefing van de agent doornemen, gemarkeerde clausules beoordelen, finale review en akkoord op de wijzigingsvoorstellen.
De tijdwinst is voor het kantoor minder belangrijk dan wat ermee gebeurt. De vrijgekomen ruimte wordt ingezet op het werk waar het marge-rendement het hoogst ligt, en waar het inhoudelijke onderscheidend vermogen van het kantoor tot zijn recht komt. Voor partners zit hier vaak ook een tweede effect, omdat repetitief standaardwerk een vorm is van slijtage die meetbaar afneemt zodra hij wordt geautomatiseerd.
In een SaaS scale-up van rond de honderd mensen heeft de Customer Success-afdeling vrijwel altijd dezelfde uitdaging. Het account-portfolio per CSM is groter dan hij in zijn hoofd dagelijks bij kan houden, en de signalen die op een aankomende churn wijzen liggen verspreid over meerdere systemen. Product-usage in de database, ticket-volume in de support tool, NPS-scores in de feedback tool, deal-status in het CRM en het kanaal van het account-team in chat. In de praktijk wordt churn doorgaans pas zichtbaar wanneer een klant zijn opzegging al heeft besloten.
Het bouwblok dat hier als eerste landt is een Customer Health Digest. De agent kruist dagelijks de signalen uit de relevante systemen, berekent per account een health-score die rekening houdt met sector en accountgrootte, en levert per CSM een ochtenddigest met de drie accounts die de meeste aandacht vragen en de drie accounts waar de score juist verbetert. Klaar betekent dat churn-risico structureel twee weken eerder zichtbaar is, en de gemiddelde response-tijd op een gemarkeerd signaal daalt van vierentwintig naar vier uur.
Signalen verspreid over systemen, opgemerkt op het moment dat de CSM toevallig in die tool zit of een collega opmerkt.
Ochtenddigest om 08:00 met drie geprioriteerde accounts. CSM start de dag met een lijst, in plaats van met een leeg scherm.
Wat de organisatie hier wint is niet alleen tijdwinst, maar voorsprong in de tijd. Een klantgesprek dat twee weken eerder begint heeft fundamenteel andere uitkomsten dan hetzelfde gesprek twee weken later. Voor een SaaS-organisatie van honderd mensen vertaalt een paar procent minder churn zich direct in maandelijks terugkerende omzet, en in een hogere lifetime value per account.
In een recruitment bureau bestaat een aanzienlijk deel van het dagelijkse werk uit het matchen van inkomende vacatures aan beschikbare kandidaten. Een recruiter leest een vacaturetekst, vormt zich een beeld van het ideale kandidaatprofiel, doorzoekt LinkedIn, de eigen database en aangrenzende bronnen, en stelt een eerste lijst van potentiële kandidaten op. Op deze sourcing-fase rust een groot deel van de doorlooptijd van een opdracht.
Het bouwblok dat hier als eerste landt is een ICP Matcher. De skill leest de vacaturetekst, extraheert de hard- en soft-criteria, doorzoekt de gekoppelde bronnen en levert een eerste long-list van vijftien tot twintig kandidaten met per kandidaat een onderbouwing van waarom de match relevant is. De recruiter beoordeelt de lijst, schrapt waar nodig en bouwt vanuit deze long-list de short-list voor de klant. Klaar betekent dat de sourcing-tijd per opdracht is gehalveerd, terwijl de interview-rate per voorgedragen kandidaat gelijk blijft of stijgt.
Vacature lezen, profiel vormen, zoeken op meerdere bronnen, longlist samenstellen, eerste afsnijding maken.
Vacature aanleveren, longlist beoordelen, kwalitatieve afsnijding maken op basis van de meegeleverde onderbouwing.
De winst zit in de doorlooptijd per opdracht en in het volume dat het bureau aankan zonder extra hires. Voor een bureau van vijftig recruiters betekent een halvering van de sourcing-tijd dat substantieel meer opdrachten parallel uitgevoerd kunnen worden, terwijl de kwaliteit van de voorgedragen kandidaten op hetzelfde niveau blijft. Het inhoudelijke gesprek met klant en kandidaat blijft mensenwerk, en wint juist aan ruimte.
In een wealth management firm vraagt de KYC-doorlooptijd structureel veel capaciteit. Een Compliance Officer beoordeelt elk nieuw cliëntdossier op identificatie, herkomst van middelen, sanctielijst-toets, PEP-status en passende risicoclassificatie. Een aanzienlijk deel van de dossiers volgt een standaardpatroon dat met de huidige bezetting toch dezelfde aandacht krijgt als de werkelijk complexe gevallen. De gemiddelde doorlooptijd wordt daardoor gedragen door de eenvoudige gevallen, en de complexe gevallen krijgen niet altijd de aandacht die ze verdienen.
Het bouwblok dat hier als eerste landt is een KYC Triage Agent. De agent ontvangt het inkomende dossier, voert de gestandaardiseerde toetsen uit, vergelijkt tegen de risico-matrix van de firm en classificeert het dossier als standaard, complex of geblokkeerd. Een standaard-dossier wordt voorzien van een gestructureerde samenvatting, klaar voor finale akkoord van de Compliance Officer. Een complex of geblokkeerd dossier wordt gerouteerd naar de juiste specialist, met de zorgwekkende elementen vooraan in de briefing. Klaar betekent dat tachtig procent van de inkomende dossiers binnen vijftien minuten een standaard-akkoord krijgt, en de overige twintig procent met scherpere context bij de specialist landt.
Elk dossier doorloopt dezelfde stappen, ongeacht complexiteit. De wachtrij bepaalt het tempo, niet het inhoudelijke werk.
Standaard-dossiers binnen vijftien minuten klaar, complexe dossiers behouden de oorspronkelijke aandacht en doorlooptijd, maar landen direct bij de juiste specialist.
Voor een firm in deze sector is governance net zo belangrijk als efficiëntie. De agent levert een audit-trail bij elk dossier, met de toetsen die zijn uitgevoerd en de signalen die zijn meegewogen. De finale handtekening blijft bij de Compliance Officer, en bij geblokkeerde dossiers altijd bij een mens. De winst zit in de combinatie van snellere doorloop voor standaard-werk en scherpere context voor specialisten op de gevallen die er werkelijk toe doen.
De cases verschillen in sector, maar tonen telkens hetzelfde patroon. Een gekozen rol, daarop een afgebakend bouwblok met een outcome-definitie die in waarneembare termen is geformuleerd, en als gevolg daarvan een verschuiving van productie naar regie binnen de werkstroom. Het werkmodel is sector-agnostisch, en juist daarom past het op de schaal van vijftien tot vijfhonderd mensen waar dit document zich op richt.
Het werkmodel werkt alleen wanneer twee vragen even serieus worden genomen als de bouwvraag zelf. De eerste vraag gaat over wat bewust mensenwerk blijft, ondanks dat AI het technisch zou kunnen overnemen. De tweede vraag gaat over wat de invoering van dit model van een organisatie vraagt aan governance, eigenaarschap en aansturing.
AI versnelt productie, maar versterkt niet automatisch de kwaliteit van het concept of de eigenheid van de organisatie. De volgende onderdelen blijven daarom bewust mensenwerk, vanuit de overtuiging dat juist hier het onderscheidend vermogen tot stand komt.
Het expliciet maken van deze onderdelen heeft een functie die verder gaat dan het beschermen ervan. Het levert ook duidelijkheid op voor de rest. Wanneer team en organisatie weten waar de mens onmisbaar blijft, ontstaat ruimte om met meer vertrouwen te kijken naar de plekken waar AI wel kan landen. Het gesprek gaat dan over inrichting, niet over angst.
Een werkmodel werkt zelden alleen omdat het op papier klopt. De invoering vraagt vier dingen van de organisatie zelf, los van de bouwer aan de andere kant van de tafel.
Het eerste is een intern eigenaar. Een bouwblok dat op de schop van mij staat is voor de organisatie een afhankelijkheid. Een bouwblok waarvoor een interne eigenaar is aangewezen wordt onderdeel van het bedrijf zelf. Die eigenaar hoeft niet de slimste prompt-engineer te zijn, maar moet wel mandaat hebben om beslissingen te nemen over scope, kwaliteit en doorontwikkeling.
Het tweede is een afspraak over governance. Wie ziet welke data, waar belandt die data, wie heeft inzage in de logs van een agent en wie tekent voor uitzonderingen. Voor de meeste organisaties in deze schaal is dat geen ingewikkeld document, maar wel een onderwerp dat vooraf op tafel hoort. Privacy, herleidbaarheid en aansprakelijkheid worden er concreet door, in plaats van abstract.
Het derde is een review-ritme. Een bouwblok dat in productie staat hoort periodiek tegen het licht gehouden te worden. Werkt hij nog zoals afgesproken, levert hij nog de outcome waarvoor hij is gebouwd, drijft hij af van zijn oorspronkelijke kwaliteit. Een korte maandelijkse review met de interne eigenaar en de specialist die er dagelijks mee werkt, is doorgaans voldoende.
Het vierde is bereidheid om de eigen werkstroom aan te passen. Een bouwblok dat een specialist twee uur per week tijd oplevert, levert pas waarde wanneer die twee uur ook ergens anders naartoe gaan. Dat lijkt vanzelfsprekend, maar in de praktijk is het de stap die het meest wordt onderschat. De vrijgekomen tijd vraagt om een gesprek over wat er met die tijd gebeurt, voordat hij weglekt in extra rondjes of nieuwe meetings.
De EU AI Act treedt gefaseerd in werking sinds augustus 2024, en passeert op 2 augustus 2026 een mijlpaal die voor organisaties in de schaal van dit document directe gevolgen heeft. Op die datum worden de transparantie-verplichtingen uit Artikel 50 volledig afdwingbaar, moeten alle lidstaten een werkende AI-sandbox hebben ingericht, en geldt voor providers van high-risk AI-systemen een verplichte conformity assessment voordat een systeem op de markt komt. Voor de meeste organisaties in de doelgroep van deze whitepaper geldt dat ze deployer zijn, gebruiker dus, en niet provider van AI-systemen, maar ook voor deployers ontstaat per die datum een eigen reeks verplichtingen.
De deployer-verplichtingen die in werking treden raken vier domeinen tegelijk. Ten eerste het bewaren van system logs van high-risk AI-systemen, zodat herleidbaarheid achteraf mogelijk blijft. Ten tweede transparantie naar de personen op wie het systeem effect heeft, met name in HR, krediet en publieke dienstverlening. Ten derde technische en organisatorische maatregelen om het systeem te gebruiken zoals de provider het heeft bedoeld. Ten vierde, voor organisaties die als publieke entiteit of als publieke-dienstverlener werken, een Fundamental Rights Impact Assessment voorafgaand aan het in gebruik nemen van een high-risk systeem.
Specifiek voor de cases in Deel IV is de Act op twee plaatsen direct relevant. Recruitment-toepassingen vallen onder Annex III categorie 4 (employment, workers management en access to self-employment). KYC- en kredietwaardigheid-toepassingen vallen onder categorie 5 (access to essential private services). Voor beide geldt dat ze als high-risk worden geclassificeerd, met de bijbehorende deployer-verplichtingen. Voor de andere drie cases blijven de eisen beperkt tot de transparantie-laag van Artikel 50, met de notitie dat copywriting-output die zich voordoet als menselijk werk per 2 augustus 2026 als zodanig moet worden gemarkeerd.
Het werkmodel sluit op deze eisen aan zonder dat er een aparte compliance-laag overheen moet. Doordat elk bouwblok een outcome-definitie heeft, een interne eigenaar, een review-ritme en een audit-trail in de logs, is de documentatie die de Act vraagt grotendeels al aanwezig. Voor organisaties die nog twijfelen waar te beginnen, biedt dit een tweede reden om in deze richting te bewegen. De inrichting die voor productiviteit waarde levert, is dezelfde inrichting die de regelgeving aanstaande maakt.
Een werkmodel waarin AI bewust landt is doorgaans ook een werkmodel waarin AI verantwoord landt. Outcome-definities, eigenaarschap en review-ritmes zijn niet alleen instrumenten voor productiviteit, maar ook voor governance. Wie de werkstroom-vraag serieus neemt, lost een aanzienlijk deel van de governance-vraag tegelijk op.
Een werkmodel ontwerpen voor vandaag heeft alleen zin wanneer het ook morgen blijft kloppen. In dit deel beschrijf ik vier verschuivingen die het veld in 2026 en 2027 zichtbaar bepalen, en hoe het werkmodel daarop is voorgesorteerd. De observaties komen uit gesprekken met founders en operators, recent gepubliceerde onderzoeken en de bouwpraktijk van Mono zelf.
Tot 2024 was AI in bedrijven grotendeels een verzameling losse tabs. Een copywriting-tool hier, een meeting-summarizer daar, een datasheet-AI in de browser. Vanaf 2025 begint die verzameling structuur te krijgen. Open standaarden zoals het Model Context Protocol, dat Anthropic eind 2025 aan de Linux Foundation heeft gedoneerd, maken het mogelijk om AI-systemen op een gestandaardiseerde manier aan databronnen en interne tools te koppelen. Daardoor verandert wat een bouwblok is. Het is geen geïsoleerde skill in een browser meer, maar een component dat zich plugt op de bestaande data en applicaties van de organisatie en zich daar als een vast onderdeel gedraagt.
De praktische gevolgen zijn aanzienlijk. Een Ad Copy Generator hoeft niet meer telkens handmatig te worden gevoed met productinformatie. Een Customer Health Digest hoeft geen aparte ETL-pijp meer naar het CRM. De integratie-laag, die jarenlang het duurste en meest fragiele stuk van elke AI-implementatie was, schuift op naar een lichter en herbruikbaar niveau. Organisaties die hun bouwblokken vanaf het begin met een standaard zoals MCP in het achterhoofd ontwerpen, ontkomen aan een dure rebuild over twaalf maanden.
De tweede verschuiving is dieper en raakt het commerciële model van een hele generatie aan SaaS-bedrijven. Tot nu toe verkocht software vooral toegang aan gebruikers. Een organisatie kocht honderd seats, en de waarde lag in wat die honderd mensen vervolgens met de tool deden. Verticale AI-agents draaien die logica om. Wat zo'n agent oplevert is het voltooide werk zelf, in plaats van de mogelijkheid om dat werk te doen. Een KYC Triage Agent levert afgeronde dossiers af, een Performance Digest Agent levert klaargezette ochtendbriefings. De factuur wordt daarmee gekoppeld aan een uitkomst die de inkoper kan controleren, in plaats van aan een licentie die wel of niet wordt gebruikt.
Voor organisaties in de doelgroep van dit document heeft die verschuiving twee kanten. Aan de inkoopkant betekent het dat een groeiend deel van wat eerst als software werd ingekocht, zich nu meldt als operationele dienst met een vast outcome. Dat verandert de manier waarop budgetten worden gestructureerd en hoe leveranciers worden gekozen. Aan de andere kant ontstaan voor de eigen organisatie nieuwe mogelijkheden om interne bouwblokken te plaatsen op precies de plekken waar generieke SaaS niet meer past. De keuze om eigen agents te bouwen rond eigen werkstromen, in plaats van te accepteren wat de markt biedt, wordt voor het eerst realistisch op de schaal van vijftig tot vijfhonderd mensen.
Gartner verwacht dat tegen het einde van 2026 ongeveer 40 procent van alle enterprise-applicaties task-specifieke agents zal hebben ingebed, tegenover minder dan 5 procent in 2025. Voor middelgrote organisaties is het onderscheid tussen wat ze nu inkopen en wat ze straks ingebouwd krijgen daarmee minder belangrijk dan de vraag wie de werkstroom eromheen heeft ontworpen.
Een verrassend resultaat uit recent onderzoek is dat middelgrote organisaties in 2026 sneller agentic AI adopteren dan grote enterprises. De reden ligt voor de hand. Er zijn minder approval-lagen, de afstand tussen besluit en uitvoering is korter, en turnkey-platforms van Salesforce, Microsoft en gespecialiseerde nieuwkomers maken bouwen toegankelijker zonder eigen platform-team. Tegelijk laat dezelfde groep ook de hoogste abandonment-cijfers zien. Partial deployments stranden vaker, en de winst die op pilot-niveau zichtbaar was komt minder vaak terug in de structurele cijfers.
De oorzaak is in alle onderzoeken hetzelfde: governance-gap. Achtenzestig procent van de organisaties wijst gebrekkige governance aan als de primaire reden waarom AI-agents niet doorschalen voorbij de pilot-fase. Bij grote enterprises wordt die gap doorgaans opgelost door interne compliance- en data-teams. Bij middelgrote organisaties is die capaciteit niet aanwezig, en wordt de gap een muur zodra het eerste echte incident plaatsvindt of de eerste audit klopt.
De combinatie van voorsprong en valkuil maakt 2026 en 2027 voor middelgrote organisaties tot een venster met een hoog rendement en een hoge prijs voor wie de basis niet op orde heeft. Wie nu de bouwsnelheid inzet zonder de borging mee op te bouwen, levert binnen achttien maanden alsnog de hele inrichting opnieuw in. Wie nu beide tegelijk inricht, neemt structureel voorsprong op zowel grotere als kleinere spelers in dezelfde markt.
De vierde verschuiving raakt direct de manier waarop externe partijen aan dit soort werk meedoen. Tot nu toe was de norm in deze schaal dat strategie-consultancy aan de voorkant zat en implementatiepartners aan de achterkant. Daartussen lag een vertaalprobleem dat in vrijwel elk traject zichtbaar werd. De rapporten van de voorkant pasten niet op de praktijk van de achterkant, en wat de achterkant bouwde week vaak af van wat de voorkant had bedacht.
In een wereld waarin bouwen in dagen kan en adoptie in weken, valt dat onderscheid weg. Wat overblijft is een rol die ontwerpt en bouwt in één doorlopende beweging, met de organisatie in de regie. Voor de Mono-praktijk is dat geen aankondiging, maar de werkwijze zoals beschreven in dit document. Voor de bredere markt is het een verschuiving die langzaam zichtbaar wordt en in 2027 de mainstream zal raken.
Vier verschuivingen, vier manieren waarop het werkmodel uit dit document goed gepositioneerd is. Standaardisatie via MCP en vergelijkbare protocollen sluit naadloos aan op het bouwblok-denken, omdat een bouwblok per definitie een afgebakende component is met heldere input en output. De verschuiving van seats naar completed work valt samen met de outcome-definitie waarmee binnen het werkmodel elk bouwblok wordt opgeleverd. De governance-muur die mid-market organisaties tegenkomen verdwijnt grotendeels door de combinatie van interne eigenaar, review-ritme en audit-trail die het werkmodel oplevert. En de verschuiving van adviseur naar architect-meebouwer is precies de rol die Mono in projecten invult.
Dat een werkmodel toevallig past op vier toekomstige verschuivingen is geen geluk. Het is het resultaat van het ontwerpen vanuit de werkstroom in plaats van vanuit de tool, en vanuit de uitkomst in plaats vanuit de uren. Wie nu een werkmodel kiest dat op die principes is gebaseerd, kiest tegelijk een werkmodel dat over twee jaar nog kloppend is.
Wie dit document tot hier heeft gelezen, herkent waarschijnlijk een aantal patronen uit zijn eigen organisatie. De winst van AI voelt aanwezig, en blijft tegelijk in cijfers achter. Een afdeling probeert, maar het werk verandert nauwelijks. De vraag waar te beginnen is groter dan de vraag wat te gebruiken.
Mono by Dusty werkt met organisaties in deze schaal langs het werkmodel zoals hierboven beschreven. Een traject begint met een korte Discovery van een werkweek, gevolgd door bouwblokken die in een tempo worden opgeleverd dat aansluit op de absorptie-capaciteit van het team. Er zijn geen tijdpakketten, en er is geen rapport-eerst-implementatie-later constructie. Per bouwblok wordt vooraf afgesproken wat klaar betekent, en daar wordt op gestuurd.
Wie een eerste verkenning overweegt, hoeft niet vooraf precies te weten welke rol of welk bouwblok het meest oplevert. Het werkmodel begint juist met die vraag, en levert binnen een werkweek een concreet antwoord. Voor de meeste organisaties is dat een prettige manier om de eerste stap te zetten, zonder dat er meteen een meerjarig traject voor nodig is.
Dusty Baars werkt onder de naam Mono by Dusty vanuit Amsterdam. Met een achtergrond van twaalf jaar enterprise UX bij onder andere Shell, Roche, Philips en ING heeft hij zich de afgelopen twee jaar gericht op het bouwen van AI-producten en het inrichten van AI-werkstromen in middelgrote organisaties. Memortium voor de uitvaartbranche, Open Brain als persistent geheugen voor AI-systemen en Mono Dash voor agent-orchestratie staan inmiddels in productie.
De rol die Dusty in projecten invult is die van architect-meebouwer, niet die van externe adviseur. Een traject begint met een beperkte scope die werkend wordt gemaakt, en breidt uit waar het in de praktijk waarde oplevert. De documentatie, het bouwwerk en het eigenaarschap blijven bij de organisatie zelf.