The risk you carry isn't yours
Picture a Friday-night go-live that's stalling. A consultant has a tenant admin console open in one tab and an integration error nobody can explain. The fast move is obvious: copy the config block, the error trace, and a screenshot of the screen into a free AI chatbot and ask why the connector is failing. Five minutes later there's a plausible answer. There's also a client's production configuration, sitting in a tool nobody approved, possibly violating a confidentiality clause in the very SOW that funded the project.
That's the thing that makes implementation partners different from almost every other business adopting AI. You don't mostly handle your own sensitive data. You handle theirs — tenant configurations, integration maps, architecture decisions, support logs, pricing terms, and screenshots of systems your client hasn't even shown their own board. An acceptable-use policy written for a generic SMB misses this entirely. Yours has to govern data you're contractually obligated to protect for someone else.
The research on smaller firms is consistent: AI helps delivery work, but only after governance and skills are in place. The RSM middle-market AI survey, the San Francisco Fed small-business AI analysis, and the OECD SME AI adoption report all point the same direction. For you, "governance first" isn't a maturity nicety. It's the difference between a renewable account and a breach notification.
Draw the line at the client boundary
The cleanest way to write this policy is to sort every input by one question: does it describe your work or does it describe their system? Work about your own delivery process can usually go into approved AI tools. Anything that fingerprints a specific client environment cannot.
So the green list is narrow and internal-facing: drafting a status update from your own notes, turning rough QA observations into a clean summary template, outlining the structure of a configuration document, retrieving an answer from your own approved internal knowledge base. None of that leaks a client.
The red list is the stuff that feels harmless in the moment and isn't: tenant screenshots, credentials or connection strings, integration diagrams that reveal a client's stack, the commercial terms inside an SOW, named architecture decisions, and the messy detail in an open support ticket. The rule of thumb worth printing on the wall: if pasting it would let a stranger reconstruct the client's environment, it doesn't go in an AI tool — managed or not.
Two frameworks make this defensible rather than arbitrary. The NIST AI Risk Management Framework gives you the map-measure-manage structure to justify why a given input is restricted. CISA's AI Data Security Best Practices covers how inputs and outputs get accessed, monitored, and handled. And even a configured assistant isn't a free pass — read the actual data-handling terms in Microsoft 365 Copilot's privacy controls and OpenAI's enterprise privacy commitments against the confidentiality language in each client contract before you let either one near delivery evidence.
Make it real before the next go-live
A policy nobody can act on under deadline pressure is theater. So make yours operational with named roles, not aspirations. Assign one delivery owner who approves the tool register. Write the data-classification rule as the one-line "their system vs. your work" test above. Define an architecture-review trigger so designs don't get AI-reshaped without a human signing off. Set a support-log review standard. And give people a real exception path — because the consultant on the stalled Friday go-live needs somewhere fast to take the question instead of the free chatbot.
Then pick exactly one workflow to start. Status-report drafting and QA-summary preparation are the right first moves: genuinely useful, naturally bounded to your own notes, and low-stakes if the output is rough. Keep credentials, architecture choices, commercial terms, and client commitments behind explicit human review with no exceptions.
Two next steps. Use the SMB AI readiness assessment to pressure-test your source boundaries — where would a client config actually leak today? Then use the 90-day implementation plan to sequence tool approval, team training, a pilot, and a real lessons-learned review after the first project that runs under the new rules.
