Most businesses of ten to two hundred people are not ready for AI. Not because they are behind, and not because the technology is hard. Because it is nobody’s job.
A big company has a CIO: one person whose job is to know what the technology can do for the business, what it must not be allowed to do, and who is responsible when it goes wrong. A small business has an owner who is busy, an IT person who may be a contractor or may not exist, and someone in the office who is “good with ChatGPT”. Meanwhile AI is already in daily use in the building, one person at a time, on whatever data is to hand.
This page is the CIO’s view for a business that does not have one. No jargon. Everything on it is something you could start this week.
Do you even need an IT team?
No. You need three things an IT team is sometimes mistaken for. A person whose job this is, by name. A one-page rule everyone has been walked through. And a second pair of eyes on anything the business now relies on. A ten-person firm can have all three by Friday; a two-hundred-person firm often has none of them.
What an IT team would add later is the fourth thing: someone who can look at a tool a member of staff built and say whether it is safe to depend on. That can be bought by the hour when you need it. It cannot replace the first three, and it is not where to start.
What it is worth
Being ready is not an IT project. It shows up in five places an owner already watches.
- Hours back. The best one I have seen: fifteen supervisors, half a day a week each on time cards, taken to a few minutes each. Worth hundreds of thousands a year.
- Costs down. Work done twice, re-keyed or checked by hand is a cost. One client’s invoicing and payment reconciliation were half manual; now they run on their own.
- Revenue won. Quotes out the same day win more of them. Enquiries answered first get the job. And larger customers increasingly ask small suppliers for an AI policy before they sign.
- Security. A customer’s data pasted into a free tool is a privacy problem, and it can cost you the customer.
- Continuity. If the person who set it all up left on Friday, you can still invoice, quote and pay people on Monday.
The rest of this page is how to get there.
What ready means
Ready is not a technology. It is five things a business can say out loud without hesitating:
- You can say where AI would save you time, in hours, not vibes. Three workflows, ranked, with a rough figure beside each. Protects: hours and cost.
- Someone is in charge of it, by name. Not a department, not “we all keep an eye on it”. Gets the rest done.
- Staff know what they may paste into a chatbot and what they never may. One page, briefed in person. Protects: security and customer trust.
- Anything you rely on was checked by a second person. The spreadsheet, the weekend app, the AI-written quote. Protects: errors that cost money.
- If it quietly went wrong, you would find out before a customer did. Something has to be watching while nobody is looking. Protects: revenue and reputation.
If you can say all five, you are ahead of nearly every company your size. If you cannot, the gap is almost always the same one: a tool the business relies on with nothing around it. The three-minute Ready Test puts you on one of four steps; the twelve questions further down this page are the longer version.
The three levels
“Implementing AI” is a phrase that stops most owners cold because nobody says what it means. It means one of three things, and the difference matters more than any tool.
Level 1: people use it. Emails get rewritten, documents summarised, questions answered. Everyone gets a little faster at tasks that were never the bottleneck. Useful, cheap, and where nearly every business is. It is not a plan: a chatbot for everyone is not a strategy.
Level 2: a process changed. Quotes go out the same day instead of Thursday, and a quote that arrives first wins more often. Enquiries are sorted and half-answered before a person reads them, so none sit unanswered while a competitor replies. Something that took an afternoon now takes a check. The best one I have seen came from a single question about what was still done by hand: fifteen supervisors, half a day a week each on time cards, taken to a few minutes each, worth hundreds of thousands a year. This is where the money is, in hours saved and work won, and it usually needs no new software, only a look at how work actually moves.
Level 3: software does the work. A tool built for your business, increasingly by someone on staff who could not have built it two years ago. Powerful, and the single biggest new risk in a small company, because the tools make the app easy and do nothing for everything around it.
Ready does not mean reaching level three. It means knowing which level each part of your business is on, choosing on purpose, and having someone whose job it is to know.
The invisible half
If a part of your business reaches level three, software built by AI tools, three things decide whether it becomes an asset or a liability. None of them need you to read code. They need you to ask for them before the business relies on the result.
What it can see. Which records, which customers’ data, whose login it uses to fetch things on their behalf. These are decisions, not technology, and if nobody in the business made them on purpose, they were made by default, usually “everything.” The app is the visible part is the fuller version.
Would you know if it quietly went wrong? Not “nobody has complained.” Someone looking at the numbers the business actually relies on, and something checking them automatically, all the time, against the rules that must always hold. The infrastructure around the app is the checklist.
Built to last: what happens in two years. A tool built in a weekend is the cheapest part of owning it. Ask what happens when the platform it depends on changes, or the person who built it moves on. The build is the cheap part and, on the risk of the code itself ageing badly, AI writes instant legacy code.
This is questions five to twelve below, in more detail, for the app you already depend on.
Twelve questions: the longer test
The five signs above are the short version. The longer version is whether your business would survive a bad week: the app produces a wrong figure for a month, a customer asks what you do with their data, the employee who built the thing leaves, a vulnerability is announced in something you did not know you were running.
Answer honestly. “I do not know” is a valid answer and the most useful one, because it tells you where to look. Click a question for the full version and what a good answer looks like.
Where it pays off
-
Can you name the three workflows where AI or better software would save the most?
In order, with a rough figure for each: hours a week, errors avoided, revenue unblocked. A good answer is boring and specific (“the quote follow-up, about two hours a week of the owner’s time”). “Transforms the business” is not a figure.
-
Was that list made by looking at how work actually moves, or at what a vendor offered?
Vendors sell what they have. A good answer is a walk through the business, hand-off by hand-off, done before any vendor was in the room: re-keying, chasing, waiting and checking are where the time goes.
The rules
-
Is there a one-page policy that names the tools, the data, and the person to ask?
Named tools, not “approved tools”. What may go in, what needs care, what never goes anywhere. A named person, not a department. A good answer fits on one page and reads as permission with edges.
-
Has everyone been briefed on it, in person, using the company's own documents?
A policy email is filed, not followed. A good answer is a half-day working session, leadership first and then everyone, on the company’s own tasks: what the tools do well, what they do badly, how to tell the difference when a vendor calls.
What has been built
-
For anything built or bought in the last year, is there a written description of what it does, what data it reaches, and who can see what?
A good answer is a page or two that a second person could read cold: the purpose, the data it holds, where the “who can see what” rule is enforced. If it exists only in the builder’s head, the company does not own it.
-
Was it tested by someone other than the person who built it?
Against what the business asked for, not what the builder thought it did. A good answer is a written list of the cases that matter (the refund, the end of the month, the customer with two accounts) with a tick, a date and a second name beside each.
-
Has anyone reviewed it for security, and is there a date for the next review?
Before it touched real data, and on a schedule after. A good answer names the six questions that were checked (who can get in, who can see what, what it fetches, what happens when a setting is missing, what is logged, which account it connects as), the date of the next scan, and who reviews findings.
Whether it is working
-
If it produced a wrong figure for a month, how would you find out, and how fast?
A good answer is not “a customer would tell us”. It is automatic checks on the live figures for the rules that must always hold (totals equal their parts, no customer can see another customer’s data), someone told the same day when one fails, and a record of which change was live when it started, so “when did this start” takes a minute.
-
Is anything watching it while nobody is looking?
Testing before launch catches the mistakes somebody thought of. Only monitoring catches the rest, and AI-built software is quietly wrong on the rest. A good answer is three to five written checks, running, a place errors go, and a name.
The infrastructure around it
-
Where does it run, who has the keys, and what happens if that person is unavailable?
A good answer is hosting under a company account, every account with two people on it or owned by a company identity, passwords and keys kept in a password manager rather than written into the app, and a one-page list of what is where that a second person has actually logged into.
-
Is there a backup, has a restore ever been tested, and would you know within a day if it stopped working?
A backup nobody has restored from is a hope. A good answer is a dated note: “restore tested on this date, took this long.”
-
If the builder left on Friday, could someone else keep it running on Monday, and would the next person's first day already know what the last one learned?
From written material, not memory. A good answer is a two-page handover document a second person has used to make a small change, an instructions file in the codebase the AI tool reads, and a shared place where lessons are written once and put in front of every session automatically. See Standards and continuity.
A robust plan answers all twelve. Most companies I meet can answer the first four with some work and the rest with silence. The silence is almost always in the same place: the infrastructure around the app.
The employee who can now build apps
Someone in your company who is not a software engineer can now build a working application in a weekend. It will look finished. It may well be useful. The sales team will start relying on it within a month.
This is a genuine opportunity, and also the single biggest new risk in most small companies, because the tools make the application easy and do nothing for everything around it.
Trusting an inexperienced builder with an application the business runs on is a decision to make deliberately. If the answer is yes, the condition is that they do the homework on the infrastructure around the app. At minimum:
- Where it runs, and who else can get in. Hosting under a company account, not a personal one. Access that survives the builder’s departure. Secrets stored somewhere other than the code.
- What happens to the data. Backups that exist, and one restore that has actually been tried. A written answer to which customer or staff data the app holds and who can see it.
- Testing by someone else. Not “I tried it and it worked”. A second person checking the app against what the business asked for, with the cases that matter (the refund, the edge of the month, the customer with two accounts) written down.
- A security review before it touches real data. Who can see what, what the app fetches on a user’s behalf, what happens when a setting is missing. Cheap to check at the start, expensive after.
- Something watching it. Automatic checks on the figures the business relies on, and a record of which change was live when an error started, so “when did this start” has an answer.
- A handover document. Enough that another person could keep it running. If it exists only in one head, the company does not own it.
None of this needs the builder to become a security engineer. It needs the company to require the homework before the app is relied on, and to know what the homework is. The checklist for exactly that conversation: The infrastructure around the app.
Before the next one starts, nine questions and the matching line the builder prepares: which account, which data, who the second person is, how much of their time it is worth. Before your staff build with AI is the fifteen-minute version.
Hiring a developer or agency to build it instead? The same homework applies, plus the questions an outside builder should answer before work starts: who owns code an AI wrote, which AI plan touches your data, whether their insurance covers AI-produced work, and what goes in the contract. Before you hire someone to build with AI has them, with what a good answer sounds like.
The four gaps this test usually finds
A chatbot for everyone, mistaken for a strategy. It changes no process, touches no data, measures nothing, and leaves the rules to each person. Keep the licences; stop calling them the plan.
An app with nothing around it. The visible part built, the invisible parts (something watching it, a decision about what it can see, a security check) not planned. This is the gap the twelve questions are designed to expose, because it is the one that turns into the bad week.
Standards that live in one person’s head. Two people building with AI tools produce two different codebases unless the standard is written where the tool reads it. This gap shows up eighteen months in, when someone has to work across both.
Nothing that learns, and nothing that outlives the person who knew it. Every department relearns the same lessons about working with AI, and the reasoning behind what was built leaves with whoever built it. The companies pulling ahead have a place where lessons are written once, applied every time after, and still there the day someone hands in their notice. It is the cheapest part of a plan and the one nobody does: the learning loop.
What a robust plan contains
Five short things with owners, not a strategy document:
- Where it pays off
- The rules
- For each opportunity, a decision to build, buy or fix the process
- For anything built or bought: how you would know it broke, what it can see, and when it gets a security check, decided before it goes live
- Standards, lessons and continuity, so what one project learns does not leave with whoever learned it
The full template, with what good looks like for each and roughly what it takes: What an AI plan actually contains. The last part has its own depth layer: Standards and continuity for a small AI-coding team.
Where to start this quarter
- Name the person. Today, out loud, in front of the team. If it is the person who is “good with ChatGPT”, send them the page written for them.
- Write the one-page rule and walk everyone through it. A morning. Larger customers increasingly ask suppliers for one, so it also answers the next procurement questionnaire. The template: An AI policy in one page.
- Run the twelve questions with your leadership team in one meeting. Write down the “I do not know” answers. If there is a tool the business already relies on, questions five to twelve about it come first; that is where the bad week comes from.
- Then find where it pays off. A few weeks of part-time attention, four hours of your own time, and it gives you the rest of the plan: Finding where AI actually pays off.
If you would rather borrow a CIO for an hour
I work with a small number of owners working through exactly these questions, usually starting from where the Ready Test put them. It takes one of three shapes: a call before a meeting, a bounded piece of work on one topic, or an ongoing seat as the AI lead a few days a month.
The bounded pieces are the same ones a fractional executive would bring me in for: a review of which AI accounts you are on and who could get into them if one person left, a review of how your staff are actually using AI, a verdict on the tool someone built that the business now relies on, a security pass on the platforms you chose, a second opinion before you sign with a vendor, the one-page policy with a half-day briefing, or the two-week map of where AI pays off. Fixed price, days not months, and a written result. It starts with a conversation, not a proposal. Say hello and tell me what your business does.