An AI Use Policy for Small Business: A Practical Structure

AI often enters a small business before any rule does. One person summarises meetings, another uploads a contract to a chatbot, and somebody connects a writing assistant to email. A total ban tends to push this activity out of sight. Unconditional permission leaves employees alone with the risk.

A short policy should help somebody make a decision at the moment of use: which products are approved, what information must stay out, where review is required and who owns the consequences. The framework below is a starting point, not a universal legal form. Requirements depend on jurisdiction, industry, contracts and the way a system is used.

1. Purpose and scope

Begin plainly. The policy applies to employees, contractors and generative tools that create or analyse text, images, audio, code or other information for company work.

State the purpose: to use AI where it improves quality or efficiency without undermining confidentiality, individual rights, security and professional duties. Name the person responsible for the approved-tool list and exceptions.

Avoid a long abstract definition of artificial intelligence. Give recognisable examples: a chat assistant, transcription bot, image generator, office-suite feature or AI extension in a code editor.

2. Data classification

A simple classification is more useful than “do not upload sensitive data”:

• Public: already published material and open data that may be processed in an approved service.
• Internal: drafts and internal processes allowed only in a suitable company account under approved terms.
• Confidential: client records, contracts, finance, personal data, source code and trade secrets; transfer needs specific assessment and safeguards or is prohibited.
• Strictly restricted: passwords, keys, payment details, health information, legal strategy and other designated classes; never placed in general AI services.

Adapt the classes to your contracts. Include examples of fields and documents, not just abstract labels. Apply data minimisation even with an approved service: provide only what the task requires.

3. Approved tools and accounts

Maintain a short register containing product, owner, approved uses, allowed data, retention terms and last review. Staff use a business account where provided and do not independently connect unknown extensions to company email or storage.

Review data-use terms, region, deletion, provider access, logs, multifactor protection, export and incident notification. A page of certification logos does not replace checking the contract and configuration.

4. Human accountability and review

Treat AI output as a draft until an accountable person has checked it. Specify minimum review by output:

• facts, quotations and links are checked against primary sources;
• code receives ordinary review and tests;
• images are examined for rights, misleading context and personal information;
• customer messages are checked for promises and correct details;
• decisions about employment, credit, health or individual rights are not delegated without specialist approval and appropriate oversight.

The author or operator remains accountable for the final result. “The model said so” does not explain a decision.

5. Prohibited uses

A baseline list should include:

• entering passwords, tokens or secret keys;
• concealing AI use when a contract requires disclosure;
• generating false reviews, evidence, identities or quotations;
• imitating a person’s voice or face without clear consent and a lawful purpose;
• automatic publication, payment or deletion without approved controls;
• using output with apparent infringement of copyright or other rights;
• bypassing security settings for convenience.

Your sector may require more. Do not rely solely on a list; provide a quick route for asking about a new use case.

6. Transparency with customers and audiences

Disclosure is appropriate when AI materially shaped a deliverable, a contract requires it, or silence would reasonably mislead somebody. Be specific about which part involved a system and what a person reviewed.

Not every grammar correction needs a banner. Context and audience expectations matter. A synthetic depiction of a real event, automated customer advice or AI analysis of personal data deserves much greater scrutiny.

7. Incidents and reporting

Employees need a known response to an accidental upload, exposed key, unsafe answer or incorrect automated action. Name one contact and encourage rapid reporting without punishing an honestly reported mistake.

The owner records the system, data, time, access and containment; revokes secrets and fulfils contractual or legal notification duties. After an incident, update permissions, workflow and evaluation cases—not just the prompt.

8. Training and review

Run short training with company-specific examples: one approved request, one prohibited request and one that needs permission. People should be able to recognise confidential data, verify an output and report a problem.

Review the register and policy at least every six months and after an important new service, contract change or incident. Use a risk-based approach such as the NIST AI Risk Management Framework and OECD AI Principles. Organisations operating in the EU should separately assess obligations under the EU AI Act.

A good policy may fit on a few pages. Its strength is not legal-sounding prose. It is whether an employee can find an answer before uploading the file rather than after an incident.