The Library · Perspective
The small business AI problem is not the AI
Small firms rarely fail at adoption because the model is not good enough. They fail because the work the model was supposed to help with was never written down.
A small business that tries to adopt AI and gets nowhere almost never has a model problem. It has a documentation problem that it has been able to survive until now, and the attempt at adoption is simply the first thing that made the gap visible.
What the pilot actually discovers
The pattern is consistent enough to predict. A firm picks a task — quoting, scheduling, triage, first-line support — and tries to hand part of it to a model. Within a week the project stalls, and the reason given is that the output is not reliable enough.
Look closer and the reliability problem is downstream of something else. Nobody can say what the correct output is. The task was never a procedure; it was a set of judgements distributed across two or three long-serving people, and those judgements were consistent enough that nobody had to write them down.
This is why so many pilots produce a peculiar kind of frustration. The technology appears to be underperforming, but every attempt to specify what better would look like turns into an argument about what the business actually does.
The dashed lines are the documented process. The worn bands are where the work actually goes. Adoption stalls at the gap between them, and the gap is usually discovered rather than known.
The asymmetry that makes this hard
A large firm has the opposite problem. Its processes are documented to the point of fiction — written once, diverged since, and maintained by people whose job is the document rather than the work. Its difficulty is that the documentation is wrong.
A small firm's processes are usually correct and entirely unwritten. That is a better position to be in, and it is worse for adoption, because the asset lives in people rather than in text and cannot be handed to anything.
What to do instead of a pilot
The sequence that tends to work inverts the usual one.
Start by picking a task that a competent new hire could be taught in a morning, and write the teaching down. Not a policy — the actual decisions, including the edge cases the experienced person handles without noticing. If that document cannot be produced, that is the finding, and the task is not ready.
Then check whether the task is worth automating at all. A surprising number of candidate tasks turn out to be rare, or cheap, or load-bearing for a relationship in ways that were not obvious until someone tried to describe them.
Only then introduce a model, and hold it to the written standard rather than to a vague sense of quality. A system you cannot grade is a system you cannot improve, and most stalled pilots are stalled precisely there.
The part that is genuinely about the technology
None of this means the technology is incidental. Two things have changed materially for small firms.
The first is that the floor has moved. Work that used to require a specialist — a competent first draft, a summarisation, a structured extraction from unstructured input — is now available to a firm with no specialist at all. That is a real change and it favours small operators.
The second is that the ceiling has not moved nearly as much. Work that requires being right, being accountable, or being trusted still requires a person, and the gap between a plausible output and a correct one is exactly where small firms have the least slack to absorb a mistake.
The firms that get value are not the ones with the best tooling. They are the ones that were willing to treat the adoption attempt as an audit of their own process, and to accept the finding when the audit came back badly.