Most small-team AI policies fail by being either a blanket prohibition or a page of encouragement. A workable one answers three specific questions.
Name the information that may not leave
Start from data rather than tools, because tools change constantly and categories do not. List what may never be pasted into an outside service.
For most American small organizations that list includes customer personal information, anything covered by a client confidentiality agreement, unreleased financial figures and credentials of any kind.
Stating it as categories means the rule survives a vendor change. Staff can apply it to a tool nobody has evaluated yet, which is the situation the policy actually has to cover.
Define where human review is mandatory
Distinguish output that goes to a colleague from output that goes outside the organization or into a system of record.
Internal drafts need no ceremony. Anything sent to a client, published, or entered into a customer or financial record requires a named person to check it before it goes.
Writing that distinction down prevents the two failure modes at once, which are reviewing everything until the tool is useless and reviewing nothing until something goes out wrong.
Say who decides the unclear cases
Every policy meets a situation it did not anticipate. If nobody owns that decision, people either stop or proceed quietly, and both outcomes are bad.
Name one person who approves new tools and rules on edge cases, and give them a short turnaround expectation so asking is faster than guessing.
Keep a short record of what is in use
Maintain a simple list of approved tools, what each is used for and who owns the account. It takes minutes to maintain and answers most questions that arise later.
The list also matters when someone leaves, since an unrecorded account with company material in it is the most common loose end small teams discover late.
Client contracts increasingly ask about subprocessors and tool use, and a maintained list turns that into a lookup rather than an investigation.
Revisit it on a schedule rather than after an incident
A policy written once becomes wrong quietly as tools change and people find workarounds. Set a short review, twice a year, with the person who owns approvals.
Ask what people are actually doing rather than what the document says, because the gap between the two is the only useful input to a revision.
A policy that reflects real practice gets followed, and one that has drifted from it stops being a control and becomes a document nobody consults.