We didn't set out to run AI. We ended up here because we were already running
the layer underneath it.

Depends on the job. Most of what our clients need reasoning for lands better with Claude. For teams already deep in Microsoft 365 with a lot of routine document and email work, Copilot earns its seat. For specific research, coding, or search tasks other models sometimes win. The honest answer is that this is a portfolio question, not a religion question, and any vendor who tells you it's always one answer is telling you what they're paid to say.

We're mostly a Claude shop because that's where most of our production builds have landed. We deploy Copilot where the client already runs Microsoft and the workflow fit is genuine. We'll tell you when neither is the right answer.

Six things, at minimum. Which tools are approved. What data is allowed in each. How output is reviewed before it goes to a client, a regulator, or a court. What happens when someone breaks the policy. How the policy gets updated when the tools change (which is every quarter right now). And who owns it.

Most templates you can download online cover the first two and miss the other four. That's the part that gets a business in trouble later. We write acceptable use policies with your legal counsel, calibrated to your industry, and refresh them when the tool landscape shifts.

Three layers. First, tool selection: enterprise-tier AI products (Claude Enterprise, ChatGPT Enterprise, Copilot for Microsoft 365) contractually don't train on your inputs. Consumer versions do. That distinction is real and worth paying for. Second, DLP rules at the browser and endpoint level that block sensitive content from being pasted into unapproved tools. Third, training for the humans, because the tool controls only get you so far.

The failure mode we see most often is a well-meaning staff member on a personal ChatGPT account working over the weekend. The technical controls are important. The culture around what's allowed matters more.

Usually the answer is both. Copilot for the horizontal knowledge-worker use cases (drafting, summarizing, meeting notes). Custom builds for the specific workflows where your business has a unique process, unique data, or unique language that a general model doesn't understand well.

The threshold for “build something custom” is not as high as it used to be. We’ve shipped custom AI applications using API connections to Claude and MCP servers for custom data usage in weeks, not quarters. The right build for a mid-market operator is usually smaller and more specific than the pitch decks suggest.

Model Context Protocol. It's the standard for connecting AI models to your actual data and tools safely. Think of it as the plumbing that lets Claude or another model read from your ticketing system, your document library, or your ERP, with your permissions, your logs, and your rules, without the model or its provider holding a copy of any of it.

It matters if you want AI to work with your real business data. Which most operators eventually do. If your MSP or your consultant can't explain MCP, they're not thinking about your AI beyond the demo. We've implemented MCP servers for several clients already. Happy to walk through what it looks like.

You need a small standing group that owns AI at the operational level. Usually one senior operator, one from IT or security, one from legal or compliance, and one from a heavy-user business unit. It meets monthly. Its job is not to slow things down. Its job is to make sure the tool inventory, the acceptable use policy, the data controls, and the vendor list all stay current, because they will not stay current on their own.

The failure mode is treating AI governance as a project that finishes. It doesn't. The tools change every quarter. The controls have to change with them.

This is the question every industrial operator will eventually ask, and almost nobody in the MSP market is answering it.

AI that touches your knowledge workers (drafting proposals, summarizing meetings, cleaning up expense reports) is IT territory. Governance, DLP, acceptable use. Manageable with the tools discussed above.

AI that touches your control systems, your historian data, your SCADA environment, or field operations is OT territory and a completely different conversation. Different threat model, different failure modes, different regulatory picture, different vendors. The bridge between the two is where most operators get caught, because their MSP knows one side and their OT vendor knows the other and nobody owns the seam.

We do both. That's not standard for a managed IT firm, and it's deliberate. Our clients run real operations, not just offices.