MSPs should help clients govern AI adoption through an explicitly scoped service: the client retains authority over business decisions and risk tolerance, while the MSP delivers only the advice, configuration, monitoring, and response work the parties agree to. A useful starting point is NIST’s voluntary AI Risk Management Framework (AI RMF) and its Generative AI Profile, translated into client-specific approvals, data boundaries, controls, and contract terms.
Who owns decisions when a client uses AI?
The client’s leaders remain accountable for deciding why an AI use case is acceptable, what risks the business will tolerate, and whether the resulting business process is appropriate. An MSP may assess technical risks and operate agreed controls, but access administration or tool configuration does not transfer the client’s business approval or risk-acceptance decisions.
As an Amazon Associate I earn from qualifying purchases.
CISA’s guidance for MSP customers says the division of responsibility depends on the parties’ circumstances and should be jointly agreed and clearly reflected in their relationship. Outsourcing IT services does not remove executives’ risk-management responsibilities. The guidance concerns MSP/customer cybersecurity and risk allocation, not a special AI legal duty. CISA: Risk Considerations for Managed Service Provider Customers
Free tools Windows power users keep installed
One-click scans. No signup required.
For each use case, the client should name an accountable business owner and involve legal, privacy, security, procurement, and affected operational teams as appropriate. The MSP can advise on feasibility and controls; the client decides whether the business purpose and residual risk are acceptable.
Use NIST as a scaffold, not a compliance promise
NIST’s AI RMF 1.0 organizes risk work into four functions: Govern, Map, Measure, and Manage. Its playbook suggests actions organizations can adapt; it is not a mandatory control set, certification, or guarantee of compliance. NIST states that public- and private-sector organizations are not required to use the framework. NIST AI Risk Management Framework NIST AI RMF FAQ
NIST’s Generative AI Profile, AI 600-1, published July 26, 2024, complements AI RMF 1.0. It highlights that generative AI can call for additional oversight, human review, tracking, documentation, and management attention. It also recognizes that organizations can restrict applications that cause harm, exceed risk tolerances, or conflict with organizational values. NIST AI 600-1: Generative Artificial Intelligence Profile
Rank #2
NIST’s AI RMF page says version 1.0 is being revised as part of the White House AI Action Plan. Check the current NIST page when adopting the framework; do not treat a planned revision as a successor already in force. NIST IR 8596, the Cyber AI Profile, was listed as an initial preliminary draft published December 16, 2025, with comments closed January 30, 2026. It is a draft resource, not final authority. NIST IR 8596, Initial Preliminary Draft
Build an inventory before approving use
Maintain a client-specific record of AI tools, embedded AI features, integrations, and material use cases. Generative AI may appear in different products and workflows, and the context of use changes the risks. Record enough information to identify who owns each use, what it touches, and whether it is permitted.
Rank #3
- Business purpose and accountable client owner
- Tool, provider, embedded feature, and relevant integrations
- Data categories involved, including personal, confidential, regulated, customer, or third-party information
- Users, access arrangements, and recipients of AI outputs
- Approval status: approved, restricted, or prohibited
Keep the inventory current as employees adopt new tools or existing products add AI features. An inventory is an operational record, not proof that every use is safe.
Assess each use case in context
Before deployment, the client owner and MSP should examine the use case together. NIST’s framework and GenAI Profile support context-sensitive risk assessment, risk tiering, human review, documentation, and pre-deployment evaluation; the questions below are a practical adaptation for an MSP-client relationship, not an official NIST checklist.
- Define the work and consequence. What decision, communication, or work product will AI influence? Who is affected if an output is wrong, misleading, biased, or unavailable?
- Set the review boundary. Who checks outputs, what expertise is required, and which outputs must never be used without human approval? Decide whether the tool is assisting a person or making a consequential decision in practice.
- Identify data exposure. Determine whether users may enter personal, regulated, confidential, customer, or third-party information. Check the provider’s applicable terms for input retention, model-improvement use, subprocessors, and data handling; do not assume those terms from a product label.
- Assess access and evidence. Identify available identity, access, configuration, logging, retention, and monitoring controls. Assign who enables them, checks them, and can provide evidence.
- Test likely failure modes. Define proportionate tests and review before production use, considering the intended task and plausible harms rather than treating a successful demonstration as sufficient.
- Set approval and reapproval triggers. Specify what changes—such as a new data type, model, integration, use, or provider term—require reassessment, and what incidents require suspension or escalation.
Third-party AI introduces questions beyond the client’s own configuration. NIST identifies potential intellectual-property, privacy, and information-security risks, and points to transparency, risk-based controls, and service-level or assurance information as ways to inform vendor risk management. NIST AI 600-1 PDF
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Write the responsibility split into the agreement
The service agreement and operating procedures should allocate concrete tasks among the client, MSP, and AI provider. CISA advises clear and transparent definition of service scope and roles, including incident contingencies. FTC business guidance recommends specifying vendor security and data handling in writing, verifying compliance, and keeping controls current. These sources do not prescribe AI contract wording; the provisions below are practical applications of their guidance. CISA MSP customer guidance FTC: Protecting Personal Information
- Scope and exclusions: Identify covered AI tools, use cases, environments, and deliverables, as well as excluded services and dependencies.
- Approval authority: State who approves tools and use cases, who can restrict or suspend them, and which client decisions the MSP cannot make on the client’s behalf.
- Identity and configuration: Assign responsibility for access, configuration, security settings, changes, and periodic checks.
- Data boundaries: Specify permitted and prohibited data, retention and deletion expectations, handling of logs and outputs, and who verifies relevant provider terms.
- Monitoring and evidence: Define what is monitored, who reviews alerts, what records are retained, and what reporting the MSP provides.
- People and process: Allocate responsibility for employee guidance, human review, and escalation of unapproved or harmful use.
- Incident handling: Set reporting channels, notification timing, response roles, decision authority, and recovery responsibilities. Include relevant AI events such as exposure of sensitive input or a harmful output affecting operations.
- Change and exit: Define review when tools, integrations, data, or provider terms change, plus transition, access removal, and data disposition at service termination.
Avoid blanket promises that the MSP will “make the client AI compliant.” Describe deliverables, assumptions, exclusions, client dependencies, and the evidence each party will provide. Contract language should be reviewed for the actual services, client sector, geography, and applicable law; the framework itself does not settle those legal questions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Operate governance as an ongoing service
Approval is not a one-time event. Use the responsibility matrix to make routine operation actionable: who receives alerts, how staff report an unapproved tool or harmful output, who can pause a use, and how decisions and changes are recorded. NIST’s GenAI Profile calls for attention to monitoring, change management, data protection, incident response, and decommissioning, including tracking errors, near misses, and negative impacts.
Reassess a use case when its purpose, users, data, model, integration, provider terms, or consequences change. Review whether the assigned controls still work and whether the client’s risk tolerance or operational needs have shifted. If a risk exceeds the client’s stated tolerance, the client may restrict or stop the application rather than treating deployment as irreversible.
Choose governance effort by risk, not by a universal score
NIST, CISA, and FTC guidance supports tailoring controls to context, risk, resources, and contract scope; it does not provide a universal MSP scoring system. A low-impact internal drafting aid and an AI-supported decision affecting customers should not automatically receive identical review. For each use case, compare:
- Who has decision authority: client, MSP, or shared operational responsibility
- Which tools, embedded features, and uses fall within the approved scope
- Data sensitivity and consequences of an error
- Required human review and approval
- Access, logging, and monitoring controls
- Incident notification, response, and recovery duties
- Evidence, review cadence, and the cost and effort of the controls
For legal or regulatory questions, obtain advice applicable to the client’s jurisdiction and sector; this U.S.-oriented guidance does not establish a universal legal obligation to use the AI RMF. NIST reports that more than 240 organizations contributed during the framework’s 18-month development period, a fact about how it was developed—not evidence of its effectiveness or adoption.
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.
