Every few weeks someone at a mid-market company asks me some version of the same question: “What should our AI policy be?” And what they’re picturing, almost always, is a document. A long one. Something that goes through legal, comes back with track-changes, sits in a wiki, and gets read by approximately no one.
I understand the instinct. It feels responsible. But a forty-page AI policy at a company this size is the wrong instrument, for a simple reason: it’s written to cover the company, not to change what people do on a Tuesday. And AI risk at your size isn’t a legal-exposure problem first. It’s a behavior problem. The danger isn’t that you lack a policy. It’s that someone on your team pastes a customer list into a chatbot, or sends an AI-drafted email with a made-up number in it, before any policy would have stopped them.
So here’s what I actually hand people instead. Five things. One page. You could put them in place this week, and they’d cover the large majority of your real risk. The behavioral kind, the kind that actually happens.
1. A “what not to paste” rule
One page. Plain English. And the trick is to name categories, not a hundred examples, because people follow a rule they can remember and ignore a list they can’t.
The categories: customer data, personally identifiable information, contracts, financials, credentials. That’s it. “Don’t paste any of these into an AI tool unless it’s one we’ve explicitly approved for it.”
Why this one is first: it’s the failure that’s already happening at most companies, quietly, right now. Someone is pasting something sensitive into a consumer chatbot to save fifteen minutes, with no idea where it goes. The “what not to paste” rule is the single highest-value sentence you can put in front of your team, and it costs you an afternoon. I’ll confess how easy this is to get wrong: secrets are the trap. Claude feels like it’s on the team, and more than once I’ve caught myself about to ask it to update files that hold trusted keys. It’s a completely natural thing to do, which is exactly why it has to be a rule. Don’t.
2. A workspace-level data setting
Get your team onto a Team or Enterprise tier of whatever AI tools they actually use, turn on the admin controls, and confirm in writing that your data isn’t being used to train anyone’s model. Then write that down somewhere you can find it.
The reason isn’t paranoia. It’s that you will get asked. A customer’s security questionnaire, a partner’s procurement form, your own board: someone will ask “is our data training an AI model?” and “I think we’re fine?” is not an answer that holds up. Spending an hour to make the setting correct and documented turns a future scramble into a one-line answer.
This is also the move that quietly upgrades you from “people using random free tools” to “the company has a sanctioned way to do this.” Your customers will appreciate your governance at this stage.
3. A verification step for anything that leaves the team
This is the one that matters most, and it’s one line: no AI-generated output reaches a customer, a partner, or the public without a human checking it first.
Here’s why your company should implement this change. AI doesn’t fail randomly. It fails confidently. It invents numbers, fabricates citations, writes plausible-and-wrong copy, all in flawless grammar. (I wrote a whole piece on where it lies and how I work around it.) Engineers have a safety net for this: tests, code review, CI. Your marketing team, your ops team, your support team do not. So without a deliberate check, a wrong AI output reaching someone outside the company isn’t an if. It’s a when.
The check doesn’t have to be heavy. It’s not a committee. It’s one person looking at the part that would actually hurt if it were wrong. The number, the claim, the customer’s name… before it goes out. Targeted, a few minutes, every time. That single habit prevents the embarrassing public mistake that no policy document ever would have.
4. A named human owner per AI-assisted workflow
For each place AI is doing real work (drafting proposals, triaging support tickets, generating reports), one named person is accountable for the quality of the output. Not a team. A name.
This sounds bureaucratic; it’s the opposite. It’s what prevents bureaucracy, because the alternative is the diffuse-responsibility failure: everybody assumes someone else is checking, so nobody is, and when something goes wrong the answer is “the AI did it.” That is not an answer any customer accepts. A name on the workflow means the verification in move #3 actually has someone responsible for it happening. You can meet with that person and ask for their work progress. Nowhere is this truer than in open-source code: a real person has to own the process of delivering quality code. The tool doesn’t carry that accountability. A name does.
5. A quarterly thirty-minute review
Once a quarter, half an hour: what’s working, what we killed, what’s next. Calendar it. That’s the whole move.
The reason this matters more than it looks: AI tooling changes fast, and without a deliberate moment to look, you accumulate. Tools nobody uses. Workflows that quietly stopped earning their keep. New capabilities you didn’t notice you could use. The quarterly review is where you prune the dead stuff and redirect toward what’s actually producing results. Not coincidentally, that’s the only thing that matters. Adoption isn’t the goal with AI. Results are. Thirty minutes, four times a year, keeps the whole thing pointed at outcomes instead of drifting into AI-for-its-own-sake.
What this is really doing
Notice what’s not on this list. There’s no model-risk taxonomy, no forty-page acceptable-use appendix, no approval board. Not because those never matter. At a regulated enterprise, some of them do. Because at a mid-market company, they’re cargo-cult governance. They look like the real thing and they change nothing about Tuesday.
These five do change Tuesday. A rule people remember. A setting that’s correct and documented. A check before anything ships. A name on each workflow. A regular look. That’s not a policy you file. It’s five practical habits you make automatic, and together they catch the failures that actually occur at your size.
The hardest part isn’t writing them. It’s deciding which one is genuinely hard at your company. Usually one of them is. In my experience it’s #1 that slips the most. Pasting the wrong thing is so easy that even people who absolutely know better do it. Me included. It’s just too easy to forget in the moment. That friction is the useful signal: it shows you where the real risk actually lives.
Start there. Five moves, one page, this week. You can write the forty-page version later, if you ever actually need it. Most companies your size never do.
I’m Brian Fromme. I help mid-market teams get real results from AI. Built and shipped, whether that’s code or content. More at atelier.purpleblossom.ai.