An AI plan for a smaller company is five things, each short, each with a name next to it. Not a strategy document. This is the template: what each part is, what good looks like, roughly what it takes, and who owns it. Click a part for the detail.
1. Where it pays off
What it is. A ranked list of the workflows in the business where AI or better software would save real time or money, scored on payoff and effort, with what would need fixing first.
What good looks like, and what it takes
The boring wins are at the top and the reasoning is in plain English. The owner could hand it to any developer or vendor and they could act on it. The decision to do nothing on some items is written down as a decision.
About two weeks of part-time attention and four hours of the owner’s time. The method is a separate playbook: Finding where AI actually pays off.
Owner. The owner or managing director. This one does not delegate well.
2. The rules
What it is. A one-page policy: what staff may use AI for, what data may go into which named tools, what must never be pasted anywhere, and who to ask.
What good looks like, and what it takes
People can follow it without a lawyer. It reads as permission with edges. Staff have had a half-day briefing on what the tools do well and badly, using the company’s own documents.
A day to write, half a day to brief. Do it alongside part one. The template is here: An AI policy in one page.
Owner. Whoever owns HR or operations. Reviewed twice a year, because the tools change.
3. Build, buy, or fix the process
What it is. For each of the top three items from part one, an honest decision: change the process with no software, buy something off the shelf, configure a tool you already pay for, or build.
What good looks like, and what it takes
At least one of the three is “fix the process”. Anything bought was bought after the vendor answered the seven questions. Anything built was scoped as a small first stage that proves the payoff before the second stage is approved.
A decision meeting per item. The building or buying is a separate matter with its own timeline.
Owner. The person who runs the workflow it affects, not the person who runs IT.
4. Instrumentation, guardrails and security
What it is. For anything built or bought: how you will know it is working, what data it may reach, and when it is reviewed. Decided before it goes live.
What good looks like, and what it takes
Checks that run on real data stating things that must always be true, with same-day alerts. Errors tagged with the version that caused them. A written answer to what the feature can see and where that rule is enforced. A scheduled security pass on every change, and independent human testing annually for anything handling money or personal data.
For a built feature, days added to the build and a small monthly cost to run. For a bought one, a conversation with the vendor and a clause in the contract. The checklist is The infrastructure around the app.
Owner. Whoever is responsible for the system after launch. If nobody is, that is the first finding.
5. Standards, lessons and continuity
What it is. The instructions every AI coding session reads before it writes anything, a shared place where what the company learns is written down once and applied automatically after, and a way for work to survive whoever is doing it leaving.
What good looks like, and what it takes
Every repository carries a short instructions file, an architecture note and a decision log, read at the start of a session and updated before it ends.
Those point up to a shared vault: a repository of notes with an index every AI-assisted session starts with, a named owner who runs a monthly gardening pass, and a rule that contradictions are resolved and recorded rather than argued case by case. New projects connect to all of it automatically. Work in progress is pushed daily, not held on one laptop.
An afternoon to start the vault, an hour a month to keep it. The instructions files are written once per project and cost little to maintain. The full method, including the conflict rule and the drill that proves any of it works: Standards and continuity for a small AI-coding team. The shorter version is the MyVault section.
Owner. Someone who likes tidying, for the vault. For the drill: whoever is not the usual owner of the thing being tested.
The order
- One and two together, first. They are cheap and everything depends on them.
- Then five, because it will capture what you learn doing three and four.
- Then three, one item at a time.
- Four is not a step. It is a condition on every item in three.
What this is not
It is not a technology roadmap, a vendor shortlist or a training program, though it may produce all three. It is the smallest written thing that lets a company answer “what are we doing about AI” with something better than a licence count, and update the answer as it learns.
Changelog
- 2026-09-05: first version.
- 2026-09-05: part five expanded from “the learning loop” to “standards, lessons and continuity”, covering per-repository instructions files and the departure/onboarding case, with a link to the new depth-layer playbook.
- 2026-09-08: “what good looks like” and “what it takes” collapsed under each part; the order made a list; short version added.