How should SMBs and MSPs divide responsibility for securing AI use and reducing shadow AI risk?

MSPs should lead the operating model, technical controls, and client guidance, while SMBs should enforce usage policies and approve risk decisions. The partnership works best when the MSP delivers readiness assessments, monitoring, and response playbooks, and the client owns business context, data handling rules, and staff behavior. Clear accountability matters because AI risks cross identity, device, and SaaS boundaries.

Dividing AI security duties between the MSP and the SMB

For SMBs and MSPs, the cleanest split is to treat AI use like a shared service with different owners for operations and business judgement. The MSP should set up the technical guardrails, monitoring, and response capability; the SMB should decide which AI uses are acceptable, what data may be exposed, and who can approve exceptions. That division matters because shadow ai usually appears when staff adopt tools faster than policy, visibility, or support processes can keep up.

One useful way to think about the partnership is that the MSP manages the control plane while the SMB manages the business risk. The MSP can standardise access, logging, endpoint checks, SaaS discovery, and alerting around AI-enabled services. The SMB can define data handling rules, acceptable use, and approval thresholds for new use cases. A practical reference point is the NIST AI Risk Management Framework, which is useful here because AI governance only works when roles for risk, oversight, and accountability are explicit rather than implied. In practice, many organisations discover that role confusion is the first control failure, not the AI tool itself.

That split also helps avoid a common mistake: asking the MSP to “own AI risk” without giving them authority over business data decisions, or asking the SMB to approve risk without any telemetry or technical enforcement. Neither model works well. A better arrangement is a documented operating model with named decision makers, escalation paths, and a shared inventory of approved AI services. If the SMB and MSP do not agree on where the approval line sits, shadow AI will fill the gap.

What each side should actually control day to day

Day to day, the MSP should concentrate on discovery, baseline controls, and response. That means identifying AI services in use, detecting unsanctioned tools, applying device and browser controls where possible, and making sure activity logs are retained for investigation. The SMB should control the business-facing decisions: which data classes may be used, whether customers or regulated information can enter an AI tool, and when a use case needs review by legal, privacy, or leadership.

The MSP should maintain an inventory of approved and observed AI services, then review it regularly with the client.
The SMB should define a policy for acceptable AI use that is specific enough to cover staff behaviour, not just generic principles.
Both parties should agree on what triggers escalation, such as sensitive data entry, unapproved integrations, or new AI tools appearing outside the approved stack.
The MSP should help test monitoring and response playbooks, but the SMB should own the final business decision to accept, reject, or constrain a use case.

This is where the operational value becomes clear. Shadow AI is rarely just a policy issue; it is usually a visibility issue, an access issue, and a training issue at the same time. Guidance from the NIST AI Risk Management Framework is helpful because it reinforces that risk treatment should be tied to mapped roles, not assumed by default. The model breaks down when the MSP has logs but no business context, or when the SMB has policy but no control over the tools being used.

The practical boundary is simple: the MSP can help secure the environment, but it cannot decide what the business is allowed to say to an AI system.

Where the shared model breaks down, and how to keep it workable

Tighter control often increases friction, so SMBs and MSPs need to balance usability against containment. That tradeoff becomes visible when users shift to personal accounts, unapproved browser extensions, or consumer AI services because the sanctioned path is too slow or too restrictive. When that happens, the control design is usually too rigid, too complex, or too detached from real work patterns.

There is also a governance edge case where the MSP supports multiple clients with similar tooling, but each SMB has different tolerance for data exposure, retention, and auditability. One client may permit limited public-model use for drafting, while another may prohibit any external prompts containing customer data. Those differences matter, so a shared MSP standard cannot replace client-specific policy.

Another common edge case is regulated or high-trust data. In those environments, the MSP should not be left to infer acceptable use from general security language. The SMB must define the boundary explicitly, and the MSP should convert that boundary into enforceable settings, monitoring, and escalation. For organisations that want a broader control baseline, the NIST Cybersecurity Framework 2.0 is useful as a general governance reference, but it needs AI-specific policy detail to be effective here.

If the partnership cannot answer who approves use, who blocks exposure, and who investigates exceptions, the shared model is too vague to control shadow AI.

Risk and Threat Considerations

Shadow AI creates a material exposure because staff may place sensitive, regulated, or proprietary data into tools that the organisation has not vetted. The main risk is not only data leakage; it is also loss of visibility over where that data travels, how prompts are retained, and whether AI outputs are reused in other systems without review.

Failure mechanism: Risk materialises when the SMB assumes the MSP is monitoring all AI use, while the MSP assumes the client has approved the business context. That gap allows unsanctioned tools, unmanaged browser use, and unreviewed integrations to bypass normal controls. It also weakens incident response, because neither party may have complete authority over discovery, containment, or evidence collection.

Impact: The result can be confidential data exposure, policy breaches, audit findings, and inconsistent decisions about acceptable AI use. In more serious cases, the organisation may lose control over which business processes depend on AI and may be unable to prove that risky use was detected, reviewed, or stopped.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	AI risk governance needs explicit role and accountability split.
Recommendation — Assign clear AI governance ownership, approval paths, and escalation duties across MSP and SMB.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Shared AI use is a governance and organisational risk-management issue.
	DE.CM-01 — Asset and Service Monitoring	Shadow AI requires discovery and monitoring of unsanctioned services and usage.
Recommendation — Define and document the shared risk strategy for approved AI use and shadow AI exceptions. Monitor for AI services, browser use, and integrations that fall outside the approved stack.
CIS Controls v8	CIS Control 15 — Service Provider Management	MSPs are third parties whose responsibilities must be explicitly governed and verified.
Recommendation — Set measurable security responsibilities and review evidence for the MSP's AI control coverage.
ISO/IEC 42001:2023	4.2 — Understanding the needs and expectations of interested parties	AI governance must reflect differing SMB and MSP stakeholder expectations.
Recommendation — Align AI policy, approvals, and control boundaries to each client's business expectations and constraints.

Practitioner Guidance

What to prioritise: Start with a written responsibility split that separates technical enforcement from business approval. The important question is not who “owns AI” in general, but who can stop a risky tool, who can approve a new use case, and who receives alerts when staff step outside policy.

What to verify: Confirm that the MSP can actually see the AI services in use and that the SMB can name the data classes that are forbidden, restricted, or approval-only. If either side cannot evidence its part, the operating model is aspirational rather than operational.

Common mistake: Do not treat a generic acceptable-use policy as sufficient control. Shadow AI usually exploits the gap between policy language and the practical reality of browser access, personal accounts, and fast-moving SaaS adoption.

Practitioner takeaway: The strongest SMB-MSP model is the one where technical visibility, policy authority, and exception approval are deliberately split, then rejoined through a shared escalation path.