AI Acceptable Use Policy for MSP Staff and Clients

Approve a Use, Not Only a Brand

Record the approved service and the account arrangement your business has reviewed. Add the purpose and the permitted data for that use. Approval of drafting internal text doesn't automatically approve connecting a client's ticket system or sending messages on the client's behalf.

Think of an approved AI service as an approved courier: you still decide what may be sent and to whom. Keep that decision in the workflow. The staff member shouldn't need to interpret a broad vendor promise at the moment they paste a ticket.

It depends on the data handling terms, account configuration, connected sources, and intended action. Those conditions can differ between uses of a service with the same name. Check the actual arrangement rather than borrowing an assurance from a different product or account type.

Use the relevant supplier documentation and agreement to check the specific tool. A general policy doesn't establish a vendor feature that nobody has verified.

Write Rules Staff Can Apply

Use this as a starting policy structure to complete for your business. Replace generic role names with real approval and reporting routes. The short version should point to the current approved-use record, not try to reproduce every product's settings.

Store the detailed approvals where staff can find them while working. Identify who maintains the record when a use changes. An old screenshot of an approval in a chat thread should not become the continuing source of authority.

Keep the policy's incident route usable without asking staff to repeat sensitive information into another tool. Record enough to investigate through the approved system. Tell the reporter who takes the next action rather than treating submission of the report as the resolution.

Keep the Data Boundary Specific

Start with the information involved in the proposed task. A generic training example can be sufficient for exploring a prompt without sending a real client's ticket. Where the task genuinely needs client information, resolve the permission and permitted handling before using it.

Removing a client's name isn't by itself a check that the remaining record is suitable to share. Review the contents and the task's actual need. Details about a system or a person can still matter even when the obvious label has been removed.

Check uploads and connected data sources as well as text typed into a prompt. The approval record should cover what the workflow can reach. Don't permit a connector merely because the original text-only use passed review.

In practitioner advice, Jimmy Hatzell suggests using existing environment reports to begin a client conversation about unapproved AI use. He describes moving that discussion toward approved tools and the information staff may enter. That's his suggested approach, not a claim that a report discovers every AI use.

Make Output Review Match the Consequence

Assign review to someone who understands the work the output will influence. Checking spelling isn't enough for a technical recommendation. Ask the reviewer to verify the relevant sources and the proposed action before approving its use.

For a hypothetical failure, suppose an AI draft includes a configuration recommendation that sounds familiar but doesn't apply to the client. If staff paste it into a change without checking, the implementing engineer or client may be the first to discover the mismatch. The policy should put that check before the approved work proceeds.

Don't ask the tool whether its own answer is correct and count that as independent verification. The review needs evidence appropriate to the task. A useful uncertainty should remain visible instead of being edited out to make the draft sound confident.

The model favors automating suitable level-one work and using a capable resource for the task. That position doesn't make a generated instruction ready for unattended action. Put the review and access boundary around the actual workflow before changing its operating mode.

Treat Client and Shared Uses Separately

Your staff policy controls your MSP's approved work. A client's employees need decisions from their own responsible leadership about their use. Help them complete the rules for their environment rather than presenting your internal approval as authority over their data.

Separate your own use of AI in service delivery from a new service you propose to provide. State who owns the review and which party can approve changes to scope or access. Don't let the same policy page quietly create an additional operational commitment.

Enterprise practitioner Christoffer Besler Hansen distinguishes personal agents from agents used by a wider group. He proposes an intake review of instructions and access before broader use, including connectors and integrations. That is his design suggestion, not evidence that an agent is ready merely because its creator found it useful.

Use a similar review when staff want to share a workflow. Check the new audience and the work it can perform. Keep permission to experiment separate from permission to act on client systems.

Check That the Rule Works in a Real Task

Walk staff through a representative approved task and an example that needs escalation. Have them find the approved-use record and explain the data boundary. Repair any point where the short rule leaves them guessing who can decide.

Name the policy owner and the event that requires a review, such as a material change in the tool, data source, or permitted action. Use changes and reported failures to keep the record current. The useful next step is to test the page against the next actual task before approving another broad use.