Een taalmodel is van zichzelf al capabel. Het heeft tijdens zijn training miljarden teksten verwerkt en heeft daarmee een breed begrip opgebouwd van taal, redeneren en kennis. Maar soms lijkt dat niet genoeg. Het model kent jouw branche niet goed genoeg, gebruikt de verkeerde toon, of maakt fouten op een specifiek type taak. Dan ontstaat de vraag: moet ik dit model trainen op mijn eigen data?

Het antwoord is vaker nee dan ja. Maar om te begrijpen waarom, is het nuttig om het verschil te kennen tussen de twee belangrijkste manieren om een model te sturen: fine-tuning en prompt engineering.

Wat is fine-tuning?

Fine-tuning betekent dat je een bestaand model verder traint op een eigen dataset. Je geeft het model voorbeelden van input en gewenste output, en het past zijn interne parameters aan op basis daarvan. Het resultaat is een model dat beter presteert op die specifieke taak of in die specifieke stijl, zonder dat je bij elke aanroep uitgebreide instructies mee hoeft te sturen.

Dat klinkt aantrekkelijk, maar er zitten haken en ogen aan. Fine-tuning kost geld, tijd en goede trainingsdata. Die data moet representatief zijn, consistent van kwaliteit en groot genoeg om het model daadwerkelijk iets bij te brengen. Een handvol voorbeelden is niet voldoende. Daarnaast is een gefinetuned model een momentopname: zodra je werkwijze verandert of je wilt iets aanpassen, moet je opnieuw trainen.

Wanneer is fine-tuning zinvol?

Er zijn situaties waarin fine-tuning de moeite waard is. De belangrijkste is wanneer je een specifieke stijl of format structureel nodig hebt die moeilijk via een prompt af te dwingen is. Denk aan een model dat altijd output genereert in een bepaald gegevensformaat, of dat consequent de huisstijl en terminologie van een organisatie hanteert zonder uitgebreide instructies.

Fine-tuning is ook zinvol als je werkt met een kleiner, goedkoper model dat je wilt opwaarderen voor een afgebakende taak. Een klein model dat gefinetuned is op ticketclassificatie kan daarvoor beter presteren dan een groot generalistisch model, tegen een fractie van de kosten per aanroep.

Wanneer volstaat prompt engineering?

Voor de meeste toepassingen die MSP’s bouwen of inzetten, is prompt engineering de betere keuze. Het is sneller aan te passen, goedkoper om mee te experimenteren en werkt over modelversies heen zonder dat je opnieuw hoeft te trainen. Als het model de taak begrijpt maar de output niet de juiste vorm heeft, is de instructie vrijwel altijd de snellere oplossing.

Zoals in de vorige aflevering besproken, geldt hetzelfde voor situaties waarbij het model werkt met veranderende informatie. Fine-tuning bakt kennis in op een bepaald moment. RAG levert actuele informatie aan bij elke aanroep. Voor klantspecifieke of regelmatig bijgewerkte informatie is RAG structureel flexibeler.

Fine-tuning bij klanten

Als klanten vragen om een AI-oplossing die ‘onze manier van werken’ leert, is fine-tuning vaak het eerste wat ze in gedachten hebben. Het is zaak die verwachting te managen. Fine-tuning leert een model patronen uit voorbeelden, maar het vervangt geen actuele kennisbank en garandeert geen foutloze output. Een klant die denkt dat een gefinetuned model zijn interne processen volledig beheerst, heeft een verkeerd beeld van wat de technologie doet.

De realistische inzet van fine-tuning bij klanten is beperkt maar concreet: het aanpassen van toon en stijl aan de huisstijl van de organisatie, het trainen op specifieke outputformaten, of het verbeteren van prestaties op een nauw omschreven taak waarvoor voldoende trainingsdata beschikbaar is.

De volgende aflevering gaat over een keuze die voor MSP’s steeds relevanter wordt: lokaal draaien of in de cloud, en wat dat betekent voor privacy, kosten en afhankelijkheid.

Staatssecretaris Willemijn Aerdts van Economische Zaken en Klimaat heeft de voorgenomen overname van Solvinity door het Amerikaanse Kyndryl definitief verboden. Het besluit, formeel genomen op 25 mei 2026, volgt op een dwingend advies van het Bureau Toetsing Investeringen (BTI). Dat bureau concludeerde dat de deal een risico vormt voor het publieke belang.

Solvinity is de Nederlandse IT-dienstverlener die de infrastructuur beheert waarop DigiD en MijnOverheid draaien. Via die systemen wisselen miljoenen Nederlanders gegevens uit met de Belastingdienst, zorgverzekeraars en pensioenfondsen. Kyndryl, de voormalige IT-infrastructuurdivisie van IBM die in 2021 zelfstandig werd, meldde de overnameplannen op 21 november 2025. Daarmee werd meteen een politiek gevoelige kwestie aangesneden: Amerikaanse wetgeving biedt de Amerikaanse overheid mogelijkheden om in bepaalde gevallen toegang te eisen tot data van bedrijven die onder haar jurisdictie vallen.

BTI concludeerde risico voor publieke belang

Het BTI voerde een onderzoek uit op basis van de Wet ongewenste zeggenschap telecommunicatie (WOZT). Die wet is het wettelijk kader voor investeringstoetsing binnen de digitale infrastructuur. Normaal gesproken werkt het BTI in stilte, maar de WOZT schrijft voor dat een volledig verbod openbaar moet worden gemaakt.

Aerdts benadrukte in haar Kamerbrief dat de toets landenneutraal, risico-gebaseerd en proportioneel was. “Nederland hecht grote waarde aan de aanwezigheid van buitenlandse, waaronder nadrukkelijk ook Amerikaanse technologiebedrijven en hun bijdrage aan de Nederlandse economie en digitale infrastructuur,” schreef ze. De exacte inhoud van het BTI-advies blijft vanwege staatsveiligheid en bedrijfsgevoeligheid geheim. Het kabinet heeft de Tweede Kamer een vertrouwelijke technische briefing aangeboden.

Dat Aerdts snel handelde, had een reden: ze had serieuze indicaties ontvangen dat de voltooiing van de transactie op korte termijn aanstaande was.

Politieke druk al langer aanwezig

De Tweede Kamer had zich al vroeg in het proces uitgesproken. Een brede meerderheid verzette zich tegen de overname. Eerder werd een motie aangenomen die het kabinet opriep het DigiD-hostingcontract in 2028 niet te verlengen als de overname toch doorging. Alleen JA21 stemde destijds tegen.

Begin mei wees een kortgedingrechter nog een eis af om het contract met Solvinity per direct te beëindigen. De rechter oordeelde dat een verantwoorde overgang zes tot acht maanden vergt, en dat directe stopzetting onaanvaardbare risico’s met zich meebrengt voor essentiële overheidsdiensten. Desondanks verlengde staatssecretaris Eric van der Burg (Binnenlandse Zaken) het contract met Solvinity nog met twee jaar, om de continuïteit en veiligheid van de DigiD-dienstverlening te waarborgen.

Het verbod zet een streep door een deal die naar schatting minimaal 100 miljoen euro waard was. Ook een alternatief bod vanuit een Nederlandse partij viste net achter het net.

Kyndryl spreekt van politisering

Kyndryl reageert teleurgesteld. “Wij zijn uiterst teleurgesteld over het besluit van de Nederlandse regering om de overname van Solvinity door Kyndryl te verbieden,” aldus het bedrijf in een officiële verklaring. “Ondanks deze samenwerking en onze lange geschiedenis van het beheren van bedrijfskritische activiteiten in Nederland, heeft de politisering van dit proces de duidelijke en belangrijke voordelen die deze transactie had kunnen bieden aan de klanten van Solvinity en Nederlandse burgers overschaduwd.”

Kyndryl benadrukt desondanks actief te blijven in Nederland. Het bedrijf wil zijn klanten blijven ondersteunen bij het moderniseren van legacy-systemen en het inzetten van zogeheten Agentic AI-technieken voor zowel gereguleerde als niet-gereguleerde klanten.

Solvinity blijft in dialoog

Solvinity zelf reageert zakelijk. Het bedrijf laat weten zich onverminderd te richten op het leveren van veilige, betrouwbare en hoogwaardige IT-dienstverlening aan haar klanten. Solvinity geeft aan in dialoog te blijven met de betrokken autoriteiten over de gemaakte afwegingen op het gebied van nationale veiligheid, digitale autonomie en bescherming van de Nederlandse vitale infrastructuur.

Het kabinet laat weten de komende periode in contact te blijven met Solvinity en de huidige, Britse eigenaar over de toekomst van het bedrijf.

Een taalmodel weet veel, maar niet alles. Het is getraind op een grote hoeveelheid tekst van het internet, boeken en andere bronnen, tot een bepaald moment in de tijd. Wat daarna is gebeurd, kent het niet. En wat intern bij jouw organisatie of bij je klant leeft, heeft het nooit gezien. Jouw runbooks, je escalatieprocedures, je klantspecifieke afspraken: dat zit niet in het model.

Maar daar is een oplossing voor: Retrieval-Augmented Generation, afgekort RAG. De naam klinkt technischer dan het concept is.

Hoe RAG werkt

Het basisidee is eenvoudig. In plaats van het model te vragen iets uit zijn eigen training te halen, geef je het de relevante informatie mee op het moment dat je een vraag stelt. Je bouwt een systeem dat eerst zoekt in een kennisbank, de meest relevante fragmenten ophaalt en die meestuurt in de prompt. Het model gebruikt die fragmenten als context voor zijn antwoord.

Stel dat een helpdeskmedewerker een vraag stelt over een specifieke klantconfiguratie. Het RAG-systeem zoekt in de interne documentatie naar relevante passages over die klant of dat type configuratie, voegt die toe aan de vraag en stuurt het geheel naar het model. Het model genereert een antwoord op basis van zowel zijn algemene kennis als de specifieke informatie die is meegegeven.

Het model wordt hierdoor niet slimmer, het krijgt gewoon betere informatie aangeleverd. Het verschil zit in de input, niet in het model zelf.

Wat kun je ermee?

Ten eerste intern: het ontsluiten van je eigen kennis. MSP’s beheren doorgaans veel informatie die verspreid zit over ticketsystemen, wiki’s en gedeelde schijven. Netwerktopologieën, afspraken over responstijden, escalatiepaden. Een taalmodel zonder toegang tot die informatie kan er niets mee doen. Met RAG maak je die kennisbank doorzoekbaar en koppel je hem aan het model, zodat medewerkers sneller het juiste antwoord vinden zonder elk document zelf te hoeven doorzoeken.

Ten tweede extern: RAG als propositie richting klanten. Een advocatenkantoor dat zijn contractenarchief doorzoekbaar wil maken, een zorginstelling die medewerkers snel toegang wil geven tot protocollen en richtlijnen, een productiebedrijf dat technische documentatie wil ontsluiten. In al die gevallen bouw jij als MSP het systeem, maar is de kennisbank van de klant. Dat maakt RAG tot een concrete dienst die je kunt aanbieden, niet alleen een techniek die je intern gebruikt.

Wat je nodig hebt

Een RAG-systeem bestaat uit drie onderdelen. Ten eerste een kennisbank: de documenten, procedures of data die je wilt ontsluiten. Ten tweede een zoeklaag die relevante fragmenten kan ophalen op basis van een vraag. De meest gangbare aanpak gebruikt vectoropslag, een manier om tekst om te zetten in wiskundige representaties waarmee je op betekenis kunt zoeken in plaats van op exacte trefwoorden. Ten derde het taalmodel zelf, dat de opgehaalde fragmenten verwerkt en een antwoord formuleert.

Voor MSP’s die zelf geen softwareontwikkelaars in dienst hebben, zijn er kant-en-klare platforms die dit soort architectuur aanbieden zonder dat je alles zelf hoeft te bouwen. De kostenstructuur is wel iets om goed te doorgronden, want die bestaat uit meerdere lagen.

Het bouwen en integreren van het systeem is grotendeels eenmalig werk: de koppeling met de kennisbank, de zoeklaag inrichten, de verbinding met het model leggen. Dat is projectwerk, of je het nu zelf uitvoert of uitbesteedt aan een partner.

De vectordatabase, waar de geïndexeerde documenten in worden opgeslagen, kent doorgaans een abonnementsmodel op basis van de hoeveelheid opgeslagen data en het aantal zoekopdrachten per maand. Bij een bescheiden kennisbank en beperkt gebruik stelt dat weinig voor, maar bij grote documentcollecties of intensieve inzet is het een serieuze kostenpost.

Het omzetten van documenten naar vectoren, het zogeheten embedden, kost ook tokens. Dat gebeurt eenmalig bij het inladen van de kennisbank, maar ook steeds opnieuw als documenten worden bijgewerkt of toegevoegd. En het taalmodel zelf blijft gewoon per token betaald bij elke zoekopdracht die een gebruiker stelt.

Voor klanten betekent dit dat een RAG-oplossing niet alleen een bouwbudget vraagt, maar ook een doorlopende exploitatiekost kent. Die is bij bescheiden gebruik goed te overzien, maar vraagt wel om een bewuste afweging voordat je tekent.

Wat RAG niet oplost

RAG is zo goed als de kennisbank die eraan ten grondslag ligt. Als de documentatie verouderd is, onvolledig of inconsistent, reflecteert het model dat in zijn antwoorden. Garbage in, garbage out geldt hier onverminderd.

Dat geldt zowel voor je eigen documentatie als voor die van klanten. De invoering van een RAG-systeem leidt dan ook vrijwel altijd tot een gesprek over de kwaliteit van de onderliggende informatie. Bij klanten is dat gesprek soms ongemakkelijk, maar wel waardevol. Een RAG-systeem dat werkt op slechte documentatie geeft zelfverzekerd verkeerde antwoorden, en dat is lastiger te corrigeren dan een medewerker die zegt dat hij het niet weet.

De volgende aflevering gaat over fine-tuning: wanneer heeft het zin om een model aan te passen op jouw situatie, en wanneer is het een kostbare omweg?

Je hebt een goed model gekozen, je weet wat tokens kosten en je begrijpt hoe het contextvenster werkt. Dan stuur je je eerste vraag in en het antwoord stelt teleur. Vaag, te algemeen, of gewoon niet wat je zocht. Het model is niet het probleem. De vraag is het probleem.

Hoe je iets vraagt aan een taalmodel maakt meer uit dan de meeste mensen verwachten. Taalmodellen vullen geen ontbrekende context aan vanuit aannames. Ze raden niet wat je eigenlijk bedoelt. Ze verwerken wat er staat, en produceren daar een antwoord op dat zo goed mogelijk aansluit bij de patronen in hun training. Dat lijkt een beperking, maar het is ook een hefboom. Want als je begrijpt hoe die verwerking werkt, kun je je instructies zo formuleren dat de output structureel beter wordt: prompt engineering.

Context is key

De meest voorkomende fout is te weinig context meegeven. Een vraag als “schrijf een samenvatting van dit document” levert een ander resultaat op dan “schrijf een samenvatting van dit document in drie alinea’s, gericht op een directeur die beslissingen neemt over IT-budgetten en geen technische achtergrond heeft.”

Beide vragen zijn valide. De tweede levert bijna altijd bruikbaardere output op, omdat het model weet wat het doel is, wie de lezer is en welke vorm verwacht wordt. Die drie elementen, doel, doelgroep en gewenste vorm, zijn de basisingrediënten van een goede instructie.

Een handige structuur is de combinatie van rol, taak en format. Je geeft het model een rol (“je bent een ervaren helpdeskmedewerker”), beschrijft de taak (“verwerk het volgende ticket en stel een antwoord op voor de klant”) en specificeert het format (“gebruik een begroeting, maximaal drie alinea’s en een concrete vervolgstap”). Voor eenvoudige taken volstaat een heldere taakomschrijving. Maar zodra je prompts inbouwt in geautomatiseerde processen, loont het om dit bewust te doen.

Voor MSP’s die oplossingen bouwen

Als je een AI-tool bouwt voor klanten, wordt prompt engineering een ander vak. Je schrijft dan geen losse vragen, maar systeemprompts: vaste instructies die bij elke aanroep worden meegestuurd en bepalen hoe het model zich gedraagt. Die systeemprompt is de ruggengraat van je toepassing. Hij definieert de rol van het model, de grenzen van wat het doet, de toon die het aanhoudt en het format van de output.

Lange systeemprompts van tientallen of zelfs honderden regels zijn op internet volop te vinden. Soms zijn ze zinvol: een complexe toepassing met veel randgevallen vraagt om gedetailleerde instructies. Maar kopiëren zonder begrip werkt zelden goed. Een prompt die voor het ene model is geschreven, presteert anders op een ander model. Instructies die zijn bedoeld voor een specifieke context passen niet automatisch op jouw situatie. De vuistregel is: begin compact, test wat het oplevert en breid alleen uit waar de output tekortschiet.

Een goed opgebouwde systeemprompt die honderd keer per dag wordt uitgevoerd, levert structureel betere resultaten op dan een vage instructie die toevallig soms goed uitpakt. Behandel je prompts daarom als code: versiebeheer, documenteer wat je hebt gewijzigd en waarom, en deel effectieve instructies binnen je team.

Wat je niet moet vragen

Even belangrijk als wat je vraagt, is wat je niet vraagt. Een puur taalmodel is niet geschikt voor taken waarbij een exacte, verifieerbare uitkomst vereist is, zoals het bevestigen van recente feiten of het ophalen van actuele prijzen. Het genereert plausibele tekst, geen gecontroleerde waarheid. Moderne AI-tools lossen dat deels op door een zoekfunctie in te bouwen die externe bronnen raadpleegt, maar ook dan blijft de kwaliteit van je instructie bepalend voor wat je terugkrijgt.

Verder lezen

Prompt engineering is een vaardigheid die je opbouwt door te proberen, te vergelijken en bij te stellen. Wie zich hier verder in wil verdiepen, vindt goede uitgangspunten bij de officiële gidsen van Anthropic (docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) en OpenAI (platform.openai.com/docs/guides/prompt-engineering), en op PromptingGuide.ai, een onafhankelijke bron met technieken voor meerdere modellen.

De volgende aflevering gaat over RAG: hoe je een taalmodel koppelt aan je eigen kennisbank, zodat het werkt met jouw documentatie, jouw klantdata en jouw processen.

De markt voor taalmodellen groeit snel. Er zijn modellen van grote techbedrijven, modellen van gespecialiseerde AI-labs en open modellen die je zelf kunt draaien. Ze dragen namen die weinig zeggen, worden regelmatig opgevolgd door nieuwe versies en worden in marketingmateriaal vrijwel altijd als de beste optie gepresenteerd. Voor een MSP die klanten adviseert of AI wil inbouwen in dienstverlening, is dat verwarrend. Toch veranderen de vragen die je moet stellen nauwelijks, ongeacht welk model er op dat moment bovenaan staat.

De eerste stap is loslaten dat er één beste model bestaat. Taalmodellen zijn geoptimaliseerd voor verschillende doelen. Sommige zijn groot en krachtig, geschikt voor complexe redeneerprocessen en genuanceerde tekst. Andere zijn kleiner, sneller en goedkoper, en presteren uitstekend op afgebakende, herhaalbare taken. De keuze hangt af van wat je wilt doen, hoe vaak je het doet en wat het mag kosten.

In de praktijk onderscheid je grofweg drie categorieën. Grote, krachtige modellen zijn geschikt voor taken waarbij redeneren, nuance en kwaliteit vooropstaan. Denk aan het analyseren van contracten, het opstellen van rapportages of het beantwoorden van complexe klantvragen. Middelgrote modellen bieden een goede balans tussen kwaliteit en snelheid, en zijn geschikt voor de meeste dagelijkse toepassingen. Kleine, snelle modellen zijn geoptimaliseerd voor volume en lage latency, en passen bij toepassingen waarbij je veel verzoeken verwerkt en elke milliseconde telt.

De afweging die telt

Bij het kiezen van een model spelen vier factoren een rol. Kwaliteit is de meest voor de hand liggende: hoe goed presteert het model op jouw specifieke taak? Dat is niet altijd hetzelfde als de algemene benchmarkscore die fabrikanten publiceren. Een model dat uitblinkt in creatief schrijven hoeft niet de beste keuze te zijn voor technische documentatie.

Snelheid is relevant zodra je AI inbouwt in een werkproces of klantinteractie. Een model dat drie seconden nodig heeft om een antwoord te genereren, voelt traag in een livechat maar is prima voor een nachtelijke rapportage.

Kosten worden bepaald door het aantal tokens, zoals uitgelegd in de eerste aflevering. Grotere modellen kosten meer per token. Bij laagfrequent gebruik is dat nauwelijks relevant, maar bij automatisering op schaal is het een serieuze post.

Privacy en dataverwerking is de vierde factor, en voor MSP’s vaak de meest gevoelige. Waar worden de gegevens verwerkt? Welke voorwaarden gelden voor trainingsdata? Mag klantdata het land verlaten? Dit zijn vragen die je moet kunnen beantwoorden voordat je een model inzet in een omgeving met vertrouwelijke informatie.

Gesloten of open?

Naast de keuze tussen modellen is er een fundamentelere keuze: gebruik je een gesloten model via een API van een grote aanbieder, of zet je een open model in dat je zelf beheert?

Gesloten modellen zijn doorgaans krachtiger en makkelijker in gebruik. Je hoeft geen infrastructuur te beheren en profiteert automatisch van updates. De keerzijde is afhankelijkheid: van de aanbieder, diens voorwaarden en diens prijsbeleid.

Open modellen geef je meer controle. Je bepaalt waar de data blijft, je kunt het model aanpassen aan jouw situatie en je bent niet afhankelijk van een externe partij. De keerzijde is dat je er infrastructuur en kennis voor nodig hebt. Voor MSP’s die privacy hoog in het vaandel hebben of klanten bedienen in gereguleerde sectoren, is dit een serieuze optie om te verkennen. In aflevering 7 gaan we daar dieper op in.

Wat je klanten erover moeten weten

Als MSP ben je steeds vaker degene die klanten adviseert over AI-keuzes. Dat betekent dat je niet alleen moet begrijpen welk model je zelf gebruikt, maar ook hoe je die keuze uitlegt aan iemand die er niets van weet.

De eenvoudigste manier is de taak centraal stellen. Wat wil de klant bereiken? Hoe vaak? Met welke data? Vanuit die vragen werk je toe naar een model dat past, zonder dat je de klant hoeft mee te nemen in technische details. De modelnaam doet er daarbij minder toe dan de eigenschappen: snel of grondig, goedkoop of krachtig, lokaal of in de cloud.

Modellen zullen blijven veranderen. Wat vandaag de beste keuze is, kan over een jaar zijn ingehaald. Maar de vragen die je stelt bij de keuze blijven hetzelfde.

De volgende aflevering gaat over prompt engineering: waarom de manier waarop je een vraag stelt zoveel uitmaakt, en hoe je daar als MSP bewust mee omgaat.

Je stuurt een vraag naar een AI-tool. Het model geeft antwoord. Je stelt een vervolgvraag, en het model reageert alsof het de hele conversatie heeft meegelezen. Dat klopt ook, maar tot op zekere hoogte. Want elk taalmodel heeft een grens aan hoeveel het tegelijk kan verwerken en onthouden. Die grens heet het contextvenster, en het is een van de meest praktische begrippen om te kennen als je AI serieus inzet.

In de vorige aflevering legden we uit wat tokens zijn: de basiseenheden waarmee taalmodellen tekst verwerken. Het contextvenster is de hoeveelheid tokens die een model in één keer kan bevatten. Alles wat binnen dat venster valt, ziet het model. Alles daarbuiten bestaat voor het model niet.

Dat venster omvat niet alleen de laatste vraag die je stelt, maar de volledige conversatie: jouw vragen, de antwoorden van het model, eventuele instructies die je vooraf hebt meegegeven en documenten die je hebt aangeleverd. Al die tekst samen moet binnen het venster passen.

De maat van dat venster verschilt per model. Gangbare modellen werken met contextvensters van 128.000 tot 200.000 tokens, wat neerkomt op 100 duizend tot 150 duizend woorden. Dat klinkt ruim, en voor de meeste toepassingen is het dat ook. Maar er zijn situaties waarin je er tegenaan loopt.

Wat gebeurt er als het venster vol is?

Een taalmodel werkt niet zoals een mens die iets vergeet omdat de herinnering vervaagt. Het is directer: wat buiten het contextvenster valt, is simpelweg niet beschikbaar. Het model kan er geen rekening mee houden, er niet naar verwijzen en er niet op voortbouwen.

In de praktijk betekent dit dat bij een zeer lang gesprek of een grote hoeveelheid aangeleverde documenten het begin van de conversatie op een gegeven moment buiten het venster valt. Het model gedraagt zich dan alsof die informatie nooit is uitgewisseld. Dat kan leiden tot inconsistente antwoorden of herhalingen van informatie die je al eerder hebt gehad.

Voor MSP’s die AI inzetten voor documentanalyse, contractreview of kennismanagement is dit relevant. Een model dat gevraagd wordt om een groot aantal documenten tegelijk te verwerken, kan daardoor minder nauwkeurig worden naarmate de invoer groter is.

Contextvenster en geheugen zijn niet hetzelfde

Een veelvoorkomend misverstand is dat een groot contextvenster gelijkstaat aan geheugen. Dat is het niet. Het contextvenster is tijdelijk: zodra een gesprek wordt afgesloten, is alles weg. Een nieuw gesprek begint altijd blanco, ongeacht hoe uitgebreid de vorige sessie was.

Echte geheugenoplossingen, waarbij relevante informatie uit eerdere gesprekken wordt opgeslagen en teruggegeven aan het model, vereisen extra techniek. Dat kan via een database die relevante fragmenten opzoekt en meestuurt in de prompt, een aanpak die bekendstaat als RAG. Daar gaan we in een latere aflevering dieper op in.

Wat betekent dit voor jouw praktijk?

Voor dagelijks gebruik in een chatinterface merk je weinig van het contextvenster. De limieten zijn ruim genoeg voor de meeste gesprekken. Maar zodra je AI inbouwt in werkprocessen, wordt het relevanter.

Een paar situaties om rekening mee te houden. Als je grote documenten aanlevert ter analyse, check dan of de totale omvang binnen het contextvenster van het gekozen model past. Als je een geautomatiseerd systeem bouwt dat lange instructies meestuurt bij elk verzoek, telt die instructie mee in het venster en blijft er minder ruimte over voor de eigenlijke taak.

Bij toepassingen die via een API lopen, en dat zal voor MSP’s die oplossingen bouwen meestal het geval zijn, werkt het contextvenster anders dan in een chatinterface. De API heeft geen automatisch geheugen. Bij elke aanroep stuur je zelf de volledige gespreksgeschiedenis mee, zodat het model weet wat er eerder is uitgewisseld. Doe je dat niet, dan begint het model elke keer opnieuw: geen herinnering aan eerdere vragen, geen context, geen opgebouwde kennis over de situatie. Elke API-call is dan in feite een nieuw gesprek.

Stuur je de geschiedenis wél mee, dan betekent dit dat een lang gesprek of uitgebreid werkproces bij elke stap meer tokens verbruikt, omdat de hele geschiedenis steeds opnieuw wordt meegestuurd. Bij het ontwerpen van een API-toepassing is het daarom slim om te bedenken hoeveel context het model echt nodig heeft, en wat je kunt weglaten.

Via de API kun je overigens actief monitoren hoe vol het venster raakt. De meeste aanbieders bieden een manier om het aantal tokens in je verzoek te tellen voordat je het verstuurt, zodat je in je applicatie een check kunt inbouwen die waarschuwt of ingrijpt voordat je de limiet bereikt. In een chatinterface ontbreekt die zichtbaarheid — je merkt het pas als het model dingen lijkt te vergeten of inconsistent wordt.

Juiste vragen stellen

En als je klanten adviseert over AI-toepassingen voor kennismanagement of documentverwerking, is de grootte van het contextvenster een van de eerste technische vragen om te stellen.

De volgende aflevering gaat over de modellen zelf: wat zijn de verschillen tussen de grote spelers, wanneer kies je welk model, en hoe weeg je dat af als MSP?

Als je AI-tools inzet in je bedrijf, of ze doorverkoopt aan klanten, kom je vroeg of laat een term tegen die weinig uitleg krijgt maar wél bepaalt hoeveel je betaalt, hoe slim een model zich gedraagt en waar de grenzen liggen: de token, een begrip dat direct raakt aan kosten, prestaties en verwachtingen.

Een taalmodel leest en schrijft geen tekst zoals jij dat doet. Het werkt met tokens: stukjes tekst die ergens tussen een letter en een woord in zitten. Een gangbare vuistregel is dat één token overeenkomt met ongeveer vier tekens, of driekwart woord. Dat betekent dat duizend tokens ruwweg 750 woorden zijn, of anderhalve pagina tekst.

Eenvoudige woorden zoals “hallo” of “server” zijn vaak één token. Langere of zeldzame woorden worden opgesplitst. “Informatiebeveiliging” levert vermoedelijk vier of vijf tokens op. Spaties, leestekens en opmaakelementen tellen apart mee.

Het onderliggende principe heet Byte Pair Encoding: het model heeft geleerd welke lettercombinaties zo vaak voorkomen dat ze een eigen eenheid verdienen. Veelgebruikte stukjes tekst worden één token, zeldzame combinaties worden opgesplitst. Dat is efficiënter dan werken met losse letters, en nauwkeuriger dan werken met hele woorden.

Waarom Nederlands duurder is dan Engels

Hier zit iets wat MSP’s die werken voor Nederlandse klanten concreet merken: Nederlandse tekst kost meer tokens dan Engelse. De modellen zijn voor een groot deel getraind op Engelstalige data, waardoor Engelse woorden vaker als één token worden herkend. Nederlandse samenstellingen als “beheerplatform” of “netwerkinfrastructuur” worden opgesplitst in meer stukjes.

Het verschil is niet dramatisch, maar bij intensief gebruik loopt het op. Een Nederlandse prompt van honderd woorden vraagt gemiddeld twintig tot dertig procent meer tokens dan dezelfde tekst in het Engels. Als je op grote schaal automatiseert, telt dat mee in de rekening.

Kosten en limieten

De meeste mensen maken kennis met AI via een abonnement, zoals Claude Pro of ChatGPT Plus. Daarbij betaal je een vast bedrag per maand en zit er een limiet op hoeveel je kunt gebruiken, uitgedrukt in berichten per tijdsvenster of in totale rekenkracht. Handig voor individueel gebruik, maar minder geschikt als je AI wilt inbouwen in een werkproces of tool.

Dat is waar de API om de hoek komt kijken. Via een API spreek je het model rechtstreeks aan vanuit software, zonder tussenkomst van een gebruikersinterface. Je betaalt per token, precies voor wat je gebruikt. Dat maakt de API geschikt voor automatisering op schaal. Denk aan een helpdesktool die automatisch tickets samenvat, of een rapportgenerator die elke nacht draait.

Bij gebruik via een API betaal je per token, input en output apart. Wat je instuurt aan prompt kost geld, wat het model teruggeeft ook. Dat klinkt abstract, maar het heeft directe gevolgen voor hoe je een toepassing bouwt. Een systeem dat lange instructies meestuurt bij elk verzoek, of dat uitgebreide HTML-output genereert, verbruikt meer tokens dan een strakke, sobere opzet.

De andere kant van tokens is het contextvenster: de hoeveelheid tekst die een model tegelijk kan verwerken en onthouden. Dat venster wordt uitgedrukt in tokens. Een model met een contextvenster van 200.000 tokens kan ruwweg 150.000 woorden tegelijk verwerken, meer dan de meeste romans. Maar zodra je daar overheen gaat, valt het begin van het gesprek weg. Het model vergeet het als het ware. Dat is relevant als je AI inzet voor langlopende processen of grote documenten.

Wat je er praktisch mee doet

Je hoeft geen tokenexpert te worden om AI goed in te zetten. Maar een paar dingen zijn de moeite waard om te onthouden. Korte, heldere prompts zijn niet alleen prettiger voor de gebruiker, ze zijn ook goedkoper. Onnodige opmaak, herhalingen en overbodige context tellen allemaal mee. En als je een AI-toepassing evalueert of inkoopt voor klanten, vraag dan naar de tokenlimieten en tarieven. Die bepalen mede of een oplossing bij die schaal nog rendabel is.

Tokenisatie is de basis waarop alles rust. De volgende aflevering gaat over wat er met die tokens gebeurt zodra ze er zijn: het contextvenster, het werkgeheugen van een model, en wat dat betekent voor de manier waarop AI taken uitvoert.

Vanaf vandaag is het officieel: ChannelConnect bestaat niet meer. Wat jarenlang dé plek was voor nieuws en achtergronden over het IT-kanaal, heeft een nieuwe naam, een nieuwe vorm en een bredere ambitie. Welkom bij MSP Business.

ChannelConnect was een vertrouwd vakmedium. Gericht op resellers, distributeurs en iedereen daartussenin. Maar de markt is veranderd, en eerlijk gezegd was de naam al een tijdje niet meer helemaal dekkend. De doelgroep die we bedienen — MSP-ondernemers, directeuren van IT-dienstverleners, MKB’ers die steeds meer afhankelijk worden van hun IT-partner. Dit vraagt om een nieuwe naam.

Meer dan een naamswijziging

Tegelijk met de rebrand pakken we het ook anders aan. Samen met StoryYo bouwen we aan iets wat verder gaat dan een website met artikelen. Het wordt een platform met drie pijlers: het magazine en de online content, MSP Late Night als talkshowformat voor de échte gesprekken, en de MSP Performance Club als communitylaag voor ondernemers die van elkaar willen leren.

Die samenwerking met StoryYo voelt niet als een zakelijke constructie. Het is een klik tussen twee partijen die allebei vinden dat er meer uit de markt te halen valt dan er nu uitkomt. Meer diepgang, meer openheid, meer gesprekken die ergens over gaan.

ChannelConnect heeft een mooie run gehad. Veel interviews, veel events, veel nieuws dat zijn weg vond naar de mensen die er iets mee konden. Maar het vakmedium-model heeft zijn grenzen. Lezers worden overladen met informatie van alle kanten. Wat mensen écht zoeken, is overzicht en een gevoel dat ze er niet alleen voor staan.

Voor MSP-ondernemers die willen groeien van pure techclub naar strategisch partner van hun klanten, is dit het platform dat daarbij past. Niet omdat wij dat vinden, maar omdat de markt daarom vraagt.

Veel organisaties denken dat ze hun databeheer op orde hebben zolang de back-ups netjes draaien. Er is een schema, er zijn meldingen, en af en toe wordt er iets teruggezet. Tot het moment dat er echt iets misgaat. Dan blijkt dat niemand precies weet wat er bewaard wordt, waarom het bewaard wordt, en hoe lang het eigenlijk had moeten blijven bestaan.

Die neiging om alles te bewaren staat niet op zichzelf; opslag is in veel organisaties jarenlang gegroeid zonder duidelijke keuzes, waardoor steeds minder helder is waarvoor data eigenlijk wordt bewaard.

Herkenbaar? Klanten vragen om zekerheid, maar bedoelen iets anders dan wat de techniek daadwerkelijk levert. Back-up, archief en dataretentie worden door elkaar gebruikt alsof het synoniemen zijn. Dat zijn ze niet. Het verschil wordt ook nog eens steeds relevanter, door strengere wetgeving, groeiende hoeveelheden data en de toenemende impact van incidenten.

Het misverstand

Hoe zat het ook weer? Back-up is bedoeld voor herstel. Het is een technische maatregel om data terug te kunnen zetten na verlies, corruptie of verstoring. Dat kan gaan om een per ongeluk verwijderde mailbox, een fout in een applicatie of een ransomware-incident. De focus ligt altijd op snelheid en beschikbaarheid: hoe snel kun je weer verder, en met zo min mogelijk dataverlies?

Back-up is dus niet een systeem om data langdurig, gestructureerd en doelgericht te bewaren. Toch zien veel organisaties back-ups als een soort vangnet voor alles wat ze ooit nodig zouden kunnen hebben. Oude projectbestanden, mailboxen van ex-medewerkers, historische administratie, klantdata die misschien ooit nog van pas komt. Alles blijft staan, want het kost weinig moeite en opslag kost niks meer.

En dat gaat heel lang goed, zolang niemand vragen stelt. Dan komt er een audit, een juridisch verzoek of er vindt een incident plaats waarbij blijkt dat herstel ingewikkelder is dan gedacht.

Drie verschillende begrippen

Even de begrippen op een rijtje.

Het probleem ontstaat wanneer deze drie door elkaar lopen. Als back-ups worden gebruikt als archief, ontbreekt structuur. Als retentie niet expliciet is vastgelegd, blijft alles staan. En als archivering wordt gezien als iets dat IT wel regelt, zonder afstemming met de business, ontstaan risico’s.

Alles bewaren ≠ strategie

Alles bewaren voelt veilig. Je weet nooit wat je nog nodig hebt, dus waarom zou je iets weggooien? Klinkt logisch, maar is in de praktijk riskant. Data groeit sneller dan veel organisaties beseffen. Niet alleen documenten en mail, maar ook logbestanden, exports, tijdelijke datasets en applicatiegegevens. Wat vandaag overzichtelijk lijkt, wordt over een paar jaar onhandelbaar. Dat maakt zoeken, herstellen en controleren steeds lastiger.

Daarnaast vergroot het bewaren van alles de impact van incidenten. Hoe meer data er is, hoe groter het oppervlak bij ransomware, datalekken of misbruik van accounts. Ook het herstel wordt complexer. Het terugzetten van een omgeving met jaren aan ongefilterde data kost meer tijd, meer capaciteit en meer geld.

Er zijn ook juridische risico’s. Data die je bewaart, kan opgevraagd worden. Data die je had moeten verwijderen maar nog steeds bezit, kan tegen je werken bij audits, rechtszaken of verzoeken van toezichthouders. Niet weten wat je bewaart, is geen verdedigbare positie.

Tot slot speelt kostenbeheersing een rol. Opslag lijkt goedkoop, maar back-ups, replicatie, egress-kosten en beheer tellen op. Zeker als bewaartermijnen ongemerkt steeds langer worden.

Data lifecycle management

Veel mkb-organisaties hebben geen expliciet data lifecycle management. Data komt binnen, wordt gebruikt en verdwijnt uit beeld, maar niet uit systemen. Als msp ligt hier een belangrijke rol: structuur aanbrengen zonder het onnodig ingewikkeld te maken.

Data lifecycle management begint bij een paar simpele vragen. Welke data maken we aan? Waar wordt die opgeslagen? Wie gebruikt die data actief? En wanneer verliest die data zijn waarde of noodzaak?

Op basis daarvan kun je onderscheid maken tussen actieve data, data die alleen nog geraadpleegd wordt, en data die eigenlijk geen functie meer heeft. Dat betekent niet dat alles meteen verwijderd moet worden, maar wel dat er keuzes gemaakt worden. Wat hoort in een archief, wat valt onder back-up, en wat moet na verloop van tijd verdwijnen?

Belangrijk is dat deze keuzes niet alleen technisch worden ingestoken. De business moet begrijpen waarom bepaalde data niet eindeloos beschikbaar blijft en wat daarvoor in de plaats komt. Een goed ingericht archief biedt vaak meer zekerheid dan een stapel oude back-ups waar niemand grip op heeft.

Juridische en operationele risico’s

Dataretentie raakt al snel aan juridische vragen, maar dat betekent niet dat elk gesprek juridisch hoeft te worden. Vaak gaat het vooral om een operationeel risico. Neem een medewerker die vertrekt. Mailboxen blijven vaak bestaan, soms jarenlang. Niemand weet precies wat erin zit, wie er toegang toe heeft en of die data nog nodig is. Bij een datalek of een inzageverzoek ontstaat ineens paniek.

Of klantdata die langer wordt bewaard dan nodig. Niet uit kwade wil, maar uit gemak. Dat kan botsen met privacyregels, maar ook met interne afspraken of contracten. Het ontbreken van een duidelijk retentiebeleid maakt het lastig om dit uit te leggen of te corrigeren.

Ook bij herstel na incidenten speelt dit mee. Als een omgeving teruggezet moet worden, is het belangrijk te weten welke data leidend is. Oude data die automatisch mee terugkomt kan fouten veroorzaken, verwarring geven of zelfs opnieuw risico’s introduceren.

Kosten en herstelbaarheid

Waar je bijna nooit iemand over hoort is de impact van dataretentie op herstel. Back-ups worden vaak ingericht met een focus op volledigheid. Alles wordt meegenomen, want dat is veilig. Maar bij een grootschalig incident blijkt die volledigheid vooral nadelen op te leveren.

Herstel duurt langer, want er moet meer data door het proces. De kans op het terugzetten van ongewenste of verouderde data neemt toe. En het kost meer capaciteit om alles weer beschikbaar te maken, zeker bij cloudomgevingen waar data-uitstroom en compute per gebruik worden afgerekend.

Je kunt ook nog denken aan meerdere recovery fases. Niet alles hoeft meteen terug. Herstel eerst de kernsystemen en actuele datasets, en archiefdata pas later. Of maak die op een andere manier beschikbaar.

Verwarring structureren

Voor jou als msp een herkenbaar spanningsveld. Klanten willen zekerheid, maar weten niet wat ze precies vragen. De neiging is om dat technisch op te lossen door meer back-ups, langere bewaartermijnen en extra opslag. Daarmee verschuif je het probleem, maar los je het niet op. De meerwaarde zit in het ontwarren van de verwarring. Door begrippen uit elkaar te trekken, voorbeelden te geven en consequent te blijven in taalgebruik. Niet alles is back-up. Niet alles hoeft bewaard te blijven. En niet alles wat bewaard blijft, hoort in een back-up.

Belangrijk is om keuzes expliciet te maken. Dat kan door scenario’s te schetsen. Wat gebeurt er bij een incident? Wat willen we binnen een dag terug hebben, en wat mag later? Wat moeten we wettelijk bewaren, en wat niet? Die gesprekken zijn vaak effectiever dan abstracte beleidsdocumenten.

Back-up is een essentieel onderdeel van databeheer, maar het is geen archief en geen retentiestrategie. Wie dat wel zo gebruikt, bouwt ongemerkt risico’s op. Pak je dit goed aan, dan ga je verder dan de techniek. Help klanten onderscheid te maken, keuzes te maken en die keuzes vast te houden.

ChannelConnect is dit jaar opgenomen in de prestigieuze Top 106 van wereldwijde channel media outlets, samengesteld door onderzoeksbureau Omdia. Het platform, dat sinds kort onderdeel is van Dutchit.com, voegt zich daarmee bij Dutch IT Channel, dat al jaren in deze selecte lijst staat.

De opname bevestigt de groeiende positie van ChannelConnect als toonaangevend vakplatform voor de Nederlandse IT-partnermarkt. Vendoren die de Nederlandse MSP- en partnercommunity willen bereiken, beschikken daarmee over twee erkende Nederlandse mediakanalen in de wereldwijde top.

Europa wint terrein

De erkenning valt samen met een opvallende verschuiving in het mondiale medialandschap. Volgens de laatste analyse van Steven Kiernan, Senior Vice President bij Omdia, is het aantal kanaalpublicaties in de EMEA-regio in twee jaar tijd gegroeid van 38 naar 48 titels. Noord-Amerika zag juist een krimp: van 29 naar 18 titels.

Het totale aantal erkende channel media outlets wereldwijd bleef stabiel op 106, maar de invloed verschuift duidelijk richting de regio’s.

Lokale media, lokaal vertrouwen

Kiernan constateert dat lokale kanaalmedia de meest vertrouwde informatiebron blijven voor IT-partners, ondanks — of juist dankzij — de toenemende digitale fragmentatie. De drempel om een medium te starten is sterk verlaagd: een domeinexpert kan vandaag een nieuwsbrief of podcast lanceren en direct concurreren met gevestigde namen. Dat maakt een gerichte, regionale aanpak voor vendoren belangrijker dan ooit.

Voor tech-fabrikanten trekt Omdia een duidelijke conclusie: wie uitsluitend op Amerikaanse media vertrouwt, mist het groeiende partnernetwerk in Europa en Azië.

MSP Business als volgende stap

ChannelConnect ondergaat momenteel een rebranding naar MSP Business, gericht op een nog scherpere focus op managed service providers. De opname in de Omdia Top 106 onderstreept dat het platform deze transitie maakt vanuit een positie van erkende invloed.