An employee can paste a customer complaint into a generative AI chatbot faster than a manager can approve the chatbot. That gap is why a small business needs an AI acceptable use policy before informal habits become normal practice.
I’d keep the policy short enough to use, but specific enough to answer three questions: Which tools are approved? What information can employees enter? Who checks the result before it affects a customer or a business decision? The AI policy template below gives you wording to adapt, plus the process needed to make it work.
What an AI Acceptable Use Policy Needs to Decide
An AI acceptable use policy sets boundaries for employees, contractors, and anyone else using AI for company work. It should cover generative AI, browser chatbots, coding assistants, automated agents, and artificial intelligence tools built into existing software. But a tool isn’t approved just because it appears inside an app your team already pays for.
I’d name one policy owner and keep a register of approved AI tools outside the policy. Each entry should identify the tool, its business purpose, permitted data, approved users, and relevant settings. A small business can keep this lightweight without adopting an enterprise AI governance program.
The policy also needs a route for mistakes. If someone enters restricted information into an unapproved tool, they need to know whom to tell immediately. A reporting rule is more useful than a blanket ban employees are afraid to admit they broke.
Set Data Rules Employees Can Apply
“Don’t enter sensitive data” leaves too much room for interpretation. I’d use three data classification categories and give employees a default when they’re unsure.
| Data Category | Examples | Default AI Rule |
|---|---|---|
| Public | Published product descriptions, public FAQs | Use in approved tools. |
| Internal | Unpublished plans, routine meeting notes | Use only when the tool and business purpose are approved for internal data. |
| Restricted | Customer records, employee details, credentials, confidential contracts, certain intellectual property | Don’t enter unless a documented exception approves the exact workflow. |
These categories support data privacy and data protection, but don’t replace legal review of contracts or compliance requirements. If you handle regulated information, have qualified counsel assess the rules that apply to your business.
Show What a Safe Prompt Looks Like
A marketer can ask an approved tool to draft variations of a public product description. Pasting an unpublished customer list to personalize those variations is a different use, even if the output looks harmless.
For HR, a prompt using a generic job description is easier to approve than one containing an applicant’s résumé and interview notes. Removing names alone may not remove identifying details.
Cover More Than Typed Prompts
The rule should apply to uploads, connected folders, browser extensions, meeting transcripts, and API requests. Employees may never type a secret into a prompt, yet a connected tool could still retrieve it. When the classification is unclear, I’d require the employee to stop and ask the policy owner.
AI Acceptable Use Policy Template: Scope and Tool Rules
Replace the bracketed fields, then check the wording against your actual tools and contracts. The text below is a working template, not a legal determination.
Scope and Approval
“Effective [Date], this policy applies to employees and contractors using generative AI tools for [Company Name] work, including AI features in existing software and automated workflows. [Policy Owner] maintains the approved-tool register at [Register Location]. Use a tool for company work only when its entry approves the specific account, configuration, task, and data category for your role.”
“Employees must not connect an AI tool to company accounts, repositories, drives, email, or customer systems without documented approval. Personal accounts and public AI tools aren’t covered by approval for a company-managed version.”
That distinction matters. Product names alone don’t tell you which account, settings, or contract govern a session. Check the relevant vendor terms and configuration before allowing company data into a tool, including how it handles training data and retention. These practices can vary by product and change over time.
Data and Prohibited Uses
“Public data may be entered into approved tools. Internal data requires approval covering that tool and purpose. Restricted data, including sensitive data, must not be entered, uploaded, or made accessible to AI tools unless [Approval Authority] has documented an exception for the specific workflow.”
“Employees must not submit passwords, access tokens, private keys, or other credentials to an AI tool. They must not use AI output to impersonate a person, disclose confidential information or intellectual property, or make an employment, financial, legal, or customer-impacting decision without the required human review.”
An approved-tool register should record exclusions as clearly as permissions. If a chatbot is approved for public marketing drafts, say so. Don’t let “approved” imply permission to analyze payroll records.
Policy Clauses for Review, Reporting, and Ownership
An AI acceptable use policy also has to address what happens after a model produces an answer. Permission to draft isn’t permission to publish, and AI generated content isn’t proof that its claims are correct.
Human Review and Automated Actions
“A person responsible for the work must review AI-generated facts, calculations, citations, code, and customer-facing material before use. Review must match the risk of the task. The reviewer must check source material for accuracy, intellectual property rights, privacy, or contractual commitments.”
“AI agents may not send external messages, change records, grant access, delete data, make purchases, or deploy code without documented approval for those actions and an appropriate human checkpoint.”
I’d assign the reviewer by job, not by vague references to “the team.” Our guidance on AI agent permissions and tool access explains why permission to read information should be separate from permission to act on it.
Incidents, Exceptions, and Acknowledgment
“Report a suspected data disclosure, unauthorized tool connection, or harmful AI action to [Incident Contact] through [Reporting Channel] as soon as it’s discovered. Preserve relevant details. Don’t conceal or independently delete evidence. [Incident Owner] will direct containment and any required notifications.”
“Exceptions require written approval from [Approval Authority], a defined business purpose, permitted data, controls, and an expiry or review date. Employees must acknowledge this policy before using AI for company work.”
I’d have counsel review the incident and decision clauses where contracts or sector-specific requirements apply. A copied policy can’t determine your notification duties.
Make New Tool Requests Boring and Fast
If approval takes months, employees have an incentive to work around it. I’d use a short request form and give every request a named owner.
Ask for the Workflow, Not a Product Pitch
The requester should describe the task, expected users, data categories, integrations, and whether the tool can take actions. “We want to try an AI assistant” isn’t enough to assess risk.
The reviewer can check vendor terms, retention settings, training data use, access controls, logging, and deletion options for the specific plan and configuration under consideration. They should also confirm how the plan handles intellectual property and what security controls it provides. If a tool connects to third-party services, review those connections too. Our guide to auditing third-party MCP servers goes deeper on integration risk.
Record a Decision That Can Be Revisited
Approve a limited pilot, reject the request with a reason, or request changes. Record who decided and whether the tool joins the approved AI tools list. Note what data is allowed and when approval expires or needs review. The same path should handle one-off exceptions.
A small company may not need enterprise AI software to start. A shared register can track requests, owners, and renewal dates. If that workload grows, AI governance platforms for small businesses are worth evaluating against it.
Control Shadow AI Without Pretending You See Everything
Shadow AI is employee use of tools the business hasn’t reviewed. The risk depends on what those tools can access and what employees send them. A standalone chatbot used for public copy creates different AI security risks than an unapproved extension connected to company email.
Start With Controls You Can Maintain
Publish the approved register, remove unnecessary app permissions, and use company-managed accounts where available. These are maintainable baseline measures within a broader cybersecurity strategy, not a substitute for one. Review connected applications and browser extensions during normal access checks. These steps cost less to operate than buying a monitoring platform before you know what problem it must solve.
If exposure warrants more control, assess browser, endpoint, or data loss prevention tools. Our review of prompt data loss prevention discusses one control category. Detection has limits: monitoring can miss unmanaged devices or encrypted paths, while broad rules can flag legitimate work. Check coverage, false alerts, privacy implications, staffing, and operating cost before deployment.
Treat AI Agents as a Separate Approval
A chatbot suggests text. An agent with connected tools may read files, update a CRM, and send messages. That creates AI security risks and could expose intellectual property. I’d require a separate review whenever an AI system can act outside its own interface.
Give the agent a named owner, narrow permissions, and a defined list of allowed actions. Record which identity it uses, what it can access, and how someone can stop it. Require approval before external sharing, payments, permission changes, deletion, or production deployments.
The OWASP Top 10 for LLM and GenAI can help identify risks such as prompt injection. It doesn’t prove an agent is secure. A malicious instruction in a retrieved document should not gain authority merely because an agent read it. Limit what the agent can do even when its response sounds confident.
Roll Out the Policy and Keep It Current
I’d start with a short employee briefing built around real tasks: a public marketing prompt, an HR record, and a connected agent. Ask employees to apply data classification to each one and find the approved-tool register. If they can’t, the policy needs clearer instructions. For the connected agent, use the OWASP Top 10 as a technical cross-check.
NIST’s AI Risk Management Framework and its generative AI profile, NIST AI 600-1, can help structure a broader review. Small businesses can adapt relevant guidance without copying an enterprise AI program. These are voluntary resources, not proof of compliance; legal and compliance obligations should be reviewed with qualified counsel. For a small business, the useful habit is to revisit the register after a tool, integration, contract, or workflow changes.
Key Takeaways
- Approve specific tools for specific work and data, not product names in general.
- Give employees a clear path to request tools and report mistakes.
- Keep human review between AI output and consequential decisions or actions.
Questions Worth Exploring Next
Three useful follow-up topics are how to audit an AI tool’s data settings, how to evaluate prompt data loss prevention, and how to set safe permissions for AI agents.
Frequently Asked Questions
Does a Small Business Need a Separate AI Policy?
I’d use a separate document if AI use crosses several teams or involves connected tools. If use is narrow, an existing acceptable use policy can carry these rules, provided employees can find the approved-tool register and reporting route.
Can Employees Use ChatGPT or Microsoft 365 Copilot?
Only if your business approves the specific account, configuration, task, and data category. Don’t infer privacy or retention rules from a product name. Check current vendor documentation and your agreement before approving sensitive workflows.
How Often Should the Policy Be Reviewed?
Review it when tools, integrations, data access, or applicable obligations change. Set a calendar review date as a backstop, and assign someone to own it. An unchanged PDF offers little protection when the approved workflow has changed.
Conclusion
The fastest way for an AI policy to fail is to leave employees guessing. I’d give them a short register, clear data categories, and a request path they’ll use.
Specific permissions matter more than a broad statement about responsible AI. They tell your team when a useful tool is safe for the job and when to stop and ask.
