An owner buys ChatGPT or Copilot licenses for the whole team. The rollout email says something like "start playing with this, let's find some efficiencies." That is it. No policy. No approved tool list. No rules about what goes into a prompt.
Six weeks later a tech has pasted a client's Active Directory export into a chat window to get help writing a script. Someone in sales dropped an entire MSA into an LLM to summarize it. A helpdesk lead built a workflow nobody else knows exists, and it breaks when they take vacation.
None of those people did anything malicious. They did exactly what you told them to do. You just never told them where the edges were.
GTIA and Censia published an AI Readiness Toolkit and a companion worksheet, Assess Your AI Readiness, that walk through preparing, packaging, and profiting from AI. The framework is solid and I use a version of it with owners. It has two gaps. It assumes you are starting from zero, and almost nobody is, because your team started without you. And it tells you to pick a use case and commit to a 60 day trial without telling you which use case, what happens when you pick wrong, or how you know at day 60 whether it worked.
For a shop in the 10 to 20 employee range with no slack in the schedule, that gap is the whole problem.
Here is the framework with the missing pieces filled in, in the order I actually run it.
The order
- Find out what is already happening
- Buy company accounts
- Write the policy
- Connect your three systems, read only
- Baseline from the PSA
- Run one pilot for 60 days
Most owners want to start at six. Starting at six is why the pilot dies.
Step 1: Find out what is already happening
The GTIA worksheet asks you to look at three areas. Those are the right areas.
Internal operations. Where are your people doing repeatable, time consuming work? Manual ticket routing, duplicate RMM entries, reports that take an hour to assemble every month.
Service delivery. Which services carry thin margins or make clients flinch at the invoice? Helpdesk, monitoring, and documentation usually top that list.
Client needs. What are clients already asking you? "Can we automate onboarding?" and "Can you help us use ChatGPT securely?" are the two I hear most.
Now add the fourth area the worksheet skips.
Current usage. What is your team using right now, without your involvement? Ask directly in a team meeting and make it clear nobody gets in trouble for answering honestly. You will learn about three tools you never approved. Write them all down.
Then check the money. Pull your credit card statements and your Microsoft billing. Count how many AI seats you pay for and how many people log in weekly. Most MSPs I talk to pay for double what they use.
If you want the full version of this step, run a short anonymous survey. Six to eight minutes, and it gets you the answer to the only question that matters: what client data has already gone into what account.
Checklist
- Document three repeatable tasks eating your team's hours
- Identify one service you fear becoming commoditized
- Note one AI related client question from the last 90 days
- List every AI tool your team currently touches, approved or not
- Compare AI seats you pay for against seats people actually use
Step 2: Buy company accounts
Cheapest fix on the list and the one that moves your risk the most in a single afternoon.
Every person running on a free or personal AI account is a person you did not give a company account to. That is a purchasing decision, not a discipline problem. Fix it before you write a rule telling them to stop, because a rule with no sanctioned alternative sends the behavior underground instead of ending it.
Paid business tiers come with a data processing agreement, admin controls, and a contractual promise that your prompts do not train the model. Free tiers usually do not, and the setting that controls it lives three menus deep where nobody looks.
Step 3: Write the policy
You do not need a forty page governance document. You need two pages your team will read. Adapt the brackets and put it in front of them this week.
[COMPANY NAME] AI Use Policy
Effective date: [DATE] Owner: [NAME, TITLE] Review cycle: Every 6 months
1. Approved tools
You may use the following AI tools for company work:
- [TOOL 1, e.g. Microsoft Copilot, business tenant]
- [TOOL 2]
Name them by product, not by category. "ChatGPT Team" is a policy. "AI tools" is not. Any tool not on this list requires approval from [NAME] before you use it for anything involving company or client information. This includes free tools and browser extensions.
2. What never goes into a prompt
Do not paste, upload, or type any of the following into an AI tool:
- Client passwords, API keys, certificates, connection strings, or any credential
- Client network diagrams, IP schemes, or firewall configurations
- Personally identifiable information belonging to clients or their employees
- Protected health information, cardholder data, or anything covered by a client compliance obligation
- Signed contracts, MSAs, or pricing that identifies a specific client
- Employee records, payroll data, or performance documentation
- Security findings tied to a named client before you remediate them
These are fine:
- Generic technical questions with client identifiers stripped out
- Public vendor documentation and error messages
- Script and automation logic that does not reference a specific client environment
- Your own internal documentation and marketing copy
When you are unsure, strip the names and the IPs first. If it still works as a question, ask it. If it does not, bring it to [NAME].
3. Client data rules
You may use AI to work with client data only when all three are true. The tool is on the approved list. The account runs on a business or enterprise plan where the vendor does not train on your inputs. The specific use falls within what your agreement with that client permits.
Consumer accounts and personal logins are not permitted for client work. That includes your own paid personal subscription.
4. Human review
AI output is a draft, never a deliverable. A person reviews and takes responsibility for anything that reaches a client, including tickets, documentation, proposals, scripts, and email. You own what you send. "The AI wrote it" is not an explanation. Never run an AI generated script in a production environment without reading every line first.
5. Client disclosure
Choose the position that matches your contracts and stick to it.
Option A: We disclose our use of AI in service delivery to clients and document it in our agreements.
Option B: We do not use AI on client data for any client whose agreement restricts subprocessors or data handling without written consent. [NAME] maintains the list of restricted accounts.
6. Adding a tool
Send [NAME] the tool name, what you want it for, and a link to its data handling terms. You get an answer within five business days. Slow approval creates shadow AI. If a request takes three weeks, your team stops asking and starts expensing.
A tool gets approved when it meets all of these: a data processing agreement is in place, prompts and uploads are excluded from model training, the vendor supports SSO and admin controls, and we know what country the data sits in.
7. Accountability
First violation, a conversation and a refresher. Repeated violations follow the standard disciplinary process. Credentials or client protected data placed into an unapproved tool is a security incident. Report it to [NAME] immediately and we run our incident response process. You will not be punished for reporting quickly. You will be punished for hiding it.
Send it out, get a signature or acknowledgment, and put a copy where new hires see it during onboarding. Then move on. Policy is a gate, not a destination.
If you want the longer version, including how to turn the same policy work into a client offer, that is on the dedicated AI policy page.
Vendor side matters too. Your RMM, PSA, and documentation platform are all shipping AI features. Find out what those features do with your data before you turn them on.
Step 4: Connect your three systems, read only
This is the step the original toolkit skips entirely, and it is the one that changes the answers to every question that comes after.
Before you buy anything that solves one workflow, give your LLM read access to the systems your team already lives in every day. Three systems, in this order.
- Your documentation platform. Every SOP, runbook, and client specific quirk your team has written down.
- Your PSA. Ticket history, resolutions, client context.
- Your RMM. Device state, alerts, patch status.
Model Context Protocol, or MCP, is how you make that connection. It is an open standard that lets an LLM query a system directly instead of you copying and pasting context into a chat window. Most major platforms either ship an MCP server now or have one on the roadmap.
Start here for two reasons. First, you stop guessing at use cases. Your techs start asking questions of your own data, and within two weeks they tell you exactly where the friction is. The use cases surface on their own, and they are real ones, because they came from the work instead of from a list.
Second, a tech who joined four months ago can ask what your team did the last three times this client's line of business app broke. That answer used to live in one senior person's head or in a ticket nobody could find. Now it takes eleven seconds.
Read only. All three. Every time.
This is the part I do not negotiate on. No write. No delete. Not on the RMM, not on the PSA, not on the documentation platform.
I watched a partner give an AI tool write and delete permissions on production systems because it was faster to set up that way. What follows is not a learning experience. It is a catastrophic failure with client data attached to it, and you get to explain it on a call you will not enjoy.
Read only gives you every benefit of the connection and none of the risk. Your techs get instant answers across your whole stack. The model cannot change a thing. When someone in your shop eventually asks about write access, and they will, the answer is that you revisit it after 90 days of clean usage and a specific workflow worth the exposure. Not before.
No shared accounts
The second failure I see constantly. Somebody wires the connection to a shared admin account so the whole team can use it.
Now every technician sees every client's data, your logs show one identity for all activity, and you cannot answer the question of who queried what. If you carry any compliance obligation for your clients, and you do, that setup fails the first serious audit question anyone asks.
Give each technician their own credentials, scoped to what that person already has access to in the underlying system. The MCP connection should not expand anyone's permissions by one inch.
Choosing your LLM
I do not push a preference. Owners I work with run Claude, ChatGPT, Hatz AI, and Synthreo, and I help them either way. The criteria that actually matter:
- Where your data goes and who retains it. Get this in writing before you connect anything client related.
- Native MCP support. Some platforms make this straightforward. Others need a middle layer you will maintain.
- Cost per seat at your headcount, including the seats you will add when this works.
- Admin controls. Can you see usage, revoke access, and enforce policy centrally.
- What your team already uses. Adoption beats capability every time at your size.
If you have compliance heavy clients, criteria one and four move to the top of that list and stay there.
Step 5: Baseline from the PSA
A 60 day trial with no baseline means you have an opinion at the end instead of a number.
Three metrics, all already sitting in your PSA.
- First call resolution
- Average time on ticket
- Tickets worked per day
Pull all three for the 30 days before you connect anything. Write it down where your team can see it.
One caution. Read the three together or they will lie to you. A tech closes more tickets per day by closing them badly. Time on ticket drops when work gets punted to someone else. Any single number moves for bad reasons. All three moving the right direction at once is real.
Step 6: Run one pilot
One. Not two, not three. A shop your size that starts three finishes none.
Here are the common starter use cases with an honest read on each.
Proposal and RFP writing. Easiest win on the list. Nothing touches production, nothing touches client data, and you see results in two weeks.
Client onboarding documentation. Fastest payback I see. Onboarding eats hours and follows a repeatable pattern.
AI powered knowledge base. Auto generate articles from past resolutions. High value, completely internal, low risk. Good if your documentation is thin.
Ticket triage automation. AI categorizes, assigns, and summarizes tickets. Strong pick, and your PSA vendor probably already ships it. Start there before you build anything.
Security event correlation. Useful, but this is a buy, not a build. Check what your existing security stack offers before adding a vendor.
Client chatbots. Skip until you have a policy in place and one successful internal pilot behind you. It touches client users directly and it fails loudly.
Pick one, internal first. If you are under 15 people, pick proposals or documentation, because you do not have the bench to babysit a pilot that touches production. Pick the one where you already know the process, the process is repetitive, and a bad output is easy to catch. Something where the failure mode is embarrassment, not liability.
Do the math before you start. Estimate the hours the task consumes each month, multiply by your loaded labor cost, and compare against license cost plus the time someone spends building it. If the number does not clear, pick a different use case.
Four decisions, in writing
People. Assign one owner. Not your best tech. Your best tech optimizes for the interesting problem, which is what makes them good, and it is why they build something clever nobody uses. The owner needs to be organized and willing to chase people for feedback. Give them a few hours a week and put it in their goals.
Tool. One no code or low code option for the pilot. If you already pay for Microsoft 365 Business Premium, look at what is included before you buy anything new.
Timeline. A 60 day goal with a checkpoint every two weeks. Put the checkpoints on the calendar now.
Kill criteria. Decide in advance what makes you stop. Write it down before you start, because sunk cost gets loud around day 45. Something like: if this does not save eight hours a month by day 60, we stop and reallocate the license.
The 60 day checkpoints
Day 14. Which questions is your team actually asking? Write down the top five. These are your real use cases.
Day 30. Pull the three metrics again. Note what moved and what did not.
Day 60. Pull them again. Compare all three to baseline together. Decide what you connect next, or what you fix.
Then rerun your discovery survey at day 90. Same questions. The delta is your real progress report.
The worksheet
Print it, fill it in, bring it to your leadership meeting.
Where you are right now
Mark each Not Started, In Progress, or Done.
- Team surveyed on current AI use
- Company accounts issued to everyone previously on a personal login
- Written policy signed and acknowledged
- Documentation platform connected with read only access
- PSA connected with read only access
- RMM connected with read only access
- Individual credentials for each technician, no shared accounts
- Baseline captured for first call resolution, average time on ticket, and tickets worked per day
- One person named as owner, and it is not just your best tech
Your plan
Which system do you connect first? ____________________
Who owns this internally? ____________________
Which LLM did you pick, and why? ____________________
What are your read only credentials scoped to? ____________________
Where does your data go, and who retains it? ____________________
Date you start: ____________________
Your baseline, last 30 days
First call resolution: ____________________
Average time on ticket: ____________________
Tickets worked per day: ____________________
Your one pilot
Use case: ____________________
Owner: ____________________
Hours saved per month required to keep it: ____________________
Date we kill it if that number does not appear: ____________________
The short version
Find out what your team already uses. Buy them company accounts. Write the policy. Connect your three systems read only. Baseline from the PSA. Run one pilot for 60 days with an owner and an exit condition.
The framework is not complicated. The discipline is.
Talk it through
Most owners I work with know they need this and keep pushing it to next quarter. The harder question is not which tool. It is what AI does to your pricing and your hiring plan over the next two years, and whether the efficiency you gain shows up as margin or quietly gets handed to your clients.
Everything above is a template. Run it yourself this week and never talk to me. What I will not do is hand you a system and tell you your shop is wrong for not matching it.
Not sure this is your actual constraint? Take the MSP Owner Reality Check. Five questions, nine minutes, and it names the two or three things quietly capping your growth. https://themsphero.com/resources/msp-owner-reality-check-assessment
If you already know what is broken, book a 30 minute fit call at https://letschat.themsphero.com
Mike Kolb The MSP Hero
Adapted from the AI Readiness Toolkit for ITSPs and Assess Your AI Readiness: 3 Steps to Prepare, Package and Profit from AI in the Channel, published by GTIA in partnership with Censia. The diagnostic, opportunity canvas, and starter use case list come from their material. The order of operations, the read only requirement, the policy framework, the metric baseline, and the kill criteria are mine.