playbook
How to write an AI usage policy for a 10-person company
A short AI usage policy framework for small companies that need rules before employees use AI tools with work data.
Target users
This playbook is for a 10-person company that wants employees to benefit from AI without creating unmanaged data exposure.
The goal is not to write a long legal document. The goal is to give employees a rule they can remember, give managers a way to approve new tools, and give customers confidence that sensitive data is not being copied into personal AI accounts.
Policy goals
The policy should answer six questions:
- Which AI tools are approved?
- What data is allowed?
- Which integrations require approval?
- Who owns admin settings and offboarding?
- When must a human review AI output?
- How often will the policy be reviewed?
For a small company, the best first version is a one-page operating rule backed by a short approval process. NIST’s AI Risk Management Framework describes AI risk management across govern, map, measure, and manage functions; a 10-person company can translate that into ownership, approved use cases, review checkpoints, and follow-up cadence rather than a heavy committee process.
Who owns the policy
Assign one named owner and one backup:
| Role | Owner | Responsibilities |
|---|---|---|
| Policy owner | Founder, operations lead, or security-minded manager | Maintains the policy, approves exceptions, reviews tools quarterly. |
| Admin owner | Workspace admin or technical lead | Configures managed workspaces, removes departed users, checks integrations. |
| Department reviewer | Team lead closest to the workflow | Reviews use cases that touch customer, financial, legal, or employee data. |
| Employee | Every AI user | Uses approved tools, follows data rules, reports mistakes quickly. |
Do not leave ownership with “everyone.” In a 10-person company, that usually means nobody will check settings, renewals, browser extensions, or departing-user access.
One-page policy template
Copy this baseline into your handbook, then replace the bracketed parts:
AI Usage Policy
Owner: [name]
Last reviewed: [date]
Approved tools:
- [Tool 1] for [allowed use cases]
- [Tool 2] for [allowed use cases]
Employees may use approved AI tools for:
- Drafting, summarizing, brainstorming, research, and internal productivity work.
- Public information and non-sensitive company information.
- Customer or employee data only when the tool, workspace, and use case have been approved.
Employees must not enter:
- Passwords, API keys, private keys, recovery codes, or security tokens.
- Payment card data, bank data, payroll data, health data, legal records, or government identifiers.
- Confidential customer data unless explicitly approved.
- Source code from restricted repositories unless explicitly approved.
- Non-public financials, acquisition plans, board materials, or sensitive HR information.
AI output must be reviewed by a human before it is sent to customers, used in production code, relied on for legal or financial decisions, or copied into a public document.
New AI tools, browser extensions, integrations, meeting bots, custom GPTs, agents, and file connectors require approval before use with work data.
If an employee accidentally enters restricted data into an AI tool, they must notify [owner] the same business day.This template is intentionally short. If your company handles regulated records, customer security questionnaires, protected health information, payment data, or contractual confidentiality obligations, treat this as a starter and have counsel or a qualified security advisor review it.
Data classification table
Use a simple data rule employees can apply without reading a security framework:
| Data type | Examples | Default AI rule | Approval path |
|---|---|---|---|
| Public | Blog posts, public docs, public pricing, marketing copy | Allowed in approved tools | No special approval. |
| Internal low-risk | Internal meeting notes without sensitive names, process drafts, generic templates | Allowed in managed approved tools | Team lead may approve recurring use. |
| Confidential company data | Roadmaps, private metrics, investor updates, internal strategy, non-public financials | Do not paste by default | Policy owner approval required. |
| Customer data | Names, emails, tickets, contracts, usage logs, support transcripts | Do not paste by default | Policy owner plus customer-data owner approval required. |
| Regulated or high-risk data | Payment data, health data, legal files, government IDs, payroll, secrets, credentials | Prohibited unless formally approved | Legal/security review required before any use. |
| Source code | Public repo code, internal app code, customer code | Public code may be allowed; private code requires controls | Technical lead approval required. |
The easiest practical rule: if the data would be awkward in a forwarded email to the wrong customer, do not paste it into an AI tool without approval.
Approved tools list
Small teams should prefer managed business workspaces over personal accounts when work data is involved. OpenAI says business products such as ChatGPT Business, ChatGPT Enterprise, ChatGPT Edu, ChatGPT for Healthcare, ChatGPT for Teachers, and the API platform are not used for model training by default. That does not make every use safe, but it is a better baseline than unmanaged personal accounts.
Track approved tools in a table:
| Tool | Status | Approved uses | Data allowed | Required settings |
|---|---|---|---|---|
| ChatGPT Business | Approved if workspace is managed | Drafting, research, summaries, internal productivity | Public and internal low-risk by default | Workspace admin, member offboarding, sharing controls reviewed. |
| Claude Team | Approved if workspace is managed | Drafting, analysis, document summaries | Public and internal low-risk by default | Team workspace, access review, data settings checked. |
| Notion AI | Conditional | Drafting inside existing docs | Depends on workspace content | Confirm workspace sharing and external guest access first. |
| AI meeting bot | Conditional | Recording and summarizing approved meetings | Depends on meeting content | Consent, retention, bot access, and transcript sharing reviewed first. |
| Browser AI extension | Conditional | Page summaries or writing help | Public pages only by default | Permissions reviewed; no broad access to all sites unless approved. |
This table should live where employees already look for operating rules: handbook, wiki, Notion, Google Drive, or the internal security page.
Tool approval process
Use a lightweight request process instead of informal Slack approval:
- Employee submits the tool name, vendor URL, intended use, data types, integrations, and whether files or browser pages will be shared.
- Policy owner checks whether the use case touches customer, financial, legal, HR, credential, or source-code data.
- Admin owner checks whether the tool supports managed accounts, member removal, sharing controls, data export, and audit or usage visibility.
- Department reviewer checks whether AI output will affect customers, contracts, hiring, pricing, security, or production systems.
- Owner records the decision as approved, conditional, pilot-only, or rejected.
Approval should be fast for low-risk tools. The point is to catch risky data flows, not to block every productivity experiment.
Prohibited uses
These should be blocked unless the policy owner has made a written exception:
| Prohibited use | Why it matters |
|---|---|
| Pasting credentials, API keys, private keys, seed phrases, or recovery codes | Secrets can grant direct system access and are hard to contain after exposure. |
| Uploading customer contracts or support exports into personal accounts | Customer obligations often restrict where data can be processed. |
| Connecting AI tools to email, Drive, Slack, CRM, GitHub, or calendar without approval | Connectors can expose far more data than a single prompt. |
| Installing AI browser extensions with broad page access | Extensions can read pages, forms, and app content depending on permissions. |
| Sending unreviewed AI output to customers as factual, legal, financial, or security guidance | AI output can be wrong, stale, or missing context. |
| Using AI-generated code in production without review | Generated code can introduce licensing, security, and reliability issues. |
Human review rules
Require human review before AI output is used in:
| Output type | Required review |
|---|---|
| Customer emails or support replies | Employee checks accuracy, tone, and confidentiality. |
| Security, legal, financial, medical, or compliance content | Qualified owner reviews before external use. |
| Public website content | Editor checks facts, sources, and claims. |
| Production code | Developer reviews, tests, and scans before merge. |
| Hiring, promotion, or disciplinary decisions | AI may assist drafting only; a manager makes and documents the decision. |
Employee acknowledgment
Have every employee acknowledge the policy once, then repeat after major updates:
I have read the company AI Usage Policy.
I will use only approved AI tools for work data.
I will not paste restricted data, credentials, customer confidential data, or regulated records into AI tools unless approved.
I will request approval before using new AI tools, agents, meeting bots, browser extensions, or data connectors with work data.
I will review AI output before using it in customer-facing, production, legal, financial, hiring, or security workflows.
I will report accidental restricted-data exposure to the policy owner promptly.Store acknowledgments in your HR folder, employee onboarding checklist, or compliance tracker.
Review cadence
For a 10-person company, use this rhythm:
| Cadence | Action |
|---|---|
| New hire | Add policy acknowledgment to onboarding. |
| Monthly | Review approved tools, user access, departed users, browser extensions, and high-risk exceptions. |
| Quarterly | Re-check vendor data controls, workspace settings, new integrations, and customer contract requirements. |
| After incidents | Update the policy if an employee pastes restricted data, installs an unsafe extension, or connects an unapproved data source. |
| After major vendor changes | Re-review if a tool changes product names, data retention, training defaults, admin controls, or connector behavior. |
NIST’s AI RMF playbook frames AI risk management as an ongoing process, not a one-time document. Keep a dated review log so the policy does not become stale.
Rollout plan for a 10-person company
Day 1:
- Name the policy owner and admin owner.
- Publish the one-page policy.
- List currently used AI tools and personal accounts.
Week 1:
- Move work use into managed workspaces where possible.
- Disable or remove risky browser extensions.
- Create the tool approval form.
- Add policy acknowledgment to onboarding.
Month 1:
- Review the first batch of tool requests.
- Check whether employees understand the data classification table.
- Add missing examples from real workflows.
- Revisit the Small Team AI Security Checklist.
Evidence checked
- NIST AI Risk Management Framework
- NIST AI RMF Playbook
- CISA AI resources and secure AI guidance
- OpenAI business data privacy
- OpenAI data use policy for model improvement
- Claude Code data usage
FAQ
Can employees use free AI accounts?
They can use free accounts for public information if your policy allows it, but work data should default to managed business workspaces. Free personal accounts are harder to administer, audit, offboard, and align with customer obligations.
Does “not used for training by default” mean the data is safe?
No. Training defaults are only one control. You still need to check retention, sharing, admin access, connectors, data exports, user permissions, and whether the employee is allowed to send that data to the vendor.
Should we ban all customer data in AI tools?
For a small company, the safest default is no customer data unless the tool, workspace, contract, and use case have been approved. If you later approve a specific workflow, document exactly which customer data is allowed and who can use it.
What should employees do after a mistake?
They should notify the policy owner the same business day with the tool, account, data type, approximate time, and what was entered. Do not punish fast reporting; delayed reporting is what makes exposure harder to contain.
Who should approve AI meeting bots?
The meeting owner and policy owner should approve them before use. Meeting bots can capture customer conversations, employee names, sales discussions, financial information, and sensitive internal decisions, so they need a stricter rule than ordinary drafting tools.
Recommended next step
Pair the policy with the AI Tool Risk Checker for new tool requests and the Small Team AI Security Checklist for monthly reviews.