How MSPs and vCISOs can deliver governed AI to clients.
Short answer. An MSP or vCISO delivers governed AI (AI whose actions need a named person’s approval and leave a record) to a client. It delivers this the same way it delivers any other managed control. It assigns an identity, scopes its permissions, requires sign-off on the exact action before it runs, and produces a record. The service is not switching on a vendor’s AI feature. It is a use policy, a tenant-isolated workspace (each client’s data kept in its own separate environment), and a quarterly evidence pack the client can hand to their own auditor or insurer.
The useful question a client can bring to an MSP or vCISO about AI is a narrow one: what is already happening in their environment, and who is responsible for it. That question sits inside the same scope as patching, backup and access review. It does not need a separate practice built from nothing.
What are clients asking their MSP or vCISO about AI?
I would sort a client’s AI questions into three kinds. What is a member of staff allowed to put into a public AI tool. Whether a vendor’s AI feature can be switched on without breaking an existing compliance commitment. And how to get some benefit from AI without losing control of client or patient data. Each question needs a different service.
Some of this is a compliance question wearing an AI label. A question about a chatbot is often a question about where the data goes. Treat it as a data-route question first and an AI question second.
What service shapes deliver governed AI to a client?
Four service shapes cover most of the ground, and they build on each other.
- AI use policy and register. A short policy stating what staff may put into which tool, plus a register that names every AI tool in use, its data route and who approved it. The register is the document that turns a policy into something you can audit.
- Permission and data-route review. For each AI tool or feature already switched on, establish which account it runs under, what it can read, and which model endpoint receives the data. We set out the five permissions to check in AI access is not one permission, it is five.
- A governed workspace run for the client. Where the client wants AI to act on their systems, stand up a workspace scoped to that client’s own tenant, with identity, approval and logging configured before the first task runs. This is what makes the next two shapes possible.
- Quarterly evidence review. A recurring service where the MSP or vCISO pulls the records from the quarter, checks them against the register, and hands the client a pack they can give to their own auditor, insurer or board.
The first two shapes suit a client who is not ready to hand over administration. The last two suit a client who wants the MSP to run the thing. Sell them as separate line items.
How do you keep clients separated inside one governed AI practice?
Tenant separation matters most when several clients want the same workspace product. Each client gets its own tenant, its own administrator identity, and its own log store from day one. No shared credential should reach into two clients’ data at once, and no search or model context should cross between them. The same five-question test we use to check a vendor’s sovereignty claim applies per client here: who holds the keys, which model route, whose logs. See what is a sovereign AI platform for the full list.
Where your own staff need access to fix something in a client’s tenant, route it through a support ticket tied to that client, the same way you would document access to their backup console. If a client asks who at your firm could see their AI logs last month, you should be able to point to the ticket record that answers it.
What evidence pack do you hand a client every quarter?
An auditor samples what actually happened. A policy only describes what should. See how to prove AI controls to an auditor for the reasoning behind this table, which sets out what I hand a client each quarter and where each item comes from.
| Deliverable | What it shows | Source record |
|---|---|---|
| AI use register, current | Which tools are approved, their data route and who owns each one | Config export from each tool’s admin console, checked against the register |
| Access and permission review | Who holds AI-related access this quarter and what scope each grant covers | Identity provider export for the period under review |
| Approval log sample | A sample of proposals the AI put forward, who approved or rejected them, and when | The governed workspace’s action log |
| Exception and shadow-AI findings | Any AI use found outside the register, and what was done about it | Network or endpoint findings, with the follow-up action recorded |
| Framework mapping note | Which of the client’s own control objectives each record above supports | A mapping note the vCISO maintains and reviews each quarter |
The mapping note is where a framework earns its place. It is not itself evidence. The four records above it are.
How do you onboard the first client?
- Inventory AI use across the client’s staff and vendor stack, sanctioned and shadow, before writing anything down as policy.
- Draft the use policy and register with the client’s own leadership, and get a named person to sign off the scope.
- Stand up tenant-isolated identity for any workspace the MSP will administer, with a distinct administrator account per client.
- Pick one low-stakes workflow and run the approval and rejection test on it before anything wider goes live.
- Set the quarterly evidence cadence, name the log store’s owner, and put both in the services agreement.
- Deliver the first evidence pack, walk the client through it, and calendar the next one.
Step four is worth doing even when the client is impatient to start. A workflow that has never been rejected in front of the client has not actually been tested.
Where does liability sit when an MSP or vCISO oversees a client’s AI use?
Plainly: contracts and counsel decide this. No framework does, and neither does this article. Managing a client’s AI use produces more documentation than leaving it alone would, and that documentation can cut either way in a dispute. Put the division of responsibility in the services agreement before the first workspace goes live, and have both sides’ counsel read it.
Frameworks help with structure. They do not settle liability. NIST’s AI Risk Management Framework sets out Govern, Map, Measure and Manage functions an MSP can use to organise a practice. ISO/IEC 42001 gives a certifiable structure for the management system underneath it. Neither one assigns fault when something goes wrong. That question stays with the contract.
Questions buyers ask.
Should the MSP or the client hold the AI use policy?
The client should own it, with the MSP or vCISO drafting and maintaining it under the services agreement. Ownership needs to sit with the party whose staff the policy governs and whose regulator or insurer will eventually ask to see it.
Do I need a separate governed workspace for every client, or can I run one shared instance?
Run separate tenants. A shared instance with only logical separation is harder to prove clean if a client asks who could reach their data. Separate tenants, separate admin identities and separate log stores make the tenant-separation question answerable without an investigation.
Is a signed AI use policy enough to satisfy a client’s auditor?
No. A policy is a claim about intended behaviour. An auditor samples what actually happened, so the policy needs the register, the access review and the approval log behind it before it will hold up. Treat the policy as a cover page for that evidence, nothing more.
How is this different from simply enabling a vendor’s built-in AI feature for a client?
Switching on a feature is a configuration change. It becomes a service once you add an identity scoped to that feature, an approval path for anything it can act on, and a quarterly record, whichever vendor’s AI sits underneath.
This is the same evidence discipline behind the twelve tests in the Agentic AI Procurement Handbook, and it is the practice I would build if I were running an MSP’s AI offering today. Handvantage builds Vantage Workspace, a self-hosted AI workspace built so that AI actions go through human approval and leave a record, so weigh my view accordingly. This is an evaluation method. It is not legal advice, and your own counsel should review the liability terms in any services agreement before you sign one.
Josh Olayemi · Founder, Handvantage · September 2026 · About the author
