Vincent van Deth 

Je hebt het misschien gehoord: de AI Act is uitgesteld. Dat klopt, maar slechts half. De zwaarste regels schuiven inderdaad door naar 2027 en 2028. Het deel dat de meeste MKB-bedrijven raakt, gaat op 2 augustus 2026 gewoon in.

Dat is precies de verwarring die ik nu in gesprekken hoor. "Uitgesteld" klinkt als achterover leunen. Maar wat uitgesteld is, geldt voor een klein deel van de bedrijven. Wat blijft staan, geldt voor bijna iedereen die een chatbot of AI-content gebruikt. Dit stuk zet de twee uit elkaar, zodat je weet wat je nu moet regelen en wat kan wachten.

## Wat de AI Act uitstelt (en waarom dat opluchting is voor het MKB)

In juni 2026 stemde het Europees Parlement in met de Digital Omnibus, een pakket dat de tijdlijn van de AI Act herschrijft. De kern: de verplichtingen voor high-risk AI gaan later in.

- **High-risk AI op zichzelf** (Annex III, denk aan systemen die beslissen over toegang tot zorg, krediet of werk): van 2 augustus 2026 naar **2 december 2027**.
- **High-risk AI ingebouwd in producten** (Annex I, zoals medische AI): van 2 augustus 2027 naar **2 augustus 2028**.

Voor de meeste MKB-bedrijven is dit goed nieuws, en wel om een simpele reden: je gebruikt waarschijnlijk helemaal geen high-risk AI. Een chatbot op je website, AI die offertes opstelt of teksten schrijft, dat valt niet onder high-risk. Die zware categorie raakt vooral specifieke sectoren. Het uitstel haalt dus druk weg bij een groep waar de meeste ondernemers niet eens in zitten.

## Wat op 2 augustus 2026 wél ingaat

Hier zit het addertje. De **transparantieverplichtingen (artikel 50)** schuiven niet op. Die gaan op 2 augustus 2026 in, en ze gelden voor elk AI-systeem in een paar veelvoorkomende situaties, niet alleen voor high-risk.

Concreet, en dit raakt wél het gewone MKB:

- **Een chatbot moet zich kenbaar maken als AI.** Praat een klant met een bot op je site, dan moet duidelijk zijn dat het geen mens is.
- **AI-gegenereerde content moet als zodanig herkenbaar zijn.** Teksten, beelden, audio en video die een AI maakt, moeten gemarkeerd worden, ook machine-leesbaar (een soort watermerk).
- **Deepfakes moeten gelabeld worden.** Realistische AI-beelden of -video van mensen of gebeurtenissen die niet echt zijn, moet je als kunstmatig aanduiden.

De boodschap is simpel: zodra je AI inzet richting klanten of publiek, moet je open zijn dat het AI is. Geen verstopte bots, geen ongemarkeerde AI-beelden. Dat sluit aan op de bredere privacyvraag rond AI, die ik uitwerkte in [wat mag wel en niet met AI en de AVG](/blog/ai-avg-privacy-wat-mag-wel-niet).

Tijdlijn van de AI Act: transparantie-eisen op 2 augustus 2026, high-risk uitgesteld naar december 2027 en augustus 2028

## Wat dit concreet voor jouw MKB betekent

Vertaal het naar je eigen bedrijf. Drie checks:

1. **Heb je een chatbot of AI-assistent in klantcontact?** Zorg dat die meldt dat het AI is. Eén regel volstaat vaak: "Je chat met een AI-assistent."
2. **Publiceer je AI-gemaakte teksten, beelden of video's?** Markeer ze. Gebruik je een generatieve AI-tool die al vóór 2 augustus 2026 in gebruik was, dan is er een respijt: de machine-leesbare markering hoeft pas op 2 december 2026 op orde te zijn.
3. **Gebruik je realistische AI-beelden van mensen?** Label ze als AI-gegenereerd.

Dat is het, voor de meeste bedrijven. Geen conformiteitsbeoordeling, geen zware audits, dat hoort bij high-risk en dat is uitgesteld. Wat nu telt is eerlijkheid: laat zien waar AI in het spel is.

## De boetes, en de verzachting voor het MKB

De AI Act kan stevig beboeten: tot 15 miljoen euro of 3 procent van de wereldwijde jaaromzet voor overtredingen in deze categorie. Dat klinkt heftig, en voor grote spelers is het dat ook.

Voor het MKB geldt een verzachting, en die is concreter dan "proportioneel". Voor kleine bedrijven draait de boeteregel zelfs om: niet het hoogste van die twee bedragen, maar het laagste. Een klein bedrijf riskeert dus een fractie van dat maximum, niet de volle 15 miljoen. De toezichthouder gaat een klein bedrijf met een nette chatbot-melding ook niet hetzelfde behandelen als een multinational die bewust deepfakes verspreidt. Maar reken niet op die nuance als excuus om niks te doen: de transparantie-eis zelf is helder en goedkoop om te halen.

## Het uitstel is inmiddels definitief

Toen ik dit schreef stond het nog niet in beton. Inmiddels wel. Verordening (EU) 2026/1744, de Digital Omnibus on AI, is aangenomen op 8 juli 2026 en in werking sinds 27 juli 2026. De nieuwe datums zijn daarmee geldend recht: 2 december 2027 voor Annex III, 2 augustus 2028 voor Annex I, en 2 augustus 2027 voor de sandboxes.

Wat betekent dat voor jou? Plan op de transparantie-eis van 2 augustus 2026, want die schoof niet mee. En controleer de datum in elk stuk advies dat je krijgt: veel Nederlandse bronnen tonen nog steeds 2 augustus 2026 voor hoog-risico.

> **Lees ook:** **[AI Act voor het MKB: wat je nu geregeld moet hebben](/governance/ai-act)**: de actuele stand van zaken per artikel, met een checklist van 17 punten en de boete-nuance voor het MKB uit artikel 99, lid 6.

## Wat ik zou doen

Niet wachten, en ook niet in paniek schieten. Loop je AI-gebruik langs met de drie checks hierboven, en regel de transparantie waar nodig. Dat is een middag werk, geen project. De volledige stappenlijst staat in [de AI-Act-checklist voor het MKB](/blog/ai-act-augustus-2026-mkb-checklist).

Zit je in een sector waar high-risk AI wél speelt (zorg, krediet, werving, onderwijs)? Dan heb je nu tijd gekregen, maar gebruik die tijd om je leverancier te laten aantonen dat hij de high-risk-compliance op orde krijgt vóór zijn deadline. Uitstel is geen afstel.

> **Lees ook:** **[AI in de zorg: waar het mag, en waar het moet wachten](/blog/ai-zorg-mkb-waar-het-mag)**: hoe de high-risk-grens uitpakt in een sector waar het wél speelt.

Veelgestelde vragen

## Regel de transparantie, houd de rest in de gaten

De AI Act is geen muur die op 2 augustus op je afkomt. Het deel dat de meeste MKB-bedrijven raakt is klein en goedkoop te regelen: wees open dat je AI gebruikt. Het zware deel is uitgesteld en raakt je waarschijnlijk niet.

Wil je zeker weten welke AI-Act-eisen op jouw bedrijf van toepassing zijn en wat je moet regelen? [Plan een vrijblijvend kennismakingsgesprek](/ai-voor-het-mkb), dan lopen we je AI-gebruik samen langs.

large_ai-act-2-augustus-wat-verandert_cover

medium_ai-act-2-augustus-wat-verandert_cover

small_ai-act-2-augustus-wat-verandert_cover

thumbnail_ai-act-2-augustus-wat-verandert_cover

ai-act-2-augustus-wat-verandert_cover

AI Act op 2 augustus: wat ingaat, en wat is uitgesteld

Je kunt de beste AI-tool van de markt aanschaffen en alsnog niets veranderen. Niet omdat de techniek niet werkt, maar omdat niemand hem gebruikt. AI-adoptie is het stuk waar de meeste MKB-bedrijven op vastlopen, en het is precies het stuk dat in de meeste adviezen ontbreekt.

In dit stuk lees je hoe je AI-adoptie in het MKB wél voor elkaar krijgt. Niet met een groot programma vol trainers en champions, want dat past niet bij een bedrijf van twintig man. Wel met een aanpak die ik als eenpitter bij kleinere MKB-bedrijven gebruik, met de eigenaar en de proceseigenaar als motor.

## Het probleem zit bij de mensen, niet bij de tool

De cijfers zijn duidelijk over waar het misgaat. Onderzoek van Prosci laat zien dat ongeveer 63% van de knelpunten bij AI-implementaties bij de mens ligt, niet bij de techniek. BCG komt voor AI met een vergelijkbare verhouding: de waarde zit voor ongeveer 70% in mensen en processen, en maar 10% in het algoritme. De meeste bedrijven investeren precies andersom.

Dat herken je waarschijnlijk. Iemand koopt een licentie, houdt een demo, en drie weken later is iedereen terug bij de oude manier van werken. De tool staat er, maar het gedrag is niet veranderd.

AI verandert het werk zelf, niet alleen het gereedschap. En werk verander je niet met een mailtje van de directie dat "we nu AI doen". Je verandert het door de mensen die ermee moeten werken er echt bij te betrekken.

> 📖 **Lees ook:** **[Waarom het MKB worstelt met AI-implementatie](/blog/mkb-worstelt-met-ai-implementatie)**: de struikelblokken die de meeste bedrijven raken.

## Het grootbedrijf-draaiboek past niet op het MKB

Grote organisaties hebben hier een vast recept voor. Ze rollen AI uit in golven, trainen managers, en bouwen een netwerk van champions: collega's die als aanspreekpunt fungeren en de rest meenemen. Bedrijven met zo'n actief champion-netwerk halen er twee tot drie keer zoveel gebruik uit als bedrijven die het hun mensen zelf laten uitzoeken.

Dat werkt op de schaal van duizenden medewerkers. Maar als je twintig of vijftig man bent, heb je geen afdeling die een champion-programma kan optuigen, en geen budget voor maandenlange trajecten. Het draaiboek van een bank van zesduizend mensen kopiëren naar jouw bedrijf is vragen om teleurstelling.

De onderliggende les klopt wel: adoptie loopt via mensen, niet via een tool. Alleen de vorm moet anders. Kleiner, directer, en zonder overhead.

De motor van adoptie: eigenaar en proceseigenaar betrekken het team, niet andersom

## Wat wél werkt: AI-adoptie bij kleiner MKB

In een klein bedrijf hoef je geen champion-leger op te bouwen. Je hebt al iemand naar wie mensen toelopen met vragen: vaak de eigenaar zelf, of de persoon die het proces het beste kent. Dat is je champion. Zo pak ik het aan.

### Betrek de eigenaar en de proceseigenaar direct

Ik bouw nooit iets over de hoofden van mensen heen. De eigenaar en de proceseigenaar zitten vanaf het begin aan tafel: zij kennen het werk, zij voelen de pijn, en zij hebben het gezag om het echt te laten landen. Niet als opdrachtgever op afstand, maar als mede-eigenaar van de verandering.

Dat is meteen het verschil met een tool die van bovenaf wordt opgelegd. Als de proceseigenaar zelf heeft meegedacht over wat AI overneemt en wat niet, verdedigt hij het ook naar de rest van het team.

### Laat hen de voortgang bewaken

Hier zit de kern. Adoptie houd je niet vast met een eenmalige training, maar met een terugkerend moment. Ik zorg dat de eigenaar en proceseigenaar de voortgang bewaken door het regelmatig met hun team te bespreken.

Geen apart overlegcircus, maar een vast punt in het bestaande teamoverleg: wat ging goed, waar liep iemand vast, wat passen we aan. Dat houdt het levend, het haalt frictie naar boven voordat mensen afhaken, en het maakt duidelijk dat dit blijft, geen proefballonnetje.

### Begin met één proces en één klein succes

Geen grote uitrol waarin alles tegelijk moet. Eén proces dat nu pijn doet, daar iets bouwen dat werkt, en het zich laten bewijzen. Een kleine geslaagde stap doet meer voor het draagvlak dan elk plan op papier. Zo ziet het [automatiseren van je eerste proces](/blog/eerste-processen-automatiseren-ai) eruit.

Als dat ene proces werkt en het team het merkt, ontstaat de vraag naar het volgende vanzelf. Dat is adoptie van binnenuit, niet van bovenaf opgelegd.

### Meet, en bespreek wat je meet

Goed bewaken kan alleen als je weet hoe het ervoor staat. Ik leg vooraf een nulmeting vast: hoeveel tijd kost dit proces nu, hoe vaak gaat het fout. Daarna meet ik opnieuw, en dat cijfer gaat terug het teamoverleg in.

Een ritme van zes tot acht weken werkt goed: meten, bijsturen waar het gebruik laag is, opnieuw meten. Zo zien mensen zwart op wit dat het iets oplevert, en blijft het systeem verbeteren in plaats van na de oplevering stil te vallen. Meer over hoe je dat narekent staat in mijn stuk over [de ROI van AI berekenen](/blog/roi-ai-berekenen-mkb-rekensommetje).

### Maak het veilig om te experimenteren

Mensen gebruiken AI pas echt als ze niet bang zijn iets fout te doen. Laat zien dat experimenteren mag, dat een misser geen ramp is, en dat de laatste controle altijd bij een mens ligt. Het saaie werk laat je los, de beslissing houd je in handen.

Dat past ook bij hoe je AI verantwoord inzet: een spoor van wat er gebeurt en een menselijke check op de plekken die ertoe doen. Niet om af te remmen, maar om het vertrouwd genoeg te maken dat mensen het echt gaan gebruiken.

## Adoptie is geen project met een einddatum

De grootste valkuil is AI behandelen als een boekhoudpakket: één keer uitrollen, go-live, klaar. AI vraagt om doorlopende aandacht, want het werk blijft veranderen. Daarom is dat terugkerende moment in het teamoverleg belangrijker dan welke training ook.

Voor het MKB is dat juist goed nieuws. Je hebt geen duur programma nodig. Je hebt de eigenaar en proceseigenaar nodig die het serieus nemen, één proces dat zich bewijst, en een vast moment om het te bespreken. De rest volgt.

Dit sluit aan op hoe ik over [AI-advies voor het MKB](/blog/ai-advies-mkb-wat-het-is) denk: niet bij de tool beginnen, maar bij het proces en de mensen.

## Wil je je team echt meekrijgen met AI?

Begin niet met een tool, maar met je proces en de mensen eromheen. De gratis **[AI-Readiness-Scan](/ai-kansen-scan)** brengt in dertig minuten in kaart waar AI in jouw bedrijf het meeste oplevert, en hoe je het ingevoerd krijgt zonder dat het na drie weken stilvalt.

Plan een gratis kennismakingsgesprek, dan kijken we samen naar dat ene proces waar je zou willen beginnen.

large_ai-adoptie-mkb-team-meekrijgen_cover

medium_ai-adoptie-mkb-team-meekrijgen_cover

small_ai-adoptie-mkb-team-meekrijgen_cover

thumbnail_ai-adoptie-mkb-team-meekrijgen_cover

ai-adoptie-mkb-team-meekrijgen_cover

AI-adoptie in het MKB: zo krijg je je team echt mee

De beste sales-tip komt meestal een week te laat. Na de call, in de review, als de deal al gewonnen of verloren is. Tegen die tijd verandert geen enkele tip meer iets.

Ik wilde sales coaching tijdens het gesprek, niet erna. Een coach die met je meeluistert en je op het moment zelf rustig bijstuurt. Dus bouwde ik OnCue, mijn open-source live sales copilot. Hij luistert mee tijdens je call, coacht je op je eigen scherm, en je klantdata blijft op je eigen computer.

## Waarom sales coaching achteraf te laat komt

Je kent het patroon. De gespreksopname die niemand terugkijkt. De call-review een week later. De feedback die klopt, maar die je op het moment zelf had moeten weten.

Sales-training gebeurt bijna altijd naast het echte werk. Je leert de theorie in een zaaltje, en in het echte gesprek moet je het maar zien toe te passen. De momenten die ertoe doen zie je pas terug als het al voorbij is. De gemiste vraag, het onbeantwoorde bezwaar, de klant die afhaakt.

Coaching tijdens het gesprek draait dat om. Niet een oordeel achteraf, maar een rustige duw op het juiste moment.

## Wat OnCue tijdens je gesprek doet

OnCue draait op je eigen Mac en luistert mee tijdens een video-call, of dat nu Teams, Zoom of Google Meet is. Op je tweede scherm ziet alleen jij wat er gebeurt. Vijf dingen concreet.

**Het schrijft je gesprek live uit.** OnCue zet spraak naar tekst op je eigen machine, zodat je het gesprek kunt meelezen. Die audio en dat transcript verlaten je computer niet.

**Het bewaakt je spreektijd.** Een balk laat doorlopend zien hoe het gesprek verdeeld is, jij tegenover je klant. In het voorbeeld hieronder 45 tegen 55 procent. Praat je te lang aan één stuk door, dan verschijnt na ongeveer 76 seconden een zachte hint: tijd om te luisteren. Geen geluid, geen pop-up, niets wat je uit je gesprek trekt.

**Het herkent pijnpunten en bezwaren op het moment dat ze vallen.** Zegt je klant iets over kosten, capaciteit of een concurrent, dan verschijnt er een kaartje met de categorie en de exacte zin erbij. Zo mis je het koopsignaal of het bezwaar niet terwijl je met je antwoord bezig bent.

**Het zet de juiste klantcase op het juiste moment in beeld.** In de Pro-versie schuift OnCue de bijpassende case-slide in je gedeelde presentatie op het moment dat het pijnpunt valt. Voor je klant ziet het eruit als een gewone dia-wissel. Er is geen flits of glitch.

**Het geeft je elke minuut een vervolgvraag.** Naast een korte samenvatting stelt OnCue een concrete vervolgvraag voor, passend bij wat er net gezegd is. Zodat je nooit zonder volgende vraag zit.

Het OnCue-dashboard tijdens een gesprek: links het coaching-signaal met een voorgestelde vraag, in het midden het live transcript per spreker, rechts de herkende bezwaren en pijnpunten met hun zekerheid en de spreektijdverdeling

## Waarom lokaal draaien voor jou het verschil maakt

De bekende tools (Gong, Chorus, Fireflies) nemen je gesprekken op en zetten ze op een server van een ander. Ze werken achteraf, en ze kosten 75 tot 200 euro per gebruiker per maand.

OnCue doet het omgekeerde. Je audio en je transcript blijven op je eigen machine. Voor gevoelige gesprekken of gereguleerde sectoren kun je zelfs zo instellen dat er helemaal niets weggaat, of dat alleen korte, geanonimiseerde stukjes tekst naar je eigen cloud-omgeving gaan.

Dat betekent drie dingen die met een cloud-tool niet kunnen. Je klantdata blijft van jou. Je bent niet afhankelijk van een externe partij die morgen zijn prijzen verhoogt. En **[privacy is geen bijzaak](/blog/ai-avg-privacy-wat-mag-wel-niet)** die je achteraf moet regelen, maar de standaard.

## Het werkt niet alleen voor sales

Ik begon dit voor mijn eigen verkoopgesprekken, maar de onderliggende vraag is breder. In elk gesprek dat ertoe doet wil je weten of je te veel praat, of je de juiste vragen stelt, en wat de ander eigenlijk zei.

Daarom zitten er drie profielen in, en die kies je voor het gesprek begint.

**Sales.** Herkent pijnpunten en bezwaren, bewaakt je spreektijd, en zet de juiste klantcase klaar.

**Coaching.** Een coach die zelf gecoacht wil worden. Praat jij te veel in plaats van je klant? De talk-time-balans is genadeloos eerlijk, en de samenvatting laat zien welke vragen echt iets losmaakten. Voor trainers en coaches die aan hun eigen gespreksvaardigheid werken is dat directer dan een opname terugkijken.

**Recruitment.** Sollicitatiegesprekken, met een belangrijke kanttekening. Zodra je AI inzet bij werving valt dat onder de strengere regels van de AI-verordening. Dan gelden extra eisen: een risicobeoordeling vooraf, vastleggen wat het systeem doet, en menselijk toezicht op elk selectiebesluit. OnCue heeft daar een apart profiel voor met strengere toestemming en een aantoonbaar logboek. Ga je die kant op, laat het dan eerst juridisch toetsen. Dat meen ik.

Die zware eisen voor werving gaan sinds de Digital Omnibus overigens pas op 2 december 2027 in. Wat vandaag al geldt is de transparantiekant van de AI Act, en die raakt bijna elk bedrijf dat AI richting mensen inzet: [wat er per 2 augustus 2026 van het MKB wordt verwacht](/governance/ai-act).

Een compleet overzicht van de toepassingen staat op [vincentvandeth.nl/oncue](/oncue).

## Gratis of Pro

De complete copilot is gratis en open source. Live meeluisteren, spraak naar tekst, talk-time-coaching, pijnpunt- en bezwaardetectie, de samenvatting en het rapport na afloop: dat zit er allemaal in, zonder te betalen.

De betaalde Pro-laag voegt de extra's toe: de case-slides die automatisch in je presentatie schuiven, opname van telefoongesprekken, een centrale audit voor compliance, en automatisch starten bij een call. De kern-copilot heb je daarvoor niet nodig te kopen.

## Voor wie, en waar het nu staat

OnCue is voor MKB-salesteams, sales-trainers en coaches, en iedereen die veel gesprekken voert en beter wil worden terwijl het gesprek loopt. Het past in een bredere beweging: AI voor het MKB die echt iets oplevert, niet als speeltje.

Je hebt een Mac met Apple Silicon (M1 of nieuwer) en minimaal 16 GB geheugen nodig. Er is een experimentele Windows-versie, maar Mac is de bewezen route. OnCue is nu in beta: de kern werkt op echte gesprekken, en ik zoek een paar mensen die 'm in hun eigen calls willen uitproberen.

## Probeer het

Wil je OnCue in je eigen gesprekken uitproberen? De beta staat open, en de code staat op [github.com/Vinix24/OnCue](https://github.com/Vinix24/OnCue). Stuur me een bericht via <vincent@vnx.digital> als je mee wil doen.

Wil je eerst sparren over AI in je salesproces? [Plan een vrijblijvend kennismakingsgesprek](/ai-consultancy), dan kijk ik met je mee.

> **Lees ook:** **[Lokale LLM's voor het MKB: de benchmark](/blog/lokale-llm-benchmark-mkb)**: welke AI-modellen goed genoeg zijn om lokaal op je eigen machine te draaien.

oncue sales coaching tijdens het gesprek cover

large_oncue-sales-coaching-tijdens-het-gesprek_cover

medium_oncue-sales-coaching-tijdens-het-gesprek_cover

small_oncue-sales-coaching-tijdens-het-gesprek_cover

thumbnail_oncue-sales-coaching-tijdens-het-gesprek_cover

oncue-sales-coaching-tijdens-het-gesprek_cover

Sales coaching tijdens het gesprek, niet erna: zo werkt OnCue

Over the last few months I have quietly removed more MCP servers than I have added. Most of the work they did moved to a plain CLI call, and the agents got faster, cheaper, and easier to audit.

This is not a "MCP is dead" post. The Model Context Protocol solves real problems, and for some of them nothing else comes close. But the MCP vs CLI question deserves a sharper answer than "add every server you can find". The honest framing is a decision rule: which MCP servers earn their place, and which you should replace with a scriptable CLI call. After running both in production, here is where I draw the line.

## The hidden cost of MCP: the context tax

The problem with MCP is not the protocol. It is what it does to your context window.

Every time an MCP server is connected, its full tool definitions get injected into the model's context on every single turn. Tool names, descriptions, complete parameter schemas. You pay for that on every message, whether or not you ever call the tool.

The numbers are blunt. A single MCP server can add roughly 770 tokens of standing schema per turn. That sounds small until you scale it: a 93-tool GitHub MCP server consumes around 55,000 tokens at initialization, Jira adds another 17,000, and a typical enterprise stack of five to ten servers burns 100,000 to 200,000 tokens before the user types a single character. In practice MCP can eat 40 to 50 percent of the available context window before the agent does any real work.

A CLI binary costs zero standing tokens. It sits on disk and consumes nothing until you call it. When you do, you pay for one command, not for a permanent schema dump.

This is why I am not alone in this shift. In early 2026 Perplexity's CTO Denis Yarats said publicly that they were moving away from MCP toward plain APIs and CLI tools, citing exactly these two issues: context consumption and clunky auth flows.

## Where the CLI wins

For most of what an agent does, a CLI call is simply the better tool.

- **Token efficiency.** A CLI command averages a couple of hundred tokens. The equivalent MCP operation, with its schema overhead, runs from thousands of tokens per call up to tens of thousands of standing schema across a full server set. One measured agent-search comparison found the MCP path used about 17 times more tokens per call. Spend those tokens on the actual problem instead.
- **Determinism.** A CLI call is the same every time. Same input, same flags, same output. You can pin it, version it, and diff it. That is the foundation of a system you can trust.
- **Auditability.** A command is a line you can log. I can show you exactly what ran, with which arguments, and when. For governance that is gold.
- **A smaller attack surface.** Fewer always-on connections, fewer tool definitions sitting in context for a prompt injection to hijack.

This is the core of how I run my own orchestration. It is CLI-driven by design, open source on GitHub, and it never depended on OAuth. That choice is also why it survived the OAuth ban that broke other tools. I wrote that story up in [the best OpenClaw alternative after the OAuth ban](/blog/best-openclaw-alternative-cli-subprocess-oauth-ban) and in [how to orchestrate Claude Code without OAuth](/blog/orchestrate-claude-code-without-oauth-cli-patterns).

## Where MCP still earns its place

Now the fair half. There are jobs where a CLI call is the wrong answer, and MCP is exactly right.

- **The service has no CLI.** If a vendor only ships an API and you do not want to hand-roll a client, an MCP server is the clean wrapper.
- **OAuth and dynamic, multi-user auth.** If you need per-user tokens, refresh flows, and scopes across many users, MCP gives you that without building it yourself.
- **Stateful, multi-step sessions.** When a workflow holds a connection open and carries state across steps, the protocol earns its overhead.
- **Built-in schemas, RBAC, and audit logs.** For a multi-tenant enterprise tool, the standardization MCP provides is worth the tokens.

The pattern is clear. MCP wins when you need auth you do not want to build, state you cannot easily script, or an integration that has no command line of its own.

## The decision table

Strip away the debate and it comes down to matching the task to the tool. This is the table I actually use.

Decision table: keep MCP or replace with a CLI call, per task type

| Task type | Keep MCP | Replace with CLI |
|---|---|---|
| Cloud ops (AWS, GCP, GitHub) | | CLI: mature vendor tools exist |
| Local scripts and file work | | CLI: deterministic, zero schema cost |
| Database queries | | CLI: scriptable, auditable |
| OAuth across many users | MCP: auth you don't want to build | |
| Stateful multi-step session | MCP: holds state across steps | |
| Service with no CLI | MCP: clean API wrapper | |
| Multi-tenant with RBAC + audit | MCP: standardized schemas | |

The rough split I land on in practice: CLI for the roughly 80 percent of tasks built on tools the model already knows, and MCP for the 20 percent where you genuinely need auth, state, or a missing command line.

## The token gap closes if you build the server right

One honest caveat. The token tax is not a law of nature, it is a default. A well-built MCP server that uses code execution and on-demand tool discovery, instead of dumping every schema upfront, can match a CLI on token efficiency while keeping the auth, the audit trail, and the multi-tenant support a raw CLI cannot give you.

So the rule is not "always CLI". It is "do not pay the context tax for nothing". If a server gives you auth and state you would otherwise have to build, it earns its tokens. If it is wrapping a tool that already has a perfectly good command line, it does not.

## The security angle you should not skip

There is a reason I weigh the attack surface, not just the token count. MCP's always-on tool definitions are a target. Security researchers have documented prompt injection through tool descriptions, lookalike tools that silently replace trusted ones, and tool combinations that can exfiltrate files. Adding more tokens to context does not just cost money, it dilutes your instructions and widens the surface an attacker can manipulate.

A CLI call does not remove that risk, but it shrinks it. Fewer standing definitions, deterministic commands, and a log of exactly what ran. I went deeper on this in [why I don't install most MCP servers](/blog/mcp-servers-niet-installeren-security).

## What I would do

Audit what you have connected right now. For each MCP server, ask one question: does this give me auth or state I cannot easily script? If yes, keep it. If it is wrapping a tool with a real CLI, replace it and reclaim the context.

Then measure. Look at how many tokens are spent before the agent does anything useful. That number is your context tax, and most teams are paying far more of it than they realize.

The architecture beats the protocol, the same lesson I drew in [architecture beats models](/blog/architecture-beats-models-ai-agent-dispatches). Match the task to the tool, keep the line auditable, and stop loading schemas you never call. This is [how I design AI systems for production](/ai-architectuur), and the orchestration behind it is open source if you want to see how: [github.com/Vinix24/vnx-orchestration](https://github.com/Vinix24/vnx-orchestration).

Frequently Asked Questions

large_mcp-vs-cli-when-to-replace_cover

medium_mcp-vs-cli-when-to-replace_cover

small_mcp-vs-cli-when-to-replace_cover

thumbnail_mcp-vs-cli-when-to-replace_cover

mcp-vs-cli-when-to-replace_cover

MCP or CLI? Which servers to keep, and which to replace with a CLI call

A live sales copilot has to answer three questions in the time a prospect finishes a sentence. What did they just say? Was that an objection or a buying signal? And what should I say back? Each question has a different latency budget, and only one of them needs the cloud.

This is OnCue, my open-source live sales copilot. It runs local-first on a Mac, the code is on GitHub under AGPL-3.0, and it listens along on a real sales call to transcribe, detect, and coach. This post is the architecture and the measured numbers behind it. No hand-waving, and one asterisk I will get to.

## Three jobs, three latency budgets

The whole design falls out of one observation. A live copilot does three things while the prospect is still talking, and each has its own budget.

| Job | Latency budget | Where it runs |
|---|---|---|
| Transcribe (continuous) | real-time | whisper.cpp large-v3-turbo, local |
| Match a known objection | under 100 ms | embedding router (~5 ms), local |
| Read the window (pain, doubt) | 1 to 3 s | LLM, local or cloud, your choice |
| Reframe (what to say now) | 1 to 3 s | cloud LLM, or a stronger box on your LAN |
| Summarize (running plus post-call) | 10 to 60 s | local LLM, fine |

Transcription and detection run fully local and fast. The generative reframe, the "what should I say right now" step, is the only piece a local LLM cannot serve at conversational latency today. That is the asterisk. The 100 percent local tier ships transcription, detection, and summarization on-device. Only the live reframe reaches out, and even that is your choice, not a default.

The live path can never block on a local LLM. So the embedding router and the pre-authored cards carry the instant path, and the LLM reads the conversation on its own cadence, off the critical path. Measured over the whole chain (audio, transcription, detection, model, render), the p95 sits at roughly 2.9 seconds and no measured segment went over 5 seconds.

## Two tracks, not one classifier

Detection is not a single pipeline. Two tracks run side by side over the prospect's speech, and they answer different questions at different costs.

**Track one, cards behind an embedding router.** Prospects rarely say "that is too expensive". They say "we would have to look at the budget for that". The router matches on meaning rather than tokens, in roughly 5 milliseconds, against a library of canonical objections. A hit puts a pre-authored card on screen: a known objection mapped to its strongest rebuttal, zero inference, fully predictable output. Objections and buying signals are single-sourced here, so the curated rebuttal and the tier check are applied in exactly one place.

**Track two, the window classifier.** One `instructor`-structured LLM call reads the last five prospect chunks as a whole and returns pain points and doubt. It fires only when the window holds at least three chunks and at most once every five seconds (`DETECTOR_MIN_CHUNKS`, `DETECTOR_DEBOUNCE_S`), and only the prospect's speech ever enters it.

What keeps this affordable is not an escalation threshold. It is the window, the debounce, and the prospect-only filter. That also makes the privacy boundary explicit: the classifier is a model call, so whichever tier you picked for the call is the tier that reads those windows. Choose Ollama and nothing leaves the machine; choose a cloud provider and short prospect-only fragments do.

The OnCue dashboard mid-call: the coaching signal on the left, the live transcript per speaker in the middle, and on the right the objections and pain points each track surfaced, with their confidence and the talk-time split

Both tracks land on the same screen, which is where the split becomes visible. The objection card on the right carries a curated rebuttal and fired in milliseconds. The pain point cards next to it came out of the window read, arrived a beat later, and are the ones that reference a matching case.

The design consequence I like: track one is a data problem, not a model problem. Every card and every canonical objection I add takes work off track two, which lowers both latency and cost. That is a much better scaling curve than swapping in a bigger model.

## Why the window, and why two debounces

Track two is deliberately not a per-sentence classifier. A sliding window buffers the last N transcript chunks (`DETECTOR_WINDOW_SIZE=5`), because a thought frequently spans two or three fragments and a per-chunk classifier keeps cutting them in half. The system prompt is phase-aware and carries ten-plus negative examples, which is what stops it firing on backchanneling ("ja", "hmm", "precies").

There are two separate debounces, and conflating them is a good way to build a dashboard that behaves like a slot machine. `DETECTOR_DEBOUNCE_S` throttles how often the window is re-read at all. `DEBOUNCE_SECONDS=45` is a per-category cooldown on what reaches the screen, so the same objection does not re-announce itself every time the window slides by one chunk.

The legacy semantic-router path still exists in the codebase, but it is no longer the default classification route.

## Everything talks through a localhost hub

The backend is a locally running Python process with two browser frontends. Every component communicates over WebSocket on `127.0.0.1:8760`. No component can reach another over the network without going through the hub. The hub binds to localhost only, so it is not reachable from other machines by default.

OnCue splits a local data plane that stays on your Mac from a control plane you choose per call

The channels are granular: `/ws/transcript`, `/ws/talk-time`, `/ws/pain-points`, `/ws/objections`, `/ws/buying-signals`, `/ws/coaching`, `/ws/suggestions`, `/ws/summary`, `/ws/slide-control`. Each module is independently runnable and testable.

One decision matters more than the rest here. Transcription runs through a single inference worker with a bounded priority queue, not two parallel engines. An earlier dual-engine design crashed with a Metal SIGABRT under concurrent GPU access on Apple Silicon. The single-worker rewrite gives sequential, stable GPU access. The prospect stream gets priority 0 (high), my own mic priority 1 (low). So the person I need to react to is always transcribed first.

## Two streams instead of diarization

The audio layer hides every capture route behind one `AudioStream` protocol: `start`, `stop`, `read`, plus `chunks_received` and a device label. `MicStream` reads the microphone at 16 kHz mono and is tagged `self`. The prospect route is whatever the platform offers: a whole-system Core Audio process tap on macOS, a BlackHole virtual device as fallback, or a WASAPI loopback on Windows.

That split is the point. Because my voice and the prospect's voice arrive on two physically separate streams, speaker attribution is free. No diarization model, no clustering, no confusion when two people talk over each other. Every architectural problem you do not create is one you never have to tune.

It also makes the priority queue meaningful. Two labelled streams give the queue something to prioritise, which is why the prospect is always transcribed ahead of me. Silero VAD gates both streams on CPU in under 10 milliseconds a frame, so silence never reaches the transcription queue at all.

Diarization does ship, using pyannote v3, but in shadow mode and off by default. It is there for the multi-speaker case, not for the two-party call that dual-stream already solves.

## A provider-agnostic LLM layer

Every model provider sits behind a Python `Protocol`, wrapped with `instructor` for structured output. Swapping a provider is a config change, not a rewrite. OnCue ships with six providers today: Groq, OpenAI, Gemini, Ollama, Vertex AI, and Azure OpenAI. The default is `gemini-2.5-flash`.

The most useful thing I measured was the reasoning budget of the reframe call. Same structured call, only the thinking budget changed.

| Thinking budget | Latency | Quality |
|---|---|---|
| Full (default) | ~11 s | good |
| 0 (off) | ~4 s | inconsistent (1.5 to 8.7 s) |
| 128 tokens | ~2.3 s | clean, consistent |
| 512 tokens | ~4.3 s | no better than 128 |

128 tokens of thinking took the call from 11 seconds to instant plus a couple of seconds, with cleaner questions, on one knob. That is the difference between a copilot that interrupts your flow and one that keeps up.

Transcription has the same story. The heaviest fixed cost in the chain is transcription, not generation, so I benchmarked the backend on identical audio.

| Backend | p50 latency | Cost per run | Note |
|---|---|---|---|
| Local large-v3-turbo (4 threads) | 990 ms | free | default, audio stays on device |
| Groq whisper-large-v3-turbo | 209 ms | $0.0005 | ~5x faster, opt-in, audio leaves the machine |
| OpenAI whisper-1 | 1076 ms | $0.0049 | slower and pricier |

For generation I compared a fast model against a frontier one on the same structured path. Haiku 4.5 landed at p95 ~2.4 s at $1 in and $5 out per million tokens. GPT-4o was not measurably faster and cost roughly twice as much. Frontier is the reference, not the default. Fast and cheap wins the live path.

## The numbers that shaped the model choices

I did not pick models on vibes. I measured them on the copilot's own signals.

For detection, my local free-tier model (`gemma-3n-e4b`) hit a 58 percent category match with zero failed calls. The cloud reference (`gemini-2.5-flash`) hit 87 percent in 1.4 seconds. Local is good enough for the fast route, and the cloud sharpens it where precision matters.

For transcription accuracy, the quantized `large-v3-turbo-q8_0` (834 MB, roughly 55 percent of full size) scored 17.1 percent WER against 17.2 percent for the full turbo model on a clean call, streaming at p50 2.79 seconds. Half the footprint, same accuracy.

The embedding result was the one that changed how I think about this. I tested four multilingual embedders on 16 canonical objections and 18 held-out phrasings. The best model (`multilingual-e5-large`) got 13 of 18 first-hit, 72 percent. The old small model already in the stack (`MiniLM`, 384 dimensions, from 2020) got 12 of 18 and beat two larger models, losing by exactly one query. Every per-query embed ran under 15 milliseconds. The lesson: a fuller library of objections and rebuttals beats a better embedding model. Fill the memory, do not chase the model.

## The bottleneck is hardware, and I need help there

The open problem, stated plainly: transcription is the heaviest fixed cost in the chain, and I cannot brute-force it on the machine I have.

Locally, whisper large-v3-turbo sits at p50 990 ms on 4 threads. I doubled it to 8 threads and got 986 ms. That is noise, not a speedup. The cost is not thread-bound, it is raw-compute-bound, so throwing more CPU at it does nothing.

Groq runs the same model on the same audio at 209 ms, roughly 5x faster, for $0.0005 a run. That gap is what a genuinely fluent live experience feels like. The catch is that it sends audio off the machine, which is the one thing this design exists to avoid. So it ships as opt-in, never as the default.

But it proves the ceiling is hardware, not the model. A sufficiently strong local GPU should be able to approach that 209 ms figure with the audio staying on-device, which would close the last real gap between the local tier and the cloud one.

I cannot benchmark that alone. I have one Mac, which is one data point. If you run a serious local GPU, a DGX-class box, or a Strix Halo, your numbers are worth more than mine here. The transcription harness is in the repo. Run it, open an issue with your hardware and your p50, and that turns a hunch into a spec. This is the contribution I most want right now.

## License enforcement without a server in the hot path

The tiering has to work offline. So the license authority issues Ed25519-signed keys with an `SCP-` prefix, and verification happens fully on the client with no network call.

The 32-byte Ed25519 public key is baked into the build itself, in a generated `_embedded_keys.py` that the verifier resolves at startup, so there is no config file or environment variable that can swap it at runtime. An `SCP-` key is a 91-byte struct (version, tier, rotation epoch, issued-at, expires-at, a 128-bit pseudonymous license id, and a 64-byte signature), and the signature covers the first 27 bytes. The private key lives only on the issuing worker, so there is no way to mint a valid key from the client.

A single `FeaturePolicy` is the one entitlement source. It reads the key, verifies the signature and expiry offline, and holds the whole capability list in one place. Pro grants eight capability ids today; the four that matter most to a user are in-call slide injection, telephony capture, the central tamper-evident audit, and autostart. Missing, invalid, or expired keys degrade to the free tier. The only phone-home is a revocation check that posts nothing but the 128-bit `license_id`, at most once every seven days, and it fails open inside a grace window. The server never terminates the app over license status.

One note on status: the verifier, the entitlement policy, and the grace flow ship and are tested. The Cloudflare Worker that issues keys is deployed and live, and the pilot signup flow runs on it end to end: request, double opt-in, key issued, seat counted. The paid checkout path is built but has not been exercised in production yet, because the pilot keys are free.

## Privacy is a choice you make per conversation

Audio, full transcripts, and any session recordings never leave the machine. whisper.cpp transcribes on-device, so unlike cloud-Whisper services, no LLM destination ever receives audio. What can optionally leave is short, PII-redacted transcript fragments of one to three sentences, and only the prospect's speech is classified, never my own.

Where those fragments go is a per-call decision across three tiers:

1. **Fully local**, with Ollama. Nothing leaves the device.
2. **Your own cloud tenant**. Azure OpenAI in your Azure subscription, Vertex AI in your GCP project, or AWS Bedrock in your account. Fragments stay inside your existing contract, DPA, and chosen EU region, with no new processor added.
3. **A third-party API**, processed under that provider's terms and region.

The same person can pick tier 1 for a sensitive call and tier 3 for an internal sales training. The own-tenant tier makes compliant processing within your tenant possible, but it does not make an organization compliant by itself. The controller stays responsible for provider, region, contracts, and lawful use.

## The asterisks

Three things I will not pretend away. The live reframe cannot run locally at conversational latency today, so that one job leans on the cloud or a stronger machine on your LAN. The `mlx-whisper` backend is an experimental fallback with a known silent zero-segments bug, which is why whisper.cpp is the default. And the license control plane issues keys in production, but its paid checkout path has not carried a real transaction yet.

None of the four benchmark tracks needs the cloud to reproduce. That was the whole point, the same way I run **[my agentic-harness benchmarks](/blog/frontier-models-one-agentic-harness)** in the open. You can run the shootout on your own machine.

> **Read also:** **[Glass Box Governance for multi-agent AI](/blog/glass-box-governance-multi-agent-ai)**: why I log receipts, not chat transcripts, in production AI systems.

## Build on it

The code is on GitHub: [github.com/Vinix24/OnCue](https://github.com/Vinix24/OnCue), AGPL-3.0. The architecture doc and the reproducible benchmark harness (with an **[NDJSON audit log](/blog/ndjson-receipt-ledger-ai-audit-trail)**) are in the repo. Clone it, poke holes in the latency claims, or send a pull request (there is a CLA).

If you break one of the numbers above on your own hardware, open an issue with your setup. The transcription benchmark on fast local silicon is the single most useful contribution right now. What the tool does at the product level lives at [vincentvandeth.nl/oncue](/oncue).

This is the kind of production AI system I design and ship: **[architecture first](/ai-consultancy)**, models second.

oncue local first real time ai architecture cover

large_oncue-local-first-real-time-ai-architecture_cover

medium_oncue-local-first-real-time-ai-architecture_cover

small_oncue-local-first-real-time-ai-architecture_cover

thumbnail_oncue-local-first-real-time-ai-architecture_cover

oncue-local-first-real-time-ai-architecture_cover

Inside OnCue: the architecture of a local-first, real-time sales copilot

Sales-software luistert je gesprekken af en zet ze op een server die jij niet beheert. Ik wilde het omgekeerde. Een copilot die tijdens mijn sales-calls meeluistert, mij coacht op het juiste moment, en geen byte de deur uit stuurt.

Dus bouwde ik 'm zelf. Dat werd OnCue, mijn open-source live sales copilot. Een open source sales copilot die volledig lokaal op mijn eigen Mac draait, met de code op GitHub. Dit stuk is geen verkooppraatje. Het is wat ik onderweg heb geleerd over lokaal bouwen, over de modelkeuzes achter de drie jobs, en over de licentie.

## Waarom een open source sales copilot, en niet gewoon Gong?

De bestaande tools ken je wel. Gong, Chorus, Fireflies. Ze zijn cloud-first, ze werken achteraf, en ze kosten 75 tot 200 euro per gebruiker per maand. Je gesprekken worden opgenomen op een server van een ander.

Voor privacy, AVG en gereguleerde sectoren is dat een blokkade bij de inkoop. En achteraf is te laat. De call-review een week later verandert niets aan een deal die al beslist is.

Ik wilde twee dingen die geen enkele cloud-tool me gaf. Coaching tijdens het gesprek, niet erna. En mijn klantdata die op mijn machine blijft. Dat kan alleen als je het lokaal bouwt en de code openlegt.

## Drie jobs, drie latency-budgets

Dit was het inzicht dat de hele architectuur bepaalde. Een live copilot moet drie dingen doen terwijl de prospect nog aan het praten is. En elk van die drie heeft een eigen tijdsbudget.

De drie jobs van een live sales copilot met hun latency-budgets: transcriberen in real-time, detecteren in twee delen (bezwaar matchen onder 0,1 seconde en het venster lezen in 1 tot 3 seconden), en herformuleren in 1 tot 3 seconden

**Transcriberen** loopt doorlopend en moet real-time. Dat is spraak naar tekst, en het draait lokaal met whisper.cpp. Geen audio verlaat de machine.

**Detecteren** valt in tweeën. Een bekend bezwaar of koopsignaal herkennen moet instant, onder een tiende seconde. Een lokale embedding-router doet dat in ongeveer 5 milliseconden. Het bredere lezen van het gesprek (welk pijnpunt speelt hier, twijfelt iemand?) mag 1 tot 3 seconden kosten en gaat door een taalmodel, lokaal of in de cloud, dat kies je zelf.

**Herformuleren** (wat zeg je nu?) mag 1 tot 3 seconden duren. Dit is het enige stuk dat een lokaal taalmodel vandaag niet op gesprekssnelheid haalt. Hier leunt de copilot op een cloud-model, of op een sterkere machine op je eigen netwerk.

Er is een vierde job, samenvatten, die op de achtergrond draait en 10 tot 60 seconden mag kosten. Die doet een lokaal model prima.

Het enige voorbehoud is dus die herformulering. Alleen dat stuk kan naar de cloud. Al het andere blijft op de machine.

## Twee sporen naast elkaar, niet één classifier

De live-keten mag nooit blijven wachten op een taalmodel. Dus lopen er twee sporen naast elkaar over wat de klant zegt, met een heel verschillende prijs.

De twee detectiesporen in OnCue: een embedding-router die bekende bezwaren in 5 milliseconden op een kaart zet, naast een taalmodel dat het gespreksvenster leest

**Spoor 1: kaarten achter een embedding-router.** Klanten zeggen zelden letterlijk "dat is te duur". Ze zeggen "we moeten even naar het budget kijken". Een embedding herkent dat op betekenis in plaats van op exacte woorden, in ongeveer 5 milliseconden. Is het raak, dan staat de vooraf geschreven kaart er meteen: het bezwaar met de sterkste tegenreactie. Geen model, geen wachttijd, volledig voorspelbaar. Bezwaren en koopsignalen komen alleen uit dit spoor, zodat de gecureerde tegenreactie op precies één plek wordt bepaald.

**Spoor 2: het gespreksvenster.** Eén gestructureerde model-call leest de laatste vijf stukjes klanttekst als geheel, en haalt daar pijnpunten en twijfel uit. Dat gebeurt pas bij minstens drie stukjes en hoogstens eens per vijf seconden, en alleen over wat de klant zegt. Nooit over mijn eigen spraak.

Wat dit betaalbaar houdt is niet een slimme drempel, maar het venster, de wachttijd ertussen, en het filter op alleen de klant. Dat maakt de privacy-grens ook eerlijk: spoor 2 is een model-call, dus welk niveau je voor dat gesprek koos, is het niveau dat die vensters leest. Kies je Ollama, dan gaat er niets weg. Kies je een cloud-model, dan gaan er korte stukjes klanttekst naartoe.

Het aardige gevolg: spoor 1 verbeteren is een datavraagstuk, geen modelvraagstuk. Elke kaart en elk bezwaar dat ik toevoeg haalt werk weg bij spoor 2, en dat scheelt tijd en geld.

## De modelkeuzes, met de cijfers erbij

Ik heb dit niet op gevoel gekozen. Ik heb het gemeten.

Voor de **detectie** vergeleek ik **[lokale modellen](/blog/lokale-llm-benchmark-mkb)** tegen een cloud-referentie. Mijn lokale free-tier model (gemma-3n-e4b) haalde 58% categorie-match met nul fails. De cloud-referentie (gemini-2.5-flash) zat op 87% in 1,4 seconde. Lokaal is dus goed genoeg voor het snelle pad, de cloud scherpt bij waar het moet.

De grootste vondst zat in het **denk-budget** van het herformuleer-model. Dezelfde gestructureerde call met vol redeneren duurde ongeveer 11 seconden. Met een denk-budget van 128 tokens zakte dat naar ongeveer 2,3 seconden, met schonere output. Van elf seconden naar instant plus een paar tellen, met één knop.

Over de hele keten gemeten (audio, transcriptie, detectie, model, scherm) zit de p95 op ongeveer 2,9 seconden. Geen enkel gemeten fragment ging boven de 5 seconden.

## Een voller geheugen telt meer dan een beter model

De les die me het meest verraste zat in de **embeddings**, het model dat bezwaren herkent op betekenis in plaats van op exacte woorden.

Ik testte vier meertalige modellen op 16 canonieke bezwaren en 18 achtergehouden formuleringen. Het beste model (multilingual-e5-large) pakte 13 van de 18 in één keer goed, 72%. Het oude, kleine model dat er al in zat (MiniLM, 384 dimensies, uit 2020) haalde 12 van de 18 en versloeg twee grotere modellen. Het verloor met precies één query verschil.

De conclusie was ontnuchterend. Een voller geheugen telt meer dan een beter model. Ik kon beter mijn bibliotheek met bezwaren en tegenreacties vullen dan een groter embedding-model najagen. Dat scheelt schijf, geheugen en laadtijd, en het levert meer op.

## Waar ik nu vastloop: de hardware

Hier zit mijn grootste openstaande probleem, en ik wil er niet omheen draaien.

De transcriptie is de zwaarste vaste kost in de keten. Zwaarder dan het genereren. Lokaal draait whisper large-v3-turbo op p50 990 milliseconden. Ik gooide er meer CPU-threads tegenaan, van 4 naar 8, en kwam uit op 986 milliseconden. Vrijwel geen verschil. De kost zit niet in de threads, maar in rauwe rekenkracht.

Toen testte ik dezelfde audio via Groq. Hetzelfde model, 209 milliseconden, ongeveer vijf keer sneller, voor een halve cent per run. Dat is precies het gat dat de hele live-ervaring soepel zou maken.

Alleen: dan verlaat je audio je machine. Dat is exact wat ik met OnCue wilde voorkomen. Dus is dat een opt-in, geen standaard.

Die 209 milliseconden laten wel zien wat er mogelijk is zodra je genoeg rekenkracht hebt. Het is geen modelprobleem, het is een hardwareprobleem. Met een sterke lokale GPU zou dezelfde transcriptie richting die 200 milliseconden moeten kunnen, met de audio gewoon op je eigen machine.

Dat kan ik niet in mijn eentje uitzoeken. Ik heb een Mac, en dat is één datapunt. Draai je een dikke lokale GPU, een DGX-achtige bak of een stevige Strix Halo? Dan is jouw meting waardevoller dan wat ik hier kan produceren. Draai de benchmark, open een issue met je hardware en je cijfers. Daar zoek ik contributors voor.

## Waarom AGPL-3.0-only plus een commerciële licentie

De code is open. De moat zit niet in de code. Die zit in de gecureerde kaart-data, de gehoste dienst eromheen, en de implementatie-expertise. Die drie houd ik apart.

Dat maakt de licentiekeuze scherp. Ik koos AGPL-3.0, en wel om een specifieke reden. De netwerk-clausule van AGPL sluit het gat dat gewone GPL laat liggen. Wie een aangepaste versie als netwerkdienst aanbiedt, moet zijn wijzigingen ook publiceren. Een SaaS-fork die mijn werk sluit is daarmee van tafel.

Ik koos bewust de `-only` variant, niet `-or-later`. Bij dual-licensing wil je grip houden op welke licentieversie geldt. `-or-later` laat gebruikers eenzijdig een toekomstige AGPL-versie kiezen. `-only` houdt die keuze bij mij.

Daaronder ligt een CLA in de stijl van Apache. Elke bijdrager houdt zijn eigen copyright en verleent mij een brede licentie, geen overdracht. Dat is wat dual-licensing mogelijk maakt: dezelfde code kan onder AGPL en onder een commerciële licentie de deur uit.

BSL en FSL heb ik overwogen en afgewezen. Dat is source-available, geen open source. Ik mag het geen open source noemen, en het jaagt bijdragers en vroege gebruikers weg. Gratis tot ik besluit dat je moet betalen leest niemand als open. De bescherming tegen concurrenten heb ik al via AGPL plus die gescheiden moat.

## Wat ik hiervan meeneem

Vier dingen die ik bij een volgend real-time systeem meteen weer zo doe. Het is precies hoe ik **[AI-productiesystemen ontwerp](/ai-consultancy)**: eerst de architectuur, dan het model.

Splits het werk eerst op latency-budget, dan pas op model. Laat de kaarten en de embeddings het instant-spoor dragen, en geef het taalmodel een eigen tempo naast de live-keten in plaats van erin.

Vul de bibliotheek voordat je een groter model pakt. Data verslaat modelgrootte vaker dan je denkt.

Meet waar je tijd echt heen gaat. Ik ging er lang van uit dat het genereren de bottleneck was. Het was de transcriptie, en daarmee de hardware.

En kies de licentie op dag één, bewust. Een licentie is tegelijk je distributiekanaal en je moat-beslissing. Niet iets om achteraf op te plakken.

> **Lees ook:** **[AI en AVG: wat mag wel en niet met klantdata](/blog/ai-avg-privacy-wat-mag-wel-niet)**: waarom lokaal draaien het privacy-probleem bij de bron oplost.

## Bouw mee

De code staat op GitHub: [github.com/Vinix24/OnCue](https://github.com/Vinix24/OnCue), onder AGPL-3.0. Sloop het, stel vragen, of bouw mee via een pull request (er hoort een CLA bij).

Twee dingen waar ik concreet hulp bij zoek. Heb je snelle lokale hardware, draai dan de transcriptie-benchmark en post je cijfers in een issue. Ik wil weten hoe dicht je lokaal bij die 209 milliseconden komt. En ik zoek een paar beta-testers die OnCue in echte gesprekken gebruiken, geen demo-scenario's.

Wat de tool verder allemaal doet, en voor welke gesprekken hij bedoeld is, staat op [vincentvandeth.nl/oncue](/oncue).

oncue lokaal open source sales copilot cover

large_oncue-lokaal-open-source-sales-copilot_cover

medium_oncue-lokaal-open-source-sales-copilot_cover

small_oncue-lokaal-open-source-sales-copilot_cover

thumbnail_oncue-lokaal-open-source-sales-copilot_cover

oncue-lokaal-open-source-sales-copilot_cover

OnCue: een open source sales copilot die volledig lokaal draait

> **Update augustus 2026:** de datums stonden hieronder nog als voorstel. Ze liggen inmiddels vast. Verordening (EU) 2026/1744, de Digital Omnibus on AI, is aangenomen op 8 juli 2026 en in werking sinds 27 juli 2026: hoog-risico Annex III schuift naar 2 december 2027, Annex I (waaronder AI in medische hulpmiddelen) naar 2 augustus 2028. Wat op 2 augustus 2026 wél inging zijn de transparantieverplichtingen uit artikel 50 en de handhaving van de AI-geletterdheidsplicht uit artikel 4. De grens tussen wat nu al mag en wat moet wachten verandert daar niet door. Actuele stand: **[de AI Act-pagina voor het MKB](/governance/ai-act)**.

In de meeste sectoren is governance een rem. In de zorg is het de voorwaarde. Zonder een heldere grens tussen wat mag en wat niet, begin je niet eens.

Dat klinkt streng, maar het is goed nieuws. AI in de zorg hoeft niet te wachten tot alle regels zijn uitgekristalliseerd. Een groot deel mag nu al, mits je weet waar de grens ligt. Dit stuk trekt die grens: waar AI in de zorg vandaag al waarde toevoegt, en waar je beter wacht tot de regels en de techniek volwassen zijn.

## Waarom AI in de zorg anders ligt

Het verschil met andere sectoren zit in twee dingen: de data en de inzet. De data is patiëntdata, het gevoeligste wat er is, met de AVG er strak omheen ([wat mag wel en niet met AI en privacy](/blog/ai-avg-privacy-wat-mag-wel-niet)). En de inzet is gezondheid, soms een leven. Een foute offerte kost geld. Een foute diagnose kost meer.

Daarom is de scheidslijn niet "kan AI dit technisch", maar "mag een AI-uitkomst zonder menselijke beoordeling tot een handeling leiden". Het antwoord in de zorg is bijna altijd nee. AI is een hulpmiddel, geen vervanger van de zorgverlener. Die regel bepaalt wat nu al mag.

## Waar AI in de zorg nu al mag

Dit zijn de toepassingen die vandaag al waarde toevoegen in een praktijk of kliniek, omdat een mens altijd de laatste beslissing neemt. Concrete voorbeelden van AI in de zorg die binnen de lijntjes blijven:

- **Administratie en planning.** Afspraken inplannen, agenda's puzzelen, declaraties voorbereiden. Praktijken die dit automatiseren melden een flinke daling in administratietijd. Geen patiëntbeslissing, puur logistiek.
- **Spraakgestuurde verslaglegging.** De zorgverlener spreekt, AI maakt een concept-verslag voor het dossier. De zorgverlener leest na, corrigeert en accordeert. Dat scheelt typewerk en houdt de aandacht bij de patiënt.
- **Consultvoorbereiding en triage-ondersteuning.** AI vat binnenkomende klachten samen en geeft een indicatie van urgentie. De assistente of huisarts beoordeelt en beslist. AI sorteert voor, de mens kiest. Let op: zodra de AI zélf de urgentie bepaalt en daarmee de toegang tot zorg stuurt, kan het onder de strenge regels vallen. Houd het bij voor-sorteren.
- **Interne kennisvragen.** Een AI die je eigen protocollen en richtlijnen doorzoekt en een onderbouwd antwoord geeft, met bronverwijzing. Sneller dan zoeken, en de zorgverlener checkt de bron.
- **Patiëntcommunicatie.** Concept-antwoorden op veelgestelde vragen, afsprakenherinneringen, nazorginstructies. De praktijk keurt de inhoud, AI levert de eerste versie.

De rode draad: dit is voorwerk. AI levert een concept of een sortering, een mens neemt de beslissing. Zo houd je de tijdwinst zonder de verantwoordelijkheid uit handen te geven.

> 📖 **Lees ook:** **[AI voor administratie, facturen en boekhouding](/blog/ai-administratie-facturen-boekhouding)**: hoe je het administratieve voorwerk veilig automatiseert.

Twee kolommen: wat AI in de zorg nu al mag versus wat moet wachten door de AI Act

## Waar AI in de zorg moet wachten

Aan de andere kant van de lijn staan de toepassingen die direct ingrijpen op de diagnose of behandeling. Daar moet je voorzichtig zijn, en vaak even wachten.

- **Diagnose-ondersteuning en beeldanalyse** die zelfstandig een conclusie trekt.
- **Klinische beslisondersteuning** die een behandeling voorstelt zonder dat een arts elke stap weegt.
- **Patiëntmonitoring** die zelf alarmeert of ingrijpt zonder menselijk toezicht.

Niet omdat het niet kan, maar omdat het onder strenge regels valt en de foutmarge klein moet zijn. Deze toepassingen gelden onder de Europese AI Act als high-risk. Dat betekent harde eisen: aantoonbare datakwaliteit, menselijk toezicht, en een conformiteitsbeoordeling voordat je het inzet. Die high-risk-verplichtingen worden gefaseerd ingevoerd. Voor AI in medische hulpmiddelen (Annex I) is dat 2 augustus 2028, voor de stand-alone systemen uit Annex III 2 december 2027. De transparantie-eisen gelden eerder: die gingen op 2 augustus 2026 in.

Wachten is hier niet stilstaan. Het is de techniek volgen en pas instappen als de leverancier de compliance op orde heeft en jij het toezicht hebt geregeld.

## De AI-Act-grens, concreet

De AI Act is geen losse regel maar een extra laag boven de bestaande zorgwetgeving en de AVG. Medische AI die als medisch hulpmiddel telt, moet aan beide voldoen.

Voor jou als praktijk of kliniek vertaalt zich dat naar drie vragen bij elke tool:

1. Valt deze toepassing onder high-risk? (Grijpt het in op diagnose of behandeling?)
2. Is er aantoonbaar menselijk toezicht ingebouwd?
3. Waar wordt de patiëntdata verwerkt en opgeslagen?

De volledige checklist voor augustus 2026 werkte ik uit in [de AI-Act-checklist voor het MKB](/blog/ai-act-augustus-2026-mkb-checklist). De zorg zit aan de strenge kant daarvan. Wil je per punt zien [wat er per 2 augustus 2026 geldt en wat pas op 2 december 2027](/governance/ai-act), dan staat dat op mijn AI Act-pagina.

## Houd de data binnen

De gevoeligste vraag is de derde: waar gaat de patiëntdata heen? Veel AI-tools sturen data naar een server buiten je eigen muren, vaak buiten Europa. Voor patiëntdata is dat een risico dat je niet zomaar neemt.

Het alternatief is AI die lokaal of binnen Europese diensten draait, zodat de data je organisatie niet verlaat. Dat is precies de afweging die ik beschrijf in [van wie is jouw AI eigenlijk](/blog/ai-werkstation-85000-data-soevereiniteit). In de zorg is dat geen luxe maar vaak een harde eis. Controleer bij elke tool waar de data wordt verwerkt, voordat je een patiëntgegeven invoert.

## Governance is de voorwaarde, niet de rem

Ik kom uit de financiële wereld, waar elke beslissing een spoor moet achterlaten: wie deed wat, op welke grond, wanneer. ISO, ISAE, audittrails. Dat klonk lang als bureaucratie, tot je beseft dat het precies is wat de zorg nodig heeft om AI veilig in te zetten.

Een audittrail die vastlegt welke AI-uitkomst tot welke menselijke beslissing leidde, is in de zorg geen administratie. Het is je bewijs dat de mens de laatste schakel was. Bouw dat spoor in vanaf het begin, dan is governance geen rem die je achteraf moet inbouwen, maar de basis waarop je veilig kunt versnellen.

## Wat ik zou doen

Begin aan de veilige kant van de lijn. Pak een administratieve of ondersteunende taak die nu tijd kost: planning, verslaglegging, patiëntcommunicatie. Zet daar AI op, met een mens die accordeert, en leg vast wie wat goedkeurt.

Blijf met je handen af van alles wat zelfstandig een diagnose of behandeling raakt, tot de leverancier de high-risk-compliance kan aantonen en jij het toezicht hebt geregeld. Zo boek je nu winst zonder een risico te nemen dat je in de zorg niet kunt veroorloven.

## Begin aan de veilige kant

AI in de zorg is geen kwestie van wel of niet, maar van waar. Aan de ene kant van de lijn ligt directe winst zonder risico. Aan de andere kant ligt high-risk-terrein waar je beter even wacht.

Wil je weten welke AI-toepassingen in jouw praktijk of kliniek nu al veilig kunnen, en waar de grens voor jou ligt? [Plan een vrijblijvend kennismakingsgesprek](/ai-voor-het-mkb), dan kijk ik met je mee naar wat wel en niet kan, en hoe je het toezicht inricht.

large_ai-zorg-mkb-waar-het-mag_cover

medium_ai-zorg-mkb-waar-het-mag_cover

small_ai-zorg-mkb-waar-het-mag_cover

thumbnail_ai-zorg-mkb-waar-het-mag_cover

ai-zorg-mkb-waar-het-mag_cover

AI in de zorg: waar het mag, en waar het moet wachten

Het duurste AI-model is niet automatisch het beste. Ik heb het net zwart op wit gemeten.

In een test waarin ik veertien AI-varianten dezelfde echte programmeertaken liet doen, sprong een goedkoop open model van de onderkant naar de absolute top. Niet door een ander model te pakken, maar door hetzelfde model anders in te zetten. Diezelfde verschuiving bepaalt of jouw AI-keuze geld bespaart of geld kost. Dit stuk legt uit waarom, zonder dat je techneut hoeft te zijn.

## Waarom de meeste AI-ranglijstjes je op het verkeerde been zetten

Je ziet ze overal: lijstjes die AI-modellen rangschikken op "wie is het slimst". Het probleem is hoe ze testen. De meeste benchmarks geven een model één opdracht en kijken naar het antwoord in één keer. Geen gereedschap, geen kans om iets op te zoeken, te proberen en te verbeteren.

Maar zo werkt niemand. Jij werkt ook niet door blind één keer een offerte uit je mouw te schudden zonder iets na te kijken. Je raadpleegt oude offertes, je rekent na, je corrigeert. Een AI die je dat ook laat doen, presteert totaal anders dan een AI die het in één gok moet doen.

Dus een ranglijst die "schrijf het in één keer, blind" meet, vertelt je niet hoe goed een model je werk doet. Het vertelt je hoe goed het gokt. Dat is zelden wat je nodig hebt.

## Wat mijn test liet zien

Ik gaf veertien AI-varianten dezelfde echte taken, met dezelfde score-meetlat. Het verschil zat in hoe ze mochten werken.

Eén goedkoop open model kreeg eerst alleen de "blinde gok"-aanpak. Het scoorde bijna nul op de moeilijke taken. Toen gaf ik exact hetzelfde model de volle gereedschapskist: lezen, testen, fouten herstellen, net zoals de dure modellen die kregen. Op een lastige taak ging de score van een dikke onvoldoende naar bijna de top. Hetzelfde model, dezelfde aanbieder, alleen een andere manier van werken eromheen.

En het werd voorspelbaarder. In de blinde aanpak was het model wispelturig: de ene keer goed, de andere keer een misser. Met de gereedschapskist leverde het keer op keer stabiel hetzelfde hoge niveau. Voor een bedrijf is dat misschien wel belangrijker dan een hoge piek: je wilt kunnen vertrouwen dat het elke keer klopt.

De grotere les: op de echt moeilijke klussen kwamen de goedkope open modellen, mits goed ingezet, in dezelfde top terecht als de dure. Het gat tussen "duur" en "goedkoop" was veel kleiner dan elk ranglijstje doet vermoeden.

Hetzelfde AI-model: onderaan met de blinde aanpak, bovenaan zodra het de juiste gereedschappen krijgt

## Wat dit betekent als je AI kiest voor je bedrijf

Drie dingen om mee te nemen.

**Kies niet op de ranglijst, en niet op de prijs.** Een duur model is geen garantie, en een goedkoop model is geen diskwalificatie. Wat je eruit haalt, hangt vooral af van hoe het is ingezet: krijgt de AI gereedschap en de ruimte om te controleren, of moet het blind gokken?

**Een goedkoper model kan het werk van een duur model doen.** Goed ingezet kwam open AI in mijn test op het niveau van de duurste opties, op de taken die ertoe doen. Dat is direct geld: dezelfde kwaliteit, een fractie van de kosten, en je zit niet vast aan één dure leverancier.

**De inzet is het echte werk, niet de modelkeuze.** Het verschil tussen een AI die teleurstelt en een AI die levert, zat in mijn test niet in welk model ik koos, maar in hoe ik het liet werken. Dat is precies waar een goede inrichting het verschil maakt.

## De kanttekening

Dit is geen "goedkoop is altijd beter"-verhaal. Op simpele, mechanische klusjes maakte de uitgebreide aanpak weinig verschil, en soms was hij zelfs trager. De winst zit op het echte werk: dingen bouwen, controleren, beoordelen. Daar waar een mens ook zou nakijken en bijsturen.

En "goedkoop maar goed" vraagt dat je weet wat je doet. Het model is maar de helft; de inrichting eromheen is de andere helft. Zonder die inrichting haal je het verschil niet.

## Wat ik zou doen

Staar je niet blind op welk model "het beste" is volgens een lijstje. Vraag in plaats daarvan: hoe gaan we dit model inzetten, en kan het lezen, testen en zichzelf corrigeren? Daar zit je winst, en daar zit je kostenbesparing.

En durf goedkoper en open te kiezen. Mits goed ingericht doet het vaak verrassend veel, zonder dat je je vastlegt aan één dure aanbieder.

## Voor wie de cijfers en de techniek wil zien

Dit stuk is de korte versie. De volledige test, met alle cijfers, de veertien varianten en hoe ik elk model eerlijk dezelfde kans gaf, staat in mijn technische deep-dive: [one harness, five model families](/blog/frontier-models-one-agentic-harness) (Engels). De complete methode is bovendien openbaar en na te rekenen tegen de broncode, in mijn open-source runtime op [GitHub](https://github.com/Vinix24/vnx-orchestration). Geen marketingclaim, je kunt elk cijfer terugvolgen naar de meting.

Wil je weten welk AI-model bij jouw werk past, en vooral hoe je het zó inzet dat het echt iets oplevert? [Plan een vrijblijvend kennismakingsgesprek](/ai-voor-het-mkb), dan kijk ik met je mee.

large_duurste-ai-model-niet-het-beste_cover

medium_duurste-ai-model-niet-het-beste_cover

small_duurste-ai-model-niet-het-beste_cover

thumbnail_duurste-ai-model-niet-het-beste_cover

duurste-ai-model-niet-het-beste_cover

Het duurste AI-model is niet automatisch het beste

De reflex is altijd dezelfde. Als het marketingteam niet presteert, kijk je naar de mensen. Te weinig ervaring, te weinig drive, de verkeerde aanname.

Maar in de praktijk klopt dat zelden. Een marketingteam dat niet presteert ligt bijna altijd aan het systeem eromheen, niet aan de mensen erin. Geen duidelijke eigenaar, slechte coördinatie, en sturen op de verkeerde cijfers. Voordat je iemand vervangt, loont het om daar te kijken. En om te weten waar AI wel en niet helpt.

## Waarom je marketingteam niet presteert: zelden de mensen

Er is een oude wet uit de procesverbetering: zet een goede presteerder tegenover een slecht systeem, en het systeem wint vrijwel altijd. Structuur weegt zwaarder dan individuele kwaliteit. Zet een slimme marketeer in een kapot systeem en hij onderpresteert. Niet omdat hij niet kan, maar omdat het systeem hem tegenwerkt.

Dat zie ik telkens terug. Hetzelfde teamlid dat in het ene bedrijf vastloopt, bloeit in het andere. Het verschil zit niet in de persoon. Het zit in wie de richting bepaalt, hoe het werk loopt, en waarop wordt gestuurd.

Drie oorzaken komen het vaakst terug. Ik loop ze langs, en per oorzaak wat AI wel oplost en wat niet.

Drie oorzaken waarom een marketingteam niet presteert, met per oorzaak wat AI wel en niet oplost

## Oorzaak 1: geen eigenaar, geen plan

De meest voorkomende. Marketing is van iedereen, en dus van niemand. De directeur bedenkt af en toe een actie, de office manager post iets op social, de verkoper maakt zijn eigen flyer. Niemand overziet het geheel.

Het cijfer eronder is hard: een groot deel van de MKB-ondernemers start het jaar zonder concreet marketingplan. Zonder plan en zonder eigenaar stuur je zonder kompas. Dan is elk teamlid druk, en gebeurt er per saldo weinig.

Heb je helemaal geen team en doe je de marketing er zelf bij, dan is dat een ander verhaal. Daarover schreef ik in [effectieve marketing zonder marketingteam](/blog/hoe-je-effectieve-marketing-doet-zonder-marketingteam). Dit stuk gaat over een team dat er wél is, maar niet levert.

**Wat AI hier niet oplost:** het eigenaarschap. Iemand moet de richting bepalen, de keuzes maken, en de knoop doorhakken. Dat is mensenwerk en blijft mensenwerk.

**Wat AI wel doet:** het geeft die eigenaar de data om te sturen. Wat werkt, wat niet, waar het lekt. De beslissing blijft van de mens, maar hij neemt 'm op feiten in plaats van op onderbuik.

## Oorzaak 2: slechte coördinatie en afstemming

De tweede sluipmoordenaar. Het team werkt hard, maar langs elkaar heen. Sales en marketing geven elkaar de schuld: de leads deugen niet, de opvolging deugt niet. Campagnes lopen niet synchroon.

De impact is groot. Slechte coördinatie is een van de grootste redenen dat campagnes hun doel missen: het overgrote deel van de teams haalt zijn doelen niet structureel. En een groot deel van de teamtijd gaat op aan herhalend handwerk en herstellen in plaats van aan nieuw werk.

**Wat AI wel doet:** het haalt de ruis en het herwerk eruit. Het saaie verbindende werk dat altijd blijft liggen: planning, content taggen, social publiceren, rapportages, de overdracht tussen sales en marketing. Marketingteams winnen daar gemiddeld een paar uur per week mee terug, sommige tot ruim meer.

**Wat AI niet oplost:** de afspraak wie waarvoor verantwoordelijk is. AI versnelt de overdracht, maar bepaalt niet wie de bal aanneemt. Die afspraak maak je zelf.

Dit is precies waar AI taken overneemt en geen mensen vervangt. Daarover schreef ik eerder in [waarom AI taken overneemt, geen banen](/blog/ai-vervangt-taken-niet-banen).

## Oorzaak 3: je meet het verkeerde

De stilste oorzaak, en de gevaarlijkste. Het team stuurt op output (aantal posts, aantal mails) en op platformcijfers (bereik, likes), niet op resultaat (leads, omzet). Dan lijkt iedereen druk en productief, terwijl de naald niet beweegt.

Een team dat op de verkeerde cijfers stuurt, presteert per definitie onder. Niet omdat het niet hard werkt, maar omdat het de verkeerde dingen optimaliseert.

**Wat AI wel doet:** het brengt de juiste data op tafel en koppelt output aan uitkomst. Welke actie leidde tot welke lead, en welke lead tot welke klant. Het maakt zichtbaar wat eerst in losse dashboards verstopt zat.

**Wat AI niet oplost:** de keuze wat "goed" is. Welke uitkomst telt, dat bepaal jij. AI rekent, jij weegt.

> 📖 **Lees ook:** **[AI klantenservice: wat werkt echt](/blog/ai-klantenservice-wat-werkt-echt)**: waar AI in een team-functie wél en niet het verschil maakt.

## Waar AI ophoudt

Hier zit de kern. AI versterkt een team dat richting heeft. Het vervangt de richting niet.

Geef AI aan een team zonder eigenaar en zonder plan, en je krijgt precies hetzelfde resultaat als eerst, alleen sneller en in groter volume. Meer ruis, niet meer resultaat. AI is een versterker. Een versterker op een kapot signaal maakt het kapotte signaal alleen maar luider.

In mijn werk met teams die AI inzetten zie ik dat verschil steeds terug. Het team dat eerst zijn proces en eigenaarschap op orde had, won. Het team dat AI als pleister op een kapot proces plakte, kreeg meer werk en niet meer resultaat. De volgorde is alles.

De mens blijft de laatste schakel: AI doet het voorwerk en het rekenwerk, de richting en de eindkeuze blijven bij een mens.

## Soms ligt het wél aan de bezetting

Niet altijd is het systeem de boosdoener. Soms zit iemand op de verkeerde plek, of mist het team echt een vaardigheid die je niet met proces of AI dichtloopt.

Maar dat is de uitzondering, niet de regel. En je ziet het pas helder als het systeem klopt. Zolang er geen eigenaar, geen plan en geen goede meting is, weet je niet of het aan de mensen ligt. Je gokt. Repareer eerst het systeem, dan weet je het.

## Wat ik zou doen

Begin niet bij ontslag, en niet bij een nieuw AI-tool. Begin bij drie vragen.

Wie is de eigenaar van marketing, met mandaat om te beslissen? Wat is het plan, en weet iedereen wat zijn rol daarin is? Waarop sturen we, en is dat resultaat of alleen output?

Zet die drie op orde. Dan, en pas dan, zet je AI ertegenaan als versterker. In die volgorde levert het iets op. Andersom krijg je een sneller draaiend probleem.

Wil je scherper krijgen welke knelpunten bij jou aan het systeem liggen en welke aan de mensen? Daar gaat ook [waarom MKB-eigenaren vaak aan de verkeerde dingen werken](/blog/mkb-eigenaren-werken-verkeerde-dingen) over.

## Kijk eerst naar het systeem

Een onderpresterend marketingteam is bijna nooit een mensenprobleem. Het is een eigenaarschaps-, coördinatie- en meetprobleem. Repareer die drie, en zet AI er daarna op als versterker.

Wil je weten waar bij jou de winst zit, in het proces of in de inzet van AI? [Plan een vrijblijvend kennismakingsgesprek](/ai-voor-het-mkb), dan kijk ik met je mee naar wat je team echt tegenhoudt.

large_marketingteam-presteert-niet_cover

medium_marketingteam-presteert-niet_cover

small_marketingteam-presteert-niet_cover

thumbnail_marketingteam-presteert-niet_cover

marketingteam-presteert-niet_cover

Je marketingteam presteert niet? Het ligt zelden aan de mensen

Een AI-webshopbouwer zet in vijf minuten een complete winkel voor je neer. Productpagina's, teksten, een thema, navigatie, een basis aan SEO. Indrukwekkend, en het werkt echt.

Maar een webshop is nog geen bedrijf. Dat is de val waar veel ondernemers in stappen: de AI levert in een paar minuten iets dat eruitziet als af, en daarna blijft het stil omdat niemand de winkel vindt of er iets koopt. Dit stuk zet op een rij wat een AI-webshopbouwer wél voor je doet, waar hij stopt, en waar de winst van een webshop echt zit.

## Wat een AI-webshopbouwer wél doet

Op het zware opstartwerk is AI sterk. Je geeft een omschrijving van je niche of een productlink, en de bouwer genereert de boel.

- **Een complete winkel in minuten.** Productpagina's, een thema, indeling, menu en navigatie, vanuit één beschrijving.
- **Productteksten op schaal.** Je levert de productdetails, AI schrijft de beschrijvingen. Dat scheelt dagen typewerk.
- **Een eerste vulling.** Een opzet met voorbeeldproducten en een logische structuur, zodat je niet voor een leeg scherm zit.

Het lege scherm verdwijnt, en dat is de echte winst van deze tools. Wat je vroeger een weekend opzetwerk kostte, staat er nu in een middag. Onderzoekers van Stanford vonden dat medio 2025 al ongeveer een derde van alle nieuwe websites AI-gegenereerd was, vanaf vrijwel nul daarvoor. Dit wordt de norm, niet de uitzondering.

Een AI-webshopbouwer levert de opzet in minuten; vindbaarheid, conversie en onderhoud blijven daarna van jou

## Waar het stopt: een winkel is geen klanten

Hier scheidt de hype zich van de praktijk. De AI bouwt de winkel, maar levert niet de klanten. Vier dingen blijven van jou, en daar zit het echte werk.

- **Vindbaarheid.** Een mooie shop die niemand vindt, verkoopt niets. Gevonden worden in Google en in de AI-zoekresultaten is een vak apart, en dat regelt geen bouwer voor je. Hoe dat speelveld verschoven is, schreef ik in [GEO versus SEO](/blog/2026-05-02-geo-vs-seo-vs-aeo-uitleg).
- **Conversie.** Bezoekers naar kopers krijgen is meer dan een nette pagina. Het zit in vertrouwen, prijsopbouw, betaalgemak en de juiste duwtjes. Een gegenereerd thema is een startpunt, geen conversiemachine.
- **Echte productfoto's en je eigen verhaal.** Veel bouwers, vooral de dropshipping-varianten, trekken stockbeelden van leveranciers binnen. Dat herkent een koper, en het kost vertrouwen. Je eigen foto's en je eigen toon maken het verschil.
- **Koppelingen en onderhoud.** Voorraad, betalingen, verzending, je boekhouding: die moeten kloppen en gekoppeld zijn. En een webshop is nooit af; prijzen, producten en pagina's vragen doorlopend aandacht.

De rode draad is dezelfde die ik overal zie: een tool is geen systeem. AI geeft je de opzet, maar het bedrijf eromheen bouw je zelf. Datzelfde principe speelt bij je bestaande bedrijfssystemen, zoals ik beschreef in [niet migreren, integreren](/blog/niet-migreren-integreren).

## De valkuilen

Een paar dingen gaan voorspelbaar mis als je de AI z'n gang laat gaan.

- **Rommel erin, rommel eruit.** Een vage omschrijving of slordige productdata levert een slappe winkel op. Wat je erin stopt, bepaalt wat je eruit krijgt.
- **Stockfoto's als gezicht van je merk.** Snel, maar het maakt je shop inwisselbaar met honderden andere.
- **Geen strategie onder de knop.** Een winkel zonder plan voor verkeer en conversie is een etalage in een lege straat.
- **Slordig met klantdata.** Persoonsgegevens vragen om zorg; een AVG-misser kost vertrouwen en kan een boete kosten.

## Waar AI daarna wél blijvend helpt

Als de winkel staat, kan AI je in de exploitatie veel werk uit handen nemen, mits je de eindbeslissing houdt.

Productaanbevelingen die per bezoeker meebewegen op koophistorie en gedrag, een chatbot voor de eerste lijn klantenservice, productteksten die je in bulk laat schrijven en zelf nakijkt. Dat is de doorlopende winst, en die is groter dan de opzet zelf.

## Wat ik zou doen

Gebruik AI voor wat het goed kan: de opzet. Laat het de winkel, de teksten en de structuur neerzetten, en bespaar jezelf het saaie bouwwerk. Dat is een eerlijke dag tijdwinst.

Steek je eigen tijd vervolgens in wat geld oplevert: gevonden worden, bezoekers laten kopen, en je eigen foto's en verhaal. Daar wint of verliest een webshop, niet bij de bouwknop.

> **Lees ook:** **[7 taken die AI vandaag al overneemt in het MKB](/blog/ai-automatisering-mkb-7-taken)**: waar AI nog meer het saaie werk uit handen neemt.

## De winkel is de makkelijke helft

Een webshop bouwen met AI is geen kunst meer; dat is de makkelijke helft geworden. De moeilijke helft, en de winstgevende, is wat erna komt: gevonden worden en verkopen.

Wil je weten of je webshop gevonden wordt en waar je conversie blijft liggen? [Vraag een gratis Website Groei Scan aan](/ai-voor-het-mkb), dan kijk ik naar de cijfers achter je winkel.

large_webshop-bouwen-met-ai_cover

medium_webshop-bouwen-met-ai_cover

small_webshop-bouwen-met-ai_cover

thumbnail_webshop-bouwen-met-ai_cover

webshop-bouwen-met-ai_cover

Een webshop bouwen met AI: wat het wel en niet voor je doet

"Moeten wij eigenlijk niet een normaal CRM?" Die vraag krijg ik in bijna elk gesprek met een MKB-eigenaar. De data zit overal en nergens, dus de reflex is: één nieuw systeem dat alles samenbrengt.

Meestal raad ik het af. Niet omdat een CRM slecht is, maar omdat de oplossing die je zoekt zelden in een migratie zit. Een nieuw systeem is duur, pijnlijk en mislukt vaker dan je denkt. En het lost je echte probleem, versnipperde data, niet vanzelf op. Er is een andere weg: niet migreren, maar integreren. Dit stuk legt uit waarom, en hoe.

## De silo-pijn: data overal, overzicht nergens

Het patroon is overal hetzelfde. Klantinfo in het CRM, kosten in het boekhoudpakket, uren in weer een tool, de rest in Excel en op WhatsApp. Elk systeem is op zich prima, maar samen vormen ze een doolhof.

Het gevolg, in de woorden van een ondernemer: "data is verspreid, niet iedereen kan erbij, en als je er wel bij kan klopt het niet of is het verouderd." Een simpel overzicht maken kost dan handmatig knip- en plakwerk, elke week opnieuw. Diezelfde verspreiding speelt bij kennis die alleen in hoofden zit, zoals ik beschreef in [je belangrijkste medewerker is je grootste risico](/blog/belangrijkste-medewerker-grootste-risico). Dat is de pijn die je wilt oplossen. De vraag is alleen hoe.

## Waarom migreren zo vaak misgaat

De aanname is dat één nieuw systeem het doolhof opruimt. In de praktijk gebeurt vaak het tegenovergestelde.

De cijfers zijn ontnuchterend. Veel bedrijven willen hun CRM vervangen of upgraden, maar meer dan de helft van die migraties loopt vertraging op of strandt, door slechte datakwaliteit, onderschatte complexiteit en gebrekkige planning. En het opschonen achteraf kost al snel een veelvoud van het opschonen vooraf.

Belangrijker nog: migraties stranden zelden op de techniek. Daar zit maar een fractie van de mislukkingen; het overgrote deel zit in mensen en proces. Niemand is eigenaar, niemand is getraind, de oude werkwijzen passen niet in het nieuwe systeem. Je verplaatst je rommel naar een duurder systeem, en de silo's komen gewoon terug. Dat sluit aan op een patroon dat ik vaker zie: het echte probleem is meestal organisatorisch, niet technisch.

## De andere weg: een laag erbovenop

Wat je echt wilt is geen nieuw systeem, maar overzicht. En dat kun je krijgen zonder iets te verhuizen.

In plaats van je data naar één nieuw systeem te migreren, leg je er een laag overheen die je bestaande systemen leest en samenbrengt. AI haalt de relevante informatie uit je CRM, je boekhouding en je Excel-bestanden, en geeft je één plek om alles te bevragen. Je houdt je tools, je krijgt het overzicht.

Technisch heet dat een data- of semantische laag: één toegangspunt bovenop verspreide bronnen, zonder alles in één bak te dwingen. Voor jou betekent het simpelweg: je stelt een vraag ("wat is de status van deze klant, inclusief openstaande facturen?") en krijgt het antwoord dat anders in drie systemen verstopt zat.

Losse systemen (CRM, boekhouding, Excel) die via een AI-laag tot één overzicht komen, zonder migratie

## Wat dat oplevert

Het verschil met een migratie is groot. Je hoeft geen data over te zetten, geen personeel om te scholen op een nieuw systeem, geen maandenlang project. De laag sluit aan op wat je al hebt.

Wat je wint: één actueel overzicht in plaats van knip-en-plakwerk, antwoorden in seconden in plaats van zoeken in drie systemen, en data die klopt omdat hij uit de bron komt en niet uit een verouderde kopie.

## De eerlijke grens

Integreren is niet gratis en niet altijd het antwoord. Een paar dingen om scherp te houden.

De datakwaliteit blijft van jou. Een laag erbovenop maakt verspreide rommel doorzoekbaar, maar als de bron niet klopt, klopt het antwoord ook niet. En één centraal toegangspunt verhoogt je afhankelijkheid: toegangsbeheer, back-ups en beveiliging worden belangrijker, niet minder belangrijk. Hier komt governance om de hoek, en dat is precies waar ik op let. Houd je data bij voorkeur binnen je eigen muren, zoals ik uitwerkte in [van wie is jouw AI eigenlijk](/blog/ai-werkstation-85000-data-soevereiniteit).

En soms moet een systeem écht vervangen worden, omdat het verouderd of onveilig is. Dan is migreren wel het antwoord. De regel is niet "nooit migreren", maar "migreer niet als je eigenlijk alleen overzicht zoekt".

## Hoe je begint

Begin niet met alles koppelen. Pak de twee of drie systemen waartussen de meeste vragen vallen, meestal je klantsysteem, je facturatie en dat ene Excel-bestand. Leg daar een AI-laag overheen die ze kan bevragen, met een mens die de uitkomst controleert.

Werkt dat, en levert het je het overzicht dat je zocht, dan breid je uit. Zo los je de silo-pijn op zonder de gok van een complete migratie.

> **Lees ook:** **[7 taken die AI vandaag al overneemt in het MKB](/blog/ai-automatisering-mkb-7-taken)**: het terugkerende datawerk dat je hiermee uit handen geeft.

## Wat ik zou doen

Voordat je een nieuw CRM koopt, stel één vraag: wil ik echt een ander systeem, of wil ik gewoon overzicht over de systemen die ik al heb? In negen van de tien gevallen is het dat tweede.

Bouw dan de laag, niet de migratie. Je houdt je tools, je vermijdt het risico, en je krijgt waar het je echt om ging: kloppende data op één plek.

## Eerst de vraag, dan pas het systeem

Versnipperde data is een echte pijn, maar een nieuw CRM is er zelden de oplossing voor. Vraag je eerst af of je een ander systeem wilt of gewoon overzicht. Meestal is het dat laatste, en dan bouw je de laag, niet de migratie.

Wil je weten hoe je je bestaande systemen samenbrengt zonder een risicovolle migratie? [Plan een vrijblijvend kennismakingsgesprek](/ai-voor-het-mkb), dan kijk ik met je mee naar waar bij jou de data uit elkaar valt.

large_niet-migreren-integreren_cover

medium_niet-migreren-integreren_cover

small_niet-migreren-integreren_cover

thumbnail_niet-migreren-integreren_cover

niet-migreren-integreren_cover

Niet migreren, integreren: je hebt geen nieuw CRM nodig

Niemand begint met een AI-strategie. Iedereen begint met één taak die hij zelf niet meer wil doen.

Dat is wat ik in de praktijk zie. AI automatisering in het MKB begint nooit bij een groot plan. Het begint bij die ene klus die elke week terugkomt en die niemand leuk vindt: de offerte natypen, de inbox leegwerken, de facturen najagen. Dit stuk loopt zeven van die taken langs. Per taak: wat het je nu kost, wat AI ervan overneemt, en de tijdwinst die erin zit.

## AI-automatisering in het MKB: taken, geen functies

Eén ding vooraf, want het bepaalt alles. AI vervangt geen mensen, AI vervangt taken. Het saaie, herhaalbare deel van een functie gaat eraf, het oordeel blijft.

Dat is geen nuance om aardig te zijn. Het is hoe je het veilig inzet. Bij elke taak hieronder is de mens de laatste schakel: de AI doet het voorwerk, jij of je medewerker keurt het laatste setje. Zo houd je de snelheid zonder de controle te verliezen. Meer daarover in [waarom AI taken overneemt, geen banen](/blog/ai-vervangt-taken-niet-banen).

De cijfers hieronder komen uit leverancier- en praktijkdata. Behandel ze als richting, niet als garantie. De winst hangt af van je volume en hoe goed je het inricht.

Overzicht van zeven MKB-taken die AI overneemt, met de geschatte tijdwinst per taak

## 1. Offertes opstellen

De pijn: elke offerte is voor 80 procent hetzelfde, en toch begin je elke keer opnieuw. Teksten kopiëren, prijzen aanpassen, de toon goed krijgen.

Wat AI overneemt: op basis van een paar regels invoer schrijft het een compleet concept in jouw stijl. Jij past de details aan en verstuurt. Het tekstwerk gaat 30 tot 45 procent sneller, en een concept staat er in minuten in plaats van een half uur.

Bij een installatiebedrijf dat ik begeleidde ging de doorlooptijd van een offerte van bijna een uur naar een kwartier. Niet omdat de AI de prijzen bepaalt, maar omdat het lege scherm verdween.

De meest gestelde vervolgvraag hierbij: waarom komt de opmaak er steeds anders uit? Dat is geen AI-probleem maar een plak-probleem, en heeft **[drie oplossingen van gratis tot waterdicht](/blog/ai-offerte-altijd-in-huisstijl)**.

## 2. Klantmail en klantenservice

De pijn: je team leest, sorteert en beantwoordt mail twee tot drie uur per dag. Veel daarvan zijn dezelfde vragen.

Wat AI overneemt: terugkerende vragen krijgen direct een concept-antwoord of worden volledig afgehandeld. In de praktijk vangt een goed ingerichte assistent vaak 50 tot 70 procent van de inkomende vragen af, bij eenvoudige en terugkerende vragen meer. Support-tijd zakt navenant. De rest, het echte maatwerk, blijft bij een mens.

Wat hierin wel en niet werkt, schreef ik uit in [AI klantenservice: wat werkt echt](/blog/ai-klantenservice-wat-werkt-echt).

## 3. Facturatie en administratie

De pijn: facturen invoeren, koppelen, en daarna achter betalingen aanjagen. Routinewerk dat je avonden opeet en waar fouten insluipen.

Wat AI overneemt: facturen uitlezen en boeken, betalingen matchen, en automatisch nette herinneringen sturen. Een bedrijf dat zo'n 50 facturen per week verwerkt bespaart al snel rond de 5 uur handmatig invoerwerk. De gemiddelde incassotijd zakt in voorbeelden van rond de 35 dagen naar onder de 20, simpelweg omdat de herinneringen op tijd uitgaan.

Hoe dit eruitziet in de boekhouding lees je in [AI voor administratie, facturen en boekhouding](/blog/ai-administratie-facturen-boekhouding).

## 4. Contentproductie

De pijn: social posts, nieuwsbrieven en website-teksten kosten tijd die je er eigenlijk niet bij hebt. Dus blijft het liggen.

Wat AI overneemt: het eerste concept. Een maand aan social posts, een nieuwsbrief, een productbeschrijving: AI levert de basis, jij zet de toon recht en voegt het echte verhaal toe. De productietijd zakt met 50 tot 70 procent. Let op: het concept is het werk van de AI, de redactie blijft van jou. Anders klinkt alles hetzelfde.

## 5. Leadkwalificatie

De pijn: nieuwe aanvragen komen binnen op het verkeerde moment, en tegen de tijd dat je reageert is de interesse weg.

Wat AI overneemt: inkomende leads worden 24/7 te woord gestaan, kort gekwalificeerd met een paar vragen, en bij interesse meteen ingepland in je agenda. Je wordt wakker met afspraken in plaats van een rij onbeantwoorde berichten. De inrichting verdient zich vaak binnen 1 tot 3 maanden terug.

## 6. Planning en roostering

De pijn: roosters, afspraken en routes puzzelen kost tijd, en met de hand sluipen er fouten in. Een dubbele boeking, een rit die niet klopt.

Wat AI overneemt: het rekenwerk van het inplannen. Beschikbaarheid, voorkeuren en reistijd worden tegen elkaar afgewogen tot een werkbaar rooster. Het scheelt niet alleen tijd, het maakt aantoonbaar minder fouten dan handmatig plannen.

## 7. Terugkerend datawerk

De pijn: dat ene lijstje dat elke maand opgeschoond moet, de cijfers die je uit drie systemen bij elkaar harkt, het rapportje dat niemand wil maken.

Wat AI overneemt: het saaie datawerk. Lijsten opschonen, gegevens samenvoegen, een terugkerend overzicht in elkaar zetten. Het soort werk dat blijft liggen tot het echt niet meer kan. AI doet het in een fractie van de tijd, en consistenter.

## Begin bij één taak, niet bij zeven

De fout die ik het vaakst zie: alles tegelijk willen automatiseren. Dat loopt vast.

Pak één taak uit dit rijtje. De taak die jou het meeste irriteert en die het vaakst terugkomt. Richt daar AI op in, draai het een week, en kijk wat het echt oplevert. Werkt het, dan pak je de volgende. Werkt het net niet, dan stel je bij of je laat die ene taak met rust.

Zo bouw je iets dat werkt, in plaats van een half-af systeem dat niemand vertrouwt. Waar je het beste begint, werkte ik uit in [je eerste processen automatiseren met AI](/blog/eerste-processen-automatiseren-ai).

> 📖 **Lees ook:** **[ROI van AI berekenen voor het MKB](/blog/roi-ai-berekenen-mkb-rekensommetje)**: reken uit wat een geautomatiseerde taak je echt oplevert.

## Welke taak laat jij als eerste verdwijnen?

AI automatisering in het MKB is geen project van een half jaar. Het is één taak die je deze week kunt verplaatsen, en daarna de volgende.

Wil je weten welke taken in jouw bedrijf zich het beste lenen om te automatiseren, en wat dat oplevert? Bekijk [hoe ik AI-systemen voor het MKB ontwerp](/ai-architectuur), of volg me op LinkedIn waar ik dit soort keuzes hardop maak. En denk ondertussen vast na over één vraag: welke taak zou jij als eerste laten verdwijnen?

Blog over AI-systemen, agents en governance