Short answer
Implementing AI in a small company is an organizational exercise more than a technical one. Run one real process into production and use it to settle four questions: who owns the outcome, who approves spending, what may leave the company, and who operates it afterwards. Write a single page of policy before wide access rather than after an incident. Name the operator before the pilot starts, because that is where pilots die. Then judge progress by whether unprompted, specific requests start arriving from people who were not involved.
Why the second project is the real test
A first automation can be delivered by determination alone. Someone motivated pushes it through, gets the access they need by asking in person, and it works. Nothing about that experience tells you whether your company can do this repeatedly.
The second project is where the absence of an operating model shows. A different team wants something, nobody knows who approves it, the budget sits in a line that was a one-off, and the person who built the first one is now the bottleneck for both. Companies that stall usually stall here rather than at the start — and the fix is cheap if it is done during the first project instead of after the third.
Four decisions that need a name against them
Not a governance framework. Four questions, each with a person’s name as the answer, written somewhere findable.
- Who owns the outcome. One person on the business side, accountable for whether the thing still produces value once the novelty has worn off. Not the most technically curious employee by default, and not a committee — a committee owning something means nobody notices when it stops working.
- Who approves spending. Including the small recurring amounts, which is where control is actually lost. A named approver and a threshold below which a team can decide alone prevents both paralysis and sprawl.
- What may leave the company. Which categories of information can be sent to an external tool, and which never can. This is the decision most often deferred and the only one on the list with a legal edge to it.
- Who operates it. Whose job it is to notice the workflow failed and to do something. If the answer is the person who built it, and that person has another full-time role, you have a dependency rather than an operating model.
These four take an hour to decide and are almost never decided, because each feels premature during the first project. Every one of them becomes expensive during the third.
The one page of policy you need
A short written rule, in place before broad access rather than after an incident. Four points cover the ground in a company of ten to a hundred people.
- What must never be sent to an external tool. Named specifically — personal data about clients or staff, anything under a confidentiality clause, credentials. Specific prohibitions are followed; general appeals to caution are not.
- Which tools are approved, and how to ask for one that is not. The second half matters more than the first: an approval path that takes weeks guarantees people use personal accounts instead.
- Outputs are checked before they reach a client. Stated as a rule so that it is a shared expectation rather than an individual’s caution.
- Who to ask. A name, for the cases the page does not cover.
Longer policies get written, circulated once, and never opened. If you eventually need something more formal — because a client or a tender asks for it — NIST publishes an AI Risk Management Framework intended for voluntary use, which is the standard reference to map your page onto rather than a starting point to write from. The security reasoning behind these points is set out in our note on AI and cybersecurity, and the tool-selection side in our guide to AI productivity tools.
How a request becomes a project
Once a first automation is visible, requests start arriving — usually in conversation, usually vague. Without a path, they are either all attempted or all forgotten.
What works at this size is deliberately lightweight: a single place to put a request, three questions attached to it, and one recurring slot where the owner decides. The three questions do most of the filtering. How often does this happen? What does it cost today, roughly? What would change if it stopped being done by hand? A request that cannot answer them is not ready, and saying so is faster than starting it and stopping.
Which requests are worth taking is a separate discipline, worked through in our process audit method. The point here is only that a path exists and someone stands at the end of it.
Pilot to production, the transition that fails
A pilot demonstrates that a model can do a task. Production requires all the parts that a demonstration skips: what happens when an input is malformed, what happens when a connected tool changes, who sees the failure, and whose week includes looking at it.
The reliable preventive measure is to name the operator before the pilot begins, and to have that person involved while it runs. It changes what gets built, because a workflow designed with its operator in the room ends up with the visibility that operator will need. Pilots handed over at the end are handed to someone with no context, which is most of why they are quietly abandoned. The per-project controls for that handover are collected in our AI implementation checklist.
Where the money sits
Two patterns work and one does not. A central budget owned by the person accountable for AI keeps spending visible and slows down teams. Devolved budgets with a threshold and a shared register keep teams moving and require the register to be genuinely maintained.
The pattern that fails is no budget at all, with each project funded by whoever has room. It makes the running cost invisible — and running costs are the ones that matter here, because a workflow calling a model has a bill that grows with usage. Putting a defensible figure on that is its own discipline, and it belongs to our guide to measuring the ROI of automation; what matters at the operating-model level is only that someone can see the total. How the year’s spending is phased is the subject of our AI strategy roadmap.
Roles in a company with no AI team
Three roles, and one person can hold more than one. What matters is that each exists rather than that each has a job title.
| Role | What it covers | Where it usually sits |
|---|---|---|
| Owner | Decides, approves, and is accountable for the result. | Business side, internal. Never bought. |
| Builder | Connects the systems and ships the workflow. | Internal if you have someone capable and available, external otherwise. The role most safely bought. |
| Operator | Watches what is running, reads the failures, escalates. | Internal. The least glamorous, and the one whose absence kills the most projects. |
In practice, the owner and the operator being the same person works well in a small company. The builder being the same person as either is where fragility enters, because that individual becomes the only route to changing anything.
Signals that it is working, and that it is not
Adoption dashboards are not much use at this scale. Four observations tell you more.
- Specific unprompted requests from people who were not involved. The clearest positive signal there is, because it means someone recognized a fit in their own work.
- The second project costing visibly less than the first. If it does not, the plumbing and the operating model did not carry over.
- Failures being noticed by the operator rather than by a client. The practical test of whether monitoring exists.
- People asking for approval to use a new tool. Counter-intuitively positive: it means the approval path is known and usable. Silence usually means personal accounts.
On the negative side, the two worth watching for are a growing set of workflows nobody has reviewed in months, and a single person who has become the only one who understands any of it.
Frequently asked questions
How do you implement AI in a company that has never done it?
By treating the first project as a way to build the operating model rather than as the goal. Pick one process, put it in production, and while doing so decide four things explicitly: who owns the result, who approves spending, what may and may not be sent to an external tool, and who is called when it breaks. The first project is worth doing for its own sake; what makes the second and third cheap is having answered those four questions once.
Who should own AI in a small business?
A named person on the business side who can decide, not a committee and not the most technically curious employee by default. Ownership means being accountable for whether the workflow still produces value once the novelty has worn off, which is a management responsibility rather than a technical one. Technical work can be bought; accountability cannot.
Do we need an AI policy?
One page, yes, and it should exist before wide access rather than after an incident. It needs to say what may never be sent to an external tool, which tools are approved, that outputs are checked before they reach a client, and who to ask when something is unclear. Longer policies in companies this size are written, circulated once and never consulted again.
How long does it take to get the first thing running?
For a narrow, well-chosen process, LYVIA typically sees weeks rather than quarters across its own engagements — a pattern from client work, not a published benchmark — but the calendar is the wrong thing to plan around. What determines the duration is how quickly you can get access to the systems involved and a decision from the person who owns the process. Projects in this range usually wait on availability and permissions rather than on engineering.
Why do pilots so often fail to become production?
Because a pilot proves the model can do the task while production requires everything around it: error handling, a person who watches it, and someone whose job includes it. The transition is unglamorous and rarely budgeted, which is why so many pilots are declared a success and quietly abandoned. Naming the operator before the pilot starts removes most of the risk.
What is the strongest early signal that this is working?
Someone outside the initial group asking for something specific — not enthusiasm in general, but a request naming a process and what they want it to do. As a rule of thumb from LYVIA's own engagements rather than a published benchmark, the arrival of unprompted specific requests is the point at which an intake path becomes worth formalizing.
If you have run one project and the second is stalling, the blockage is usually one of the four decisions above rather than anything technical. Book a call.
