An AI readiness assessment checks whether a company’s processes, data, risk posture, people, and budget can support a specific AI use case. The useful version ends in a decision: go or no-go on a single pilot. Two weeks is enough when the assessment covers candidate use cases rather than the whole company.
Why a maturity score is the wrong output
Many readiness assessments grade the organization on a maturity scale across data, talent, governance, and technology. The result is often accurate and still inert. “Level 2” doesn’t say what to build, who owns it, or what success looks like.
We assess use cases, not the company. Readiness belongs to a specific process with specific data. The same company is often ready for invoice extraction and nowhere near ready for automated credit decisions. So the output is a ranked list of use cases with one recommended pilot, or a clear “not yet” with the reasons.
What an AI readiness assessment covers
It covers six areas.
Use cases from the people who run the processes
Executives know where the cost sits. The people doing the work know where the time goes. We interview the support lead, the accounts payable clerk, and the analyst who rebuilds the same report every Monday. Four answers matter: volume per week, time per item, what an error costs, and where the inputs live. A candidate without them stays on the long list.
Data: availability, quality, and access
Teams often merge these three questions.
- Availability. Does the data the task needs exist in a system, or only in someone’s head and inbox?
- Quality. We pull a real sample of 50 to 100 records and read it. Are the fields filled, consistent, and current? Are the labels trustworthy enough to evaluate against?
- Access. Is the pilot team legally and technically able to read it, and who approves that?
Process fit
Good first pilots share a shape: high volume, repetitive work, text- or document-heavy inputs, a human already checking the output, and a cheap way to correct mistakes. Poor first pilots are rare, high-stakes, or dependent on judgment nobody has written down.
Risk and compliance
For structure, we use the NIST AI Risk Management Framework (AI RMF 1.0), a voluntary framework released on January 26, 2023. NIST notes that a revision is in progress. NIST organizes the core into four functions: Govern, Map, Measure, and Manage.
For a readiness assessment, Map does most of the work. Its items cover the intended purpose and applicable laws and norms (MAP 1.1), business value (MAP 1.4), the costs of expected errors (MAP 3.2), and human oversight (MAP 3.5), as listed in the Map section of the NIST AI RMF Playbook. The Playbook calls itself “neither a checklist nor set of steps to be followed in its entirety”, so we take the items that fit. For generative AI, NIST added a Generative AI Profile, NIST AI 600-1, published July 26, 2024.
For security, we check each design against the OWASP Top 10 for LLM Applications 2025. Any use case that reads files, web pages, or other external content is exposed to indirect prompt injection (LLM01), where instructions hidden in external content change the model’s behavior.
For EU operations, the next check is Annex III of the EU AI Act, which lists as high-risk the systems that filter job applications or evaluate the creditworthiness of individuals. Under the Act as amended by the Digital Omnibus, the high-risk requirements and the provider and deployer obligations for Annex III systems apply from 2 December 2027. That status is a good reason to keep them out of a first pilot.
People and change
Every pilot needs a business owner who stays after the build team leaves, plus the people who review the output. The EU AI Act requires providers and deployers to take measures to support the AI literacy of their staff, and its human oversight article names the failure mode training has to address: automation bias, the tendency to over-rely on system output.
Run cost
A pilot that looks cheap on a test set sometimes loses money at full volume. We estimate monthly run cost before the pilot starts:
cost_per_item = input_tokens * input_price + output_tokens * output_price
monthly_cost = items_per_month * cost_per_item * (1 + retry_rate)
+ hosting + monitoring + review_hours * hourly_rateIt then sits next to the value per item from the interviews. Production also needs a spend cap. OWASP describes “denial of wallet” attacks that exploit pay-per-use AI pricing under Unbounded Consumption (LLM10).
The AI readiness checklist
One row per area, filled in for each candidate. A row without evidence counts as a “no”.
| Area | Question to answer | Evidence that counts |
|---|---|---|
| Use case | What does this process cost today? | Volume, time per item, error cost, and a named owner |
| Baseline | How will we know the pilot worked? | One metric’s current value, pulled from a system |
| Data availability | Does the input exist in a system? | Source named, sample exported |
| Data quality | Is the sample usable as-is? | 50 to 100 records reviewed, gaps noted |
| Data access | Is the pilot team able to read it? | Access approved, or a dated request |
| Process fit | Is the process stable and checkable? | Written steps, and a human reviews output today |
| Risk | What happens when the model is wrong? | Error cost, reversibility, and NIST AI RMF Map notes |
| Compliance | Which rules apply to this data and decision? | Data classification and an EU AI Act Annex III check |
| Security | What does untrusted input make the system do? | Design reviewed against the OWASP LLM Top 10 |
| People | Who owns it, and who reviews output? | Named owner and reviewers, plus a training plan |
| Architecture | Where is this data allowed to be processed? | Cloud, local, or hybrid, with the boundary drawn |
| Run cost | Does it pay at full volume? | Monthly estimate vs. value per item |
How to score and rank use cases
We score each candidate from 1 to 5 on three scales, then multiply.
- Value. What the process owner’s numbers say a working system is worth. 1 is a convenience, and 5 is a cost or delay the sponsor already tracks.
- Feasibility. Available, accessible data, a stable process, and a promising quick test on real samples. 1 means the data doesn’t exist or is out of reach.
- Risk. The consequence of a wrong output. 1 is internal, reversible, and free of personal data. 5 is a regulated or hard-to-reverse decision about a person.
Priority = Value × Feasibility × (6 − Risk), ranging from 1 to 125.
Multiplication is deliberate. A sum lets a high value score hide a data problem, while a product lets any weak dimension pull the candidate down. Illustrative scores for a hypothetical mid-size company:
| Candidate use case | Value | Feasibility | Risk | Priority | Call |
|---|---|---|---|---|---|
| Support ticket triage and routing | 4 | 4 | 2 | 64 | Pilot |
| Invoice field extraction into the ERP | 3 | 5 | 2 | 60 | Runner-up |
| Sales call summaries into the CRM | 3 | 4 | 3 | 36 | Later |
| Contract clause review for legal | 5 | 2 | 4 | 20 | Not yet |
| Screening job applications | 4 | 3 | 5 | 12 | Not yet |
Two rules sit on top of the arithmetic. A 1 on feasibility or a 5 on risk means “not yet”, whatever the product. When two candidates are close, we pick the one with the cleaner baseline, because a pilot without a measurement produces no decision.
Red flags that mean “not yet”
“Not yet” is a valid result when it comes with the reasons and a list of what to fix first. Assessments that end there share a few patterns:
- No baseline. Nobody has measured how long the process takes or what an error costs. Measurement comes first.
- No access path. The inputs live in personal inboxes, or the access request has no owner and no date.
- Unstable process. Steps differ by team or change monthly. Teams that standardize first avoid automating the inconsistency.
- Zero error tolerance with no reviewer. Language models produce plausible but incorrect statements, which researchers trace to training and evaluation that reward guessing over admitting uncertainty. If nothing catches a wrong answer before it does damage, the design isn’t ready.
- Decisions about people first. Hiring, credit scoring, and life and health insurance pricing for individuals are listed in Annex III of the EU AI Act. Strong first pilots sit where a mistake is cheap.
- No owner after launch. A pilot owned by the vendor ends with the contract.
- Boundary conflict. The data has to stay inside the company network, and only a hosted API performs well enough. That question gets settled before anyone builds.
A two-week plan, day by day
Ten working days are enough when the sponsor protects the calendar and access requests go out on day one.
| Day | Work | Output |
|---|---|---|
| 1 | Kickoff: the decision, constraints, and processes in scope. Access requests go out. | Interview list, requests filed |
| 2 | Process docs, system list, and data classification policy collected. Interviews booked. | Interview schedule |
| 3–4 | 45-minute interviews with 6–10 people who run the processes. | Long list with volume, time, and error cost |
| 5–6 | System walkthroughs and data samples for the strongest candidates. | Data notes |
| 7 | Scoring and ranking, cut to 3–5. Real samples tested on a model in an approved environment. | Ranked shortlist |
| 8 | Risk review of the top three, architecture options, and run cost. | Risk, cost, and architecture notes |
| 9 | Pilot plan for the top candidate and the final report. | Report draft |
| 10 | Decision meeting to approve, change, or reject the pilot. | Go / no-go, recorded |
What the assessment produces by day 10
Ranked use cases
The scored table with the evidence behind every score: interview notes, sample findings, and the risk call. Anyone who disagrees with a score sees what would change it.
Architecture sketch: cloud, local, or hybrid
One page showing where data flows and where the boundary sits.
- Cloud. Hosted model APIs. Fastest to start, and fine when contracts and data classification allow data to leave the network.
- Local. Open-weight models on company hardware or a private cloud, for data that stays inside, with the company running the models.
- Hybrid. A gateway in the middle masks sensitive fields or keeps them local, sending only permitted data to a hosted model. We cover that pattern in what an AI gateway does.
Pilot plan with one success metric
Scope, owner, timeline, budget, and exactly one metric that decides success. Guardrails are stop conditions, not goals.
pilot: support-ticket-triage
owner: head of support
success_metric:
name: median minutes from ticket creation to the correct queue
baseline: pulled from the ticketing system before the build
target: agreed with the sponsor before the build
guardrails:
- misrouted tickets stay at or below the baseline rate
- no customer data leaves the approved boundaryOne metric forces the hard conversation early. If the sponsor and the process owner can’t agree on it during the assessment, they won’t agree later on whether the pilot worked.
Where to start this week
We recommend five first steps, none of which need outside help:
- A written statement of the decision expected in two weeks: which pilot, or “not yet” and why.
- A sponsor who can make that call, and 6–10 people who run the candidate processes.
- Data access requests for the systems those people use. Approvals are often the slowest step.
- Security’s data classification policy and approved vendor list.
- For each candidate, one number already in a system, which becomes the baseline.
When an outside team makes more sense, our AI Readiness Sprint takes two weeks for a fixed $7,500: interviews with the people who run the processes, a data readiness check, ranked use cases, an architecture sketch, and a risk review. It ends in the same place: a pilot plan with one success metric, or a clear “not yet” with the reasons.