Most of the work that decides whether an AI tool is useful in a small business happens before the tool is switched on. It is ordinary IT and process work: knowing where your information lives, who can open it, which of it should never leave the building, and who is accountable for checking the result. A business that has done that work has options. A business that has not will get inconsistent answers out of any tool it buys, and may expose information it did not intend to share.
This checklist is written to be worked through in order. You do not need to finish all ten items before trying anything — but you should be able to answer items one through four before a tool touches real company data.
1. Start With a Workflow, Not a Tool
Pick one piece of recurring work and describe it the way it actually happens today, including the steps nobody wrote down. A workflow is a reasonable candidate when it has most of these traits:
- It repeats on a predictable rhythm — weekly, daily, or every time a certain kind of request arrives
- The input is mostly text, documents, or structured records your business already owns
- A person can tell quickly whether the output is right or wrong
- A wrong answer is caught before it causes harm, rather than after
- Someone owns the workflow and can decide to change it
If the work is unpredictable, the inputs are scattered across people's heads, or a mistake goes straight to a customer or a regulator with nobody in between, that workflow belongs later in the queue — or nowhere near an AI tool.
2. Inventory Where Your Information Actually Lives
Write down every place business information is stored. For most small businesses the list is longer than expected:
- Microsoft 365 or Google Workspace — mail, calendars, SharePoint, OneDrive, Teams, Drive
- On-premises file servers and network shares, including the one everybody calls "the old server"
- Line-of-business systems: accounting, practice management, dispatch, point of sale, CRM
- Individual mailboxes and personal drives that have become the real home of a shared process
- Paper, scans, and the shared folder of PDFs nobody has opened since the last audit
- Personal phones, home computers, and unmanaged devices holding work files
Anything not on this list cannot be governed, and it also cannot be usefully searched. Both facts matter.
3. Review Who Can Open What
An assistant working inside your environment can generally surface whatever the signed-in person already has permission to open. That is the central point of the whole exercise: AI does not usually create a new access problem, it makes an existing one visible and easy to act on. Before you add capability, look at:
- Folders, sites, and shares granted to "everyone" or to a group that has quietly grown
- Sharing links that were created for one file and never expired
- Accounts belonging to people who have left, and the files still sitting in their personal storage
- External guests, contractors, and vendors who still have access to something
- Administrator accounts that are used for day-to-day work
4. Decide What Is Off-Limits, in Writing
Name the categories of information that must not be placed into a general-purpose AI tool under any circumstances. For most businesses that list includes health information, payment card data, government identifiers, credentials and keys, information covered by a customer confidentiality agreement, personnel and payroll records, and anything currently in a legal matter. Being specific is what makes the rule usable — "use good judgment" is not a control. Our companion guide on what business data should stay out of public AI tools covers the categories in more depth.
5. Look Honestly at Data Quality
Assistants that answer questions from your own documents inherit the state of those documents. If three versions of the same policy are stored in three places and none is marked current, the answers you get back will reflect that. Before you expect useful search or question answering, confirm that:
- There is one identifiable current version of the procedures that matter
- Superseded documents are archived somewhere that is not indexed alongside the current set
- Files are named and organized well enough that a person could find them without asking a colleague
6. Name the Human Review Step Before You Build Anything
For each workflow, decide three things and write them down: who reviews the output, what "reviewed" concretely means for that task, and what happens when the output is wrong. These systems can produce fluent, confident text that is incorrect, and fluency is exactly what makes errors easy to miss. The review step is the control that keeps a plausible mistake from reaching a customer, an invoice, or a filing.
7. Read the Terms Before Anyone Signs In
Consumer and business tiers of the same branded product can differ substantially in how data is handled. Before a tool is approved, get answers to these questions from the vendor's current documentation and your agreement:
- What does the provider receive when an employee uses it — prompts, uploaded files, both?
- How long is that content retained, and can retention be configured or disabled?
- Is customer content used to train or improve the provider's models, and can that be turned off?
- Where is the data processed and stored, and is that acceptable for your obligations?
- What administrative controls, logging, and audit visibility does the business tier provide?
- Which specific licence or subscription tier do those terms apply to?
Vendor terms and product tiers change. Verify against the provider's current published terms rather than a summary written by anyone — including this one.
8. Write a Short Acceptable-Use Policy
One page, in plain language, with examples. It should tell an employee which tools are approved, what kinds of information may be used with them, what requires a manager's approval, what is never permitted, and who to ask when something falls between the lines. A policy that is short enough to read is followed more often than a policy that is thorough enough to satisfy a lawyer. If you need both, keep the one-pager and attach the detail.
9. Design the Pilot So You Can Tell Whether It Worked
Before switching anything on, record how the work is done today: roughly how long it takes, how often it has to be redone, and who touches it. Then run one workflow, with a small group, on real work, for a defined period. Agree in advance on what would count as a failure and what you will do about it. A pilot with no baseline and no stop rule tends to conclude that everyone is impressed, which is not a finding you can act on.
10. Train the People Who Will Actually Use It
Role-specific training beats a general demonstration. The people running the workflow need to know what the tool is good at, the ways it fails, what to verify every time, and when to stop and hand the task to a person. Include the failure modes openly — staff who have seen a tool be wrong in training are far more likely to catch it being wrong in production.
Signs You Are Not Ready Yet
There is no shame in this answer, and it is a common one. Deal with these first:
- Backups are not tested, or nobody is certain what is covered
- Multi-factor authentication is not enforced on email and remote access
- Nobody can say who has access to the main file share
- Former employees may still have accounts or shared links
- The workflow you want to automate has no owner
Each of those is a bigger risk than missing out on an AI feature, and each one has to be fixed before an assistant makes it more consequential.
A Reasonable Order of Operations
Inventory your information, review access, write the off-limits list, pick one workflow, define the review step, read the vendor terms, pilot small, measure against the baseline, train the users, then decide whether a second workflow earns the same treatment. Businesses that skip to the last step and work backwards usually end up redoing the first four anyway.