AI op uw eigen server — wanneer een klein taalmodel genoeg is voor het MKB

Een accountantskantoor in het oosten van het land zet een AI-zoekfunctie aan op de eigen kennisbank: contractbijlagen, jaarstukken, klantmemo’s. Het werkt goed, klanten vragen ernaar, het scheelt uren per week. Dan komt de jaarlijkse AVG-toets — en de adviseur stelt de vraag die niemand had gesteld: waar staan de stukken die het model doorzoekt eigenlijk op het moment dat het model ze leest?

Antwoord: in een Amerikaans datacenter, want de API draait via een grote cloudaanbieder. Niemand wilde dat zo. Het is gewoon zo gegroeid — een proef-opzet die nooit is heroverwogen toen het in productie ging. En nu, met de AI Act in gefaseerde uitrol en de toezichthouder met scherpere oren, zit er een vraag op tafel die niet meer weggaat: kan dit ook op onze eigen server?

In veel gevallen kan dat. De kleine taalmodellen zijn een serieus alternatief geworden — niet voor alles, wel voor genoeg.

Wat “kleine taalmodellen” eigenlijk zijn

Een small language model (SLM) is een taalmodel dat klein genoeg is om op redelijke hardware te draaien — typisch tussen de 3 en 32 miljard parameters, vaak in een gekwantiseerde vorm zodat het binnen het geheugen van één machine past. De namen die er in mei 2026 toe doen voor het MKB:

• Phi-4 van Microsoft, ontworpen om bij een kleine omvang redelijk te redeneren.
• Llama 3.2 en 3.3 van Meta, in 1B-, 3B-, 8B- en 70B-varianten — de kleinere lopen op een laptop, de grotere op één servergraad-GPU.
• Gemma 2 van Google, beschikbaar als 2B, 9B en 27B.
• Mistral Small (de Franse aanbieder), in de 22B/24B-klasse — bewust gepositioneerd voor on-prem en edge.

Deze modellen draait u via een lokale inferentie-stack: Ollama en LM Studio voor bedieningsgemak, llama.cpp of vLLM voor productie-throughput. De grenslijn ligt niet bij “kan het technisch lokaal”, maar bij “is het capabel genoeg voor uw taak”. En daar is het antwoord voor veel afgebakende MKB-toepassingen ja geworden.

Waarom dit nu trending is

Drie ontwikkelingen vallen samen.

• Modellen zijn klein én capabel geworden. Phi-4 en Llama 3 in de 8B-klasse halen op afgebakende taken — samenvatten, classificeren, vraag-antwoord boven een eigen kennisbank — een niveau waar in 2024 alleen frontier-modellen kwamen. Microsoft, Meta en Google publiceren de gewichten openlijk; voor verifieerbaarheid en lock-in-risico is dat een wezenlijk verschil met een gesloten API.
• De hardware-grens is gezakt. Een moderne Apple Silicon-Mac, een werkstation met een consument-GPU of een kleine server met één professionele GPU is voor een 7B-tot-13B-model afdoende. Geen rack vol AI-hardware nodig.
• AVG, AI Act en data-soevereiniteit drukken harder. Met de gefaseerde inwerkingtreding van de AI Act en aanhoudende discussie rond doorgifte van persoonsgegevens buiten de EU, krijgt “waar staat de data op het moment dat het model die ziet” gewicht. De Autoriteit Persoonsgegevens publiceert hier herhaaldelijk over.

Tegelijk speelt iets prozaïschers mee: API-rekeningen zijn moeilijk te voorspellen. Een lokaal model heeft kapitaaluitgave vooraf en stille operationele kosten — geen tellertje dat met elk gesprek doortikt.

Wat het niet is

Een paar veelvoorkomende misverstanden:

• Het is geen vervanging van frontier-modellen. Voor lange contexten, complexe redenering of hoogwaardige meertaligheid blijven de grote cloudmodellen voorlopig vooraan. Een SLM is een specialistisch gereedschap, geen universele opvolger.
• Het is geen vrijbrief voor minder AVG-werk. Lokaal draaien lost doorgifte op, maar niet doelbinding, niet bewaartermijnen, niet het register van verwerkingen, en niet de inzage- en wisbaarheid die u betrokkenen verschuldigd bent.
• Het is geen “set & forget”. Modellen worden bijgewerkt, beveiligingspatches komen langs, prompt-aanpassingen verschuiven gedrag. Net als bij een cloud-agent (zie ook ons artikel over observability en evals) hoort een lokaal model in een onderhouds- en monitoringritme.
• Het is geen excuus voor zwakke security. Een server in uw eigen pand verdient dezelfde rechten-, logging- en update-discipline als elk ander systeem in uw infrastructuur — sterker zelfs, omdat hij gevoeliger data zal zien.
• Het is geen “groter is altijd beter”. Voor veel afgebakende taken werkt een 7B-model op een goede stack beter dan een 70B-model dat te traag draait om gebruikt te worden.

Drie signalen dat dit voor u relevant is

In gesprekken met MKB-directies komen drie signalen telkens terug:

1. U verwerkt structureel persoonsgegevens of geheimhoudingsplichtige stukken. Zorgdossiers, klantfinanciën, juridische stukken, HR-data. Elke keer dat zo’n stuk een externe API in gaat, ontstaat een vraag waarop u een goed antwoord moet hebben.
2. De AI-rekening is moeilijk te voorspellen. Het maandbedrag schommelt, een nieuwe feature laat hem onverklaarbaar omhoog springen, en niemand weet precies welke prompt of welke gebruiker de uitschieter veroorzaakte.
3. Uw inkoper of DPO heeft vragen die u nu niet kunt beantwoorden. Waar staan de gegevens? Onder welke wetgeving? Wie kan erbij? Zonder rechte lijnen daarop wordt elk nieuw AI-experiment moeilijker uit te leggen dan het vorige.

Komt één van de drie u bekend voor, dan zit u op het punt waarop dit een echte ontwerpvraag wordt.

Wat dit voor het MKB praktisch betekent

U hoeft geen eigen AI-lab te runnen om dit goed in te richten. Een werkbaar startpunt ziet er meestal zo uit:

• Een taakafbakening op papier. Één concrete taak (samenvatten, classificeren, vraag-antwoord boven kennisbank), met een verwachting van kwaliteit en doorlooptijd — voordat er een model is ingekocht.
• Een bewuste modelkeuze. Phi-4, Llama, Gemma of Mistral Small — afgewogen op grootte, taalondersteuning (Nederlands telt mee), licentie en geschiktheid voor uw taak.
• Een passende kwantisatie. 4-bit voor maximale snelheid op bescheiden hardware, 8-bit voor een betere kwaliteit-prestatie-verhouding, FP16 alleen als de hardware het rechtvaardigt.
• Een inferentie-stack op de juiste laag. Ollama of LM Studio voor pilots, vLLM of llama.cpp voor productie-doorzet. Één keuze, gemotiveerd vastgelegd.
• Een combinatie met RAG en, waar nodig, cloud-burst. De lokale stack doet het dagelijkse werk; voor de moeilijke gevallen mag — als beleid het toelaat — een gecontroleerde call naar een frontier-model in een Europese cloud uitkomst bieden.
• Een eigenaar, een logboek, een monitoringritme. Dezelfde discipline als bij een cloud-agent, net wat anders gevuld.

Wij hebben de essentiële vragen samengevat in een korte checklist: “AI op uw eigen server — voor MKB-directies en IT-managers”. Één A4’tje, geen verkooppraatje. Wilt u er na het invullen over doorpraten, dan plannen we een uur. Geen verkopers-script — een gesprek tussen ondernemer en ontwikkelaar.

Voor wie is dit niet?

Eerlijk afgebakend: dit artikel is niet voor u als uw AI-taak echt frontier-werk vereist — juridische argumentatie over honderden pagina’s, complexe meertalige redenering, zware code-generatie. Daar wint de grote cloud voorlopig. Het is ook niet voor u als u nog geen AI-toepassing in productie heeft; experimenteer eerst in een gecontroleerde cloud-omgeving en haal het later naar binnen. En het is niet voor u als data-soevereiniteit voor uw werk geen rol speelt — dan zijn de lasten van eigen beheer de moeite niet waard. Maar zit u in de zorg, in finance, in juridisch werk of in HR-software, en heeft u op zijn minst één AI-toepassing waarvan u zich afvraagt of die op de juiste plek draait: dan is dit precies het gesprek dat u nu wilt voorbereiden.

Één A4’tje, geen formulierenrace.