AI usage policy for small businesses: what to include

Your team is already using AI. Marketing is feeding campaign briefs into ChatGPT. Sales is drafting outreach emails with Claude. Finance is uploading CSV files to get pivot tables back. If you do not have an ai usage policy in place, you have no visibility into what data is leaving your perimeter, which vendors are processing it, or whether anyone has accidentally trained a public model on your client list.

The question is not whether you need a company ai policy. You do. The question is what to put in it so it actually gets followed. Most templates you will find online are either thousand-word legal documents nobody reads or vague 'be responsible' statements that give zero practical direction. This guide walks through the eight sections every ai policy for business must contain if you want it to work in a real SMB environment where people need to move fast and compliance cannot slow every decision to a crawl.

1. Scope: which tools, which teams, which use cases

**The first section of your ai usage policy defines boundaries.** Which AI tools are in scope? Which teams are covered? Which business functions can and cannot use AI assistance? Most SMBs make the mistake of writing a policy that only talks about generative text models and then wonder why it does not address the AI-powered CRM scoring tool the sales team adopted three months ago.

Your scope section needs to cover all AI systems: generative models like ChatGPT, Claude, and Gemini; AI agents that take actions on behalf of users; automated decision systems like lead scoring, fraud detection, or applicant ranking; and any third-party SaaS tools that use AI under the hood, even if the vendor does not headline it. If a system makes predictions, generates content, or automates decisions previously made by a human, it belongs in scope.

Define which teams the policy applies to. In most SMBs, the answer is everyone. If you carve out exemptions for specific departments, you create a compliance gap. The policy should also specify use cases that are prohibited outright, permitted with approval, and permitted without prior review. For example, using AI to draft internal meeting notes might be unrestricted, while using AI to generate client-facing legal advice requires sign-off.

Finally, include a version number and an effective date. Policies evolve. When you update Section 6 in three months, teams need to know they are looking at the current document. Klevere's /solutions/ai-strategy engagements typically start with a scope audit to map every AI touchpoint across the business before we draft the policy, because you cannot govern what you have not inventoried.

2. Approved tools and vendor standards

**This is the section that stops shadow AI.** An effective ai policy for business maintains a list of approved tools and sets the criteria a new tool must meet before it gets added. Without this, every department will adopt whatever they found on Product Hunt last week, and you will have no centralised view of your AI vendor surface.

Your approved tools list should include the tool name, vendor, primary use case, data residency region, and approval date. For example: OpenAI ChatGPT Enterprise (content drafting, US/EU data residency, approved March 2026), Anthropic Claude for Work (technical documentation, US residency, approved April 2026), HubSpot AI (CRM scoring, EU residency, approved January 2026). This is not about limiting innovation. It is about knowing where your data is going.

Set vendor standards that any new tool must meet before it can be added to the approved list. Common criteria include SOC 2 Type II certification, GDPR compliance if you handle EU data, a published data retention policy, the ability to opt out of model training, and contractual liability for data breaches. At Klevere, we hold ourselves to SOC 2 Type II, ISO 27001, HIPAA, GDPR, and CCPA. Those are the same standards we recommend SMBs require from their AI vendors.

Include a process for requesting a new tool. Marketing wants to trial a new AI video generator. What do they do? The policy should specify who reviews the request, what documentation the vendor must provide, how long the review takes, and who has final approval. In a 20-person company, this might be a simple form submitted to the operations lead. In a 200-person company, it might route through IT, legal, and finance. Either way, the process must be in the policy or people will skip it.

3. Data classification and handling rules

**The third section of your ai usage policy tells people what data they can and cannot feed into which systems.** This is where most policy failures happen, because the rules are either too vague to follow or so restrictive nobody can get work done. The fix is a clear data classification scheme tied to explicit handling rules for each category.

Start by defining three or four data tiers. A simple scheme that works for most SMBs: public data (anything already published or intended for public release), internal data (business information not intended for external sharing but not confidential), confidential data (client information, employee records, financial data, trade secrets), and regulated data (anything subject to GDPR, HIPAA, PCI-DSS, or other statutory requirements).

Then map each tier to specific AI use cases. Public data can be used in any approved tool without restriction. Internal data can be used in approved enterprise tools with data residency controls, but not in free-tier consumer AI products. Confidential data requires explicit client consent or anonymisation before it touches an AI system. Regulated data must only be processed in tools with the relevant compliance certifications, and only for purposes permitted under the regulation.

Give examples. Marketing can use ChatGPT Enterprise to draft a blog post because blog content is public data. Sales can use an AI agent to summarise deal notes because deal metadata is internal data and the tool is approved. Finance cannot upload a client invoice to Claude free tier because invoices contain confidential billing information. Support cannot paste a customer support ticket into a non-GDPR-compliant AI tool if the ticket contains EU personal data.

Make it explicit that screenshots, PDFs, and CSVs are data too. People instinctively know not to paste a client contract into a prompt, but they will happily upload a screenshot of that contract if the policy does not say otherwise. Klevere's /solutions/ai-audit process includes a data flow mapping session for exactly this reason. We trace where sensitive data appears in non-obvious formats, so the policy can address it.

4. Prompting standards and output review

**Section four governs how people interact with AI systems and what they do with the output.** The goal here is not to micromanage every prompt. The goal is to stop people from accidentally leaking data in a question or publishing AI-generated content without verification.

Set standards for prompt construction. Do not include personal identifiers like names, email addresses, or account numbers unless the tool is approved for that data tier. Do not paste entire documents if a summary or excerpt will do. Do not use prompts that ask the AI to make decisions the company has reserved for humans, such as hiring recommendations, credit approvals, or medical advice.

Require output review before any AI-generated content or decision reaches a customer, gets published externally, or informs a material business decision. This does not mean a lawyer has to read every email. It means the person using the AI is responsible for verifying the output is accurate, appropriate, and aligned with company standards. For client-facing content, a second set of eyes is non-negotiable.

Specify what people should do if an AI system produces something problematic: biased language, factually incorrect claims, confidential information it should not have access to, or advice that contradicts company policy. The answer is usually to flag it to a manager and log it in the incident process covered in section six. If your company ai policy does not tell people what to do when the AI messes up, they will either ignore it or panic.

5. Human oversight and decision authority

**This section draws the line between augmentation and automation.** Which decisions can an AI make on its own, and which require a human in the loop? In regulated industries like recruitment, finance, and healthcare, this is often a legal requirement. Even if it is not, it is good risk management.

Define decision categories. Operational decisions that do not materially affect individuals or the business can often be automated: scheduling social media posts, routing support tickets, generating data reports. Decisions that affect individuals or carry financial risk require human review before execution: rejecting a job applicant, approving a refund, assigning a credit score. Decisions that carry legal, safety, or reputational risk require human decision-making with AI as a supporting tool only: contract terms, medical diagnoses, regulatory filings.

For AI agents that take actions autonomously, set approval thresholds. An AI sales agent can send a follow-up email on its own, but it must escalate to a human if the prospect asks a question outside its training scope. An AI operations agent can reorder inventory below a certain value, but a human must approve purchases above that threshold. Klevere's AI OS includes configurable oversight controls for exactly this reason. The Chief of Staff agent can delegate tasks to other agents, but critical decisions still route to the relevant human owner.

Make it clear that the human who approves or publishes an AI output is accountable for it. The AI is a tool. The person wielding it owns the result. This is not about blame. It is about maintaining a culture where people do not outsource their judgment to a model.

6. Incident reporting and response

**Section six is your safety valve.** When something goes wrong with an AI system, your team needs to know how to report it, who investigates, and what happens next. Most SMBs skip this section entirely, which means the first time an AI agent sends a prospect the wrong pricing or a model hallucinates a false claim in a published article, nobody knows what to do.

Define what counts as an AI incident. Data leakage: confidential information was shared with an unapproved system or appeared in an AI output when it should not have. Bias or discrimination: an AI system produced output that could be construed as discriminatory based on protected characteristics. Factual errors: an AI system generated false information that reached a customer or informed a business decision. Security events: unauthorised access to an AI system or unusual usage patterns that could indicate compromise.

Set a reporting process. Incidents should be reported to a named individual or team within 24 hours. In a small business, this might be the operations manager or the person who owns IT. In a larger SMB, it might be a compliance lead or an AI governance committee. The report should include what happened, which system was involved, what data was affected, and what immediate containment actions were taken.

Define response protocols for each incident type. A data leakage incident might require notifying affected clients, filing a breach report with regulators if it meets reporting thresholds, and suspending access to the tool until the issue is resolved. A factual error might require issuing a correction, reviewing the prompting process, and adding a new output review checkpoint. Klevere's /solutions/ai-consulting engagements include incident response planning as a standard deliverable, because this is not something you want to figure out during a live incident.

7. Training and ongoing education

**Your ai usage policy is only as good as your team's understanding of it.** Section seven defines who gets trained on what, how often, and how you verify they have actually absorbed it. This does not have to be a formal certification programme. It does have to be more than sending a PDF and hoping people read it.

Set a baseline training requirement for all staff. Everyone who uses any AI tool in their work should complete a one-hour policy overview within 30 days of hire or within 30 days of the policy going live, whichever comes later. The training should cover the approved tools list, data classification rules, prompting standards, and how to report an incident. A recorded session or a simple slide deck with a short quiz at the end is usually sufficient.

Define role-specific training for higher-risk use cases. Teams that use AI agents to interact with customers should get additional training on output review and escalation protocols. Teams that handle regulated data should get training on the compliance requirements that apply to their AI use. Managers who approve new AI tools should understand the vendor standards and approval process.

Require refresher training when the policy is updated. If you add a new approved tool, change the data handling rules, or update the incident response process, the relevant teams need to know within a week. A short email summarising the changes and a link to the updated policy document is better than nothing. A 15-minute team call walking through the changes is better still.

Track completion. This does not require a learning management system. A shared spreadsheet with names, training dates, and version numbers is enough for most SMBs. The point is to have a record that shows everyone was trained on the current policy, which becomes useful evidence if you ever need to demonstrate you took reasonable steps to prevent a data incident.

8. Policy review and update cadence

**The final section of your ai usage policy commits you to keeping it current.** AI vendors change their terms, new tools launch, regulations evolve, and your business adopts new use cases. A policy written in January 2026 will be obsolete by January 2027 if you do not build in a review cycle.

Set a review schedule. Most SMBs should review their ai policy for business at least quarterly. If you operate in a heavily regulated industry or you are scaling fast, monthly is better. The review does not have to be a full rewrite every time. It can be a 30-minute check-in to confirm the approved tools list is accurate, the data handling rules still reflect how the business operates, and no new regulatory requirements have landed.

Assign ownership. One person or one team should be responsible for maintaining the policy. In a small business, this might sit with the operations lead or the founder. In a larger SMB, it might be a compliance officer or an AI governance committee. Whoever owns it needs the authority to make updates and the accountability to ensure they happen on schedule.

Trigger reviews after incidents. If your company experiences an AI-related data breach, publishes AI-generated content that turns out to be false, or gets called out for bias in an automated decision system, the policy should be reviewed within two weeks to determine whether a policy change could have prevented the incident. This is not about blame. It is about continuous improvement.

Publish a changelog. When you update the policy, document what changed and why. Version 1.1 (March 2026): added Anthropic Claude for Work to approved tools list, clarified data residency requirements for EU client data. Version 1.2 (June 2026): updated incident response process to reflect new regulatory reporting thresholds under the EU AI Act. This makes it easier for teams to see what is new without rereading the entire document.

How Klevere approaches AI policy and governance

**We have built AI usage policies for recruitment agencies, law firms, marketing agencies, and ecommerce businesses.** The structure above is the same across all of them. What changes is the specifics: which tools get approved, which data tiers apply, which decisions require human oversight, and what the incident thresholds are.

Klevere's /solutions/ai-strategy service includes a full policy build as a core deliverable. We start with a free 30-minute AI audit to map your current AI footprint and identify governance gaps. Then we draft a working ai policy template tailored to your industry, your data environment, and your risk appetite. We do not hand you a generic document and walk away. We run training sessions with your team, set up the approval workflows, and build the tracking tools you need to keep the policy alive.

For clients deploying Klevere's AI OS, the policy work is even more integrated. Each of the six agents in the OS - Chief of Staff, Sales, Marketing, Operations, Recruitment, Support - comes with pre-configured oversight controls, data handling rules, and escalation protocols that map directly to the policy sections outlined above. You are not bolting governance onto a black-box system. You are deploying a system designed to be governable from day one.

We also offer standalone /solutions/ai-consulting engagements for companies that need policy help but are not ready for agent deployment. A typical consulting sprint includes a current-state audit, a policy draft, a vendor assessment framework, incident response planning, and a training deck. Time from kickoff to a live, adopted policy is usually four to six weeks, depending on how quickly your team can review drafts and approve the approved tools list.

If you are earlier in your AI journey and just need to understand what good governance looks like, book a free audit at /contact. We will walk through your current AI usage, flag the highest-risk gaps, and give you a clear view of what a working ai policy for business would look like in your specific context. No sales pitch, no obligation. Just a practical 30-minute conversation with someone who has built this 50 times before.

The policy is not the hard part. Adoption is.

**You can write a perfect ai usage policy in a weekend.** The hard part is getting 30 or 50 or 200 people to actually follow it when they are in the middle of a deadline and ChatGPT is right there. That is why the policy needs to be short, specific, and anchored in real scenarios your team will recognise.

Avoid legal language. Write in plain English. Use examples. Make it scannable. A five-page policy that people can read in ten minutes and reference when they have a question is infinitely more valuable than a 30-page policy that lives in a drawer. The goal is not to cover every edge case. The goal is to give your team enough guidance that they make good decisions 95 per cent of the time and know when to ask for help the other 5 per cent.

Review this guide against your current setup. If you do not have an approved tools list, start there. If you have a list but no data classification rules, add that next. If you have both but no incident reporting process, that is your next build. You do not need to implement all eight sections at once. You do need to know which gaps you are carrying and have a plan to close them before they become problems.