“The tools you run for us. Is any of our stuff going into AI?”
Your client asks this at the renewal meeting, where nothing has gone wrong and the question is simply due, the way any governance question comes due once a stack gets complicated enough. Put a line about the AI in your own stack on the QBR agenda, next to patching and backup, and say what you do not know as plainly as what you do. That answer turns the question into one more item you were already on top of.
40% of small and mid-sized businesses have no policy governing which AI tools their staff use. Your client is one of the businesses living that reality at home, whether or not they would put it in those words. Then they look across the table at the stack you run for them and wonder whether the same thing is happening where they cannot see it.
The AI Line Your QBR Agenda Needs
Give your client three facts about the AI in your stack, and it takes 30 seconds to say them:
- Which tools in the stack have AI features switched on
- What those features read
- What gets logged, and for how long
Those three facts are the whole line, so name the functions and the controls, and keep the model providers behind each tool in your back pocket for the client who does ask. A buyer who wanted a subprocessor table would have sent a questionnaire and skipped the coffee altogether; your client at the QBR just wants to know what the tools do. Reciting brand names anyway turns a renewal meeting into a stack tour and costs you the airtime you needed for the roadmap.
Most MSPs and MSSPs have not fielded this question yet, even though a year of MSP community conversation turns up five questions operators ask most, and all five point outward at the client’s AI adoption. None asks what to say about the AI inside your own tools.
Say “we take data privacy seriously” and your client hears someone who has not checked. Say “here is where AI runs in your stack, here is what it reads, here is what the vendors commit to keeping, and here is when I last looked,” and your client hears someone who has. The facts underneath might be identical. The second version is the one that gets repeated to the board after you leave.
What Your Vendors Publish About AI Data Use
Getting those three facts takes an afternoon, and the vendor pages are where you start. Pull up the AI trust page for your best-documented vendor, the kind of published commitment on AI training and data usage you would expect to settle the question. It covers training and little else. It does not name a model provider, state a retention period, or name a region, and the date at the bottom is months old.
The harder problem is that one page can say two things. A vendor will confirm in one section that customer data does not train generative models, then note in another that content flagged as malicious may improve its detection models. Both can be true at once. Squaring them takes a distinction between generative and non-generative training, and nobody in your client’s boardroom carries that around.
Several tools in your stack will have published nothing, and a handful answer only if you email them. That email is two questions: does customer data train your models, and what do you retain and for how long? Where the data actually goes once someone clicks the chat button is the primer’s subject, and it is covered in what MSPs should know about the AI in the software they use.
Which Clients Need a Written AI Answer
Most of your book gets the 30 seconds and nothing more. A smaller group will put the same question in writing.
A client with an auditor, a framework obligation, or an insurer asking questions at renewal will send paper. The assessor rarely asks an AI question by name, but will ask for the vendor list and the access controls they always ask for, and the model APIs land in there. They need names, retention terms, and regions, in a spreadsheet, by Friday.
Most of your clients will never ask for this in writing, so serve the ones who do properly. The written version is the same three facts with two columns added: the model provider behind each tool, and what that vendor commits to retaining. Build it once from the emails you already sent and it answers every questionnaire that follows.
Having the answer written down turns a questionnaire into an afternoon of filling in boxes; without it, the same questionnaire is two weeks of chasing six vendors while a renewal date moves closer.
If your clients are also asking how to handle the AI their own staff are adopting, that is a separate conversation with its own playbook. Keep the two apart.
Publish the Gaps in Your Own Stack
Both tiers get the same underlying answer, and a polished version of it can backfire, since a client who thinks you are reading a script stops listening.
One Australian MSP publishes 10 questions for buyers to put to their IT partner, and argues that no honest provider in 2026 should be able to ace all of them. A partner with a clean answer to every question has either not looked or is selling. Fluency on the hard questions is the warning sign.
That firm then published its own scorecard against its own list, including the answers that do not flatter it. Its incident response playbook, it says, is documented but not yet stress-tested.
Publish your own version, starting with the vendors who never replied, and say which ones answered, which ones did not, and what you do in the meantime. A client who sees the unknown column believes the rest of the sheet, since you clearly did not smooth over what you could not confirm.
Preparation protects the meeting itself as much as it protects the answer, while an improvised response invites follow-up questions nobody scoped or priced. A client who senses you are working it out in real time keeps pulling on the thread. Walk in with the line already settled, and the topic closes in 30 seconds.
What you do in the meantime is the part that is yours to control. Nobody can warrant what a model does downstream, and you should never imply you can vouch for it; what you can say is that AI output is reviewed by a qualified person before it reaches the client. AI features run inside the permissions the user already holds, and you can switch them off for an account that wants them off. That is your process, and it is what a client’s auditor wants to see anyway.
Recheck Your Vendors Once a Year
Most trust pages are months out of date by the time you find them. Vendors add model providers, change retention windows, and ship AI features into products that did not have them at your last renewal. An answer you gathered in March is a claim about March.
Put the check on a cycle you already run, once a year or at contract renewal, walking the same short list and noting what moved. Record the date you checked beside each vendor, so that date is the answer when a client asks how current it is. It is a handful of vendors, checked once and applied across the whole stack. Most of your book still gets the 30-second line; the few who ask in writing get the spreadsheet.
The work is bounded and covered in one sitting, and what your client sees next quarter is a provider who answered a hard question before anyone asked it, then answered it the same way twice.
The same discipline that gets the AI line onto the agenda carries the rest of the review. Service providers use Cynomi, the Security Growth Platform, to turn security posture, roadmap, and risk into a client-ready review instead of a week of assembly work. See how QBR-ready reporting works, and walk into the next one with the answer written down and the roadmap already priced.
Table of contents
