Is your company ready for AI? A technical readiness checklist

An AI prototype can look convincing before the surrounding workflow is ready. Data access, evaluation, human review and running costs determine whether it can become a useful product for an Indian SME or startup.

Use this checklist to identify those dependencies before committing to a build. It is a planning guide, not a record of client outcomes or a prediction of accuracy.

Can you get your own data, and is it any good?

Every useful LLM system is a data pipeline with a model in the middle, and the pipeline fails first. Before any architecture conversation, run two tests.

The one-day pull test

Ask an engineer to assemble 500 representative examples of the real input — referral faxes, support tickets, contracts, whatever the system will actually read — by tomorrow. Not a curated sample: the true distribution, including the photographed forms, the scans at an angle, and the emails where the answer hides four replies deep. If the pull requires a ticket queue, two access reviews, and a legal opinion, you have found your first project, and it is not an AI project.

The someone-who-knows test

Now put those 500 examples in front of a person who can explain them: what each field means, which values are plausible, which source systems lie. Schemas and validation rules get written from exactly this knowledge. If it lives in nobody's head, or in one head with no time for you, accuracy has a ceiling that no model choice can raise. Note what is missing from this section: volume. Many application designs can use retrieval, schemas and validation without training a new model. Meaning is the constraint, not size.

An eval harness before the first feature

The strongest readiness signal we know is boring: a hand-labeled evaluation set — a few hundred real examples with correct answers, agreed by the people who own the workflow. It converts "the model seems good" into a sentence like "the model is right on 94 percent of vendor-name fields and 78 percent of line-item categories" — a sentence you can act on: it says what ships, what routes to review, and what needs redesign.

Build the harness before the first feature, because it is the only honest way to answer the go/no-go question. Two weeks of labeling with your domain experts measures the accuracy ceiling on your documents rather than on a vendor's benchmark. If the ceiling is too low to ship, you have spent two weeks finding out. Skip the eval and you will find out in production, two quarters and one executive review too late.

A demo proves the model can do the task once. An eval proves it can do the task ten thousand times — and tells you the week it stops.

The harness keeps paying after launch. Every prompt change, model upgrade, and threshold adjustment runs against it before production does, and a monthly audit against freshly labeled samples surfaces drift in a report instead of in a customer incident.

Name the human who checks the model's work

Human-in-the-loop is not an admission that the AI failed. It is the design decision that lets a probabilistic system touch consequential records at all, and it has to be designed — a person rubber-stamping a queue at 4pm is not a control, it is a liability with a login.

The mechanics that make review real: every extracted value carries a confidence score and a pointer back to its exact location in the source, low-confidence outputs demand attention before anything else, and the review screen puts each field beside its highlighted source snippet so confirming a value takes one glance instead of a hunt. In pnlbook, the trading journal we built, nothing lands in the ledger until a person has confirmed anything the model was unsure about — and because that review screen was designed as the product rather than bolted on, confirming a flagged value takes one glance instead of a re-key.

The readiness questions: who are your reviewers, what does one review cost in minutes, and does the workflow owner accept that cost? If reviewing an output takes as long as producing it by hand, the design has failed before the model runs. Done well, review is a small fraction of the original task — and that fraction is where the ROI lives, so model the review cost before you model the savings.

Draw the compliance and cost boundaries before the architecture

Where PHI and PII may travel

If your data includes PHI, PII, or anything a regulator has a name for — the usual case in healthcare software — the data boundary is an input to the architecture, not a review gate at the end. Write one page with your compliance lead before any code exists: which fields may leave your infrastructure and under which agreements (BAA, DPA), whether anything may enter a model provider's training set (the correct answer is no), and what logs and traces may contain — prompts leak PHI by default, and excluding it is deliberate engineering, not a setting. A system designed inside those lines passes review in weeks. A system that meets its compliance officer in month eight becomes a pilot that cannot legally graduate.

A cost ceiling per request, in writing

Token costs look like rounding errors until they are multiplied by production volume. Set a ceiling per unit of work — per document, per ticket, per conversation — and tie it to the money that unit saves. A pilot estimate may omit retries, unusually long inputs and reranking, so measure those costs before projecting production spend. Model routing, caching, and batching are the engineering responses to a ceiling; without one, "we'll optimize later" quietly becomes the unit economics. The discipline is the same one that keeps any build honest — we wrote up what custom software actually costs in 2026 — but AI adds a variable cost per request that no launch date makes retroactively affordable.

Mind the pilot-to-production gap

Between a working pilot and a production system sits most of the real budget, and it is where AI projects go quiet. The pilot handled the happy path on curated inputs. Production handles malformed documents and 40-page outliers, provider outages and retries, prompts and model versions pinned and change-controlled so that Tuesday's output can be explained on Thursday, accuracy and cost on a dashboard someone reads, and an on-call rotation that knows what "broken" means for a system that is probabilistic on its best day.

Then ask the question pilots never answer: who owns this in month 13? Somebody adjusts thresholds, reads the drift report, and approves the next model upgrade through change control. If the answer is "the vendor, forever," price that dependency honestly. If the answer is a shrug, the pilot is a sunk cost in progress.

Signs you are not ready

Situations where a simpler approach may be more useful:

• The sponsor is enthusiasm, not a workflow owner. Ready projects start from a metric that hurts — a queue measured in days, a cost per case everyone knows. "The board asked about AI" is not a workflow.
• Data access requires a committee. If your own engineers cannot reach the inputs, an outside team certainly cannot.
• Nobody can name a reviewer. No named humans for the loop means no loop, which means no path past legal for anything consequential.
• "Seems good" is the acceptance criterion. No labeled baseline means every executive review reopens the question of whether the system works, forever.
• Compliance has not heard of the project. Every month of silence is converting into rework at an unfavorable rate.
• The plan has no month 13. No owner for thresholds, drift, and upgrades means you are building a demo with production infrastructure costs.

None of these is a verdict. Most are six-to-twelve week fixes, they cost far less than a stalled pilot, and every one of them — data access, an eval habit, a compliance relationship that starts early — pays off even if you never ship a model. Scored honestly, the checklist fits on one page:

AI readiness scorecard — one point per yes

[ ] 500 representative real inputs pulled in one day, legally
[ ] A named person who can explain every field in that sample
[ ] A hand-labeled eval set and a per-field accuracy number
[ ] Named reviewers, and the cost of one review in minutes
[ ] A one-page data boundary your compliance lead has signed
[ ] A cost ceiling per request, tied to what the unit saves
[ ] A named owner for the system in month 13

6-7  fund the build
4-5  fix the gaps first — weeks now instead of quarters later
0-3  run a feasibility phase, not a project

A high score does not guarantee the model clears your accuracy bar — that still has to be measured, on your documents. Operational readiness still needs to be tested alongside model performance. If you land in the middle and want the measurement done properly, our approach to AI development can begin with a scoped feasibility phase: a labelled evaluation set, measured performance on your own data and a decision about whether a larger build is justified.