Small businesses often adopt artificial intelligence one task at a time. A team member drafts an email, summarizes meeting notes, tests an image tool, or pastes a customer question into a chatbot. Each action may look minor. Together, they create decisions about data, accuracy, customer promises, security, and accountability.
An AI use policy turns those informal decisions into a short operating rule. It should tell people what they may use, what they must not enter, which outputs require human review, and who owns the final decision. The goal is not to predict every new tool. It is to make safe choices repeatable while the tools change.
This guide is for an owner or manager writing a first policy for everyday generative-AI tools. It is general operational guidance, not legal, privacy, employment, security, or regulatory advice. Requirements vary by location, industry, contract, and type of data, so obtain qualified advice where the stakes require it.
Begin with the work, not the technology
Start by listing the tasks for which the business is considering AI. Examples may include brainstorming, rewriting public copy, summarizing non-sensitive notes, drafting internal checklists, coding assistance, or producing first-pass images. Then describe the decision that follows each output. A low-stakes idea list is different from a price quote, hiring decision, safety instruction, financial statement, or customer commitment.
The NIST AI Risk Management Framework organizes AI risk work around govern, map, measure, and manage. NIST says the framework is voluntary, and its actions are not a universal checklist. For a small business, the practical lesson is to define context and responsibility before choosing controls.
Create a simple use-case register with five columns:
- task and intended outcome
- tool or service
- data that may be entered
- person who reviews the output
- consequence if the output is wrong or exposed
This register can be one page. Its purpose is to reveal where a casual experiment has become a business process. If nobody can name the owner, allowed data, or review step, the use case is not ready for routine use.
Set an approved-tool rule
A policy should name either approved tools or an approval process. “Use AI responsibly” is too vague because it does not tell an employee whether a free browser tool, personal account, installed extension, or paid business workspace is acceptable.
For each approved tool, record the business account owner, plan or workspace, enabled features, vendor terms reviewed, data-retention setting, model-training setting if available, access controls, and next review date. Do not assume that two plans from the same vendor handle business data in the same way. Verify the actual terms and settings that apply to the account being used.
The U.S. Federal Trade Commission has warned AI companies to honor privacy and confidentiality commitments. That does not replace a buyer's review. It is a reason to compare a vendor's promises with its contract, settings, and actual business need.
Include a route for temporary experiments. For example: an owner may approve a limited test using invented or public data, for a stated period, without connecting the tool to company systems. A successful experiment should still pass the normal approval process before it becomes routine.
Draw a clear data boundary
The most useful policy sentence may be a direct list of information that must not be entered into an unapproved AI system. Build that list from the data the business actually holds, not from a generic template.
A cautious starting boundary may prohibit customer personal information, payment data, health information, authentication secrets, private contracts, unpublished financial records, employee records, confidential client files, source code containing secrets, and third-party material the business is not permitted to share. Some businesses will need stricter or different categories.
The FTC's privacy and security guidance says businesses should honor the privacy promises they make. Its AI-related enforcement guidance also emphasizes that companies remain accountable for how consumer data is obtained, retained, and used. A small-business policy should therefore connect AI use to existing privacy, confidentiality, retention, and security obligations rather than treating AI as an exception.
Add one positive rule: use the minimum data needed for the task. Remove direct identifiers where that genuinely reduces risk, but do not assume this makes every dataset anonymous or safe. NIST's de-identification review explains that some de-identified data can sometimes be re-identified; the remaining risk depends on the data and context.
Keep a human accountable for the final output
“Human review required” is only useful when the policy explains what the reviewer must check. Name the role, the evidence, and the decision. A reviewer should not simply read an AI answer and decide that it sounds polished.
For public or customer-facing work, the review may include:
- checking factual claims against reliable sources
- recalculating numbers from the original records
- confirming names, dates, links, prices, and product details
- checking that private information was not introduced
- reviewing tone, bias, accessibility, and contractual commitments
- confirming that the named human accepts the final decision
NIST's AI RMF calls for documented roles and responsibilities and says processes for human oversight should be defined and assessed. It also recommends evaluating systems in conditions similar to where they will be used. That supports a practical rule: the reviewer needs the original context and authority to reject the output, not just a final draft.
Prohibit AI from making an unsupervised final decision where an error could materially affect a person's employment, credit, health, safety, legal position, eligibility, or access to an essential service. This is a risk boundary, not a complete statement of applicable law. Qualified review may require counsel or a domain professional.
Require evidence for factual claims
AI-generated citations, quotations, calculations, and summaries can be wrong even when they look specific. NIST's Generative AI Profile describes confidently presented false content and fabricated citations as forms of confabulation. The policy should require staff to open the original source, confirm that it exists, recalculate material numbers from authoritative inputs, and check that the evidence supports the proposed claim. A list of links produced by a model is not verification.
Use a simple evidence rule:
- Mark every material factual claim in the draft.
- Link it to a reliable source or an authoritative internal record.
- Record any qualification, date, jurisdiction, or limitation.
- Remove or rewrite the claim if support is missing.
NIST's Generative AI Profile identifies risks that are distinctive to or worsened by generative AI and proposes actions for managing them. NIST also notes that AI RMF 1.0 is being revised as of this article's research date. A policy should therefore name its source version and review date instead of presenting any framework as permanent.
For editorial work, preserve a claim ledger with the draft. For calculations, preserve the inputs and formula. For customer records, use the authoritative system rather than an AI summary as the final record. This is similar to building a customer feedback loop: keep the evidence separate from the team's interpretation.
Control customer-facing claims and disclosure
A business should treat every claim it chooses to publish or promise as its own review decision. An AI tool does not supply the evidence needed to make a performance claim, testimonial, comparison, guarantee, or disclosure accurate. The FTC's business guidance, including “Keep your AI claims in check,” warns businesses not to exaggerate what an AI product can do and to consider reasonably foreseeable risks.
Write two policy rules. First, no one may publish an unverified claim merely because an AI tool supplied it. Second, the person approving the final content owns the claim. If the business offers an AI-enabled service, describe what the service actually does and retain the evidence supporting performance statements.
Disclosure is context-dependent. A small business may decide to disclose AI assistance when customers would reasonably need that fact to understand how a service, recommendation, image, or interaction was produced. Do not invent a universal disclosure formula. Check applicable laws, platform rules, contracts, professional duties, and customer expectations.
Add security, access, and incident rules
AI tools should fit the company's existing security process. NIST CSF 2.0 includes identity management, authentication, and access-control outcomes; a proportionate small-business rule is to prefer business-managed accounts, limit access to what each role needs, remove access when a role changes, protect credentials, and review connected applications. Do not paste secrets into prompts or store them in reusable prompt libraries.
The joint NCSC and CISA-backed Guidelines for Secure AI System Development organize guidance around secure design, development, deployment, and operation. The guidance is aimed mainly at providers, including those building on external APIs, but it also asks managers and risk owners to make informed choices. Its secure-deployment section recommends explaining system limitations, failure modes, and where user data may be used, accessed, or stored.
A small business using third-party tools is not the same as an AI developer, so apply provider guidance proportionately. At minimum, define what staff should report: accidental sensitive-data entry, suspicious output, unexpected data exposure, a compromised account, harmful content, a customer complaint, or an important decision made without the required review.
The policy should name one reporting route and one owner. Depending on the incident and qualified response process, possible early actions may include pausing the affected use, preserving relevant records, restricting access, rotating exposed credentials, and seeking qualified help. The policy should not prescribe a fixed action that could destroy evidence, increase harm, or conflict with a legal or contractual duty.
Use a one-page policy structure
A first policy can be short if it points to supporting records. Use this structure:
- Purpose: why the business permits limited AI use.
- Scope: people, contractors, tools, accounts, and tasks covered.
- Approved use: approved tools and permitted use cases.
- Prohibited data and actions: information and decisions outside the boundary.
- Human review: named reviewer and checks required before use or publication.
- Evidence and records: sources, calculations, prompts, output, and decisions retained where appropriate.
- Security and incidents: access rules and reporting route.
- Ownership and review date: policy owner, effective date, version, and next review.
Keep the approved-tool register and use-case register as separate appendices. That allows the business to update a tool or task without silently rewriting the policy's core principles. Use version control appropriate to the business, and make the current version easy for staff to find.
Write the policy in plain language and test it against real scenarios. If an employee cannot decide whether a customer transcript may be summarized, the boundary is not clear enough. A good policy supports a quick “yes,” “no,” or “ask the owner” decision.
Roll it out in fourteen days
Days 1–3: inventory current AI use. Ask staff which tools, accounts, extensions, and connected applications they use. Record tasks and data types without punishing honest disclosure.
Days 4–6: classify the use cases. Separate low-stakes drafting from customer, financial, employment, safety, legal, or sensitive-data work. Pause any use that lacks a clear owner or data boundary.
Days 7–9: draft the one-page policy and registers. Choose approved tools, prohibited data, review rules, and the incident route. Ask a qualified adviser to review areas governed by law, contract, or professional duty.
Days 10–12: run scenario training. Give staff examples from their work and ask what they would do. Revise rules that produce inconsistent answers.
Days 13–14: issue version one. Record acknowledgement as appropriate, set the next review date, and assign an owner. Do not claim that the policy eliminates risk. It creates a repeatable way to identify and manage it.
An illustrative example
Imagine a six-person bookkeeping firm. The owner approves one business AI workspace for rewriting non-sensitive client education and drafting internal checklists. The policy prohibits client records, tax documents, bank details, passwords, and confidential correspondence. Every public claim must be checked against an official source, and a qualified staff member approves the final text.
A team member wants to summarize a client's uploaded ledger. The use-case register shows that financial records are prohibited in the approved writing tool, so the answer is no. The team instead uses its existing authorized accounting process. Later, it tests AI on an invented ledger to explore a workflow without exposing client data. This example illustrates a decision boundary; it is not legal or accounting advice.
The same firm adds an incident rule: if restricted information is entered accidentally, the user stops, records what happened, and contacts the named owner. The owner follows the firm's qualified incident process rather than improvising in the policy document.
Review the policy when the context changes
Set a routine review, but also trigger review when the business adds a tool, enables a new integration, changes a vendor plan, begins a higher-stakes use case, receives a material complaint, learns of an incident, or faces a new contractual or regulatory requirement.
NIST CSF 2.0 organizes cybersecurity outcomes around six functions, including Govern, and NIST's Small Business Quick Start Guide is intended to help smaller organizations begin a cybersecurity risk-management strategy. An AI policy should connect to that wider system. It is not a substitute for access control, privacy practices, vendor review, staff training, backups, or incident response.
Keep a short decision log: date, proposed use, data involved, reviewer, decision, conditions, and next review. For recurring operations, turn the approved process into a practical one-page SOP. The policy sets the boundary; the SOP explains how a specific task stays inside it.
What this policy cannot prove
A written policy does not prove that a tool is accurate, secure, lawful, fair, or suitable. Using a vendor does not remove the business's need to manage its own choices, data, review steps, and customer promises. It does not guarantee that staff will follow the rules, and it does not replace testing, monitoring, contractual review, or professional advice.
Do not claim compliance merely because a template exists. Evidence may include approved-tool records, training, access reviews, claim ledgers, incident logs, vendor decisions, and sampled output checks. The evidence should match the risk and applicable requirements.
Frequently asked questions
Should a very small business have an AI policy?
If people use AI for business work, a short policy can clarify tool, data, review, and accountability boundaries. The policy should be proportionate to actual use and risk; size alone does not answer which rules or legal duties apply.
Can employees use free AI accounts?
Only if the business has reviewed and approved the exact account, terms, settings, data handling, and use case. A personal or free account should not be assumed equivalent to a managed business service.
What data should never go into an AI tool?
There is no universal list. Start with confidential, regulated, personal, financial, authentication, employee, client, and third-party data the business is not authorized to share. Map the final boundary to applicable law, contracts, vendor terms, and professional advice.
How often should the policy be reviewed?
Choose a routine the owner can maintain and add event-based reviews for new tools, integrations, higher-stakes uses, incidents, material complaints, or changed requirements. Record the version and review decision.
Does human review make an AI output safe?
No. Human review is one control. It is useful only when the reviewer has appropriate expertise, original evidence, clear checks, and authority to reject the output.
Editorial sources
- National Institute of Standards and Technology, “AI Risk Management Framework.”
- NIST AI Resource Center, “AI RMF Core.”
- NIST AI 600-1, “Generative Artificial Intelligence Profile.”
- NIST, “Cybersecurity Framework 2.0 for Small Business.”
- NISTIR 8053, “De-Identification of Personal Information.”
- NIST, “CSF 2.0 Quick Start Guides.”
- Federal Trade Commission, “Keep Your AI Claims in Check.”
- Federal Trade Commission, “AI Companies: Uphold Your Privacy and Confidentiality Commitments.”
- Federal Trade Commission, “Privacy and Security.”
- UK National Cyber Security Centre and international partners, “Guidelines for Secure AI System Development.”