AI in de MSP: waarom je data lake bepaalt of het werkt
AI in de MSP is nu overal, en tegelijk nergens echt. Iedereen zet een tool aan, iedereen roept dat de service desk verdwijnt, en ondertussen zit je vrijdagmiddag zelf nog steeds ticket 4711 op te lossen omdat een klant uit de verkeerde printlade print. Voor de tweede keer die maand. De kloof tussen de LinkedIn-posts over “AI-first MSP’s” en wat er dinsdagochtend 09:15 daadwerkelijk in je PSA gebeurt, is groter dan ooit. En die kloof begint zelden bij de AI zelf.
Het patroon is elke week hetzelfde. Een MSP-eigenaar koopt een AI-tool in, hangt hem aan de PSA, laat hem los op een berg tickets en documenten uit tien jaar historie, en verwacht dat er magie uitkomt. Wat er uitkomt is meestal iets tussen teleurstelling en gevaar. Het MIT-onderzoek van twee maanden geleden noemde het cijfer: 90% van de AI-projecten in het bedrijfsleven mislukt. Dat is geen doemdenken, dat is een spiegel.
De reden is bijna altijd hetzelfde en heeft weinig met AI te maken. Je datasource is niet schoon. Je ticketsysteem bevat opmerkingen uit 2003 over open source Linux-configuraties die niks meer met de huidige situatie te maken hebben. Je documentatie zit verspreid over PDF’s, Word, Excel, e-mailthreads en de kop van één specifieke engineer die volgende maand met pensioen gaat. Als je AI daar tegenaan zet, brengt hij niet je waarde omhoog. Hij brengt de rotzooi omhoog, in mooie volzinnen, met een confidence die de klant gaat geloven.
Wat wel werkt: eerst het data lake, dan de agent
Wat je in de praktijk ziet werken bij MSP’s die serieus stappen maken, is een omgekeerde volgorde. Niet eerst een tool aanzetten en dan kijken wat eruit komt. Eerst alle output van je bestaande stack, denk aan Microsoft 365-scans, vulnerability scans, backup-rapporten, facturatie, getekende overeenkomsten, netjes verzamelen in één data lake. Per klant gelabeld, met metadata, geautomatiseerd binnengehaald via Power Automate of vergelijkbaar. Pas dan zet je er een agent op die vragen kan beantwoorden vanuit de rol van de vrager.
Het verschil met een generieke chatbot is dat een CFO andere vragen stelt dan een IT-manager. De CFO wil weten waarom de Microsoft-facturatie 18% is gestegen ten opzichte van vorig kwartaal. De IT-manager wil weten hoeveel endpoints achterlopen op patching. Dezelfde onderliggende data, twee compleet andere rapportages. Dat is waar AI in de MSP business impact levert: niet in het intern automatiseren van je eigen techniek, maar in het geven van insights die je klant nooit eerder kon opvragen omdat je Power BI-dashboard er niet in voorzag.
Triage, vakantie-flows en de dingen die echt tijd besparen
Concreet zien we drie plekken waar AI in de MSP nu al harde uren spaart, en drie plekken waar het vooral tijd kost. Op de eerste categorie: ticket-triage. Een MSP die zijn inbound tickets via Azure OpenAI laat categoriseren, prioriteren en voorzien van een concept-antwoord, zit op ongeveer 80% correcte categorisatie. Dat scheelt per ticket 20 tot 40% verwerkingstijd. Op een service desk van 15 man is dat geen efficiëntie-projectje meer, dat is capaciteit die je ergens anders inzet zonder iemand te ontslaan. Reken het even terug: als je gemiddeld 1.200 tickets per maand hebt en je haalt er 25% verwerkingstijd af op de helft ervan, dan praat je over ongeveer 1,5 FTE die vrijkomt voor projectwerk. Dat is het verschil tussen wel of niet meebieden op die grotere klant waar je vorig kwartaal nee tegen moest zeggen.
“De snelheid waarin technologie zich ontwikkelt gaat exponentieel hard”
De vakantie-flow als voorbeeld uit de praktijk
Nog concreter: een MSP-eigenaar noemde deze zomer een probleem dat elke MSP herkent. Rond de vakantieperiode 300 tickets per maand over conditional access, omdat gebruikers vanuit Spanje of Turkije proberen in te loggen. Ze hebben het volledige proces geautomatiseerd. Gebruiker meldt zich, agent vraagt land en periode, aanpassing in de tenant wordt automatisch uitgevoerd, gebruiker krijgt bevestiging. Nul tussenkomst van een engineer. Dat is geen visie-praat over 2030, dat draait nu. En het mooie: dezelfde flow werkt voor onboarding van nieuwe medewerkers, voor het aanvragen van tijdelijke admin-rechten, voor MFA-resets die niet via self-service lukten. Elke repeterende, regel-gebaseerde handeling waar een engineer historisch tussen zat, is een kandidaat.
“AI moet in de praktijk ook echt werken, niet zomaar een e-mailtje”
Waar het misgaat bij MSP’s die te snel willen
Waar het misgaat: zelf een AI-oplossing bouwen die je vendor over zes maanden gratis in de PSA fietst. Een data lake bouwen zonder een security officer die begrijpt dat je AI-agent nu schrijfrechten heeft op je Microsoft-tenants. En verkopers een AI-tool geven zonder salesframework eronder. Zoals één van de scherpere observaties luidde: geef een fool een tool en je hebt een fool with a tool. AI versterkt wat er staat, inclusief de zwakke plekken die je liever niet versterkt zag. Wie zelf bouwt zonder capaciteit om het bij te houden, verliest van de vendor. Wie wacht op de vendor zonder eigen data lake, mist de klant-insights die je onderscheiden.
Er is nog een derde valkuil die minder besproken wordt: de governance. Op het moment dat je AI-agent in een klanttenant iets kan aanpassen, verandert je aansprakelijkheidsprofiel. Wie tekent af dat de agent conditional access mocht wijzigen? Waar wordt gelogd dat het geen mens was? Wat gebeurt er als de agent hallucineerd en een verkeerde tenant raakt? MSP’s die dit vooraf regelen, met audit trails, human-in-the-loop op risicovolle acties en heldere afspraken in de DAP met de klant, kunnen versnellen. MSP’s die het overslaan, komen dat gesprek een keer tegen op een manier die je niet wil meemaken.
De echte keuze voor MSP-eigenaren gaat niet over welke AI-tool je koopt. Die gaat over waar je op stuurt. Stuur je op het aanzetten van features, of stuur je op wat er in je data lake terechtkomt en wie erbij kan? De MSP’s die over twee jaar voorop lopen, zijn de MSP’s die nu hun documenten, scans en tickets op één plek krijgen. De rest zit dan nog steeds tools te vergelijken. Begin klein: kies één klant, één databron, één use case waar je klant vandaag al pijn voelt. Bouw dat uit tot iets werkends, en schaal daarna pas breder.
Share on