The question is not whether you have an AI plan. It is whether the plan 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.
Most companies of ten to two hundred people have something they call a plan. A licence for everyone. A policy email. An enthusiastic employee who built an app the sales team now depends on. Often all three. This page is a way to test that plan against the bad weeks before they happen.
Twelve questions
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 checks that run on real data stating what must always be true (totals equal their parts, no record points at another customer’s data), with someone told the same day, and every error tagged with the version that produced it 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, secrets in a secret store rather than the code, 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. Checks on the figures the business relies on, and errors tagged with the version that produced them, 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.
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 (instrumentation, guardrails for data, security) 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: instrumentation, guardrails and a security schedule, 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
- Run the twelve questions with your leadership team in one meeting. Write down the “I do not know” answers.
- If there is an application the business relies on, start with questions five to twelve about it, this month. That is where the bad week comes from.
- Then do the first two questions properly. A few weeks of part-time work, and it gives you the rest of the plan.