Managing AI Use in a Small Business

A sales colleague uses an assistant to prepare proposals. Operations summarises supplier documents in another tool. Customer support experiments with suggested replies. Each activity may seem modest, but the business now has several routes through which information can leave its normal systems or influence customer-facing work.

Before writing a policy, establish what is happening. Ask teams to describe the task, the tool, the information entered and what happens to the output. Include features built into existing software as well as standalone subscriptions. The word “AI” on a purchasing record will not necessarily reveal every use.

Keep this exercise factual. Staff need a practical way to disclose experiments and seek advice. If the only visible response to uncertainty is prohibition, the organisation may learn less about what people actually do.

The inventory can begin as a short register. Record an owner for each use, the group of users, relevant data, whether outputs reach customers and any actions the system can take. Add the supplier and renewal information so responsibility survives a colleague leaving.

A policy cannot supervise a tool whose use nobody can describe. The register provides a starting point for proportionate controls and a way to spot duplication. It may also reveal that a tool is solving a genuine operational problem the formal systems have left unattended.

For a small business, this visibility is an immediate management gain. It replaces a vague debate about whether AI is allowed with a concrete discussion about particular work.

Drafting an internal agenda and determining a customer's eligibility for a service deserve different treatment. The relevant distinction is the consequence of an error, the sensitivity of the information and the authority granted to the system.

Use those factors to establish a few practical review levels. Low-impact assistance may require approved tools, basic data restrictions and user responsibility for checking the output. Customer-facing work may need a named reviewer and an approved source of information. Systems that change records, spend money or affect important rights require more explicit authority and assessment.

NIST's AI Risk Management Framework provides a voluntary basis for considering AI risks in context. It can inform this assessment without becoming a claim that a small business has achieved a certification.

For each proposed use, write a short failure scenario. A draft contains an outdated price. A summary omits a contractual condition. An assistant sends private information to the wrong account. Then identify what would prevent, detect or contain that event. This produces a more practical discussion than an abstract label such as “medium risk”.

Assign responsibility to someone able to act on the finding. A business owner may accept a commercial trade-off; a technical owner may implement access controls; a process owner may supervise daily use. One person can hold several roles in a small firm, but the responsibilities still need to be distinguishable.

Where sector or country obligations apply, obtain the appropriate local advice. A general internal policy cannot resolve every legal question across markets.

A rule saying “do not share confidential information” is too broad to guide everyday work. Staff need examples of what they may enter, what must be removed and which approved route can handle information that an ordinary tool cannot.

Define the categories that matter to the business: customer contact details, payment information, employee records, commercial contracts, credentials and sensitive sector data. Decide which tools may process each category and under what conditions. Check supplier settings and contractual terms rather than assuming a paid account resolves every concern.

Limit access to the task. A proposal assistant may need an approved service catalogue and selected enquiry details. It does not automatically need the full customer database. The US Federal Trade Commission's business security guidance recommends limiting retained information and controlling access; these principles can inform the technical design.

Apply the same specificity to actions. Distinguish producing a draft from sending it, recommending a change from saving it, and identifying a potential payment from initiating one. A written prohibition has limited value if the integration still grants broad permissions.

Give users a safe route when the approved setup is insufficient. They should know whom to ask, what context to provide and how to complete urgent work while a request is assessed.

This is where cybersecurity and AI implementation meet. Governance becomes credible when the account permissions, integrations and everyday interface reflect the boundaries the business has agreed.

An approved use can become a different use over time. A summarisation tool gains a connection to customer records. A draft-only assistant starts sending messages. A supplier changes an important setting. The original review no longer describes the system staff are operating.

Identify changes that require another look. New data categories, new external recipients, additional actions and a wider group of users are sensible triggers. Routine wording improvements may need a lighter process. The aim is to focus attention where the consequence can change.

Keep a short record of what was approved, by whom and with which limits. This gives the next owner a basis for maintenance and prevents a cautious pilot from quietly expanding into a broader service.

Prepare an incident route before the first serious problem. Staff should know how to report an incorrect external action or suspected information disclosure, how to stop further processing and who will assess the affected records. Preserve relevant evidence while following the organisation's retention and privacy requirements.

NIST's AI RMF Playbook is intended to be adapted to circumstances. A small business can follow that principle by maintaining a concise, tested response procedure instead of copying a large organisation's documentation.

Review recurring problems as well as major incidents. Repeated corrections can reveal a weak source document, unclear policy or unsuitable use. Governance should make those findings visible to the person who can change the system.

Choose a review cadence the team can sustain and add reviews when significant changes occur. The owner should check whether each use still has a business purpose, whether access remains appropriate and whether unresolved issues require action.

Ask users what they are actually checking. “Human review” may sound reassuring while meaning little more than a quick read for tone. For consequential tasks, define what the reviewer must verify and provide access to the relevant evidence. If the workload makes that checking unrealistic, reduce scope or redesign the process.

Training should use real task types without exposing sensitive records. Show a plausible error, explain how to identify it and demonstrate the escalation route. Staff need to understand when the tool can help and when its output requires additional evidence.

Retire abandoned uses. Close accounts, remove integrations and handle retained data according to the agreed arrangements. Tools should not keep access simply because nobody remembers why it was granted.

The practical output is a compact system of ownership: a current inventory, explicit boundaries, implemented controls and a way to handle change. An AI automation project should strengthen that system as it introduces new capability. The business can then adopt AI with a clear account of who is responsible for its operation and how that responsibility is exercised.

Keep the register close to existing operational records, with a named backup owner. If maintaining it depends on one person's memory or a separate reporting exercise nobody opens, it will drift from reality. The record should change when the actual workflow changes.