AI readiness checklist for mid-market operations

Data readiness (10 points)

AI is only as good as the substrate it sits on. If your source-of-truth is spread across ten spreadsheets and three legacy databases, no model will save you.

• You can name the single system-of-record for every entity the AI will touch (customer, order, ticket…).
• The data has been profiled in the last 90 days: nulls, duplicates, outliers, freshness distributions documented.
• A repeatable extraction path exists for the AI workload — not a one-off SQL dump.
• PII fields are catalogued and access-controlled; the AI workload has a documented data-handling boundary.
• Historical labelled data (for tuning / evaluation) is available or has a plan to be generated.
• Data lineage — you can trace any field the AI consumes back to its source table and its update cadence.
• A written retention + deletion policy covers any data the AI ingests, transforms or logs.
• Latency budgets for read paths are defined and measured against actual production load.
• A change-data-capture or event stream exists for anything the AI must react to in near-real-time.
• Someone owns the data quality metric. Not "the team". A named person.

Evaluation & safety (10 points)

You cannot ship what you cannot measure. Every AI system that reaches production needs an evaluation harness before the first customer sees it — otherwise you find out about failures in a support ticket.

• A golden dataset of 30–200 representative examples exists (or has a plan).
• Each example has a clear pass/fail criterion — not "looks good" but a rule a reviewer can apply consistently.
• The evaluation runs on a schedule (nightly at minimum) and produces a trend, not a single number.
• Failure modes are catalogued: hallucination, refusal, over-refusal, wrong tool call, wrong entity extraction.
• There is a human-review queue for edge cases and a written escalation path for uncaught failures.
• Prompt injection has been considered explicitly and mitigations chosen (input filtering, output constraints, sandbox).
• Personally-identifiable outputs are constrained by policy, not by the model's judgement.
• A red-team exercise is planned before go-live for anything customer-facing.
• Rollback is one-click: revert to the previous prompt / model / retrieval config in under 5 minutes.
• Cost per interaction is measured, budgeted and alerted on.

Ownership & change (10 points)

The wrong owner sinks more AI projects than the wrong platform. Whoever owns this workload needs authority to approve prompts, approve tool access, and approve changes to the source data.

• A single accountable owner is named — with authority to make production changes.
• The operating team affected by the AI has been consulted before scope was signed.
• Success criteria are written down and quantitative (e.g. "cut tickets touching billing by 30% within 90 days").
• A weekly review cadence is on the calendar for the first 90 days after go-live.
• Comms + training materials for end users are drafted before the pilot goes live.
• Support escalation paths are updated to include the AI workload.
• A written kill switch policy exists: what does "shut it down" look like operationally?
• Legal / privacy / security have signed off — not been informed.
• The budget covers not just build but 12 months of run, evaluation and iteration.
• Someone owns telling a compelling story about why this was done — internally and externally.

Scoring

• 26–30: Ready to scope a delivery engagement.
• 22–25: Ready for a paid discovery to close the small gaps.
• 18–21: Do the readiness work first. A month of grunt work will save six months of pilot fatigue.
• Below 18: Do not buy a platform yet. The readiness work is the real project.

If you want an outside pair of eyes on this checklist for your specific operation, book a 30-minute consultation and we'll score with you.