An honest AI-readiness assessment for a small business

Most AI readiness assessments are funnels with checkboxes. Answer every question honestly or hopefully and you arrive at the same last page: book a call. Ours has a column labeled stop here, and it gets used.

A business is ready for AI when it has data it can find and trust, a process someone can describe, a workflow where plain software wouldn't do, a person who owns the outcome, and a risk-and-money picture it can defend. Miss two of those five and the right move is to fix them first, which is cheaper than any AI project.

We call them the five checks. Each has three questions, green/yellow/red criteria, and the answer that should stop you.

What AI readiness actually means

AI readiness — the point at which a specific workflow can put a model to work and keep it working: the data exists and can be trusted, the process can be described, the problem actually needs a model, someone owns the result, and the risk and full cost are understood. It belongs to a workflow, not to a company.

That last sentence is where most checklists go wrong. They score the whole company, its maturity and strategy and culture, and a company-level score leads naturally to a company-level engagement. A workflow-level score leads somewhere less lucrative and more useful: one process, one owner, one decision about whether a model belongs in it.

The ending is the other giveaway. If every path through an AI readiness checklist, audit, or maturity model leads to a sales call, it isn't measuring readiness. It's measuring interest.

How many pillars of AI readiness are there? Every AI readiness framework has its own count, and none is magic. Enterprise versions list strategy, infrastructure, data, governance, talent, and culture; in a business of a few dozen people, most collapse into two questions: is the data usable, and does anyone own this? We use five checks because each one, answered badly, can sink a first AI project on its own.

Check 1 — Data reality

Data reality asks whether the information a workflow runs on exists in a system, can be pulled without heroics, is consistent enough to trust, and has an owner who decides which source is right. AI data readiness is less about volume than about findability: a model can't use what nobody can locate.

Three questions. Can you find it in one place, or is it spread across tools that disagree? Is it consistent: one spelling per customer, required fields actually filled in? Who owns it: when two systems disagree, whose number wins?

• Green (2): One system or pipeline holds it, a month of it can be pulled in an afternoon, and a named person owns the source of truth.
• Yellow (1): It's spread across tools or needs cleanup every time it's used. Nobody officially owns it, though someone always knows.
• Red (0) — stop here: It lives in inboxes, paper files, or people's heads, or nobody knows which system is right. Build a pipeline or a validated form first, not a model.

Field note: A digital agency assembled client reports by hand every month from ad platforms, search data, and analytics, too late to act on. Before any model was involved, connectors and a small warehouse consolidated every platform per client. That pipeline was the readiness work; the weekly brief a model now drafts from the numbers, reviewed by the account lead, came after. Reporting went from a monthly scramble to a weekly rhythm.

A quick test: pull last month's volume, turnaround, and rework for the workflow. If that takes a week of digging, the data isn't ready, and neither are the before-and-after numbers you'd need to judge an AI project.

Check 2 — Process reality

Process reality asks whether someone can describe the workflow on one page — steps, decisions, exceptions — and whether two people would handle the same case the same way. A model can follow a process, speed it up, and cope with its messy inputs. It cannot invent a process that doesn't exist yet.

Three questions. Could the person who does this work write it down on one page, exceptions included? Would two people on the team handle the same case the same way? Describing it out loud, how often do they say "it depends"?

• Green (2): The page exists or could be written this week, exceptions are listed rather than remembered, and two people agree on how a case is handled.
• Yellow (1): The process is real but lives in one person's head, and a few "it depends" moments have never been unpacked.
• Red (0) — stop here: Nobody can describe it, or everyone describes it differently. Write it down first; sometimes the writing-down is the whole fix.

Rule of thumb: Count the "it depends." Each is either a rule nobody wrote down or a genuine judgment call. Write the rules down, exceptions included, since that's where the hours usually go. Whatever survives is where a model might earn its place.

Check 3 — The plain-software test

The plain-software test asks whether the workflow needs a model at all. If a competent person can write the decision as if/then on one page, it's software — cheaper, testable, and predictable. A model earns its place only where inputs are unstructured, judgment is needed at volume, or the output is language itself.

Three questions. Can the decision be written as a rule? Is the input messy (scans, email, voice, free text), or the volume of judgment calls beyond what people can sustain? When the output is wrong, is someone positioned to catch it before it matters?

• Green (2): At least one step genuinely needs judgment or reads unstructured input, and a person catches mistakes before they cost anything.
• Yellow (1): There is a real judgment step, but nobody reviews it yet, or the volume is low enough for a person to handle.
• Red (0) — stop here: The whole decision fits on a page as rules. Build the software and skip the model.

When plain software beats AI covers this check in depth, including the two questions that sort almost every request. A red here is the cheapest verdict on the scorecard: the problem was never an AI problem.

Check 4 — People and ownership

People and ownership asks who owns the outcome, who reviews the output, and who maintains the system when documents, prices, or models change. An AI system without a named owner doesn't fail loudly. It drifts — still running, slowly wrong, trusted out of habit — until a customer notices before you do.

Three questions. Who is the one person accountable for whether this works? Who reviews the output, and is that time actually in their week? Who updates the system when a policy, a price, or the model changes?

• Green (2): A named owner who does or manages the work, review time scheduled rather than hoped for, and a name next to maintenance.
• Yellow (1): There is an owner, but review time isn't budgeted, or maintenance is "the vendor will handle it."
• Red (0) — stop here: Nobody owns it, or "the team" does, or the only owner is whoever championed the purchase. Name the owner before anyone scopes a build.

In the pattern we see, a first AI project has one champion, the person who pushed for it and understands it. If the champion leaves and nobody else can explain the system or read its logs, it becomes an orphan. Ownership means two people who can explain it and one who answers for it.

Check 5 — Risk and money

Risk and money asks three things: how sensitive is the data the workflow touches, what does one wrong answer cost, and does the budget cover what comes after the demo. A project that can't answer all three isn't ready, however good the demo looked — the demo answered none of them.

Three questions. How sensitive is the data this workflow would touch (personal, health, financial, children's), and which rules apply? What does one wrong answer cost: an annoyed customer, a compliance problem, or real money? Does the budget cover evaluation, review, monitoring, and maintenance, or does it end at launch?

• Green (2): You know the data class and its rules, a wrong answer's cost is known and capped by review, and the budget runs past launch.
• Yellow (1): Sensitive data is involved and governance isn't settled, so phase one stays away from it. Or the budget covers the build only, and everyone knows it.
• Red (0) — stop here: Regulated data would reach a model and nobody has asked where it goes. Or nobody can say what a wrong answer costs. Or the plan ends at launch.

Where the data goes belongs in this check, not in a footnote. Before the build, write down which environment processes client or customer data, whether personal identifiers are masked before any external model call, what retention terms apply, and whose cloud account holds it. In the regulated cases in our case notes, that meant the client's own cloud tenancy or an in-country region, masking identifiers before anything left that environment, and zero-data-retention terms on model calls.

Budgets also tend to price the build and forget the running: evaluation before every change, the review queue, monitoring, upkeep. We itemized that side in the real cost of an AI assistant in production, the invisible 80% a demo never shows.

Scoring and the verdict grid

Score each of the five checks: two points for green, one for yellow, zero for red. Eight to ten means ready for a scoped build. Five to seven means ready for one small workflow, with a person reviewing every output. Four or less means fix the foundations first. Two reds override the total.

Three rules keep the arithmetic honest.

Two reds override the total. Two reds and three greens make six, which looks like the middle row. It isn't: two missing foundations can't be scoped around.

One red caps you at the middle row, at best. Some reds can be designed around, like keeping sensitive data out of phase one in the example below. Some can't: a workflow with no owner has nobody to answer for it, and fixing that takes a meeting, not a budget.

A red on Check 3 means "not AI," not "not ready." The scorecard has done its job. Build the software.

When not to do this: If you land in the bottom row, don't hire anyone to build AI yet, including us. Spend the money on the foundations: a pipeline, a written process, an owner with time. And if an assessment you're offered has no possible outcome except a proposal, it isn't an assessment. It's a sales form with better typography.

What "ready" looks like — and what to do if you're not

Ready rarely means perfect data or a company-wide AI strategy. It means one workflow that passes the five checks, with the parts that aren't ready deliberately kept out of phase one. Not ready means a short, specific to-do list, and every item on it makes the eventual project cheaper.

Field note: A senior-living organization's leadership knew AI mattered but not where it made financial sense, and vendors were pitching everything; resident data carried compliance exposure most pitches ignored. The evaluation mapped where AI helps, where plain software wins, and where neither is worth the cost, including where resident data lives. Phase one was a working prototype: a family-facing assistant grounded only in public and marketing materials, with zero resident data, so it could ship while data governance matured on its own timeline. It did. The scope went around what wasn't ready instead of through it.

A children's-services nonprofit made the same move elsewhere. It works with children and families, so deciding what the assistant would never see was the first engineering decision: policies, program manuals, and reporting templates went in; case records and personal data about families stayed out. Every answer cites a source document or declines. New staff now self-serve routine answers, and program leads get hours back.

If you're not ready, the to-do list is short and unglamorous:

• Fix the data. One trusted source for what the workflow needs: a pipeline if it lives in several tools, validation at the form if it arrives dirty.
• Write the process down. One page, exceptions included, agreed by two people who do the work.
• Name the owner. One person who answers for the result, with review time in their week.
• Pick one workflow. Not an AI strategy. Score your workflows on hours, error cost, risk, and friction, and start with the one on top.

"Not ready" is a useful verdict. It comes with a to-do list, not a call booking.

Run it yourself

Pick one workflow with a start and an end, such as intake, the weekly report, or quoting. Sit down with the person who does it every day and answer the fifteen questions together, in writing. Score each check, read your row on the verdict grid, and put every red on a to-do list with a name next to it.

The honest AI-readiness scorecard below is the sheet we use for this: the five checks, three questions each, green/yellow/red criteria, and a "stop here" column on every page.

1. Fill it in with the person who does the work, not the person who buys. The buyer knows the budget; the person doing the work knows the exceptions, where the data really lives, and how often "it depends." In our experience, the buyer's scorecard comes out greener.
2. Score low when torn. Between yellow and green, it's yellow. The scorecard only helps if it's allowed to disappoint you.
3. Re-score after the fixes. A red that turns yellow is progress you can see; a workflow that reaches the top row is worth scoping.

Readiness isn't a maturity level or a strategy deck. It's five plain questions about one workflow, answered by the person who knows it best. A low score rarely means you're behind; more often it means you're about to spend less than you planned, on the right things. If you'd like a second pair of eyes on your answers, including one that might say "not yet," that's what our advisory practice is for.