Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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

MSPs should help clients govern AI within a clearly agreed service scope—not make business-risk decisions on their behalf. The client retains authority over which uses are acceptable; the MSP can help inventory tools, assess technical risks, configure safeguards, monitor agreed controls, and handle incidents under a written division of responsibilities.

For a practical structure, use NIST’s voluntary AI Risk Management Framework (AI RMF) and its Generative AI Profile, then translate the relevant work into the MSP/customer agreement and operating procedures. This is a U.S.-oriented governance approach, not a universal legal mandate or a promise of compliance.

Who owns AI decisions when a client uses an MSP?

The client’s leadership owns business decisions and risk tolerance. An MSP may administer systems and recommend controls, but technical access does not transfer the client’s responsibility to decide whether a use case is appropriate or to accept its business consequences.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

CISA’s Risk Considerations for Managed Service Provider Customers says that outsourcing IT services does not remove executive risk-management responsibilities. CISA also emphasizes that the division of responsibilities depends on the parties’ circumstances and should be agreed between them. Put that split in the contract and make it operational in procedures, rather than assuming that either party’s general terms settle every AI question.

  • Client: names an accountable executive or business owner for each use case, sets acceptable risk, approves or rejects use, and supplies relevant business, legal, privacy, and sector requirements.
  • MSP: performs only the advisory, configuration, security, monitoring, and response work included in scope; identifies dependencies and limitations; and escalates issues through agreed channels.
  • AI provider: supplies the service and its terms, technical controls, and relevant security or assurance information. The client and MSP should verify applicable provider commitments rather than assume how inputs or outputs are treated.

Involve legal, privacy, security, procurement, and affected operational teams as the use case warrants. The MSP can facilitate that work, but the client should retain the approval and risk-acceptance decisions.

Is NIST’s AI Risk Management Framework mandatory?

No. NIST describes the AI RMF as voluntary; it is a framework, not a law, certification, or guarantee of compliance. NIST’s FAQ says public- and private-sector organizations are not required to use it. It is intended to help organizations of different sizes and sectors organize AI risk work.

AI RMF 1.0 groups that work into four functions: Govern, Map, Measure, and Manage. Its playbook offers suggested actions, not mandatory controls. NIST’s official AI Risk Management Framework page says version 1.0 is being revised as part of the White House AI Action Plan; check that page for current status before adopting a version as the basis for policy.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For generative AI, NIST AI 600-1, the Generative AI Profile, was published July 26, 2024, as a cross-sector companion to AI RMF 1.0. It highlights that generative AI can call for additional oversight, human review, tracking, documentation, and management attention. Its guidance can help an MSP and client tailor controls, but it does not prescribe a universal MSP checklist.

NIST IR 8596, the Cyber AI Profile, was listed as an initial preliminary draft published December 16, 2025, with comments closed January 30, 2026. Treat it as a draft resource rather than final authority. Its draft focus areas are securing AI system components, AI-enabled cyber defense, and thwarting AI-enabled cyber attacks.

How should an MSP and client assess an AI use case?

Use a repeatable, client-specific process before production use and whenever a material change occurs. NIST’s framework and GenAI Profile support risk-based, context-sensitive assessment; the steps below adapt that guidance to an MSP/client operating relationship.

1. Set the client’s authority and risk tolerance

Assign a client business owner who can explain the purpose of the proposed use and decide whether its risks are acceptable. Identify the people who must advise or approve, based on the context: for example, security, privacy, legal, procurement, or the team whose work will be affected. Record who has final approval and who may pause or stop the use.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

2. Inventory tools, features, and actual uses

Maintain a client-specific inventory that includes standalone AI services, AI features embedded in existing software, integrations, and material use cases. For each entry, record:

  • Business purpose and accountable client owner.
  • Tool, vendor, and relevant service or model, where known.
  • Data categories used or exposed, user groups, integrations, and recipients of outputs.
  • Approval status: approved, restricted, or prohibited, with any conditions.

Inventory use, not just product names: the same tool can create different risks depending on its task, data, users, and the consequences of its output.

3. Assess context, data, and consequences

Before recommending approval, work through questions such as:

  • What decision or work product will AI influence, and who checks the output before it is relied on?
  • Could users enter confidential, personal, regulated, customer, or third-party information?
  • Do the provider’s terms say whether inputs are retained, used to improve models, or shared with another provider? Verify the terms for the specific service; do not infer data treatment from a product label.
  • What could go wrong, who could be affected, and what would the business impact be?
  • What access, logging, retention, and security controls are available? Who configures and verifies each one?
  • What testing or human review is needed before production, and which changes or incidents require renewed approval?

NIST identifies third-party AI risks that can include intellectual-property, privacy, and information-security concerns. Its guidance supports seeking transparency, applying controls proportionate to risk, and considering service-level or assurance information. Those measures do not eliminate the need to examine the particular vendor, terms, data, and use.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

4. Choose safeguards and document approval

Match safeguards to the use case and the client’s risk tolerance. Depending on the service, these may include limiting permitted data, restricting access, requiring human review, testing outputs, retaining appropriate records, or prohibiting a use that exceeds the client’s stated tolerance. NIST’s GenAI Profile says organizations can restrict applications that cause harm, exceed stated risk tolerances, or conflict with their tolerances or values.

Record the decision, its owner, approved scope, conditions, responsible parties, and review triggers. A risk tier can make the process easier to operate, but NIST does not supply a universal scoring system for MSPs and their clients. Avoid presenting an internally devised score as an official NIST rating.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What should the MSP agreement and operating procedures specify?

Write down the actual AI-related services, boundaries, and dependencies. CISA recommends clarity and transparency about MSP/customer responsibilities, service scope, and incident contingencies. The FTC likewise advises businesses to specify vendor security and data handling in writing, verify compliance, and keep controls current. These sources provide general vendor and cybersecurity guidance; they do not prescribe AI contract clauses verbatim.

For each task, assign the client, MSP, AI provider, or a shared owner. The exact allocation should fit the services being purchased.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Agreement or procedure area What to make explicit
Scope and exclusions Which AI tools, features, environments, use cases, and users are covered; what the MSP will deliver; what is excluded; and what depends on the client or AI provider.
Approval and risk acceptance Who approves tools and use cases, who sets risk tolerance, who can authorize exceptions, and who may suspend a use.
Identity and configuration Who manages accounts, access, integrations, settings, and security configurations, and who checks that agreed settings remain in place.
Data handling Permitted and prohibited data, applicable retention or deletion expectations, and how the parties verify relevant provider terms and settings.
Monitoring and evidence Who reviews available alerts and logs, what reporting the MSP provides, which records are retained, and what the client must supply or review.
Changes and maintenance How relevant changes to tools, models, integrations, configurations, or provider terms are identified, assessed, and escalated; assign patching or vendor-change duties where applicable.
Incidents and recovery How a party reports suspected misuse, harmful output, data exposure, or control failure; notification channels and timing; response roles; and backup or recovery duties where relevant.
Employee guidance Who communicates the client’s approved-use rules, restrictions, escalation route, and training expectations to employees.
Service change or termination How access is removed, data and records are handled, integrations are disconnected, and any agreed deletion or transition duties are completed.

Use a responsibility matrix alongside the agreement so staff know who acts in practice. Avoid blanket promises that the MSP will “make the client AI compliant.” Specify deliverables, assumptions, exclusions, client decisions, and provider dependencies. Contract terms should be reviewed against the services, sector, geography, and applicable law; general guidance cannot determine a client’s legal obligations.

How should AI governance operate after approval?

Approval is not permanent if the system or use changes. Define who reviews alerts, where employees report unapproved tools or harmful outputs, what triggers escalation, and how decisions and changes are tracked. NIST’s GenAI Profile calls for tracking errors, near misses, and negative impacts, as well as incident-response processes and attention to change management, monitoring, data protection, and decommissioning.

Reassess when the use, data, model, integrations, user group, vendor terms, or available controls change—or when an incident or near miss reveals that the original assessment missed a risk. If the use is no longer acceptable, the client should be able to restrict or stop it, with the MSP carrying out only the actions assigned in the agreed scope.

This approach keeps oversight tied to the actual use case: the client determines whether the business use is acceptable, while the MSP delivers and reports on the technical and operational work it has agreed to perform.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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.