AI data lake MSP: clean data before clever agents
AuthorMSP Late NightPublished on:AI in the MSP is everywhere right now, and at the same time nowhere in particular. Everyone switches on a tool, everyone says the service desk is about to disappear, and meanwhile on Friday afternoon you are still sorting out ticket 4711 because a client is printing from the wrong tray. For the second time that month. The gap between the LinkedIn posts about AI-first MSPs and what actually happens in your PSA at 09:15 on a Tuesday is wider than ever. And that gap rarely starts with the AI itself.
The pattern repeats every week. An MSP owner buys an AI tool, hooks it up to the PSA, points it at ten years of tickets and documents, and expects magic to come out. What comes out usually sits somewhere between disappointing and dangerous. The MIT research published two months ago put a number on it: 90% of AI projects in business fail. That is not doom-mongering, that is a mirror.
The reason is almost always the same, and it has little to do with AI. Your data source is not clean. Your ticket system holds notes from 2003 about open source Linux configurations that bear no relation to the current situation. Your documentation is spread across PDFs, Word, Excel, email threads and the head of one specific engineer who retires next month. Point AI at that and it does not raise your value. It raises the mess, in well-formed sentences, with a confidence the client will believe.
What does work: the data lake first, then the agent
What you see working at MSPs making serious progress is the reverse order. Not switching on a tool and then seeing what comes out. First gather all the output of your existing stack, think Microsoft 365 scans, vulnerability scans, backup reports, invoicing, signed agreements, neatly into one data lake. Labelled per client, with metadata, pulled in automatically through Power Automate or something similar. Only then do you put an agent on top that can answer questions from the role of whoever is asking.
The difference with a generic chatbot is that a CFO asks different questions from an IT manager. The CFO wants to know why the Microsoft invoicing rose 18% against last quarter. The IT manager wants to know how many endpoints are behind on patching. The same underlying data, two completely different reports. That is where AI in the MSP delivers business impact: not in automating your own technical work internally, but in giving insights your client could never request before because your Power BI dashboard did not cover them.
Triage, holiday flows and the things that really save time
Concretely, we see three places where AI in the MSP already saves hard hours, and three places where it mostly costs time. On the first category: ticket triage. An MSP that lets Azure OpenAI categorise inbound tickets, set priority and draft a reply sits at around 80% correct categorisation. That takes 20 to 40% off handling time per ticket. On a service desk of 15 people that is no longer an efficiency side project, that is capacity you deploy elsewhere without letting anyone go. Work it back: if you average 1,200 tickets a month and you cut 25% of handling time on half of them, you are talking about roughly 1.5 FTE freed up for project work. That is the difference between bidding or not bidding on the larger client you had to turn down last quarter.
“The pace at which technology develops is exponential”
The holiday flow as an example from practice
More concrete still: an MSP owner raised a problem this summer that every MSP recognises. Around the holiday season, 300 tickets a month about conditional access, because users are trying to log in from Spain or Turkey. They automated the whole process. The user reports in, the agent asks for country and period, the change in the tenant is applied automatically, the user gets a confirmation. No engineer involved at any point. That is not vision talk about 2030, that is running now. And the good part: the same flow works for onboarding new staff, for requesting temporary admin rights, for MFA resets that did not go through self-service. Every repetitive, rule-based action with an engineer historically in the middle is a candidate.
“AI has to actually work in practice, not just send an email”
Where it goes wrong at MSPs that move too fast
Where it goes wrong: building your own AI solution that your vendor drops into the PSA for free six months later. Building a data lake without a security officer who understands that your AI agent now has write access to your Microsoft tenants. And handing sellers an AI tool with no sales framework underneath it. As one of the sharper observations put it: give a fool a tool and you have a fool with a tool. AI amplifies what is already there, including the weak spots you would rather not amplify. Build it yourself without the capacity to maintain it and you lose to the vendor. Wait for the vendor without your own data lake and you miss the client insights that set you apart.
There is a third trap that gets less attention: governance. The moment your AI agent can change something in a client tenant, your liability profile changes. Who signs off that the agent was allowed to alter conditional access? Where is it logged that this was not a human? What happens when the agent hallucinates and touches the wrong tenant? MSPs that arrange this up front, with audit trails, human-in-the-loop on risky actions and clear terms in the data processing agreement, can speed up. MSPs that skip it will run into that conversation in a way you do not want to experience.
The real choice for MSP owners is not which AI tool you buy. It is what you steer on. Do you steer on switching features on, or on what ends up in your data lake and who can reach it? The MSPs leading in two years are the ones getting their documents, scans and tickets into one place now. The rest will still be comparing tools. Start small: pick one client, one data source, one use case where your client already feels the pain today. Build that into something that works, and only then scale it wider.