Quick Answer: There is no single U.S. law governing how ITSPs use AI. Existing rules—the FTC Act, HIPAA GLBA, and upcoming state laws in California, Colorado and Texas—offer fragments of guidance, not a complete framework. At ChannelCon 2026, attorney Brad Gross told attendees the real risk isn't AI itself. It's operating without a policy while customers adopt AI faster than MSPs can govern it. He laid out five risks every MSP faces without a policy, and five questions every policy needs to answer.
At his ChannelCon 2026 session, "The Ultimate AI Rules for MSPs: Policies, People and Proof," Brad Gross, president at the Law Office of Bradley Gross, PA, opened with a line that got the room's attention: When it comes to AI rules for MSPs, there aren't any.
He wasn't being flip. Gross walked through the patchwork that exists today. The NIST AI Risk Management Framework offers guidance, not enforceable rules. The FTC Act prohibits deceptive practices but doesn't set AI-specific standards. HIPAA, the Gramm-Leach-Bliley Act and COPPA predate generative AI and don't directly address it. A handful of states have moved further: California restricts automated decision-making tools; Colorado requires AI developers to disclose how their systems work and Texas prohibits AI solutions built to cause harm. Add it up, and ITSPs are left without a clear rulebook. Gross’ point: That gap doesn't make the AI question any less urgent.
Why the Gap Is a Problem
Customer demand is moving faster than most ITSPs can govern it. Clients are adopting AI tools on their own timeline; vendors are building AI into their platforms and shadow IT is spreading inside client organizations. ITSPs are left governing at policy speed while their customers implement at market speed.
Clients expect their ITSP to advise them on AI and to have a system in place for governing it. The real risk isn't AI adoption itself—it's clients adopting AI without any guardrails around it. Without a policy, an ITSP can't manage those expectations or answer for what happens when something goes wrong.
The 5 Risks of Operating Without a Policy
Gross outlined five risks that show up when an ITSP has no AI governance in place:
- Privacy: Client or company data can be disclosed through an AI tool without anyone realizing it happened.
- Security: AI tools introduce new vulnerabilities into an ITSP's environment and its clients'.
- Accuracy: AI outputs can be incomplete, biased or misleading. Gross flagged the "black box" problem directly: The same prompt can return different results, and right now, no one can fully explain why.
- Contractual: Client expectations about AI use may not match what's actually in the MSA.
- Trust: Customers who feel misled about how AI is being used, or not used, on their behalf.
The 5 Questions Every AI Use Policy Should Answer
The core message: These risks aren't reasons to avoid AI. They're reasons to build a policy. Gross framed the policy as a governance framework built around five questions.
Who is authorized to use and approve AI?
Name the categories of employees allowed to use specific AI tools, and state plainly that unauthorized platforms are off-limits. Gross was specific here: No shadow IT, no installing tools because they're convenient.
Two roles should be named directly:
- AI Officer: Reviews business purpose, functionality, risk and provides ongoing oversight of AI tools.
- Privacy Officer: Reviews data access, retention, processing and legal obligations.
A piece of advice: Don't spread this responsibility across a team until no one owns it. Name the people who are accountable.
What tools and uses are permitted?
List approved tools by name and only approve tools that have been reviewed for security, privacy, contract terms and data practices. Reassess that list whenever a tool's features, integrations or terms change. Document the approved use cases as clearly as the approved tools and match each one to the sensitivity of the data involved. AI should never make unsupervised legal, financial, employment, security or customer-impacting decisions.
What data is allowed into AI systems?
Data access should follow classification, not convenience. Gross broke it into three tiers:
- Generally permitted: Publicly available information, approved templates, sanitized examples and properly de-identified or anonymized data.
- Restricted, requires approval: Customer-confidential information, personal or regulated data, ticket content, logs, configurations, system data, proprietary code, contracts, pricing and internal strategy.
- Never permitted: Passwords, API keys, tokens, unencrypted financial information, and any data prohibited by law.
How are outputs reviewed?
Two principles anchor this section, and Gross said both belong in writing: AI output is a draft, not a decision, and the client remains responsible for approving and implementing the final work product. Keeping that responsibility with the client, not shifting it onto the ITSP, should be stated explicitly in the policy.
Who is accountable when AI fails?
This comes down to what the MSA says. Gross was blunt: An ITSP can delegate a task, but not the responsibility for it. Without clear contract language, the ITSP is exposed by default. He recommended starting with what the agreement already says about third-party solution providers, since most MSAs already state the ITSP isn't liable for third-party failures absent intentional misconduct. If an MSA is silent on AI failure, that's a gap to close immediately. Every AI policy should acknowledge, in writing, that AI can fail, and every client agreement should acknowledge that the risk exists even under best practices.
Bringing It Together
Gross closed with a practical structural point: Acceptable use and AI use are two separate policies, and both belong in a services guide alongside the MSA. Updates to policy shouldn't be delivered by email alone. Instead, tie updates to a natural touchpoint like renewal, or send a direct notice asking the client to re-sign an updated MSA and services guide.
The larger message from the session: There's no rulebook to hand an ITSP today. Building one internally, and naming who owns each part of it, is what turns AI from an open liability into a managed one.
Frequently Asked Questions
Is there a federal AI law for MSPs in the U.S.? No. There is no single federal AI law governing MSPs at this time. Existing frameworks like the FTC Act, HIPAA and the NIST AI Risk Management Framework offer partial guidance, and a small number of states, including California, Colorado and Texas, have passed narrower AI-related rules.
What are the two key leadership roles an MSP should designate for AI governance? An AI Officer, who oversees tool approval, business purpose and risk, and a Privacy Officer, who oversees data classification, retention and legal compliance.
What are the five risks of operating without an AI policy? Privacy, security, accuracy, contractual exposure and loss of customer trust.
What five questions should an internal AI use policy answer? Who is authorized to use and approve AI, what tools and uses are permitted, what data can be entered into AI systems, how are outputs reviewed and who is accountable when AI fails.
Should AI use policy and acceptable use policy be the same document? No. The recommendation is to treat them as two separate policies, both housed in a services guide alongside the MSA.
Get more ChannelCon news and follow GTIA on LinkedIn!
