AI Policy for Small Business

§1Why “we do not use AI” is rarely safe

AI is embedded in writing assistants, meeting tools, design products, search, code editors, customer support, and accounting software. A company can use AI without buying a product called AI. An absolute denial is easy to disprove and difficult to maintain.

Do a factual inventory instead. Ask which tools people use, what work they use them for, and what information enters them. Include built-in features and personal subscriptions. The result may be modest, but it is defensible.

• List stand-alone AI tools and AI features inside existing software.
• Record the business task, data category, account owner, and client involved.
• Separate experimentation from recurring production use.
• Do not punish good-faith disclosure during the first inventory.

§2Client due diligence has reached small suppliers

Larger customers increasingly extend security, privacy, and AI questions through their supply chain. They may ask whether you train models on their data, use automated decisions, assess vendors, document incidents, or align with a framework. The questionnaire may be designed for a global software company even when you are a twelve-person agency.

Do not imitate enterprise language. Answer the actual question, define scope, state what you do today, and identify any documented improvement. A short policy, vendor register, training record, and completed review can support a stronger answer than an unsupported claim of full compliance.

§3Why enterprise frameworks do not fit unchanged

Enterprise frameworks assume specialist owners, formal committees, model inventories, independent validation, and reporting systems. Those ideas can be useful, but copying the machinery creates paperwork no one maintains.

Translate each objective into the smallest reliable control. A governance committee becomes one accountable owner plus a quarterly meeting with operations and security. A model inventory becomes a spreadsheet of approved tools and uses. Formal model validation becomes documented testing for the few outputs that affect customers or people.

• Keep one policy owner and one named backup.
• Use one approved-tool register rather than several inventories.
• Escalate by consequence, not by whether a tool sounds advanced.
• Keep evidence as part of ordinary work, not a separate theatre of compliance.

§4The minimum viable policy

Cover scope, approved tools, prohibited information, human review, disclosure, vendor approval, security, sensitive decisions, incident reporting, ownership, and review. The acceptable-use template walks through each clause.

The most important distinction is between everyday, reviewable assistance and uses that can materially affect a person or expose protected information. Let the first category move under clear rules. Stop and review the second.

§5A four-week rollout

In week one, inventory tools and appoint an owner. In week two, approve or pause each tool and write the policy around those decisions. In week three, explain the rules in a thirty-minute team session and provide a one-page summary. In week four, review the highest-risk vendors and answer one sample client questionnaire using evidence.

At the end, ask five employees to explain what data they cannot paste, which tools are approved, and where to report a mistake. If they cannot answer, the rollout is not finished.

• Week 1: inventory tools, uses, owners, and data.
• Week 2: make approval decisions and adapt the policy.
• Week 3: train the team with examples from their work.
• Week 4: test vendor review, incident reporting, and client answers.

§6Controls that earn their keep

Focus on controls that prevent plausible harm or create credible evidence: company accounts, restricted-data rules, human review, vendor terms, access removal, and incident reporting. Avoid elaborate scoring that nobody understands.

Keep a decision note for every approved tool: what it does, permitted uses, prohibited data, key vendor terms, owner, and next review. That single record supports employees, procurement, client answers, and policy review.

§7Training without a compliance lecture

Use three examples drawn from real work. Show an allowed low-risk task, a task that needs redaction or an approved environment, and a prohibited or escalated task. Ask the team to classify a few more. Specific examples reveal ambiguity faster than slides about principles.

Repeat the essentials in onboarding and when tools change. Short, timely reminders beat annual training that arrives months after behavior has formed.

§8What good looks like after 90 days

You should know what tools are in use, who owns them, what data is allowed, and when they were last reviewed. Employees should know where to ask and report. A client question should be answered from records, not reconstructed from memory.

You do not need to eliminate experimentation. You need a visible lane for it. Allow low-risk trials with synthetic or public information, a time limit, and no connection to company systems until review.

§9How to answer clients honestly

Describe the control and its scope. “Our documented policy applies to employees and contractors; approved tools are recorded by use case; client confidential data is prohibited unless the service is approved for it; outputs receive human review before delivery.” That is specific enough to verify.

If a requested control is not in place, say so and offer the nearest truthful safeguard. Never claim ISO certification, regulatory compliance, or continuous monitoring because the words seem reassuring.

§10Start with the next decision

Do not wait for perfect legal certainty. Decide who owns the policy, run an amnesty-based shadow AI audit, and make clear decisions on the tools already in use. Then adapt the acceptable-use template and test it against your next client questionnaire.

A small policy works when it reduces uncertainty in daily work. It is not a miniature enterprise program. It is a maintained set of promises you can keep.

§11Keep a small evidence file

Create one folder for the current policy, prior versions, the approved-tool register, completed vendor reviews, training acknowledgements, incident records, and quarterly review notes. Restrict access appropriately; evidence can contain vendor terms, employee names, security details, and information about mistakes. The point is retrieval, not public display.

Use ordinary dates and owners. A register row should show who decided, what evidence they considered, what limitations apply, and when the decision expires. A training note should show who attended, what scenarios were covered, and which questions remained open. If a control cannot leave a small trace, it will be difficult to explain six months later.

This file also keeps sales answers honest. Before sending an assurance, compare it with the policy and register. If a buyer requests a stronger control, treat that as a business decision: adopt and resource it, negotiate the requirement, or decline it. Do not let a hurried proposal quietly rewrite company practice.

§12Handle exceptions without breaking the rule

A useful policy needs an exception path because unusual client work, accessibility needs, and short tests will arise. Require a written request that names the tool, purpose, data, user, duration, and reason the approved route does not work. The policy owner should decide with security, privacy, or legal input when the consequence warrants it.

Make exceptions narrow and temporary. Record conditions such as synthetic data only, no integrations, named users, extra review, or deletion at the end of the engagement. Give every exception an expiry date. An exception with no boundary becomes an unofficial policy amendment.

Review expired exceptions for patterns. Repeated requests may show that the approved tool set is incomplete or that the rule is impractical. The answer may be a properly reviewed vendor, a clearer approved workflow, or a deliberate decision that the use remains outside risk tolerance.

§13Frequently asked questions