De servicedesk is de plek waar IT-dienstverleners het vaakst in contact komen met eindgebruikers. Het is ook de plek waar AI het snelst zichtbaar resultaat oplevert — en waar de verwachtingen het vaakst botsen met de werkelijkheid. Want ja, AI kan tickets classificeren, antwoorden opstellen en kennisbanken doorzoeken. Maar nee, het vervangt niet zomaar je eerstelijns medewerker, en een slecht geïmplementeerde AI-assistent kost meer dan hij oplevert.

In deze aflevering kijken we naar wat AI concreet doet in de servicedesk, hoe je dat als MSP slim inzet — voor jezelf én voor je klanten — en waar de valkuilen zitten.

Wat AI goed kan in een servicedesk

Laten we beginnen met wat werkt. Een taalmodel is van nature goed in drie dingen die in een servicedesk voortdurend terugkomen: tekst begrijpen, tekst categoriseren en tekst genereren.

Ticketclassificatie is het meest voor de hand liggende beginpunt. Een binnenkomend ticket – via e-mail, chat of formulier – bevat informatie over het probleem, de urgentie en soms de gebruiker. Een AI-model kan dat ticket razendsnel lezen en categoriseren: is dit een hardwareprobleem of een toegangsvraag? Hoge of lage prioriteit? Welk team pakt dit op? Wat bij een mens tijd kost en bij drukte makkelijk mis gaat, doet een model consistent en zonder vermoeidheid.

Kennisbank-search is de tweede sterke toepassing. De meeste servicedesks hebben een kennisbank, maar die wordt zelden goed gebruikt. Medewerkers zoeken op trefwoorden, vinden niet wat ze zoeken en lossen het probleem toch zelf op,  of ze bellen een collega. Een AI-model dat toegang heeft tot die kennisbank (via RAG, zoals besproken in aflevering 5) kan een binnenkomend ticket direct koppelen aan relevante artikelen, op basis van betekenis in plaats van trefwoorden. Een ticket over ‘mijn scherm blijft zwart na het opstarten’ matcht dan ook met een kennisbankartikel over opstartproblemen na een Windows-update, ook als die exacte woorden er niet in staan.

First-line response is de toepassing die het meest opvalt, maar ook het meest genuanceerd ligt. Een AI-model kan een conceptantwoord genereren op basis van het ticket en de kennisbank. De medewerker leest het, past aan waar nodig, en stuurt het door. Dat is sneller dan vanaf nul beginnen, zeker bij terugkerende vragen. Je kunt ook verder gaan: voor eenvoudige, goed omschreven problemen kan de AI het antwoord rechtstreeks naar de gebruiker sturen, zonder tussenkomst van een medewerker. Dat heet een volledig geautomatiseerde first-line response, en daar kom je al snel in het gebied van AI-agenten, wat we in de volgende en laatste aflevering van deze serie behandelen.

Wat AI niet kan vervangen

Veel MSP’s, en zeker veel van hun klanten,  denken dat AI de servicedesk goedkoper maakt doordat je mensen kunt wegbezuinigen. Dat klopt in theorie, maar de praktijk is weerbarstiger. Hier zit het grootste misverstand.

AI is goed in patroonherkenning en tekstgeneratie. Het is slecht in context die niet expliciet in het ticket staat. Een medewerker die een eindgebruiker kent, weet dat ‘mijn laptop doet raar’ van die ene afdeling wellicht een probleem met een printerstuurprogramma is na de laatste update. Een AI weet dat niet, tenzij je die context actief meegeeft, bijvoorbeeld via een koppeling met je PSA-systeem en de geschiedenis van dat account.

AI is ook slecht in omgaan met emotie. Een eindgebruiker die voor de derde keer belt over hetzelfde probleem is niet alleen technisch gefrustreerd. Die persoon wil gehoord worden. Een geautomatiseerd antwoord – hoe accuraat ook – lost dat niet op, integendeel.

En dan is er nog het probleem van de randgevallen. AI presteert goed op de gevallen die lijken op wat het eerder heeft gezien. Maar een servicedesk krijgt ook tickets die buiten elk patroon vallen: een combinatie van problemen, een gebruiker die slecht kan omschrijven wat er mis is, of een situatie die escalatie vereist. Juist die gevallen zijn vaak de meest tijdrovende en daar biedt AI weinig soelaas.

De MSP als implementatiepartner

Een MSP heeft hier meerdere rollen. De eerste rol is intern: je eigen servicedesk slimmer maken. Dat betekent minder tijd per ticket, consistentere afhandeling en betere kennisbenutting. De investering is relatief laag als je al een ticketsysteem hebt dat API-toegang biedt. De meeste moderne PSA-platforms (ConnectWise, Autotask, HaloPSA) ondersteunen dat. Je koppelt je kennisbank, je stelt een model in dat drafts genereert, en je traint je team om die drafts te beoordelen in plaats van antwoorden te typen.

Je kunt ook extern een rol spelen: je klanten voorzien van een slimme eerstelijns support-laag. Denk aan een middelgroot bedrijf dat zijn eigen IT-helpdesk heeft, maar die wil ontlasten. Jij bouwt een AI-assistent die veelvoorkomende vragen afhandelt, tickets aanmaakt in het systeem en escalaties doorstuurt naar de juiste persoon. De klant heeft minder beldruk op zijn interne helpdesk, jij levert een beheerde dienst met meetbare resultaten.

Die tweede rol vraagt meer dan techniek. Je moet afspraken maken over wat de AI wel en niet mag afhandelen, wie verantwoordelijk is als het misgaat, en hoe je de kwaliteit van de gegenereerde antwoorden bewaakt.

Kwaliteitsbewaking: te vaak overgeslagen

Een AI-assistent in de servicedesk is geen product dat je installeert en vergeet. De kwaliteit van de output hangt af van drie dingen: de kwaliteit van de kennisbank, de kwaliteit van de systeemprompt, en de feedback die je teruggeeft aan het systeem.

Een kennisbank die verouderd is of vol staat met uitzonderingen en workarounds, produceert antwoorden die eindgebruikers op het verkeerde been zetten. Een systeemprompt die te vaag is, leidt tot antwoorden die technisch kloppen, maar praktisch onbruikbaar zijn. En als je niet bijhoudt welke gegenereerde antwoorden zijn aangepast of afgewezen door medewerkers, heb je geen signaal om het systeem te verbeteren.

Goed implementeren betekent dus ook een beheerproces inrichten. Wie controleert maandelijks of de kennisbank nog actueel is? Wie beoordeelt de kwaliteitsstatistieken? Wie past de systeemprompt aan als de output structureel afwijkt van wat je wilt?

Wat levert het op?

De return on investment van AI in de servicedesk is het makkelijkst te meten aan de kant van tijdsbesparing. Gemiddeld neemt de verwerkingstijd per ticket af als AI-assistentie goed is ingericht, zeker bij eenvoudige, terugkerende meldingen. De exacte winst verschilt sterk per organisatie en hangt af van ticketvolume, complexiteit en de kwaliteit van de bestaande kennisbank.

Minder tastbaar, maar minstens zo relevant: consistentie. Een AI-assistent geeft dezelfde antwoordkwaliteit op maandagochtend als op vrijdagmiddag. Geen vermoeidheidsfactor, geen kennisongelijkheid tussen junior en senior medewerker. Dat is ook een argument richting klanten die klagen over wisselende servicekwaliteit.

Wat je er niet van moet verwachten: een dramatische daling van je personeelskosten op korte termijn. AI verschuift werk, maar elimineert het niet. De medewerker die voorheen antwoorden typte, beoordeelt nu antwoorden en handelt de complexe gevallen af die de AI niet aankan. Dat is niet per se minder werk.

In de volgende en laatste aflevering van AI Business Basics gaan we een stap verder: wat gebeurt er als AI niet alleen antwoorden genereert, maar ook zelf acties onderneemt? Wat is een AI-agent, hoe verschilt hij van een chatbot, en wat betekent dat voor jouw processen en klantverantwoordelijkheid?

De Belastingdienst zei in februari dat het niet kon. Maar onlangs werden drie alternatieven voor Microsoft 365 en Google Workplace gelanceerd. Zijn het volwaardige werkplekpakketten en dus echte vervangers voor de Amerikaanse aanbieders? MSP Business zet ze op een rijtje.

De geopolitieke ontwikkelingen van de afgelopen jaren hebben het debat over digitale soevereiniteit versneld. De afhankelijkheid van Amerikaanse platforms is van een technische keuze een strategisch vraagstuk geworden. Overheden, zorginstellingen en bedrijven voelen de druk: waar staat onze data, wie heeft er toegang toe, en wat gebeurt er als de relatie tussen Europa en de VS verder onder spanning komt te staan?

De Nederlandse Belastingdienst formuleerde eerder dit jaar een nuchter oordeel: er is op dit moment geen volledig Europees alternatief voor Microsoft 365. En toch zijn er inmiddels drie initiatieven die dat willen veranderen. Ze heten Liber Desk, Office.eu en Euro-Office. Ze lijken op het eerste gezicht op hetzelfde probleem te reageren, maar zijn in essentie fundamenteel anders van aard.

Drie initiatieven

Liber Desk (niet te verwarren met Libre Office) is een product van het Nederlandse EGP (Espresso Gridpoint), al jaren actief als Infrastructure as a Service-aanbieder exclusief via het IT-kanaal. Liber Desk is uitdrukkelijk geen consumentenproduct: het is een modulaire werkplek die MSP’s kunnen inzetten bij hun klanten. Het platform combineert functionaliteit die organisaties kennen van Microsoft 365, maar is opgebouwd uit losse bouwstenen die naar behoefte kunnen worden gecombineerd. EGP ontwikkelde het product in co-creatiesessies met MSP’s en organisaties, en positioneert het als een manier om als IT-dienstverlener meer regie te krijgen over dienstverlening, marge en technologiekeuzes. Data blijft op Nederlandse bodem, het platform voldoet aan ISO 27001 en ISO 22301.

Office.eu is een commercieel initiatief, gelanceerd in maart 2026 in Den Haag door ondernemer Maarten Roelfs. De suite draait op Nextcloud Hub en biedt tekstverwerking, spreadsheets, presentaties, e-mail, chat en opslag in één platform. De positionering is direct: een vervanging voor Microsoft 365 en Google Workspace, volledig in Europese handen, draaiend op Europese datacenters. Office.eu richt zich voornamelijk op particulieren en het MKB. Een brede Europese uitrol is gepland voor Q2 2026, met migratiebegeleiding vanuit IMAP en CalDAV als overstappad.

Euro-Office is het meest ambitieuze en ook het meest turbulente initiatief. Nextcloud en IONOS lanceerden het in maart 2026 als open source kantoorpakket voor documenten, spreadsheets en presentaties, bedoeld als soeverein Europees alternatief voor Microsoft Office, met breed Europees draagvlak via partners als Eurostack, XWiki en OpenProject. Een previewversie werd direct beschikbaar gesteld; een stabiele release werd verwacht in de zomer van 2026. Maar Euro-Office liep al bij de start tegen een conflict aan: ONLYOFFICE, waarvan de editors als basis dienden voor de fork, verbrak de acht jaar durende samenwerking met Nextcloud en stelde dat Euro-Office licentievoorwaarden schendt, onder meer door het verwijderen van verplichte naamsvermeldingen.

Niet hetzelfde verhaal

De drie initiatieven beantwoorden dezelfde politieke tijdgeest, maar ze zijn strategisch heel verschillend. Office.eu is een dienst: je neemt een abonnement en werkt in de browser. Euro-Office is een beweging: open source, coalitiegedreven, bedoeld als Europees tegenwicht in de infrastructuurlaag. Liber Desk is een kanaalstrategie: een product dat MSP’s als eigen dienstverlening kunnen aanbieden aan klanten.

Dat onderscheid is voor MSP’s het meest relevante vertrekpunt. Office.eu en Euro-Office opereren grotendeels buiten het kanaal. Liber Desk is er expliciet voor gebouwd. Het verschil zit behalve in de technologie vooral in het verdienmodel: wie levert, wie ondersteunt, wie factureert.

De kans voor MSP’s

Microsoft 365 is voor veel MSP’s een vanzelfsprekendheid geworden, maar niet zonder spanning. De marges op licentieverkoop zijn de afgelopen jaren onder druk gekomen. Copilot voegt functionaliteit toe die klanten aantrekkelijk vinden, maar de bijbehorende kosten en de toenemende lock-in vergroten de afhankelijkheid voor zowel de klant als de MSP. Wie uitsluitend Microsoft verkoopt, verkoopt steeds meer een ecosysteem waar hij zelf weinig invloed op heeft.

Dat maakt de komst van kanaalgerichte alternatieven interessant, ook als je nu nog geen klant hebt die erom vraagt. De vraag naar Europese alternatieven groeit, zeker in sectoren met strenge compliance-eisen. MSP’s die nu kennis opbouwen, staan straks sterker als die vraag concreet wordt. Liber Desk biedt daarvoor een specifiek kanaalmodel: modulair opgebouwd, ondersteund door Nederlandse partners, met adoptiebegeleiding als onderdeel van het aanbod.

Tegelijkertijd geldt: vroeg instappen heeft risico’s. Het licentieconflict rond Euro-Office is een concreet voorbeeld van hoe snel een veelbelovend initiatief in turbulent vaarwater terechtkomt. En ook bij Office.eu en Liber Desk geldt dat bewezen massa-adoptie nog ontbreekt.

Wat er nog ontbreekt

De eerlijkheid gebiedt te zeggen dat geen van de drie initiatieven de volledige belofte al waarmaakt. Gebruikerservaring, mobiele apps, volwaardige Teams-vervanging, AI-integratie: dat zijn de echte drempels voor brede adoptie, en op al die punten lopen de alternatieven achter op Microsoft.

Maar het diepste probleem is structureler dan een feature-vergelijking suggereert. Microsoft 365 is niet populair omdat de apps zo goed zijn. Het is dominant omdat het ecosysteem diep geïntegreerd is: Azure voor identiteitsbeheer en infrastructuur, Exchange voor e-mail en agenda, Entra ID voor conditional access, Intune voor device management. Dat ecosysteem is in twintig jaar gegroeid en verweven met hoe organisaties werken. Een tekstverwerker en een gedeelde agenda zijn geen vervanging voor dat geheel. Dat is ook de impliciete erkenning achter het modulaire model van Liber Desk: een one-to-one vervanging van Microsoft 365 is voorlopig geen realistisch doel.

Positie kiezen

MSP’s hoeven nu niet te switchen, maar het is wel zinvol om de ontwikkelingen goed in de gaten te houden. Of een van de nieuwe oplossingen de massa bereikt die nodig is om een volwassen ecosysteem te worden, is maar de vraag. Maar met voldoende druk en noodzaak door de geopolitieke ontwikkelingen, nemen we straks misschien wel enkele tekortkomingen voor lief. De tijd zal het leren.

De meeste MSP’s die vandaag met AI werken, doen dat via een API van een grote aanbieder. Je stuurt een verzoek naar een server ergens in de wereld, het model verwerkt het en stuurt een antwoord terug. Snel, makkelijk en krachtig. Maar niet altijd de juiste keuze.

De vraag of je AI lokaal draait of in de cloud is voor MSP’s relevanter dan voor veel andere sectoren. Je beheert data van klanten, vaak vertrouwelijke data, en opereert in een omgeving waar privacywetgeving, contractuele afspraken en sectorspecifieke regelgeving bepalen wat er wel en niet mag.

Wat lokaal draaien betekent

Lokaal draaien betekent dat het model draait op hardware die je zelf beheert, op je eigen server, in je eigen datacenter of bij een klant on-premise. De data verlaat de omgeving niet. Er is geen externe aanbieder die de verzoeken verwerkt, en er zijn geen voorwaarden van een derde partij waar je rekening mee moet houden.

Dat klinkt als de veiligste optie, en voor bepaalde situaties is het dat ook. Maar er zijn serieuze keerzijden. Lokale modellen zijn doorgaans minder krachtig dan de grote cloudmodellen. De beste open modellen komen in de buurt, maar halen de absolute top nog niet. Daarnaast vraagt lokaal draaien om hardware-investeringen, beheer en kennis. Een krachtig model heeft forse rekenkracht nodig, en dat kost geld, ook als je het niet gebruikt.

Wat de cloud biedt

Cloudmodellen zijn krachtig, altijd up-to-date en vragen geen infrastructuurinvestering. Je betaalt voor wat je gebruikt en profiteert automatisch van verbeteringen die de aanbieder doorvoert. Voor de meeste toepassingen is dit de meest praktische keuze.

De keerzijde is afhankelijkheid. Van de aanbieder, zijn prijsbeleid, zijn voorwaarden en zijn beslissingen over welke modellen beschikbaar blijven. En van de locatie waar data wordt verwerkt. De grote aanbieders verwerken data standaard op servers in de Verenigde Staten. Europese verwerkingsopties bestaan wel, maar zijn doorgaans alleen beschikbaar via enterprise-contracten of via cloudplatforms als Azure, AWS Bedrock of Google Vertex AI, en vragen om een bewuste configuratiekeuze. De standaard API-toegang biedt die garantie niet.

AVG en gegevensverwerking

Voor MSP’s die werken met persoonsgegevens van klanten is de AVG het kader waar je niet omheen kunt. De kernvraag is waar data wordt verwerkt en onder welke voorwaarden. Maar die vraag is minder eenvoudig te beantwoorden dan het lijkt.

Een veelvoorkomend misverstand is dat een verwerkersovereenkomst het probleem oplost. Dat is niet zo. Een verwerkersovereenkomst legt vast hoe een aanbieder met data omgaat, maar verandert niets aan de locatie waar die verwerking plaatsvindt. Als die locatie buiten de Europese Economische Ruimte ligt, heb je aanvullende maatregelen nodig om doorgifte rechtmatig te maken. De meest gebruikte basis daarvoor is het EU-VS Data Privacy Framework, waaronder grote aanbieders als Anthropic, OpenAI en Google zijn gecertificeerd. Dat biedt een grondslag voor doorgifte, maar is niet onomstreden: het framework is juridisch kwetsbaar en eerder werden vergelijkbare afspraken door het Europese Hof van Justitie vernietigd.

Een tweede misverstand is dat dataresidentie en dataprivacy hetzelfde zijn. Dataresidentie gaat over waar data fysiek wordt opgeslagen. Dataprivacy gaat over wie er toegang toe heeft en onder welke juridische condities. Een model dat draait op een Europese server van een Amerikaanse aanbieder biedt dataresidentie in Europa, maar de Amerikaanse moedermaatschappij kan onder Amerikaanse wetgeving, zoals de CLOUD Act, alsnog verplicht worden toegang te verlenen aan Amerikaanse autoriteiten. Voor klanten in gevoelige sectoren is een reëel aandachtspunt.

Voor klanten in gereguleerde sectoren zoals zorg, financiële dienstverlening of overheid is de verwerkingslocatie daarom een van de eerste vragen die je moet beantwoorden voordat je een AI-oplossing implementeert. Wat voor data verwerkt het systeem? Wie heeft er toegang toe? Wat zijn de contractuele verplichtingen van de klant richting zijn eigen klanten of toezichthouder?

De afweging in de praktijk

Een handige manier om de keuze te structureren is door te kijken naar drie factoren. Hoe gevoelig is de data? Hoe hoog zijn de eisen aan prestaties en snelheid? En wat mag het kosten, zowel in investering als in doorlopende exploitatie?

Voor generieke taken met niet-vertrouwelijke data is een cloudmodel vrijwel altijd de verstandigste keuze. Voor toepassingen waarbij persoonsgegevens worden verwerkt, loont het om de verwerkingslocatie en de juridische grondslag voor doorgifte expliciet te regelen, liefst voordat de oplossing live gaat. En voor omgevingen waar data de organisatie onder geen beding mag verlaten, is lokaal draaien de enige optie die alle risico’s uitsluit.

Als MSP ben je steeds vaker degene die klanten door deze afweging heen loodst. Dat vraagt om technische kennis en het vermogen om privacyvraagstukken begrijpelijk te maken voor klanten die de nuances tussen dataresidentie, verwerkersovereenkomsten en juridische grondslagen niet kennen. Die rol is waardevol, en onderscheidt een MSP die AI serieus neemt van een die alleen een tool installeert.

De volgende aflevering gaat over een van de meest concrete toepassingen voor MSP’s: AI in de servicedesk. Ticketclassificatie, kennisbank-search, first-line response, alles met voor- en nadelen.

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.

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.

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.