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.

## Let op: het is nog niet helemaal definitief

Eén eerlijke kanttekening. Het Parlement heeft ingestemd, maar de Digital Omnibus moet nog formeel worden bekrachtigd door de Raad en gepubliceerd in het Publicatieblad voordat de nieuwe datums juridisch vaststaan. Dat wordt verwacht vóór 2 augustus 2026.

Wat betekent dat voor jou? De uitgestelde high-risk-datums zijn de verwachte richting, maar nog niet in beton. De transparantie-eis van 2 augustus staat wel vast. Plan dus op de transparantie-eis, en houd de high-risk-datums in de gaten als je in een sector zit waar dat speelt.

## 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

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

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, en voor medische AI recent verder uitgesteld (in het laatste Europese voorstel naar 2 augustus 2028). De transparantie-eisen gelden eerder. De richting staat vast, de exacte data schuiven nog, dus check de actuele stand voordat je instapt.

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.

## 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?

large_ai-automatisering-mkb-7-taken_cover

medium_ai-automatisering-mkb-7-taken_cover

small_ai-automatisering-mkb-7-taken_cover

thumbnail_ai-automatisering-mkb-7-taken_cover

ai-automatisering-mkb-7-taken_cover

AI automatisering in het MKB: 7 taken die AI vandaag al overneemt

Je hebt OpenAI of Anthropic niet nodig om goede AI te draaien. Er is een hele stapel open modellen die je gratis op je eigen machine zet, zonder dat je data je kantoor verlaat.

De vraag is niet óf het kan. De vraag is welk model je voor wat gebruikt. Dit is het overzicht: welke AI-modellen je lokaal kunt draaien in 2026, waar ze goed in zijn, en welke hardware je ervoor nodig hebt.

## Eerst: wat bepaalt of een model op jouw machine past

Twee dingen, in gewone taal.

**Geheugen.** Een model moet in je werkgeheugen passen, niet alleen op je schijf. Past het niet, dan wordt een taak van een halve minuut ineens tien minuten, of het crasht. Vuistregel: deel het aantal miljarden parameters ongeveer door twee, dan heb je de gigabytes geheugen die je minimaal nodig hebt.

**Het soort model.** Een "dicht" model gebruikt zichzelf helemaal voor elk woord. Een mixture-of-experts-model activeert maar een klein stukje per woord, en draait daardoor veel sneller op dezelfde machine. Het hele model moet nog wel in je geheugen passen, maar groter is niet automatisch trager.

Welke machine je daarvoor onder je bureau zet, schreef ik uit in [een eigen AI onder je bureau voor minder dan een laptop](/blog/lokale-ai-werkstation-dgx-spark-vs-strix-halo).

Open AI-modellen gerangschikt op grootte en toepassing

## De AI-modellen die je lokaal kunt draaien

### Qwen (Alibaba)

De allrounder, en in mijn tests het beste in Nederlands. Er zijn kleine varianten van een paar gigabyte tot grote mixture-of-experts-modellen. De middenklasse is de zoete plek: genuanceerd genoeg voor klantcommunicatie, en het draait op een gewone machine met genoeg geheugen. Meer in [Qwen lokaal draaien voor het MKB](/blog/qwen35-lokaal-draaien-ai-model-mkb).

### Google Gemma

Klein en zuinig. De compacte varianten draaien op vrijwel elke recente laptop en zijn verrassend goed voor hun formaat. Ideaal als eerste kennismaking, of voor snelle taken waar je geen zwaar model voor nodig hebt. Concrete toepassingen in [Google Gemma: modellen en use cases](/blog/google-gemma-4-modellen-use-cases).

### Mistral (Devstral en Codestral)

Het werkpaard. Snel, compact, en in mijn benchmark de beste prijs-kwaliteit voor dagelijkse Nederlandse teksten. Codestral en Devstral zijn ook sterk in code. Als je één model wilt kiezen voor doodgewoon werk, begin hier.

### Meta Llama

De bekende naam. Breed inzetbaar, goed gedocumenteerd, een grote gemeenschap eromheen. De grote varianten (70 miljard parameters) zijn capabel maar traag op betaalbare hardware. Voor de meeste MKB-taken is een kleiner model praktischer.

### DeepSeek

Groot en sterk in redeneren. Dit zijn de modellen die tegen de frontier aanzitten, maar ze vragen serieus geheugen. Voor wie echt zwaar werk lokaal wil draaien en de hardware heeft.

### Microsoft Phi

Piepklein, en het bokst boven zijn gewicht. Een model van iets meer dan twee gigabyte dat snelle eerste drafts levert op een machine met 8 gigabyte geheugen. Niet voor de fijne nuance, wel voor tempo.

### OpenAI gpt-oss

OpenAI's eigen open modellen. Mixture-of-experts, dus zelfs de grote variant draait bruikbaar op een betaalbaar werkstation. Een serieuze optie sinds ze er zijn.

> 📖 **Lees ook:** **[Gratis AI-teksten schrijven, volledig lokaal](/blog/ai-teksten-schrijven-gratis-lokaal)**: hoe je zonder abonnement teksten genereert op je eigen machine.

## Welk model voor welke taak

Geen ranglijst, maar een nuchtere koppeling:

- **Social posts, e-mails, eerste drafts:** een klein model (Gemma, Phi, kleine Mistral). Snel, draait overal.
- **Klantcommunicatie en offertes met nuance:** een groter model met goed Nederlands (Qwen middenklasse). Hier telt elke nuance.
- **Code:** Codestral, Devstral of een Qwen-coder-variant.
- **Zwaar redeneerwerk:** DeepSeek of een groot mixture-of-experts-model, mits je de hardware hebt.

De cijfers achter deze keuzes (snelheid, compleetheid, kwaliteit per model) testte ik op echte MKB-taken in [mijn benchmark van 8 lokale modellen](/blog/lokale-llm-benchmark-mkb).

Kiezen is pas stap één. Meerdere modellen laten samenwerken, elk op de taak waar het in uitblinkt, is stap twee, en hoe betrouwbaar dat lukt meet ik nu in een eigen test waar ik binnenkort op terugkom.

## Waar je ze op draait

Een model is niets zonder een machine eronder. Drie routes:

- **De Mac die je al hebt.** Met 16 of 24 gigabyte geheugen draai je de meeste taken. Waarom een Mac daar goed voor is, lees je in [waarom een Mac de beste keuze is om AI lokaal te draaien](/blog/mac-beste-keuze-ai-lokaal-draaien).
- **Een eigen werkstation** van 2.000 tot 5.000 dollar (DGX Spark, AMD Strix Halo) voor wie groter wil.
- **De compromisloze tier** van 85.000 dollar, voor gereguleerde sectoren. Wat die prijs echt koopt, staat in [een AI-supercomputer onder je bureau](/blog/ai-werkstation-85000-data-soevereiniteit).

De software om ze te draaien is gratis. Met Ollama heb je een model in vijf minuten draaiend, zonder account.

## Begin met één model

Het hele veld overzien is leuk, maar je leert het meeste door te draaien. Kies één model dat bij je belangrijkste taak past, installeer Ollama, en test het op echt werk uit je eigen bedrijf.

De rest van het overzicht hierboven loopt niet weg. Je breidt uit zodra je weet wat je mist.

Wil je hulp bij de keuze, en bij wat je er daarna omheen bouwt? Bekijk [hoe ik AI-systemen voor het MKB ontwerp](/ai-architectuur), of volg me op LinkedIn waar ik dit soort keuzes hardop maak.

large_welke-ai-modellen-lokaal-draaien_cover

medium_welke-ai-modellen-lokaal-draaien_cover

small_welke-ai-modellen-lokaal-draaien_cover

thumbnail_welke-ai-modellen-lokaal-draaien_cover

welke-ai-modellen-lokaal-draaien_cover

Welke AI-modellen kun je lokaal draaien? Het overzicht voor 2026

De meeste AI-adviezen voor het MKB zijn een PowerPoint en een tip welke tool je moet kopen. Mooie slides, een paar voorbeelden van grote bedrijven, en een advies dat neerkomt op "begin met ChatGPT" of "zet er een AI-agent op". Een halfjaar later is er niets veranderd, behalve een factuur.

Goed AI-advies voor het MKB begint ergens anders. Niet bij de tool, maar bij je proces. In dit stuk lees je wat AI-advies wél is, aan de hand van acht principes die ik in de praktijk hanteer. En waarom de meeste projecten stranden op precies die punten.

## Waarom zoveel AI-projecten stranden

De cijfers zijn ongemakkelijk. Een veelbesproken [MIT-onderzoek uit 2025](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-failing-companies/) vond dat 95% van de zakelijke AI-projecten geen meetbaar resultaat oplevert. Let op het woord meetbaar: het gaat niet om "totale mislukking", maar om geen aantoonbaar effect op de cijfers. De onderzoekers wijzen niet naar de techniek. Hun conclusie is dat het verschil zit in de aanpak.

[S\&P Global](https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/) zag dezelfde beweging. Het aandeel bedrijven dat de meeste AI-initiatieven weer schrapt, steeg in een jaar van 17% naar 42%. De grootste obstakels die ze noemen: kosten, dataprivacy en security. Geen modelkwaliteit.

En het bekendste onderzoek naar faaloorzaken, [van RAND](https://www.rand.org/pubs/research_reports/RRA2680-1.html), vond dat ruim 80% van de AI-projecten strandt. Twee keer zo vaak als gewone IT-projecten. De hoofdoorzaak is niet de technologie, maar de organisatie: het probleem is verkeerd begrepen, het model is geoptimaliseerd op de verkeerde maatstaf, of het past niet in het echte werk.

Met andere woorden: het risico zit zelden in de tool. Het zit in de aanpak eromheen. Daar hoort goed advies dus over te gaan.

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

Tool-eerst leidt tot een dood project, proces-eerst leidt tot een meetbaar resultaat

## Wat AI-advies niet is

Voordat ik vertel wat het wel is, eerst wat het niet is. Want daar zit de meeste verwarring.

AI-advies is geen slide-deck met trends. Het is geen lijst van tools die je zou moeten aanschaffen. Het is niet "implementeer ChatGPT en zie wat er gebeurt". En het is zeker niet de aanname dat elk probleem een autonome AI-agent nodig heeft.

Dat zijn allemaal antwoorden die beginnen bij de tool. Goed advies begint bij de vraag: welk proces in jouw bedrijf kost nu te veel tijd of gaat te vaak fout? De tool komt daarna, als gevolg, niet als startpunt.

## AI-advies voor het MKB: acht principes

Dit zijn de principes waarop ik een AI-traject bouw. Ze gelden voor een bedrijf van vijf man net zo goed als voor één van vijftig.

### 1. Begin bij het proces, niet bij de tool

De tool is een gevolg, geen startpunt. Voordat ik iets bouw, leg ik het proces vast: welke stappen, welke beslissingen, waar gaat het mis, wat kost tijd. Pas als dat helder is, weet je of AI er überhaupt iets aan toevoegt en op welke plek.

Dit is precies waar de 95% op struikelt. Wie begint met de tool, bouwt iets dat technisch werkt maar niet in het werk past. Wie begint met het proces, bouwt iets dat gebruikt wordt. Een procesbeschrijving van een dag voorkomt een project van een halfjaar dat niemand aanraakt.

### 2. Niet elk bedrijf heeft een AI-agent nodig

"AI-agent" klinkt indrukwekkend, maar het is vaak het verkeerde gereedschap. Een agent neemt zelf beslissingen en bepaalt zelf zijn stappen. Dat is krachtig waar je echt flexibiliteit nodig hebt, maar het is ook onvoorspelbaarder en duurder.

Voor de meeste MKB-taken is een vaste, deterministische workflow met een beetje AI erin betrouwbaarder. Denk aan: lees deze factuur, haal er deze velden uit, leg ze klaar ter controle. Vaste stappen, AI alleen op het stuk waar het iets toevoegt.

Een agent die zelf zijn stappen kiest, kan ook zelf een verkeerde stap kiezen. Bij een factuurstroom of een offerte is dat een dure fout. Een saaie workflow die altijd precies hetzelfde doet, is daar betrouwbaarder dan een slimme agent die af en toe iets verzint. Zelfs de makers van de bekendste AI-modellen adviseren om [de simpelste oplossing te kiezen](https://www.anthropic.com/research/building-effective-agents), en dat betekent volgens hen soms helemaal geen agent bouwen. Het verschil tussen [een AI-systeem en een losse AI-tool](/blog/ai-systeem-vs-ai-tool-verschil) zit hem in die keuze.

### 3. Leg je niet vast op één model

Eén AI-provider is één punt van falen. Modellen worden duurder, veranderen van gedrag, of vallen weg. In juni 2026 zette een overheidsbesluit van de ene op de andere dag een commercieel topmodel wereldwijd uit. Wie daar volledig op leunde, stond stil.

Goed advies bouwt fallback in. Je systeem moet kunnen wisselen van model zonder dat alles omvalt, en gevoelig werk kun je lokaal draaien. Dat is geen technische luxe, het is bedrijfscontinuïteit. Ik schreef eerder waarom ik bewust [vendor-onafhankelijk werk](/blog/fable-5-ban-vendor-onafhankelijkheid).

### 4. De mensenkant beslist, niet de tool

Dit is het principe dat het vaakst wordt overgeslagen, en het belangrijkste. Een tool valt of staat bij de mensen die ermee gaan werken. Onderzoek van [Prosci](https://www.prosci.com/blog/why-ai-projects-fail) laat zien dat ongeveer 63% van de knelpunten bij AI-implementaties bij de mens ligt, niet bij de techniek. [BCG](https://www.bcg.com/featured-insights/the-leaders-guide-to-transforming-with-ai) komt met een vergelijkbare verhouding voor AI: de waarde zit voor ongeveer 70% in mensen en processen, en maar 10% in het algoritme. De meeste bedrijven investeren precies andersom.

Wat werkt is niet een mail van de directie dat "we nu AI doen". Wat werkt zijn champions: een paar collega's naar wie mensen toch al toelopen met vragen. Niet de hardste roepers, maar de natuurlijke verbinders. Geef ze een half uur per week om in het teamoverleg te laten zien wat ze hebben opgelost, en de adoptie volgt vanzelf. Bedrijven met zo'n actief netwerk van interne ambassadeurs halen er twee tot drie keer zoveel gebruik uit als bedrijven die het hun mensen zelf laten uitzoeken.

Voor het MKB schaalt dit gewoon mee. Je hebt geen programma voor honderden mensen nodig: in een team van twintig is één champion genoeg. En reken op herhaling en training, niet op een eenmalige uitrol. AI is geen boekhoudpakket dat je één keer installeert en dan staat.

### 5. Meet vooraf en achteraf

Goed advies belooft niets op gevoel. Voordat je iets verandert, leg je een nulmeting vast: hoeveel tijd kost dit proces nu, hoe vaak gaat het fout. Na de bouw meet je opnieuw. Het verschil is je bewijs, of je signaal dat het anders moet.

Dit is mijn achtergrond uit de financiële wereld: zonder meting heb je geen stuurinformatie, alleen een onderbuikgevoel. En een onderbuikgevoel is geen ROI. Praktisch werkt een ritme van zes tot acht weken: meten, gericht bijsturen waar het gebruik laag is, opnieuw meten. Zo blijft het systeem verbeteren in plaats van na de oplevering stil te vallen. Hoe je dat concreet doet, lees je in mijn stuk over [de ROI van AI berekenen](/blog/roi-ai-berekenen-mkb-rekensommetje).

### 6. Begin klein, met één proces

Geen grootse transformatie waarin alles tegelijk moet. Pak het ene proces dat het meeste pijn doet, bouw daar iets dat werkt, en laat het zich bewijzen. Daarna pas het volgende.

Een kleine, geslaagde eerste stap doet meer voor het draagvlak dan elk strategiedocument. Het laat zien dat het werkt, het levert de eerste meting op, en het leert je wat er in jouw bedrijf wel en niet past. Zo ziet het [automatiseren van je eerste proces](/blog/eerste-processen-automatiseren-ai) eruit.

### 7. Houd je data binnen waar het moet

Voor veel MKB-ondernemers is privacy de echte rem, niet de prijs. Terecht. Een deel van je data hoort het pand niet te verlaten, zeker niet in sectoren als zorg, finance of recht.

Goed advies neemt dit als ontwerpeis mee, niet als bijzaak achteraf. Soms betekent dat een AI-model dat lokaal draait, zodat klantgegevens binnen blijven. Soms betekent het heldere afspraken over wat wel en niet naar buiten gaat. Met de EU AI Act die eraan komt, wordt dit bovendien een formele eis. De exacte datum is nog in beweging, maar de richting is duidelijk. Ik zette de hoofdpunten op een rij in mijn [AI Act-checklist](/blog/ai-act-augustus-2026-mkb-checklist).

### 8. Governance en mens in de loop vanaf dag één

AI-systemen nemen beslissingen die je achteraf moet kunnen navertellen. Wie keurde wat goed, op basis waarvan, en wie greep in. Dat moet je vanaf het begin vastleggen, niet als je toezichthouder erom vraagt.

Concreet betekent dat een spoor van wat het systeem deed, en een menselijke laatste controle op de plekken die ertoe doen. Niet om AI af te remmen, maar om het vertrouwd genoeg te maken dat je het echt durft te gebruiken. Het saaie werk laat je los, de laatste beslissing houd je in handen.

## Hoe een AI-traject er dan uitziet

Met die principes ziet een traject er heel anders uit dan een tool-aanbeveling. Bij mij loopt het zo:

1. **Kennismaking.** Geen verkooppraatje, maar de vraag waar de tijd en de fouten zitten.
2. **Scan.** Een gerichte blik op je processen om te zien waar AI echt iets oplevert, en waar niet.
3. **Procesbeschrijving en blueprint.** We leggen het proces vast en ik ontwerp wat erbovenop komt, inclusief de meting en de menselijke controle.
4. **Bouw.** Een werkend systeem, klein beginnend, op jouw proces gebouwd.
5. **Meten.** De nameting tegen de nulmeting. Werkt het, dan breiden we uit. Werkt het niet, dan weten we waarom.

Het is waarde-gebaseerd, niet uurtje-factuurtje. Je betaalt voor een werkend resultaat, niet voor de uren die ik aan een rapport besteed.

## Waarom ik zo werk

Ik ben geen consultant die slides levert. Ik ontwerp en bouw productiesystemen, en ik laat zien hoe het werkt. Inmiddels heb ik meer dan 50 AI-systemen in productie staan, en mijn werkwijze en governance-aanpak staan open source op GitHub. Je kunt het inzien, niet alleen geloven.

Dat is het verschil tussen een AI-partner voor het Nederlandse MKB en een AI-consultant met een mooie presentatie. De een laat een rapport achter. De ander laat iets achter dat werkt en dat je kunt meten.

## Klaar om te kijken waar AI jou echt iets oplevert?

Begin niet met een tool, maar met je proces. De gratis **[AI-Readiness-Scan](/ai-kansen-scan)** brengt in dertig minuten in kaart waar AI in jouw bedrijf het meeste oplevert, en net zo belangrijk: waar het dat niet doet.

Plan een gratis kennismakingsgesprek, dan kijken we samen naar het ene proces dat je als eerste zou willen aanpakken.

large_ai-advies-mkb-wat-het-is_cover

medium_ai-advies-mkb-wat-het-is_cover

small_ai-advies-mkb-wat-het-is_cover

thumbnail_ai-advies-mkb-wat-het-is_cover

ai-advies-mkb-wat-het-is_cover

AI-advies voor het MKB: wat het wél is (en wat niet)

In June, four of my systems told me everything was fine. All four were lying.

A scan reported "completed" with zero pages behind it. A quality gate passed a test suite it should have blocked. A finished feature shipped green and then never ran once. A default engine that every config file pointed at had never actually been built. Four separate products, four green lights, one lesson underneath all of them: green does not mean working.

This is the honest June 2026 AI build log. Not the "what shipped" highlight reel. The part where the status said done, I believed it, and then I found out. If you followed the **[May build log](/blog/2026-05-31-may-build-log-metrics-launch)**, this is the same solo build with a harder edge, because June was the month I stopped trusting my own dashboards and started building the checks that catch them lying.

June 2026 build log key numbers: four products, 346 VNX commits, version 1.0.0, 34 parallel workers in one overnight run, 14,000+ receipts, and six documented cases of a green status that was lying

## The numbers

Counted from the receipt ledger and `git log` over the month. As of 30 June 2026.

| Metric | June 2026 |
|--------|-----------|
| Products I actively built | 4 |
| Commits in the VNX repo (June only) | 346 |
| VNX version reached | 1.0.0 (public tag held back on purpose) |
| Parallel AI workers in one overnight run | 34 |
| Receipts in the ledger (lifetime) | 14,000+ |
| Sales-copilot test suite | grew to ~816 green |
| Governance pieces published | 7 |
| "Green" statuses that were lying (documented) | 6 |

That last row is the whole story. Six times this month, a system reported success while it had failed or done nothing. None of them crashed. That is exactly why they were dangerous.

## Why "green" is the most expensive word in software

Every engineer reading this already knows silent failures exist. That is not the interesting part. What is rare is admitting your own systems did it to you this month, on record, and what is new is how fast the rate is climbing now that AI writes more of the code. This is not a lesson about a thing you did not know. It is a receipt for a thing everyone knows and almost nobody publishes.

A crash is honest. It pages you, it leaves a stack trace, it demands attention. The failure that costs you is the quiet one: an operation that returns a success code while producing the wrong result, or no result at all.

I am not alone in hitting this. The 2025 Stack Overflow Developer Survey found that 66% of developers say AI answers are "almost right but not quite," and 45% lose significant time debugging AI-generated code, while more of them now distrust its accuracy (46%) than trust it (33%). Adoption is up, trust is down. The gap between the two is filled with code that looks finished.

The felt sense lies too. A [randomised study from METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) put 16 experienced open-source developers on 246 tasks in codebases they knew well. With AI tools they were 19% slower, while they believed they were 20% faster. If your own perception of "faster" is off by that much, your perception of "done" is not safe either.

And the code itself drifts. GitClear's 2025 analysis of 211 million changed lines found copy-pasted code rising from 8.3% to 12.3% between 2020 and 2024, refactored lines dropping by more than half, and more code reworked within two weeks of being committed. More volume, less structure, more churn. Speed without verification is not productivity. It is debt you have not been billed for yet.

So June's real work was not shipping features. It was building the instruments that tell me when a green light is lying. Here is where each product lied, and what I built to catch it.

## VNX Orchestration: the gate that passed itself

The spine of June was collapsing a dozen ad-hoc ways of dispatching AI work into one governed entry point. One door, every task through it, every task logged. To trust a door you have to prove it cannot be walked around.

So I did not just write tests for it. I pointed an independent reviewer model at it, prompted only to break it, not to approve it. It came back red. Over two rounds it found six real ways to slip past the gate that my own tests, and two other review models, had all passed clean. Whitespace tricks, a symlink staging path, a check-then-act timing hole. Things that were green everywhere else.

I escalated the keystone change to a stronger model for a third pass, added edge-probe tests for every bypass it found, and only merged once the same adversary that had broken it twice went green on its own attacks. That is the rule I took out of June: a **[deterministic quality gate](/blog/deterministic-quality-gates)** is only real if something that did not write the code tries to break it. A test you wrote to pass is a description of what you expected, not a defence against what you missed.

The sharper moment came at the very end of the month. I caught my own orchestrator routing some of its builds around the governed lane, which meant those builds produced no **[append-only audit receipt](/blog/audit-trail-ai-agents-ndjson)**. The governance runtime was quietly skipping its own governance. I made it a hard rule: builds go through the governed path, with a receipt, or they do not happen. The audit trail has to apply to the thing that owns the audit trail, or it is theatre. That is the argument behind [prompt engineering is dead, governance engineering is next](/blog/governance-engineering-next), proven on myself.

The upside of all that hardening: VNX reached 1.0.0 in the repo this month, 346 commits deep. I am holding the public release tag back deliberately. That last step stays human.

## My SEO tool: "scan completed", zero pages

This one I found the way you should find these things. By using the product like a customer instead of reading its status field.

I logged in, ran a scan, and the dashboard said "completed." There was no data. Zero pages scanned. I went into the logs and the database and found the ugly truth: the record was marked complete while the pipeline itself had returned not-complete, and nothing had been saved. A routing bug had quietly sent the logged-in scan down a shallower path than the one it was supposed to run. The status field was reporting the intention, not the outcome.

Two things made this a perfect example of the June theme. First, every automated test was green, because the tests checked that a scan finishes, not that a scan produces the pages it claims. Second, it only surfaced because I clicked through it live. If I had trusted the "completed" badge, I would have shipped a product that confidently tells paying users it scanned their site while saving nothing.

The fix was straightforward once I could see it: make the status reflect the artifact, not the attempt. A scan is complete when the pages exist and are stored, not when the function returns. The deeper fix was a decision it forced. I used the live-testing month to move the tool away from selling one-off reports and toward recurring value, where "it actually works every time" is the entire product, not a nice-to-have.

## Sales copilot: the default engine nobody built

I am prototyping a tool that listens during a sales call and flags the questions you missed, live. In June I took it from demo to something closer to sellable, which meant letting several models tear the codebase apart and then grinding through the backlog they produced. Security, consent, retention, tamper-evident logs. My finance-industry reflexes applied to my own product.

The best lie was almost funny. The transcription engine that every config, every preset, and every doc pointed at as the default had never been compiled. Nothing in the install process built its binary. So the moment you pressed "Start Call," it reached for an engine that did not exist and crashed. The default path, the one a first-time user hits, was the one path guaranteed to fail. Green in every setting file, dead on first contact.

The fix was to build the binary as part of install, idempotently, with a graceful fallback and an actionable warning instead of a bare crash. Then I benchmarked engines properly on real call recordings and cut live transcription latency from around six seconds to roughly two.

The harder lesson was not technical. Building the paid tier, I finally admitted something I had been avoiding: you cannot enforce a paid feature in client-side, open-source code. Anyone can read it, patch it, or fork it. Pretending otherwise is its own silent failure, a moat that reports as present while being trivially absent. So I stopped pretending the code is the moat and moved the value to the things a fork genuinely cannot copy. Honest architecture beats a lock that only looks locked.

## Mission Control: the feature that shipped and never ran

Mission Control is my own operations cockpit, the layer I run the rest of the business through. In June it went from personal tool toward something a buyer could lift and run. That meant a lot of parallel AI workers building at once, up to 34 in a single overnight run, every plan and every merge passing a model review gate and then me.

Two lies stood out. The first: I built a batch of new scoring jobs. They existed, their tests passed, the code was correct. And they were never wired into the scheduler. A finished, tested, "done" feature that would have sat there silently doing nothing forever, because nothing ever called it. Correct and useless are not opposites. A dedicated cleanup pass caught the orphans and registered them.

The second was worse, and a review panel caught it, not me. A budget check that was supposed to stop runaway work failed open. If the service it queried had an outage, the check quietly returned "you are fine, proceed," authorising unlimited work during exactly the moment you least want that. A safety limit that disables itself when its dependency hiccups is not a limit. Same panel flagged a timing-unsafe secret comparison and a handful of writes that could fail silently and still report success. All of it green, all of it wrong, all of it fixed to fail closed instead.

That is the pattern across all four products. The failures that hurt do not announce themselves. You have to go looking, and the most reliable way to look is to have something adversarial look for you.

## What I learned

None of these are new as principles. What was new this month was paying for them four times in four products, and building the checks that make the principle operational instead of a poster on the wall.

**Green is a claim, not a fact.** Every "completed," every 200, every passing suite is a hypothesis about the world. Treat it as one. Check the artifact, not the status field. The scan is done when the pages exist, not when the function returns.

**A gate is only real if an adversary tries to break it.** A single reviewer, human or model, tests what they thought of. Point something that did not write the code at it, prompted to break it, and it finds the six bypasses everyone else waved through. This is the same reason my audience keeps posting about not trusting evals nobody stress-tests.

**The dangerous failures are silent.** A crash pages you. A false success ships. Spend your instrumentation budget on detecting silence: the job that never ran, the limit that disabled itself, the success that saved nothing.

**Speed without verification is debt.** The METR result is the whole industry in one number. You feel faster and you are slower, because the time moved downstream into debugging what looked done. The gate is not what slows you down. The gate is what makes the speed real.

And the meta-lesson, from catching my own orchestrator skipping its own audit trail: the governance has to apply to the thing that owns the governance, or it is decoration. That is the whole argument for treating governance as an engineering discipline, and this month I got to prove it against myself.

## The public side of June

Underneath the four bugs, I published the through-line all month: one argument in seven pieces. Do not depend on one model, which is what **[the Fable 5 ban taught me about vendor-independence](/blog/fable-5-ban-vendor-onafhankelijkheid)**. Own a floor no order can switch off, which is why I **[benchmarked eight models on my own hardware](/blog/lokale-llm-benchmark-mkb)**. Keep the records, because the **[EU AI Act will soon expect them](/blog/ai-act-augustus-2026-mkb-checklist)**. And measure quality as a number instead of a feeling, with **[first-pass yield](/blog/first-pass-yield-ai-kwaliteit)**. Same thesis as this log, seen from the other side.

## What is next

Three things for July, in order:

- Keep the human merge gate exactly where it is. Everything above was caught by adversarial checks plus a human at the end. I am not automating that last step away.
- Ship VNX 1.0 publicly. The code is frozen at 1.0.0. The public tag is the one gate left, and it stays mine to pull.
- Turn the June governance work into a concrete offer for organisations facing the same problem: not more AI, but proof that the AI did what it said. That is the **[AI architecture](/ai-architectuur)** I build.

Four products, one lesson. Solo build, public feedback loop. See you in the July build log.

Frequently asked questions

## Sources

- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," 10 July 2025: [metr.org](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) (arXiv 2507.09089)
- Stack Overflow, 2025 Developer Survey, AI section: [survey.stackoverflow.co/2025](https://survey.stackoverflow.co/2025)
- GitClear, "AI Copilot Code Quality 2025" (211M lines analysed): [gitclear.com](https://www.gitclear.com/ai_assistant_code_quality_2025_research)
- VNX Orchestration, open source: [github.com/Vinix24/vnx-orchestration](https://github.com/Vinix24/vnx-orchestration). Commit counts and receipts are reproducible from the repo and the ledger.

large_june-build-log_cover

medium_june-build-log_cover

small_june-build-log_cover

thumbnail_june-build-log_cover

june-build-log_cover

June Build Log: The Month My Systems Lied to Me

Prompt engineering is dead. Context engineering is dying. Governance engineering is next. The skill I spent two years sharpening just lost most of its value, and the reason is good news wearing a bad disguise: the models got better at the one thing prompt engineering was compensating for.

Prompt engineering was valuable because models followed instructions badly. You paid for the guesswork: tone, framing, few-shot tricks to force behavior the model would not produce on its own. That guesswork is what governance engineering replaces, and it is now the scarce skill worth building a practice around.

## The skill that just lost its value

When a model ignored half your instruction, the person who could coax the right behavior out of it was worth a lot. That was the premium on prompt engineering. It was a premium on unreliability.

Frontier models follow instructions tightly now. "Edit only this file" means only that file. "Return JSON" returns JSON. The gap between what you asked and what you got has narrowed to the point where the clever phrasing barely moves the result.

So the premium moves. The scarce skill is no longer finding the words. It is designing the system in which tight instruction-following is safe and repeatable. That system is governance engineering.

## Tight instruction-following is a mirror test

Tight adherence is not a victory. It is a mirror.

The model now does exactly what you specify and nothing more. No bonus modifications, no creative interpretation. Also no implicit quality, no unrequested tests, no quiet self-correction. The model used to paper over weak governance by thinking along with you. That mask is gone.

What you do not specify no longer happens on its own.

That shifts the entire burden onto the architect. Your governance system is now the only place discipline can live. If the rules are not in the architecture, they are not anywhere, because the model will not improvise them for you anymore.

## What governance engineering actually is

Governance engineering is a [stack, not a mindset](/ai-architectuur). It has layers, and each layer answers a concrete question about an agent: what it may do, what it did, whether it is sound, how much trust it has earned, and how it stays sharp over time.

A vertical five-layer stack: instruction scope, receipts, quality gates, scoring, and context rotation, connected by arrows in navy and orange

1. **Instruction scope.** Define exactly what an agent may touch and do. Rules in config set the playing field, and scope is the boundary inside which tight adherence is safe. Without scope, the model follows your instruction perfectly, possibly off a cliff.

2. **Receipts.** Every agent action writes a structured record to an append-only ledger: which agent, which commit, how long, what it cost, which model. Not chat logs that expire, a ledger that reconstructs the full history. What you do not record you cannot audit.

3. **Quality gates.** Between "propose" and "execute," and between "claims done" and "is done." A task closes only when the evidence is there and the checks are clear. The agent's self-assessment is an input, not a verdict.

4. **Scoring.** Measure whether an agent has earned more autonomy. Risk scores per dispatch, trust that accrues over time, anomaly flags that send me to the dispatches that matter. Trust is earned with data, not assumed.

5. **Context rotation.** Long-running agents suffer context rot as their window fills. Rotation keeps them sharp by cycling context deliberately instead of letting it grow without bound, and the governance layer makes that decay visible.

The point is the chain. Scope decides what is allowed, receipts record what happened, gates check that it is sound, scoring decides how much freedom follows, rotation keeps the system healthy across thousands of dispatches. The prompt became an input. The architecture is the control surface.

## Soft law versus hard law

This is the hinge of the whole shift, and it is where most teams get governance wrong. There are two kinds of rules.

Soft law is rules in a config. A CLAUDE.md file, a rules directory, instructions a model reads and usually follows. It is policy. It works as long as the model cooperates, and with tight instruction-following, soft law is more reliable than it has ever been.

Hard law is hooks that enforce. A pre-write hook that physically stops the orchestrator from touching disk. A gate that will not close without evidence. Code, not a request.

The lesson took me a while. Soft law scales trust, hard law guarantees it. A rule you genuinely cannot allow the model to ignore must be a hook, not a sentence in a markdown file. In my own runtime the top orchestrator cannot write files directly, and that is enforced through hooks, not requested through instruction. The difference between those two is the difference between a policy and a guarantee, and I lean on [deterministic quality gates](/blog/deterministic-quality-gates) for exactly the rules that must not be negotiable.

## Provider independence is a governance requirement

Vendor independence is not a separate hobby. It is a governance requirement, and June made that concrete.

A governance system tied to a single provider has a single point of failure that sits outside your control. A government, a provider, or a policy change can switch off a model, and if your operation hangs on that model, your operation stops. That is not a hypothetical. On 12 June the US government forced Anthropic to disable Fable 5 and Mythos 5 worldwide, overnight, by order. I wrote about [what the Fable 5 ban means for vendor-independence](/blog/fable-5-ban-vendor-onafhankelijkheid) separately, but the governance angle is the one that matters here.

The way I design around it is plain. Workers are ordinary CLI subprocesses. There is no vendor SDK in the codebase. Receipts are provider-aware, so the ledger knows which model did what. Swapping a model is swapping a subprocess command, and the governance layer does not change. Deciding which provider runs through which lane is itself a governance decision, made explicitly, instead of trusting a default you never chose.

## Governance is not overhead

The common objection is that all of this is overhead, that governance is a tax on shipping. The numbers say otherwise.

Restructuring how dispatches are constructed cut token usage by 87% while making the system more auditable, not less. The governance architecture made the work measurably cheaper to run, not just safer. That is the part the "governance equals compliance theater" crowd misses. Done as engineering, governance pays for itself.

This is the same conviction behind everything in my [glass box governance](/blog/glass-box-governance-multi-agent-ai) work: a system you can see into is a system you can both trust and optimize.

## Where the scarce skill is heading

Prompts are becoming a commodity. Governance systems are becoming the differentiator.

Whoever owns the governance data owns the intelligence. Receipts are not just an audit trail, they are the record of what worked, which makes them the raw material for the next improvement. The architect who designs the stack wins over the prompter who hunts for the perfect sentence.

Tight instruction-following handed us a mirror. What it reflects is the quality of your architecture, because the model will no longer cover for its absence. Build the stack. The sentence was never the job.

Blog over AI-systemen, agents en governance