Nobody in your company decided to adopt AI. It happened anyway, one person at a time. Someone in sales saved a set of instructions that writes proposals the way they like them. Someone in operations uploaded the price sheet and the policy manual to their own assistant. A project manager built a little helper that drafts client updates. Each of those was a good idea. Together, they've quietly built a dozen private versions of how your business works, and none of them agree.
How it happens
Every AI tool now lets people save their own instructions, upload their own reference files and build small assistants for repeat jobs. That's the point of them, and the people doing it are usually your best ones: curious, efficient, trying to get more done. Nobody is doing anything wrong. The trouble is that each setup is built alone, tuned to one person's habits and one person's understanding of the rules.
Six months in, that adds up. Two people ask their assistants the same question about your return policy and get two different answers, because each uploaded a different version of the document. One person's instructions say you never discount; another's still carry last year's promotion. The salesperson who spent weeks refining a proposal assistant leaves, and the assistant leaves with them.
Where it turns into a company problem
Four things go wrong, and they compound. Answers drift. Customers and colleagues hear different things depending on whose AI drafted the email. Good work doesn't spread. When one person figures out how to make the AI handle a tricky job well, nobody else benefits. Knowledge lives in personal accounts. The best description of how your business runs may now sit in a tool the company doesn't control, which is the same question we raised about who actually owns your business data. Data goes places nobody tracks. Client files get uploaded to whatever account was handy, the same blind spot we flagged in vibe-coded business apps.
A company AI policy tells people what they may not do. It doesn't give their AI the same picture of the business.
A policy is the start, not the strategy
Most businesses that notice this reach for a company AI policy, and they should have one: which tools are approved, what data may never go into them, who to ask. It's a page, and it's worth writing this month. But a policy only draws the fences. It doesn't fix the drift, because the drift isn't people breaking rules. It's people working from different sources.
The fix is one shared source that every assistant in the company reads from: your services, prices, policies, tone, the way you handle the common jobs. We've written about how to build a knowledge base AI can actually use. The harder question, and the one this piece is about, is who gets to change it.
Run it like open-source software
If everyone can edit the shared source freely, it turns into a mess within weeks: duplicate pages, contradictions, someone's half-finished experiment sitting next to the official policy. If nobody can edit it, it goes stale and people drift back to their private setups. The model that works is the one open-source software has used for decades.
Everyone reads; a few write. The whole team's AI draws from the shared source, but only a handful of named owners can change it, each responsible for a section: sales, operations, service. Suggestions are captured where the work happens. When someone notices the AI got something wrong or finds a better way to do a job, they flag it in the moment, and it becomes a request rather than a private fix. Owners review on a schedule. Once a day or once a week, each owner approves the request, approves it with changes, or declines it with a reason. Specifics get their own owner. What applies to one client or one department lives in its own section, owned by the person closest to it, usually the account lead.
That's the whole system: one source, clear owners, a way in for good ideas, and a regular rhythm. None of it requires a particular product, and the tools you already pay for can probably carry it.
How we run our own
We work this way ourselves. Every AI session we run reads the same shared set of instructions and the same running log of decisions before it starts, so nothing works from a private version of how we operate. Changes to that shared core go through review rather than straight in, and each client's specifics live in that client's own file, separate from everything else. It's early, and the tooling for this is still settling across the industry; we'd be lying if we said there's a finished playbook. But the difference between AI that compounds and AI that fragments has turned out to be ownership, not software.
What to do this quarter
Find out what already exists. A short, no-blame question to the team: which AI tools do you use, and what have you set up in them? The answers are usually the best map of where your real processes live. Write the policy page. Approved tools, data that never goes in, who to ask. Pick the shared source and name the owners. One per area, with the authority to say no. Set the rhythm. A place for suggestions and a fixed time to review them. Then measure whether it's working, the way we describe in how to tell whether AI is actually paying off.
If your team is already deep into its own setups and you'd like a clear picture of what you have before you decide what to standardise, that's what our diagnostic is for.
