A Practical AI Readiness Checklist for Mid-Market Teams

I keep seeing mid-market teams jump straight to “which model?” or “which vendor demo looked coolest.” Then the pilot stalls. Not because the model was weak. Because nobody checked whether the data was reachable, the use case was real, or anyone owned the risk when something went wrong.

You do not need a six-month strategy program. You often need a half-day workshop with a blunt checklist. Something leaders can answer in plain language before money moves.

Start with data access, not the tool

If people cannot get to the records the AI would need, you are shopping for a car without keys. Map where the relevant data lives: CRM, shared drives, tickets, ERP extracts, policy PDFs, spreadsheets someone still emails every Friday.

Ask concrete questions:

• Who can grant access, and how long does that usually take?
• Is any of this personal, regulated, or client-confidential?
• Is there a single source of truth, or three versions that disagree?
• How fresh does the data need to be for the decision you care about?

AI projects behave more like data projects than pure software builds. If that framing is new, this piece on data-first AI is worth a skim. Ownership matters too: who controls the data should be clear before a vendor embeds it in their stack.

Pick use cases that survive a skeptical room

“We should use AI” is not a use case. A use case names a user, a decision or task, the inputs, and what “done well enough” looks like. I like thin slices: one process step, one role, one measurable pain (time, rework, missed handoffs).

In the workshop, force each candidate through a few filters:

• Does someone do this work every week, not once a year?
• Is the cost of a wrong answer contained, or could it hit customers, compliance, or money?
• Would a faster draft with human review still be valuable, or only a fully automated answer?
• Can you describe success in business terms, not only “accuracy”?

If you cannot explain the workflow, you probably cannot design the AI either. Process and requirements habits help here; BA-style framing is often underrated.

Talk about risk before the pilot starts

Risk does not have to mean a legal novel. It means answering: what happens if the system invents a fact, leaks a field, or sounds confident when it is wrong?

Cover at least:

• Data classes: what may leave the building, what stays internal, what never goes into a public chatbot.
• Human review: which outputs need a person before they go to a client or a system of record.
• Logging: will you know what was asked and what was returned when someone complains next month?
• Fail modes: what does the process do when the model is down, slow, or unreliable?

Teams that skip this often discover the policy in production, which is the expensive way to write policy.

Skills and capacity, honestly

Mid-market groups rarely have a full AI lab. That is fine. You still need someone who can translate business need into tests, someone who can watch data quality, and someone who can say no when a demo is not ready.

Ask:

• Who owns the pilot day to day (not “the steering committee”)?
• Do we have time for review and feedback, or only for the launch meeting?
• What do subject-matter experts still need to do that the model cannot?
• Is training a one-hour lunch-and-learn, or ongoing coaching?

If the answer is “we will figure it out later,” budget later usually never arrives.

Vendor questions that cut through the slide deck

Vendors will show polished demos. Your job is to ask things demos skip:

• Where does our data go, and can we export or delete it cleanly?
• What model versions do you use, and how do you handle upgrades without breaking our prompts and evals?
• How do you measure success for our use case, not only generic benchmarks?
• What is included in support when output quality drifts?
• Can we start with a narrow pilot and walk away without a multi-year lock-in?

If answers get vague on data residency, exit paths, or evaluation, treat that as a signal.

A workshop shape that usually works

Ninety minutes to half a day is enough for a first pass:

1. List three candidate use cases and kill two.
2. For the survivor, map data sources and access blockers.
3. Write risk rules in plain language (allowed inputs, review points, forbidden data).
4. Name owners and a four-to-eight week pilot scope.
5. Decide go / no-go on budget until access and owners are real.

Company-specific answers often need retrieval over your own material, not a generic chat box. When that is the case, RAG-style approaches should be on the table early, not as a surprise mid-build.

Practical takeaway: do not fund a pilot until you can name the use case, the data path, the review rule, the owner, and the exit criteria. The checklist is boring on purpose. Boring is what keeps mid-market AI from turning into an expensive demo.