Your AI Is Only As Good As Your Worst-Documented Client

Danelle Au made an argument in SecurityWeek recently that deserves more attention in the MSP channel than it will probably get: the future of AI-driven security depends less on model sophistication than on data completeness, because every filtered log and excluded system creates a blind spot the model can’t reason around. She’s writing for enterprise security leaders. But the problem she describes is worse for MSPs, and almost nobody is saying so out loud.

An enterprise CISO has one environment with gaps in it. You have thirty-five.

The enterprise version has one blind spot. Yours has a client count.

Au’s concern is that logs reach the SIEM already filtered and normalized, stripped of the context that would let AI reconstruct an attack chain across four systems. Fair enough. Now add the structural reality of managed services on top of it.

Your client data doesn’t live in one place, and it doesn’t live in the same places from client to client. It’s spread across RMM, PSA, the documentation platform, three different EDR tenants because two acquisitions came with their own stacks, Microsoft 365 for most clients and Google Workspace for the two who won’t move, backup consoles, a firewall vendor that changed twice in four years, and whatever the client’s internal IT person set up before you took over and never wrote down.

Point AI at that and it inherits every seam. Not as an abstract data-quality problem — as a client-specific one. The tool that produces a genuinely useful answer for your best-documented client will produce a confidently wrong one for the client you onboarded during a busy quarter and never went back to finish.

That’s the part worth sitting with. AI failure across a client base isn’t uniform. It’s concentrated exactly where your documentation is thinnest, which is also usually where your margin is thinnest and your technician turnover has been highest.

Documentation debt is now a technical ceiling

MSPs have treated documentation as a discipline problem for twenty years — something you know you should do better, filed alongside time entry and QBR prep. It has quietly become something else. It’s the input layer for every automation and AI capability you’re planning to sell.

And it’s moving the wrong direction. Kaseya found the share of MSPs struggling to create and maintain consistent client documentation climbed from 10% to 17% year over year in its 2026 State of the MSP Report. The usual failure pattern isn’t absence — it’s documentation that was accurate at creation and became progressively misleading as environments changed around it.

A human technician handles that gracefully. They open the doc, notice it says the client is on a firewall model that was replaced in 2024, and mentally discard it. An AI agent doesn’t discard it. It reasons from it.

The same problem, wearing a compliance hat

If this sounds familiar, it should. Evidence completeness is the identical problem in a different frame.

When an assessor asks how a control is implemented across a client environment, the answer has to come from somewhere. If it comes from a screenshot someone took eight months ago, a policy nobody has reviewed since it was generated, and a technician’s memory, you don’t have evidence — you have an assertion with a timestamp. The gap between what your environment actually does and what your documentation says it does is the same gap that breaks AI reasoning and breaks an audit, discovered at different moments and at very different cost.

This is why treating compliance as an operating discipline rather than a certification event matters more now, not less. The controls-mapped-to-live-environment work, the review cycles, the drift detection — that isn’t just audit hygiene anymore. It’s the data layer your AI ambitions sit on.

Contract Check

Before you point AI at client data, read your own contracts

Here’s the half of Au’s argument that changes character completely when you move it from enterprise to MSP.

She raises data sovereignty as a strategic question: where does the data go to be analyzed, who owns the output, which government can compel access. For an enterprise, that’s a risk decision the organization makes about its own information. For you, it’s a contractual obligation you owe to other people’s information, and you’re probably already in breach of it somewhere.

Consider what you actually are in each framework:

Under HIPAA, if you touch PHI for a covered entity you’re a business associate, and HHS is explicit that a business associate “must establish a BAA with its subcontractor before disclosing PHI to the subcontractor,” with all downstream subcontractors themselves becoming business associates. An AI tool processing a healthcare client’s ticket data is that subcontractor.

Under CMMC, if you operate systems that handle CUI you’re an External Service Provider inside your client’s assessment scope, and scoping guidance calls for a Customer Responsibility Matrix mapping who implements what. You cannot be certified on the client’s behalf, and as Secureframe puts it, if your MSP implements a control incorrectly or evidence is missing, “the finding belongs to your assessment” — the client’s.

Under GDPR, if you process personal data on a client’s behalf you are a processor, and Article 28(2) is unambiguous: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” Feeding client data through an AI vendor engages a subprocessor. Article 28(4) adds that when you do, the same data protection obligations must be imposed on that subprocessor by contract — and if it fails, “the initial processor shall remain fully liable to the controller”. Your liability doesn’t transfer to the AI vendor. It stays with you.

Now the practical question. When a technician pastes a client’s error log into an AI assistant to speed up a ticket — which is happening in your business this week, whether or not you’ve approved it — which of those obligations just got tested? Enterprise AI governance is a policy exercise. MSP AI governance is a subprocessor decision being made at the ticket level by people who have never read the DPA.

The short version: an AI tool touching client data is a subprocessor decision, and the liability stays with you.

Where Au’s conclusion doesn’t survive the trip

Her recommendation is to ingest everything and run the AI inside your own environment, under your own control. That’s coherent advice for an organization with a security architecture budget. It is not reachable for a twelve-person MSP, and pretending otherwise is how channel content loses credibility.

The honest version is prioritization, not completeness:

Pick the five sources that change outcomes. Identity, endpoint, email, network edge, and backup status will answer most of what you’d ask an AI tool. Get those five accurate and current for every client before you get anything accurate for one.
Make documentation a closing condition, not a project. The pattern that works is validation embedded in the ticket workflow — verify or update one piece of documentation before close — rather than the quarterly documentation sprint that gets cancelled.
Score your clients on data completeness and know where you’re blind. You already tier clients by revenue and maturity. Tier them by how much you’d trust an automated answer about their environment. The bottom tier is where AI will hurt you first.
Inventory your AI subprocessors before a client asks. Which tools have AI features enabled, what client data flows through them, and does your DPA or BAA actually cover it. This is a one-afternoon exercise that gets dramatically more expensive after an incident.
Write the client-facing version down. A shared responsibility view of what you handle, what the client handles, and where AI-assisted work fits is a trust asset. Clients in regulated industries are starting to ask, and “we’re looking into it” is not a differentiator.

The bottom line

Au is right that completeness determines outcomes, and right that exclusion is usually an architectural choice rather than a technical limit. For MSPs the choice is just made earlier and less deliberately — in onboarding shortcuts, in documentation that never got finished, in tools adopted by technicians before anyone checked what the contract allowed.

The MSPs who get real value from AI over the next two years won’t be the ones with the best models. They’ll be the ones who did the unglamorous work of making their client data accurate, current, and defensibly governed first. That work has a name, and MSPs have been calling it compliance for years without noticing it was also the foundation for everything they want to build next.