What this policy is supposed to do
Small businesses usually do not need a 70-page AI governance manual on day one. They do need a shared answer to practical questions: Can I use this assistant with a customer email? May I upload a contract? Who approves a new tool? Can a manager use a model to rank applicants? What happens if I pasted the wrong thing?
I would treat the policy as a decision aid, not a declaration that the company is “AI compliant.” The document should make low-risk work easy, slow down high-risk work, and give employees a path to ask for help. NIST describes AI risk management through functions including govern, map, measure, and manage; a small company can use that idea without copying a large organization’s bureaucracy.
This guide provides a policy core you can adapt, followed by the operating details that make it work. Replace the bracketed owner, tools, data classes, and retention periods with your own information. Have the appropriate professional review the final document for your business, contracts, industry, and jurisdictions.
The one-page policy core
Purpose: We use approved AI tools to assist with drafting, organizing, research, analysis, and repetitive work while keeping people accountable for accuracy, privacy, fairness, security, and business decisions.
Approved use: Employees may use the tools listed by [owner] for public information, brainstorming, formatting, first drafts, internal checklists, and low-risk material. They must review outputs before relying on or sharing them.
Restricted use: Client information, contracts, pricing, financial records, employee information, customer records, confidential strategy, and regulated data require the approved tool, account, workflow, and reviewer named in [approval register].
Prohibited by default: Do not enter passwords, access tokens, payment credentials, Social Security numbers, protected health information, private client files, confidential negotiations, or unapproved employee records. Do not ask AI to make the final decision about hiring, firing, pay, promotion, legal rights, medical care, safety, or eligibility.
External work: A human owner must check facts, sources, names, numbers, commitments, confidentiality, accessibility, and tone before AI-assisted content goes to a customer, client, employee, regulator, public channel, or contract.
Report quickly: If restricted information is entered, an output contains a serious error, or an AI workflow produces a harmful or unexpected result, stop using the workflow and contact [incident owner] at [contact]. Do not delete evidence or quietly repeat the error.
Use three approval levels instead of one giant list
A policy becomes hard to follow when every use case is treated the same. I prefer three levels that employees can recognize quickly. The levels describe the workflow, not the model’s intelligence. A powerful model handling public text can be lower risk than a simple automation connected to employee records.
| Level | Typical work | Minimum control |
|---|---|---|
| Green: low risk | Brainstorming, public research, grammar, generic outlines, internal formatting. | Approved tool, ordinary human review, no restricted data. |
| Amber: controlled | Client drafts, internal reports, pricing analysis, customer context, workflow automation. | Named owner, approved account, data minimization, source check, reviewer, storage and deletion rule. |
| Red: restricted | HR decisions, legal advice, health information, security incidents, payment data, confidential strategy. | Do not use by default. Require specific approval, qualified review, and a documented purpose if allowed at all. |
The point is not to turn a green workflow into a committee meeting. It is to give an employee a safe default when they are under time pressure. “I am unsure whether this is amber” should lead to a person or form, not a guess.
Name the tools and accounts, not just the brand names
“ChatGPT is approved” is not a complete policy statement. Which plan? Which workspace? Which administrator? Can the tool connect to Drive, Gmail, Slack, a CRM, or a code repository? Who can see chats and generated files? What happens when an employee leaves?
Create an approval register with one row per tool or integration. Record the business owner, purpose, account type, permitted data class, connected systems, human reviewer, retention and deletion behavior, vendor terms reviewed, and date for the next review. If a vendor changes a material control, the owner should reassess the row rather than assume the old approval still applies.
For a small team, this can be a protected spreadsheet or a versioned document. It does not need an expensive governance platform. What matters is that employees can find the current list and that an old screenshot cannot be mistaken for the current rule.
Tool approval record
Tool and account: [exact product, plan, workspace, integration]
Owner: [person responsible]
Purpose: [specific business outcome]
Allowed data: [public, internal, confidential, restricted]
Connected systems: [email, storage, CRM, code, calendar]
Review: [human reviewer, source check, output destination]
Next review: [date or trigger]
Data classification that employees can remember
Data labels fail when they sound like a security textbook. I would teach four labels with examples from the actual business. “Public” can be shared without a special restriction. “Internal” is business material that should stay in approved workspaces. “Confidential” could harm a customer, employee, partner, or the business if exposed. “Restricted” carries legal, contractual, safety, financial, health, credential, or security consequences.
Then add a transformation rule: remove names, identifiers, exact prices, account numbers, and private details before moving a document into a lower-risk workflow. Redaction is a risk-reduction technique, not permission to ignore the source data’s obligations. A redacted contract may still reveal negotiation strategy.
| Class | Examples | Default AI rule |
|---|---|---|
| Public | Published web copy, public product documentation, generic examples. | Green use in an approved tool; check output accuracy and rights. |
| Internal | Non-public plans, generic meeting notes, internal process drafts. | Approved business account; do not connect extra systems without review. |
| Confidential | Client strategy, contracts, pricing, customer histories, employee feedback. | Amber workflow with minimization, owner, reviewer, and storage rule. |
| Restricted | Passwords, payment credentials, health data, government IDs, security incidents. | Do not enter by default; use the approved specialist process. |
Human review is a control, not a magic sentence
Many policies say “a human reviews AI output” and stop there. I would define what that reviewer must check. For a public article, the checklist may include sources, facts, claims, images, accessibility, and copyright. For a client proposal, it includes scope, price, promises, and confidential details. For a customer support reply, it includes policy, account history, tone, and escalation.
The reviewer must have enough context and authority to reject the output. A junior employee asked to approve a legal conclusion they cannot evaluate is not a meaningful human-in-the-loop control. The policy should name when to escalate to a manager, subject-matter expert, security owner, HR lead, or lawyer.
For external claims, the FTC says businesses must honor privacy promises and should not make unsupported or deceptive claims. For AI-assisted work, that means a polished sentence is not evidence. Keep the source, the reviewer, and the final approved version together where practical.
Employment, legal, health, and financial uses need a hard stop
Small businesses often reach for AI in hiring, performance reviews, customer eligibility, collections, contract review, medical-adjacent work, or financial recommendations because the work is repetitive. Repetitive does not mean low risk. The person affected may have no idea an automated system influenced the outcome.
The EEOC has warned that software and AI used in employment decisions can disadvantage people with disabilities, including through screening and assessment. The policy should therefore prohibit silent automated rejection or ranking and require accessibility, accommodation, validation, documentation, and qualified review for any proposed employment use.
Legal and medical output should be treated as drafting or research support at most unless a qualified professional has designed and approved the workflow. Financial or safety-critical output needs an equivalent domain owner. The policy should make “ask the owner” easier than quietly improvising.
Client work, copyright, and public publishing
A client contract may restrict where data goes, who can subcontract, how confidential information is handled, or whether AI use must be disclosed. The policy should tell an employee to check the agreement before connecting a client workspace or using a client’s material in a new tool. “The vendor says it is secure” does not override the contract.
For public content, the reviewer checks more than grammar. They verify claims, quotes, sources, privacy, brand promises, and rights to images or text. The U.S. Copyright Office’s current material explains that copyright protection depends on human authorship and that the mere provision of prompts is not enough by itself. A business should keep meaningful human contribution and source records where ownership matters, and should get advice for its particular work.
Do not use a policy as a way to promise that every AI output is original, unbiased, private, or legally safe. Those are claims that need evidence and careful wording. A good policy makes uncertainty visible.
Incident response: make the first ten minutes obvious
People hide mistakes when a policy sounds punitive or vague. The policy should say what to do after a restricted paste, exposed secret, wrong client email, fabricated claim, biased recommendation, or unexpected automation. The first instruction is to stop the workflow and preserve the facts, not to keep trying prompts until the result looks better.
- Stop using the affected workflow and do not forward the output.
- Contact the named incident owner using the fastest available channel.
- Record the tool, account, time, data category, recipients, and actions already taken.
- Preserve relevant messages, settings, logs, and versions without spreading the restricted content.
- Let the owner determine notification, containment, deletion, contractual, security, HR, or legal steps.
- Update the policy or approval record after the review so the same failure is easier to prevent.
The employee should not be asked to decide whether a breach, violation, or legal duty occurred. Their job is to report quickly and accurately. The owner coordinates the response with the people qualified to assess it.
Five prompts for operating the policy
1. Turn business rules into an employee example
Using the policy below, create a table with four columns: situation, allowed, needs approval, and prohibited. Include what the employee should do instead when a request is prohibited. Use plain language and do not add a rule that is not present in the policy.
2. Review a proposed AI workflow
Review this proposed AI workflow. Identify the business purpose, data entering the tool, output leaving the tool, affected people, tool and account, human reviewer, system of record, client or contractual impact, failure mode, and deletion requirement. Mark each field COMPLETE, MISSING, or NEEDS OWNER. Do not approve the workflow.
3. Red-team a prompt before use
Check this prompt for secrets, personal information, confidential client material, protected health information, employee data, copyrighted material, unsupported claims, and instructions that ask the model to make a consequential decision. Return the risk and a safer redacted version. Do not reproduce sensitive content.
4. Prepare a manager review
Create a manager review checklist for this AI-generated output. Check facts, source support, names, numbers, dates, accessibility, bias, privacy, client commitments, tone, and whether the output is being used for a decision that requires a qualified human. Leave UNKNOWN where the source does not support a conclusion.
5. Write an incident summary
Using only these confirmed facts, draft an internal AI incident summary with date, people notified, tool, data involved, actions taken, current risk, evidence preserved, and next owner. Separate confirmed facts from assumptions. Do not assign blame or make a legal conclusion.
Roll it out in two weeks, not one announcement
Days one and two: inventory the tools employees already use, including personal accounts and browser extensions. Do not punish people for answering honestly; you need a realistic starting point. Identify the data classes and the three workflows that matter most.
Days three and four: approve or reject the initial tools and create the policy core. Name the owner, incident contact, document location, and review date. Ask a non-manager to read the policy and point out any sentence they cannot act on.
Days five through seven: run a short training with real examples: a safe public prompt, a redacted internal prompt, a prohibited data example, an external-output review, and an incident report. Have employees practice what they would do instead of only signing an acknowledgment.
Week two: approve a small number of workflows, collect questions, and revise confusing rules. Track acknowledgment, approved workflows, questions, near misses, incidents, time saved, and corrections. A policy that blocks every use will be bypassed; a policy that approves everything is not a control.
My recommendation
Start with a one-page employee rulebook and a separate approval register. Keep the core short enough to read before a person pastes information into a tool. Put the detail in examples, workflow records, and escalation paths.
Make low-risk work easy, make high-risk work visible, and keep accountable people responsible for decisions. Review the policy whenever the tool landscape, client work, data access, or a failure changes. NIST’s framework is voluntary, but its emphasis on continuous governance is a useful discipline for a company of any size.
The goal is not to eliminate judgment. It is to give judgment a place in the workflow before an AI output becomes a promise, a publication, a personnel decision, or a security incident.