The AI Policy Problem Gets Harder the Bigger the Team Gets

A three-person shop can sort out its AI approach over lunch. A fifteen-person shop can’t, and pretending otherwise is how you end up with half the team using AI on client work in ways nobody else knows about.

This isn’t really a technology problem. It’s a coordination problem, and coordination problems scale with headcount. The bigger the team, the more structure you need, but AI is moving fast enough that whatever structure you build today might be embarrassingly outdated by the time anyone reads it. That’s the bind.

Small Teams Have a Real Advantage Here

There’s an honest case to be made that smaller agencies have a structural edge in AI adoption, and it comes down to how decisions actually get made. When you have three or five people and everyone is in each other’s peripheral vision, shared judgment does a lot of the work that policy would otherwise need to do. You notice when someone’s output changed. You have the conversation. You adjust. The whole cycle is fluid.

This isn’t about being casual or sloppy. It’s about recognizing that in a small team, the owner is still inside the work. You see the deliverables. You know who’s doing what. The informal governance that makes a two-page AI policy unnecessary is actually a form of management that doesn’t get enough credit. Smaller marketing firms have some real structural advantages over larger competitors right now, and this is one of them. Less drag. Less communication overhead. Faster course corrections.

The problem is that advantage starts to erode somewhere around eight to twelve people. Maybe earlier if the team is distributed.

Where It Gets Complicated

Past a certain size, you’re not in everyone’s workflow anymore. Work goes out the door that you didn’t personally review. Junior people are making judgment calls about when to use AI, which tools to use, how much to disclose to clients, and how to handle the weird edge cases that come up constantly, and they’re making those calls without a clear signal from you about what you actually expect.

That’s not their fault. It’s yours. Not because you did something wrong, but because the coordination that used to happen naturally doesn’t scale automatically, and nobody handed you a manual for the transition.

So you need more structure. Fine. Most owners get there eventually. But here’s where it gets uncomfortable: by the time you’ve drafted an AI policy, circulated it, gotten feedback, revised it, and actually communicated it to the team, the specific tools and capabilities you wrote it around may have changed enough to make parts of it feel stale. Not wrong, necessarily, but already a step behind reality.

This is genuinely new territory. Most business policies address things that don’t change much. Your billing terms don’t need quarterly updates. Your client communication standards are pretty stable. But an AI policy is trying to govern something that is still visibly moving, and the gap between when you write it and when it’s obsolete is uncomfortably short.

What Actually Needs to Be in the Policy Versus What Doesn’t

Here’s what I’d argue is worth codifying, even if everything else stays informal. First, client data and confidentiality. What can and can’t go into a third-party AI tool. This is the one category where the downside of ambiguity is serious enough to justify a clear, written rule. Second, disclosure. What you tell clients about how AI was used in their work, and when. You don’t need a PhD-level framework here, but somebody needs to own the answer. Third, review expectations. AI output is a draft, not a deliverable. That seems obvious but it apparently isn’t obvious to everyone, and workflow thinking matters more than prompting skill anyway, so the review step needs to be built into the process, not left to individual judgment.

Everything else, the specific tools, the specific use cases, the detailed protocols for each practice area, probably belongs in something lighter. A living document someone actually updates, a running Slack channel, a monthly five-minute team check-in. Not a policy binder.

The goal isn’t to govern AI thoroughly. The goal is to handle the high-stakes situations consistently and leave enough room that the team can adapt to new tools without waiting for the policy to catch up.

The Real Bottleneck Is Owner Clarity, Not Team Behavior

Owners sometimes want to hand the AI policy problem to someone else. Give it to the ops lead, the senior strategist, whoever. And that person can absolutely help draft and maintain it, but the underlying decisions are yours. What does quality mean here? What are you comfortable telling clients? What risk tolerance does this firm have? Those are owner-level questions, not workflow questions.

If the team seems confused about how to use AI, or inconsistent, or overly cautious, or recklessly enthusiastic, that’s usually a signal that the owner hasn’t actually decided where the firm stands yet. The team is taking their cues from wherever they can find them, which is often just each other. The business-model implications of AI adoption are an owner-level responsibility, not something to delegate down until you’ve sorted out your own position.

This is worth sitting with for a minute. The reason large firms struggle with AI governance isn’t usually that they lack smart people or good intentions. It’s that the person at the top hasn’t made the call yet, so everyone below them is trying to read the tea leaves.

A Middle Path That Holds Up

If I were running a fifteen-person shop right now, here’s roughly how I’d think about it. Nail down three rules that don’t move: client data handling, disclosure standards, and the review gate. Write those down, make sure everyone knows them, and enforce them consistently. Past that, build for adaptability rather than broad coverage. A monthly team conversation about what’s working and what’s weird. A shared place where people can log new tools or use cases they’re trying. A clear signal from you that experimentation is okay within the guardrails, and that the guardrails will actually get updated as things change.

That’s not a full policy. But it’s enough structure to avoid the real failures without creating so much overhead that the policy becomes a liability the minute a new model drops or a tool changes its terms of service.

The smaller you are, the more you can rely on conversation. The bigger you are, the more you need written commitments on the things that actually matter. The mistake, at any size, is pretending you’ve fully solved this when what you’ve really done is postponed the conversation until something goes wrong.

Write the three rules. Have the conversation. Then keep having it every month until it stops being useful to have.