iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AI shared responsibility is already an MSP problem—not because every managed service provider automatically assumes a legal duty for a client’s AI, but because clients still have substantial work after subscribing to an AI service. They must control identities, data, policies, users, applications, agents and the way outputs are reviewed. An MSP can assess and operate many of those controls when its contract, skills and risk appetite support the work.
The practical answer is to map responsibility by deployment model, then turn the customer-side tasks into clearly scoped services. Treat Microsoft’s model as governance guidance rather than a contract or legal opinion, and use NIST’s AI Risk Management Framework as voluntary guidance, not a blanket requirement.
What “shared responsibility” means for an MSP
Shared responsibility divides AI security and governance work between the provider that supplies a service and the customer that configures and uses it. The provider may run the underlying infrastructure, model or application and embed safety features. The customer still decides who can use the system, what data enters it, which integrations are enabled, what employees are allowed to do and whether an output is safe to act on.
That division changes with the service model. A ready-made software service leaves the provider operating more layers. A platform service gives the customer more freedom to build applications and connectors, which also creates more customer-side security work. Infrastructure or a custom model leaves the customer operating most of the stack.
#1 Best Overall
For an MSP, the important distinction is between work a client retains and work the MSP has agreed to perform. Microsoft describes its responsibility model as illustrative governance guidance. It does not, by itself, create a legal obligation or alter a service contract. Any statement about an MSP’s duty must come from the signed agreement and applicable law.
How responsibility changes across SaaS, PaaS and custom deployments
| Deployment | Provider generally operates | Customer still needs to handle | Where an MSP may fit |
|---|---|---|---|
| SaaS AI | More of the application and platform stack, including provider-embedded safety capabilities. | Access configuration, data and user governance, acceptable-use rules, staff training, and review of uses and outputs. | Service inventory, identity and access configuration, data-permission reviews, guardrail settings and user guidance, if contracted. |
| PaaS AI | Managed platform capabilities and, in some cases, safety controls. | Custom applications, integrations, data grounding, plugins, connectors and application-level safeguards. | Implementation, control management and monitoring, with written boundaries among the platform provider, client and MSP. |
| IaaS or custom | Infrastructure; far fewer application or model controls. | Design, configuration, operation, monitoring and security for substantially more of the stack. | Advisory and engineering work only when the MSP has the expertise, staffing and explicit scope to operate those controls. |
This is a high-level allocation, not a universal responsibility matrix. A provider’s terms, product configuration and the client’s architecture can move a control from one party to another. Document the actual arrangement for every service rather than copying a generic template.
Three layers an MSP should map
Platform layer
The platform layer covers hosting, model infrastructure, service availability and provider-operated security capabilities. In SaaS, the provider handles most of this layer. In PaaS and custom environments, the customer may configure networking, secrets, runtime permissions, model endpoints and logging. An MSP should record which party patches, monitors and responds to incidents at each boundary.
Application layer
Application controls include prompts and system instructions, retrieval or grounding data, plugins, APIs, connectors, filters, approval workflows and business logic. Selecting a model does not secure these components. A connector that lets an assistant read a file store or update a ticketing system can introduce a larger attack surface than the original chat interface.
Usage layer
Usage covers people, processes and decisions: who is authorized, what information may be entered, how outputs are checked, and what happens when an answer is wrong. The client owns these operational choices unless the MSP has taken on a defined role such as policy administration, user training or managed review.
Why SaaS still leaves significant client work
A subscription can reduce infrastructure administration without eliminating governance. Before enabling an AI service, a client should identify its users and groups, classify the data they can access, define acceptable and prohibited uses, and decide which outputs require human verification. Training should explain confidential-data handling, prompt injection, unsupported answers and escalation paths.
Access should follow least privilege. An employee who can ask an AI tool to summarize a repository should not automatically gain rights to every repository. Review sharing defaults, external collaboration, retention, audit logs and administrator roles. Repeat the review when the provider adds a connector, changes a model or introduces a new agent feature.
An MSP can provide this work as an AI governance assessment, a recurring access review or a managed policy service. The statement of work should specify which systems are inventoried, which settings are changed, how often reviews occur and who approves exceptions.
Agents make the responsibility boundary larger
A prompt-and-response tool mainly presents content for a person to evaluate. An agent can call tools, read and write data, remember information, orchestrate other services and act under a delegated identity. That ability creates real-world effects and additional attack paths.
Risks that need explicit treatment
- Hijacking: malicious instructions in a document, web page or message can redirect an agent from its intended task.
- Sensitive-data leakage: an agent may expose information through a response, connector, log or memory store.
- Dependency compromise: a plugin, model, package or external API can become the route into an otherwise protected environment.
- Agent sprawl: teams can create undocumented agents with unclear owners, overlapping permissions and no retirement process.
Controls an MSP can help operate
- Build an inventory. Record every agent’s purpose, owner, platform, model and tool connections, data sources, delegated identity, retention settings and business criticality.
- Use distinct identities. Give each agent an auditable identity rather than sharing a human account. Grant only the permissions needed for its defined task.
- Set action boundaries. Specify which actions are read-only, which require human approval and which are prohibited. Include limits on recipients, transaction values, data categories and execution frequency.
- Provide a stop mechanism. Users and administrators need a documented way to pause an agent, revoke its credentials and disable a connector during an incident.
- Log enough for investigation. Capture prompts or triggering events where appropriate, tool calls, approvals, data-access events, model and tool versions, errors and configuration changes.
- Review memory and retention. Define what an agent may remember, how long it is retained, who can retrieve it and how it is deleted.
- Assign accountability. Name a business owner and a technical owner. Neither the agent nor an unnamed department can approve its own exceptions.
These are risk-management practices drawn from vendor and standards guidance, not a universal legal checklist. The required controls depend on the client’s data, sector, jurisdictions and contracts.
Turning the map into an MSP service catalog
The most defensible opportunity is to sell clearly bounded outcomes rather than a vague promise to “manage AI.” Start with an assessment that produces an inventory, a responsibility matrix, a risk-ranked remediation plan and an owner for every unresolved control.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →AI usage policy and training
Help the client define approved tools, prohibited data, review requirements, records retention, incident reporting and exceptions. Deliver role-specific training for administrators, developers, general users and managers. Include examples of confidential information, unsafe automation and when a human must make the final decision.
Identity and data-access management
Configure groups, single sign-on, privileged roles, service identities and conditional access where the platform supports them. Review which AI applications can search which repositories. Remove stale accounts and connectors, and produce an evidence report showing approvals and changes.
Application and connector oversight
For PaaS or custom work, review system instructions, retrieval sources, plugin permissions, secrets, input validation, output filtering, rate limits and failure handling. Separate development, test and production environments. Establish a change process for models, prompts, tools and data sources.
Agent inventory and access review
Offer a recurring review of agent owners, permissions, tools, memory, logs and approval gates. Tie critical agents to incident-response procedures and test the stop mechanism. Retire agents that no longer have a business owner or current purpose.
Monitoring and incident response
Define which events are monitored, who receives alerts and how suspected prompt injection, data leakage or unauthorized actions are contained. The plan should identify the provider’s escalation route as well as the client’s and MSP’s responsibilities. Do not promise detection or response capabilities the chosen platform cannot produce.
Choosing a deployment model without overcommitting
Microsoft recommends starting with SaaS when it meets the need, moving to PaaS when off-the-shelf capabilities do not fit, and reserving custom model-building for organizations with deep relevant expertise. That is Microsoft’s recommendation, not a universal rule. The decision should reflect data sensitivity, required customization, integration complexity, latency, budget and the client’s ability to operate controls.
| Decision question | SaaS | PaaS | Custom or IaaS |
|---|---|---|---|
| How much customization is required? | Use the provider’s packaged workflows and configuration. | Build tailored applications, integrations and grounding. | Design and operate most application and model components. |
| Who owns application safeguards? | Provider supplies more defaults; client still configures use and access. | Client and its implementers must secure custom logic, plugins and data flows. | Client owns substantially more design, security and operations. |
| MSP expertise and scope | Governance, identity, data access and user support may be sufficient. | Requires application, integration and monitoring capability. | Requires deep engineering, security operations and an explicit liability boundary. |
More customization is not automatically better. It increases the number of components that need owners, testing, monitoring and change control. An MSP should decline or subcontract work outside its competence instead of accepting an undefined obligation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Contract and liability questions to settle before delivery
- Which AI services, tenants, agents and connectors are in scope?
- Is the MSP configuring controls, operating them continuously, advising the client, or all three?
- Who approves acceptable-use policy, data classifications, exceptions and high-impact actions?
- What logs, alerts and response times are included, and what depends on provider capabilities?
- Who owns model, prompt, connector and agent changes?
- What happens when a provider changes a feature, terms, model or retention behavior?
- Are regulated decisions, confidential data or customer-facing actions excluded unless separately assessed?
- What evidence will the MSP retain to demonstrate reviews, approvals and remediation?
Use the service agreement to assign these duties. A marketing page or a generic shared-responsibility diagram cannot replace contractual language, technical documentation or applicable legal advice.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsHow NIST guidance fits
NIST describes the AI Risk Management Framework as intended for voluntary use. Its framework page dates AI RMF 1.0 to January 26, 2023, says the framework is being revised, and dates the Generative AI Profile to July 26, 2024. An MSP can use the framework’s risk-management concepts to structure assessments and evidence, but should not present it as a blanket legal requirement for MSPs.
Best Value
Use the framework as a common vocabulary for governing, mapping, measuring and managing risk. Then translate those concepts into the client’s actual services, policies, owners and records. A framework reference is useful only when it leads to a concrete decision, such as revoking an unnecessary agent permission or requiring approval before an automated payment.
A practical 90-day starting plan
- Days 1–30: discover. Interview business and technical owners, inventory AI services and agents, identify data sources and delegated identities, and document provider, client and MSP boundaries.
- Days 31–60: control. Remove unused access, set acceptable-use rules, classify approved data, establish human-approval gates, configure logging and create an incident stop procedure.
- Days 61–90: operate. Run a review cycle, test an agent shutdown, verify logs and approvals, train users, report unresolved risks and agree on recurring review frequency.
After the initial cycle, schedule reviews around material changes rather than a calendar alone: a new connector, model, agent capability, data source, administrator or business process should trigger reassessment.
The bottom line for MSP leaders
AI shared responsibility is an operational reality for clients, and therefore a credible MSP service opportunity. The opportunity is not an automatic legal mandate and not a license to claim ownership of every AI risk. It is a reason to inventory services, separate platform, application and usage controls, secure agent identities and tools, and put each duty in writing.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteMicrosoft’s 2025 Responsible AI Transparency Report captures the challenge: “While we embrace this concept of shared responsibility at Microsoft, we also recognize that pinning down how responsibilities fit together is complex, especially in a fast-changing AI ecosystem.” An MSP that makes those boundaries visible—and then delivers only the controls it is qualified and contracted to manage—can turn that complexity into dependable client operations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
