AI readiness for small-business managers — Part 1 of 5.
In August 2026 I handed four of my own projects to ChatGPT to run. It didn’t do anything special
before that. I was thinking of a structure in which Claude is the main AI, and I needed to use the
resources of ChatGPT efficiently, so I gave it the projects. What it did good was putting the
Powdorum products back in Google Merchant Center, because they were down. Then it started to detect
some very good subjects for the La Línea project, and I just had to approve the topic, and it
started writing and publishing the articles head to toe. It was a time when I thought, okay, it’s
working.
The problem with that is that, obviously, they are fully generated articles, and I don’t know how
they will go in Google. I didn’t check. I thought that was for the AI to do.
So, no. Today I would not approve them. What I would change is for it to ask me, on any topic, if
I have something to say. Because it is doing its own research, and maybe I come with something I
know from the area, because I live around here. I know what people are talking about.
That is the moment this part is about.
Someone on your team built an AI prototype, the demo went well, and now there is pressure to
switch it on for real work. This part shows you the first thing the training teaches in the room:
how to tell what the demo proved from what it didn’t, and how to write down the boundary of the
service before anyone depends on it.
You need no technical background. You need one prototype — yours or the worked example below —
and about twenty minutes.
What a good demo proves
A demo proves capability on selected inputs: the system handled the documents
someone chose to show you, on the day they chose to show them. Production needs three more things
the demo cannot prove:
- Reliability across real users and difficult inputs — the messy Monday queue,
not the curated Friday demo. - Safe operation at volume — what a 2% error rate costs when two thousand items
pass through, not twenty. - Accountable organisational dependence — a named person who answers for the
system when it fails, because eventually it will.
A fluent output is not evidence that the system is supported, complete or safe to rely on. This
matters more for AI than for ordinary software, and the reason is worth remembering: a broken
payment integration usually produces an error, while a document agent can return the wrong figure in
a complete sentence and let a user carry it into a decision. AI systems fail politely.
Step 1 — before reading further, answer in one line: what did our demo actually
prove? If your answer contains the word “works”, rewrite it until it names the inputs it
worked on.
Step 2 — write the use-case boundary
The training’s first exercise is a six-line form. Fill it in for your prototype; every later part
of this course builds on it.
- Business problem: what outcome the service exists to produce.
- Approved users: who may use it.
- Affected people: who feels the consequences without ever touching it —
customers, staff whose work it processes, people named in the documents. - Approved decisions: what the output may be used to decide.
- Prohibited uses: what it must never be used for, written down, not
assumed. - Named business owner: the person who accepts the residual risk. A committee
is not a name.
Two of these six lines stop most managers. Affected people is the line demos
never mention — a document-reading tool has users in the office and affected people everywhere the
documents came from. Prohibited uses is the line that feels pessimistic to write and
turns out to be the one you cite later, because a service without stated exclusions grows uses nobody
approved.
Step 3 — inventory the data
From the readiness checklist, domain 3, four questions:
- Does every data source have an owner, a lawful basis and a permitted purpose?
- Are personal, confidential and sensitive data minimised and protected?
- Are access, retention, deletion, location and supplier use of the data documented?
- Does your test data represent the real document types, languages and layouts production will
see?
You are not expected to answer all four today. You are expected to write Unknown
wherever Unknown is the honest answer — the checklist rule is that a No or Unknown needs an owner and
a resolution date, not a hopeful Yes.
Step 4 — label your evidence
The discipline that carries the whole course: every claim about your system gets one of three
labels.
| Label | Meaning | How you talk about it |
|---|---|---|
| Verified | You have seen the evidence yourself | State it plainly |
| Probable | Reasonable inference, evidence incomplete | Hedge it — “appears to”, “likely” |
| Unverified | Assumed, hoped, or taken from the supplier’s brochure | Say so, out loud, in writing |
The training runs this as a five-statement exercise. Try it on your own prototype — label
each:
- “The tool is accurate.”
- “Staff will check every output.”
- “It doesn’t store customer data.”
- “The supplier handles security.”
- “We can switch it off if something goes wrong.”
In the worked document-agent case, the honest labelling came out one Probable and the rest
Unverified — and that was the finding, not a failure. The trap is not having Unverified claims; every
prototype does. The trap is operating as if they were Verified.
What you have when you finish
Twenty minutes of work has produced three artefacts: a use-case boundary with a named owner, a
data inventory that admits its Unknowns, and an evidence-labelled claim list. That is more production
governance than most small-business AI deployments ever write down, and it cost you no technology at
all.
Keep all three. Part 2 takes the claim most demos lean on — “it’s 95% accurate” — and shows why
that number decides nothing, and what to ask for instead.
Authorship: HAC — human-directed, AI-assisted. The opening passage is the author’s own spoken words, transcribed and arranged, not generated. The course is converted from the 90-minute manager training “From AI prototype to production service” (segments 0–25 min), the Day 10 readiness checklist (domains 1–3), and the document-reading agent representative case. No new frameworks were created for it.
The AI readiness course: Part 1 — The prototype trap · Part 2 — Evaluation that can fail · Part 3 — Meaningful human oversight · Part 4 — Running it for real · Part 5 — The launch decision.
