Tot nu toe ging deze serie over AI als gereedschap. Je stelt een vraag, het model geeft een antwoord. Je geeft een instructie, het model voert die uit. De mens blijft aan het stuur — AI doet wat er gevraagd wordt, niet meer en niet minder.

Dat verandert bij agentic AI. Een AI-agent wacht niet op een vraag. Hij krijgt een doel, bepaalt zelf welke stappen nodig zijn om dat doel te bereiken, voert die stappen uit en gebruikt daarvoor tools, systemen en informatie die je hem hebt gegeven. Dat is een fundamenteel andere manier van werken, met andere mogelijkheden én andere risico’s.

Van chatbot naar agent

Een chatbot reageert. Je typt iets, hij antwoordt. Elke uitwisseling staat op zichzelf, tenzij je expliciet context meegeeft. Een chatbot in je servicedesk kan een ticket samenvatten, een conceptantwoord schrijven of een categorie voorstellen, maar hij neemt geen initiatief en voert geen acties uit in andere systemen.

Een AI-agent doet dat wel. Hij kan een binnengekomen ticket niet alleen lezen en classificeren, maar ook opzoeken wie de gebruiker is, de geschiedenis van vergelijkbare problemen raadplegen, een oplossing formuleren, die oplossing uitvoeren in het systeem én de gebruiker informeren, allemaal zonder dat een medewerker daar tussen zit.

Het verschil zit in twee dingen: autonomie en toolgebruik. Een agent heeft toegang tot externe tools – een API, een database, een ticketsysteem, een agenda – en besluit zelf wanneer hij welke tool inzet. Dat maakt hem krachtig. Het maakt hem ook onvoorspelbaarder dan een model dat alleen tekst genereert.

Hoe een agent werkt

Een AI-agent werkt in een cyclus. Hij krijgt een doel of een trigger, bedenkt een aanpak, voert een stap uit, bekijkt het resultaat, past zijn aanpak aan en gaat verder, totdat het doel bereikt is of hij vastloopt.

Die cyclus heet in de praktijk vaak een ‘reasoning loop’ of ‘plan-and-execute’-patroon. Het model denkt hardop: wat moet ik doen, welke tool heb ik nodig, wat levert die op, wat is de volgende stap? Dat denkproces is zichtbaar als je kijkt naar hoe moderne agentframeworks werken. Je ziet letterlijk de redenering van het model voordat het een actie uitvoert.

Wat de agent kan doen, hangt af van welke tools je hem geeft. Een agent met toegang tot je PSA-systeem kan tickets aanmaken, toewijzen en sluiten. Een agent met toegang tot je monitoringtool kan alerts beoordelen en eenvoudige herstelacties uitvoeren. Een agent met toegang tot je agenda kan een onderhoudsvenster inplannen. Hoe meer tools, hoe meer hij kan en hoe belangrijker het wordt om dat goed af te bakenen.

Wat dit betekent voor MSP-processen?

Voor MSP’s zijn AI-agenten interessant op plekken waar werk repetitief, regelgestuurd en tijdgevoelig is. Denk aan het verwerken van monitoring-alerts buiten kantooruren: een agent die een alert ontvangt, de ernst beoordeelt, een gestandaardiseerde herstelactie uitvoert en een ticket aanmaakt met de relevante context. Of aan onboarding van nieuwe gebruikers: een agent die een aanvraag ontvangt, accounts aanmaakt in de relevante systemen, een welkomstmail verstuurt en de taak als afgehandeld markeert.

Het voordeel is snelheid en consistentie. Een agent maakt geen typfouten in een gebruikersnaam, vergeet niet om een systeem mee te nemen en werkt ’s nachts net zo goed als overdag. Voor processen die nu handmatig worden uitgevoerd door medewerkers die eigenlijk liever met complexere taken bezig zijn, is dat een reële tijdswinst.

Maar er is een keerzijde. Een agent die autonoom handelt in productiesystemen, kan ook autonoom fouten maken. Een verkeerd begrepen instructie, een randgeval dat buiten het verwachte patroon valt, of een tool die onverwacht gedrag vertoont: het kan leiden tot acties die moeilijk terug te draaien zijn. Dat vraagt om duidelijke grenzen: wat mag de agent zelfstandig doen, wat vereist menselijke goedkeuring, en wat mag hij helemaal niet?

Verantwoordelijkheid en contracten

Als je een AI-agent inzet die namens jou of namens je klant acties uitvoert in systemen, ben jij verantwoordelijk voor de uitkomst. Niet het model, niet de leverancier van het agentframework. Dat betekent dat je moet kunnen uitleggen wat de agent heeft gedaan en waarom, dat je logging inricht die dat aantoonbaar maakt, en dat je afspraken maakt over wat er gebeurt als het misgaat.

Bij inzet voor klanten komt daar nog een laag bij. Welke acties mag de agent uitvoeren in het systeem van de klant? Wie keurt die lijst goed? Wat is de escalatieprocedure als de agent vastloopt of een onverwachte situatie tegenkomt? Die vragen horen thuis in de dienstverleningsovereenkomst, als praktische afbakening die voorkomt dat je achteraf discussie krijgt over wat er had moeten gebeuren.

Waar staan we nu?

De grote modelaanbieders Anthropic, OpenAI en Google investeren zwaar in agentcapabiliteiten. Er zijn volwassen frameworks beschikbaar waarmee je agenten kunt bouwen zonder vanaf nul te beginnen. En de integraties met PSA-systemen, RMM-tools en communicatieplatforms die MSP’s dagelijks gebruiken, worden steeds toegankelijker.

Tegelijk is het vakgebied jong. Best practices zijn nog in ontwikkeling, standaarden ontbreken grotendeels, en de betrouwbaarheid van agenten in complexe situaties is nog geen gegeven. Vroeg instappen heeft voordelen. Je bouwt kennis op voordat de markt het van je vraagt. Maar het vraagt ook om een eerlijke inschatting van wat je aan risico en beheerslast accepteert.

Voor MSP’s is de slimste positie nu: experimenteren in een afgeschermde omgeving, één proces kiezen dat goed gedefinieerd en omkeerbaar is, en van daaruit leren. Niet wachten tot de markt je dwingt, maar ook niet overhaast uitrollen wat je nog niet beheerst.

Drie dagen. Langer duurde het eerste publieke leven van Claude Fable 5 niet. Anthropic lanceerde zijn nieuwe topmodel op 9 juni, samen met de beperkt beschikbare Mythos 5. Op 12 juni haalde het bedrijf beide modellen alweer offline. Aanleiding was een exportbevel van de Amerikaanse overheid dat buitenlandse staatsburgers de toegang tot de modellen ontzegt. Anthropic besloot daarop Fable 5 en Mythos 5 volledig uit te schakelen. Ook Amerikaanse klanten kunnen de modellen daardoor voorlopig niet gebruiken. 

Fable 5 en Mythos 5 zijn gebaseerd op hetzelfde onderliggende model, maar Anthropic heeft ze voor verschillende doelgroepen ingericht. Fable 5 was bedoeld als de breed beschikbare variant. Het model kreeg extra beveiligingslagen om misbruik op gebieden als cybersecurity, biologie en chemie tegen te gaan. Verzoeken die volgens Anthropic te gevoelig waren, werden doorgestuurd naar het minder krachtige Claude Opus 4.8.

Mythos 5 kreeg minder van deze beperkingen. Anthropic stelde dit model uitsluitend beschikbaar aan een kleine groep cyberverdedigers en beheerders van vitale infrastructuur. De verspreiding liep via Project Glasswing, een programma waarbij het bedrijf samenwerkte met de Amerikaanse overheid.

De modellen moesten een nieuwe categorie binnen het Claude-aanbod vormen. Anthropic plaatste de Mythos-klasse boven zijn bestaande Opus-modellen. Fable 5 kon volgens het bedrijf langduriger autonoom werken, grote softwareprojecten analyseren en taken uitvoeren die dagen in beslag nemen. Mythos 5 beschikte over uitgebreidere mogelijkheden voor het vinden en onderzoeken van kwetsbaarheden in software. Die laatste eigenschap maakte het model waardevol voor beveiligingsonderzoekers, maar riep bij de Amerikaanse overheid kennelijk ook vragen op.

Exportbevel treft alle buitenlandse staatsburgers

Op vrijdag 12 juni ontving Anthropic om 17.21 uur lokale tijd een bevel van de Amerikaanse overheid. Daarin stond dat geen enkele buitenlandse staatsburger nog toegang mocht krijgen tot Fable 5 of Mythos 5. Het verbod geldt voor mensen buiten de Verenigde Staten, maar ook voor buitenlandse staatsburgers die in het land wonen of voor Anthropic werken. Het bevel verplichtte Anthropic niet letterlijk om de modellen wereldwijd uit te zetten. Het bedrijf moest voorkomen dat buitenlandse staatsburgers ermee konden werken. Anthropic stelde dat het deze eis niet op korte termijn kon naleven zonder de toegang voor alle gebruikers te blokkeren.

AWS trok op verzoek van Anthropic eveneens de toegang tot Fable 5 en Mythos 5 in alle regio’s in. Andere modellen van het bedrijf, waaronder Claude Opus 4.8, bleven beschikbaar. De Amerikaanse overheid baseerde de maatregel volgens Anthropic op zorgen over een mogelijke jailbreak van Fable 5. Bij zo’n jailbreak weet een gebruiker de ingebouwde veiligheidsmaatregelen te omzeilen. Het model zou daardoor kunnen helpen bij het vinden van kwetsbaarheden in software die het onder normale omstandigheden niet hoort te onderzoeken.

Anthropic betwist de ernst van de jailbreak

Anthropic zegt een demonstratie van de bewuste methode te hebben bekeken. Volgens het bedrijf leverde deze een klein aantal al bekende en relatief eenvoudige kwetsbaarheden op. Andere publiek beschikbare AI-modellen zouden dezelfde fouten kunnen vinden zonder dat daarvoor een jailbreak nodig is. In de weken voor de introductie liet Anthropic Fable 5 naar eigen zeggen duizenden uren testen door interne teams, externe beveiligingsonderzoekers, het Britse AI Security Institute en de Amerikaanse overheid. Tijdens die onderzoeken werd geen universele jailbreak gevonden waarmee de veiligheidslagen breed konden worden uitgeschakeld.

Het bedrijf erkent wel dat volledige bescherming tegen jailbreaks waarschijnlijk niet haalbaar is. Daarom koos Anthropic voor een combinatie van filters, monitoring en gegevensopslag. Verkeer via Fable 5 werd dertig dagen bewaard, zodat verdachte patronen konden worden onderzocht. Volgens Anthropic stond het mogelijke lek niet in verhouding tot de ingreep. Het bedrijf waarschuwde dat toepassing van dezelfde norm op andere aanbieders de introductie van vrijwel ieder nieuw frontiermodel zou kunnen blokkeren. Anthropic noemt de situatie een misverstand en zegt dat regelgeving rond risicovolle AI-modellen transparant, controleerbaar en gebaseerd op technische feiten moet zijn. Het bedrijf vindt dat bij dit bevel niet aan die voorwaarden is voldaan.

Meer dan een technisch conflict

De maatregel staat niet los van de moeizame relatie tussen Anthropic en de regering-Trump. Eerder ontstond een conflict doordat het AI-bedrijf beperkingen wilde stellen aan militair gebruik van Claude, waaronder volledig autonome wapens en binnenlandse surveillance. De Amerikaanse overheid plaatste Anthropic daarop op een lijst met bedrijven die mogelijk een risico vormen voor de militaire toeleveringsketen. Het ligt voor de hand om de exportmaatregel als een politieke vergeldingsactie te zien. Daar is geen hard bewijs voor. De overheid zegt dat nationale veiligheid de reden voor de ingreep is. Geavanceerde modellen kunnen aanvallers sneller kwetsbaarheden laten vinden in complexe software, waaronder systemen in de financiële sector en vitale infrastructuur.

De gekozen aanpak is wel uitzonderlijk. Amerikaanse exportbeperkingen rond AI richtten zich tot nu toe vooral op chips, productiemiddelen en rekenkracht. Met Fable 5 en Mythos 5 wordt de toegang tot de mogelijkheden van een online AI-model zelf beperkt. Hiermee ontstaat een lastig precedent. De nationaliteit van een gebruiker kan voortaan bepalen of die persoon toegang krijgt tot bepaalde clouddiensten, zelfs wanneer diegene legaal in de Verenigde Staten woont of voor de aanbieder werkt.

Technische teams naar Washington

Anthropic probeert de modellen zo snel mogelijk weer beschikbaar te maken. Ervaren technische specialisten van het bedrijf zijn inmiddels naar Washington gestuurd voor overleg met het Witte Huis. Volgens Axios willen beide partijen tot een oplossing komen. Op maandag 15 juni waren Fable 5 en Mythos 5 nog altijd niet beschikbaar. Anthropic heeft nog geen datum genoemd waarop de toegang kan worden hersteld. Ook is niet duidelijk welke extra beveiligingsmaatregelen of toegangscontroles de Amerikaanse overheid zal eisen.

Een mogelijke oplossing is een strengere identiteitscontrole, maar die roept nieuwe vragen op. Cloudleveranciers controleren doorgaans waar gebruikers zich bevinden en welke organisatie een account beheert. Het vaststellen van nationaliteit vraagt om veel gevoeligere persoonsgegevens. Dat kan grote gevolgen hebben voor privacy, onboarding en het beheer van zakelijke accounts.

AI-afhankelijkheid vraagt om uitwijkmogelijkheden

Fable 5 was bij de start veelbelovend. Op internet waren lovende kritieken te lezen over de mogelijkheden en de kwaliteit van de output. Door de actie van de Amerikaanse overheid komt een nieuw leveranciersrisico bovendrijven. De beschikbaarheid van een AI-model (of andere geavanceerde tools) hangt niet alleen af van storingen, capaciteit of een commerciële beslissing van de aanbieder, maar kan ook de inzet worden van (geo)politieke machtsspelletjes.

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?