Using AI in managed services without the data question
Client ticket content is the most sensitive data an MSP holds. How local model deployment removes the objection instead of arguing with it.
Every managed service provider evaluating AI runs into the same meeting. The features are compelling, the productivity case is clear, and then someone asks where the ticket content goes. The conversation usually ends there, or it ends with a data processing agreement nobody is fully comfortable with.
The objection is reasonable
Ticket content is not ordinary business data. It contains client infrastructure details, user names, occasionally credentials that should not have been pasted but were, and a running description of a client operational weaknesses. An MSP holds this for every client simultaneously.
Sending that to a third-party API may well be contractually permissible and technically secure. It is still a question you have to answer for every client, in every security review, forever. The cost is not risk so much as friction.
Removing the question rather than answering it
The alternative is to make the deployment target a configuration choice. Run against a hosted provider with your own API key when that is acceptable, and run against your own hardware when it is not. If a local model is selected, no client content leaves the network, and the security review question stops being a question.
This is more achievable than it was two years ago. The tasks that matter in service delivery — summarising a session, drafting a reply in a consistent voice, classifying a ticket — are well within reach of models that run on a single workstation.
Budget context, do not just cap it
The engineering constraint with local models is context, not capability. A feature that answers questions across an entire ticket history cannot simply pass everything to the model. It has to select what is relevant and stay within a budget. Done well, the same feature runs on a small local model and a large hosted one, and the user cannot tell which.
A useful design rule: let different tasks use different models. Screen analysis benefits from a stronger model than reply drafting does. Making that per-task rather than global keeps cost proportionate to value.
Keep the human gate on consequential actions
Data residency is one half of the trust problem. The other is what the AI is allowed to do. An agent that can drive a browser should run against an allow-listed set of domains, log every action server-side, and pause for a human decision before anything that sends, submits, pays or deletes.
Those constraints are not a limitation to apologise for. They are the reason the feature is deployable in an environment where someone is accountable for the outcome.