AI operating rules for a 50-person company that work

Why AI policies fail on day one

Most teams do not ignore a new AI policy. They hit it, get confused in two minutes, and go back to whatever helps them finish the job.

That happens fast in a 50-person company. Sales wants help drafting emails, support wants faster replies, product wants research summaries, and engineers want code help. If the policy is six pages of warnings and loose advice, nobody knows what applies to the task in front of them.

The first problem is scope. Many companies try to cover every tool, every risk, and every future edge case in version one. People do not read that under pressure. They want three answers: can I use this tool, what data can I paste into it, and who decides if I am unsure?

When those answers are missing, employees make their own rules. One person pastes customer messages into a public model. Another avoids AI because the policy sounds risky. A manager gets asked for approval but has no written limit on what they can approve, so the request sits in chat until the deadline passes.

Cost is the other day-one failure. Teams buy seats first and ask about budget later. Each tool looks cheap on its own. Then marketing has one subscription, engineering has another, support starts a trial with paid seats, and finance sees the total only after the monthly bill lands.

The pattern is predictable. The policy is longer than the work it is meant to guide. Data rules are too broad, so people cannot tell safe use from risky use. Managers own approvals on paper, but not in a clear way. Tool spend spreads across teams before anyone sets limits.

A short policy beats a complete one at the start. If people can answer data, approval, and budget questions in under a minute, they will follow the rules. If they cannot, the policy is already failing.

Start with three controls only

Most teams get stuck because they start with edge cases. A 50-person company does better with a one-page policy that answers three questions before anyone uses a tool: what data can go in, who can approve the use, and what it can cost.

Put every rule into one of three buckets: data access, approvals, or budget. If a rule does not fit one of those buckets, cut it from version one. That keeps the policy short enough to read and easy enough to remember on a busy Tuesday.

Data labels do most of the work. Four labels are enough for almost every small company: public, internal, confidential, and restricted.

Public data can go into approved AI tools without extra review. Internal data may require an approved tool and a team lead's sign-off. Confidential data, such as customer lists, contracts, or product plans, should require a named manager and a paid account the company controls. Restricted data should stay out of external AI tools unless a senior owner gives written approval.

Write the decision-maker next to each label. Write the budget owner next to it too. People should not guess. "Marketing manager approves internal campaign drafts up to $50 a month" is useful. "Use judgment" is not.

A simple example makes this real. If a sales rep wants AI to clean up call notes and those notes contain only public talking points, the rep can use the approved tool. If the notes include customer names or pricing, the rule changes. The rep now needs the company account, manager approval, and a spend limit that finance already set.

That is enough for a first policy. One page, four data labels, and one named approver and payer for each case. Most teams can follow that without a workshop. You can fix gaps after a month of real use.

Set data access rules people can follow

Most people do not break an AI policy on purpose. They guess. If the rule is vague, they paste the wrong thing into the wrong tool.

Start with one hard line. No one should put payroll records, health details, legal drafts, or customer secrets into public AI tools. Customer secrets should include source code, private roadmaps, contract terms, API keys, unreleased pricing, and any file a customer expects you to keep private.

That does not mean people need to stop using AI. Public tools are fine for low-risk work with public, fake, or masked data. A support lead can remove names, email addresses, and account IDs from a ticket, then ask for a cleaner reply draft. Marketing can turn public product notes into ad ideas or rewrite a blog intro.

Internal data needs a short permission map. Write down which teams may use it and in which tools. Marketing may use approved internal tools for campaign drafts and internal documents. Support may use masked ticket data in the same tool. Finance, HR, and legal should stay out unless you run a private tool with access controls and logs.

Saving work needs one simple rule too. Employees should store prompts, outputs, and uploaded files only in company systems tied to the project. They should not leave them in personal notes, private browser tools, or random chat threads. That makes audits, reviews, and cleanup much easier.

Exceptions need one owner, not a committee. In many 50-person companies, that is the CTO, ops lead, or an outside Fractional CTO. If a new use case does not fit the written rules, people should stop and ask before they paste anything.

Define approval paths without slowing work

Most approval flows fail because they treat every AI task the same. A 50-person company does not need that. People should move fast on low-risk work and slow down only when the output can affect customers, money, or private data.

A simple rule works better than a long policy: match approval to risk. If someone uses an approved tool for internal drafts, notes, research summaries, or meeting prep, they should not ask each time. That keeps daily work moving and stops managers from becoming a bottleneck.

A short approval ladder is usually enough:

• No approval for internal, low-risk work in approved tools.
• Manager approval for anything customer-facing, such as emails, proposals, help center text, or sales replies.
• Legal or security review for tasks that use sensitive data, contracts, regulated information, or private customer records.

This is where many policy documents get fuzzy. If the rule says "use judgment," people guess. If the rule says "manager checks all customer-facing AI output before it goes out," people know what to do.

Speed depends on response time. Set one standard, such as one business day for approvals and reviews. If the company cannot meet that, staff will work around the process. Slow rules get ignored.

Absences cause the next problem. Name a backup approver for each team. If the sales manager is out, the head of customer success can approve sales emails. If legal is unavailable, a named security lead can decide whether the task must wait or can move with edits.

A small example helps. If a support lead uses AI to summarize 40 tickets for an internal team meeting, no approval. If that same lead wants to publish an AI-written reply template for customers, the manager reviews it first. If the template uses account details from real users, legal or security should check the data handling before anyone presses send.

That gives people room to work and keeps risky use visible.

Put spend limits in plain numbers

Vague budget rules fail fast. "Use AI carefully" does not help a team decide whether a new tool is fine, whether another seat is allowed, or when someone needs approval.

Put real numbers in the policy. For a 50-person company, small fixed limits work better than fancy cost models. People can remember them, and managers can check them in a few minutes.

A simple starting point is enough. Give each team a monthly AI budget cap. Set a per-user limit for paid tools. Require manager approval before anyone adds extra seats, buys more credits, or upgrades to a higher plan. Review spend once a month against actual use, not guesses made when the tool looked useful. Remove any paid tool that nobody used in the last 30 days.

The numbers matter less than the habit. If a 10-person team burns through credits in a week, that tells you something useful. Either the cap is too low for real work, or the team is paying for the wrong tool.

Keep the approval path short. One manager should be able to say yes or no within a day. If approval takes a week, people start using personal cards, free trials, or random browser tools. That creates a bigger problem than a slightly high software bill.

A monthly review is enough for most companies. Check total spend, active users, cost per active user, and tools with no recent use. If one tool has 25 seats but only 7 active users, cut the extra seats that same week.

This is where many small companies waste money. They do not blow the budget on one giant contract. They leak $20, $40, and $99 at a time until nobody knows what the company is paying for.

Draft the first version in one week

A usable policy does not take a month. Pick one owner, bring in finance, ops, and one manager from a team that already uses AI, and make decisions quickly. The first draft should fit on one page and answer three things: what data people can use, when they need approval, and how much they can spend.

You can do that in five days.

On day 1, make a plain tool inventory. List every AI tool people use, who uses it, and the job it helps with. Most companies find a mix of approved tools, free personal accounts, and small subscriptions paid with little oversight.

On day 2, sort data into four risk levels: public, internal, confidential, and restricted. Keep the labels simple enough that a manager can classify a document in a few seconds.

On day 3, map approval paths. Draft one path for routine work and one for sensitive work. Social posts or meeting summaries may need no extra sign-off, while customer data, source code, contracts, pricing, and HR records should go through a named approver.

On day 4, set spend caps. Give each team a monthly limit and set a company-wide ceiling. Start lower than you think you need. It is easier to raise a cap later than to explain a surprise bill.

On day 5, write the policy and test it. Ask three managers from different teams to use it on real cases from the past week.

That last test matters more than the wording. If one manager says a task is fine and another blocks it, the rule is still too vague.

Keep the first version plain and a little strict. You can loosen parts later. Loose rules turn into side deals and exceptions within days.

A simple example from a 50-person company

Picture a company with 8 people in sales, 12 in support, 3 in finance, and the rest in product, engineering, and operations. They do not use a long AI policy. They keep five rules on one page, and every team can follow them.

Sales uses AI every day, but only for low-risk work. Reps rewrite outbound emails, clean up rough call notes, and turn a messy follow-up draft into something clear and polite. They can paste their own text and general meeting notes, but they cannot paste full customer records, signed contracts, or anything that exposes private account details.

Support uses AI a little differently. Agents draft replies, summarize ticket history, and ask for clearer wording when a customer issue is hard to explain. A person still checks every message and sends the final answer. That step matters. It catches wrong instructions, odd tone, and details the tool invents.

Finance gets stricter rules. The team does not paste invoices, payroll data, bank details, or tax files into public tools. If someone wants help with a spreadsheet formula or a payment reminder, they use sample data or an approved internal tool instead.

The budget is just as clear. Sales gets $150 a month, support gets $200, finance gets $50, and product and engineering share $300. New tools do not enter the company by accident. Every request needs one owner, one budget line, and one approval path.

So a $20 writing tool for sales may need team lead approval. A $300 support tool that touches customer data may need the operations lead and CTO to review it first.

This is why small-company AI rules work best when they stay concrete. People know what data they can use, when a human must review the output, and how much they can spend before they ask.

Mistakes that make the policy harder to use

The fastest way to kill a policy is to write rules nobody can act on. "Use AI responsibly" sounds safe, but it tells people nothing. A support agent still does not know if they can paste a customer ticket into a tool, who approves a new subscription, or what monthly spend is fine without asking.

Another common mistake is sending every AI question to the CEO. That may work for a week. Then marketing waits two days to test a transcription tool, engineering stalls on a coding assistant, and the CEO becomes a help desk. A 50-person company needs simple approval lanes, not one bottleneck at the top.

Long documents create a different problem. Teams do not need one policy that mixes data handling, legal review, vendor buying, and expense approval into ten dense pages. Split the decisions. One short policy can cover what data people may share. A separate buying rule can say who can approve a free tool, a paid tool, or an enterprise contract. People follow shorter rules more often.

Many companies also pretend shadow use does not exist. That fails quietly. If sales already uses AI to draft follow-up emails and design uses it for mockups, a policy that ignores real behavior will not last. Ask each team what they already use, then set limits around that reality.

One rule should stay firm: a person reviews anything that reaches customers. AI can draft a help article, a product description, or a reply to a client. It should not publish on its own. Human review catches wrong claims, odd tone, and confidential details before they leave the company.

Good policies are usually boring on purpose. They say which data is allowed, restricted, or banned. They name who approves which tools and spend levels. They require human review for customer-facing output. And they fit on a page people will actually read.

That answers the real question employees have: "Can I use this tool for this task today?"

Quick checks before rollout

A short policy still fails if people need a manager, a lawyer, and three Slack messages to use it. Before you publish anything, test the draft like a normal workday rulebook. If people hesitate, ask follow-up questions, or guess, the rule is still too vague.

Run a few simple checks with real staff, not just leadership.

Give the policy to a new hire and ask one plain question: can you tell what data you may paste into an AI tool, what needs approval, and what is banned? If that takes more than five minutes, cut words and remove exceptions.

Ask a manager to approve a normal request, such as a small paid tool for meeting notes or drafting copy. If they need a meeting to decide, your approval path is too heavy.

Put an owner next to every paid tool. That person should know the monthly spend cap, who can use it, when it renews, and who shuts it off.

Mark the work that always needs human review. Customer emails, contract text, public posts, code pushed to production, and anything that touches private company or client data should never go out unchecked.

Practice removing one tool. Revoke access, stop billing, export any needed work, and tell staff what to use instead if cost or risk goes up.

A simple test makes the gaps obvious. Imagine a new employee joins on Monday and wants to use an AI tool to summarize sales calls. They should know within minutes whether call notes are allowed, whether the tool is approved, who signs off on a paid plan, and whether a human must review the summary before it goes into the CRM.

This is where most drafts break. They sound careful, but they do not help anyone make a fast decision. Clear rules let ordinary work move without guesswork.

If one page cannot pass these checks, do not add more pages. Rewrite the page you have.

What to do next

AI rules for a 50-person company do not need polish. They need a start date. Publish version 1, name one owner, and schedule a review for 30 days later. The first month will show where people get stuck, which tools nobody uses, and which approvals slow work for no good reason.

Train team leads first. They answer most day-to-day questions, so give them the policy before everyone else and walk through a few normal cases: using AI for internal notes, pasting customer data, or asking for a paid tool. After that, hold one staff session for questions. One clear meeting is better than a week of mixed answers in chat.

Track three numbers every month: active AI tools in use, total monthly AI spend, and approved exceptions to the policy. Those numbers tell you if the rules still fit the company. If tool count grows fast, check for overlap. If spend rises, ask which tools people use each week. If exceptions keep piling up, the rule is either too strict or too vague.

As the company grows, keep the policy short. Most teams do better with one page of rules and one page of examples than with a long document nobody reads. If a new rule does not change data access, approval flow, or spend limits, leave it out.

Some companies want an outside review before rollout. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this is the kind of practical policy review he helps teams with. It makes sense when the company already uses AI tools and needs clear limits on data, approvals, and spend without turning the policy into a legal memo.

A short policy that people use every week beats a perfect policy that sits untouched in a folder.