The leak doesn't come from the policy committee. It comes from a stuck ticket at 11pm.
Picture a tier-2 engineer three hours into a P2 for a client whose IPsec tunnel keeps dropping. They've read the docs twice. So they copy the running config — interface names, pre-shared key hint, the client's internal subnet ranges — into a chatbot and ask why the phase-2 negotiation is failing. They get a coherent answer in nine seconds. The ticket closes. Nobody knows it happened.
That is the AI use case your policy has to govern, and it's nothing like "can marketing draft a blog post." An IT services firm's prompts are uniquely loaded: client architecture diagrams, raw syslog, credential material, access tokens, incident timelines, and privileged troubleshooting context that you are contractually obligated to protect. The same property that makes AI useful for support — paste in the messy real artifact, get a fast read — is the property that turns one engineer's shortcut into a breach you have to disclose.
The broader pattern is well documented. RSM's middle-market AI survey, the San Francisco Fed, and the OECD's SME report all land on the same uncomfortable point: smaller firms adopt AI faster than they build the governance and skills to control it. For a services firm holding the keys to dozens of client environments, that gap isn't a productivity drag. It's the gap a breach falls through.
Draw two lists. The whole policy lives in the gap between them.
Forget the multi-page document for a minute. The working core of a good IT services AI policy is two short lists every engineer can hold in their head.
The green list — paste freely. Generic runbook scaffolding ("write me a baseline AD hardening checklist"), ticket-summary templates that use placeholders instead of real client data, internal training outlines, KB article cleanup, and how-to questions about a technology in the abstract. None of this touches a specific client's environment, so an unmanaged tool is fine.
The red list — never goes into anything but a sanctioned, configured tool. Running configs, raw logs, packet captures, secrets and pre-shared keys, API and access tokens, network diagrams, client subnet and asset inventories, active incident details, and any credential material. The test an engineer can apply in two seconds: would this paragraph, leaked, let an attacker move inside my client's network? If yes, it does not go into a public chatbot — full stop, no "but I was in a hurry."
The structure behind those lists isn't invented. The NIST AI Risk Management Framework gives you the map-measure-manage spine for classifying where AI risk lives in your workflows. CISA's AI Data Security guidance matters specifically here because it spells out how sensitive data leaks through the parts engineers forget — not just the prompt, but retrieval stores, logs, and outputs. And "we bought Copilot, so we're covered" is the most expensive misread in the room: a sanctioned tool moves the red-list data inside your tenant, but it does nothing on its own about who can see what. Read what the tool actually does with your data — Microsoft 365 Copilot's privacy and data controls and OpenAI's enterprise privacy commitments are the documents to read line by line — then layer on tenant configuration, data classification, and access review. A permission-bound assistant happily surfaces a client's payroll share to an engineer who shouldn't see it if your SharePoint permissions were already a mess.
Make it survive contact with a Tuesday.
A policy that lives in a PDF gets violated by lunch. For a services firm, acceptable use has to ride inside the operating rhythm you already run. Three moves do most of the work:
Put the green/red split where the work happens. A pinned message in the support channel and a line in the ticketing tool's new-ticket template beats a 12-page document nobody reopens. The engineer at 11pm needs the rule in their face, not in a wiki.
Give the shortcut a legitimate destination. The reason that config got pasted into a public tool is that there was no faster sanctioned option. Stand up one configured, tenant-bound assistant the team is allowed to use on real client data, and the temptation to go around it mostly evaporates. People take shortcuts when the right path is slower; close that gap.
Make AI use auditable like any other privileged action. You already log who touched which client environment. Treat AI the same: a named exception channel for the genuinely novel case, and the ability for a service lead to answer "how is AI being used across our ticket and runbook work?" without guessing.
Start where the blast radius is smallest — service-report drafts, KB retrieval, internal summaries — and keep incident response, secrets handling, and client architecture work behind the stricter controls until the muscle is built. To pressure-test where your data and security maturity actually sits before you turn anything loose on client environments, run the SMB AI readiness assessment, then use the 90-day implementation plan to sequence the training, the sanctioned tool rollout, and the measurement in an order that won't get you breached on the way up.
