AI Readiness Assessment: 25 Questions to Ask Before an AI Pilot
Most AI programs stall at the same point. The model works, the demo lands, and then someone asks what it takes to run this daily on live data. The answer names a departed data owner, an unscheduled compliance review, an undocumented process.
- AI Development
August 13, 2026
AI OverviewWhat is AI readiness? The state of being positioned to deploy and operate AI for a specific purpose, measured across use case value, data, process, systems, people, and governance. Readiness is scored per use case, not per company: the same organization can be ready for invoice classification and unready for demand forecasting. A 25-item checklist scores each dimension 0–3 before the build, so blockers like inaccessible data or late compliance review cost days of assessment instead of months of pilot time.
An AI readiness assessment finds those blockers while they are still cheap to fix.
What follows is a working answer to how to assess AI readiness in your own organization: a six-dimension framework, a 25-item checklist, a 0–3 scoring model with gating rules, and what to do with each of the three possible verdicts.
It is written for mid-size and enterprise companies where AI implementation readiness depends on a system of record, a regulated data set, and at least one team whose daily work changes.
What Is AI Readiness Assessment
Definition
An AI readiness assessment is a time-boxed evaluation of whether a specific AI use case can reach production and stay there. It scores six things — the business case, the data, the process, the systems, the people, and the governance obligations — and returns a decision with conditions attached: go, go once these gaps close, or hold.
Scope decides the value. An assessment for AI readiness aimed at two to five candidate use cases produces findings you can act on this quarter. The same exercise aimed at “AI in the company” produces a maturity score and a slide deck.
Readiness vs. Evaluation vs. AI Readiness Audit
Vendor material uses these three interchangeably, and the difference decides what you are buying.
Term | What it covers | When it happens |
|---|---|---|
AI readiness | The state itself: how well positioned a company is to deploy and operate AI for a given purpose | Measured at a point in time |
AI readiness evaluation | The forward-looking exercise that measures that state, names what is missing, and prices the gap | Before the build |
AI audit | Review of a live system: performance drift, bias in outcomes, documentation, conformity under the EU AI Act | After deployment, on a cycle |
AI readiness audit is sold as both, so check the deliverable list before signing. Companies that skip the first row usually meet the third one under pressure.
How to Assess AI Readiness: Expected Outcomes
A completed AI readiness evaluation hands you six artifacts: a scored readiness map with the evidence behind each score, a ranked use case shortlist with value and effort ranges, a data gap register with named owners, integration and architecture requirements, a governance gap list, and a 90-day roadmap carrying an indicative AI development cost. Anything less leaves the next decision unsupported.
Why It Matters Before a Pilot
Common Failure Scenarios
Pilots fail in patterns. Five of them account for most of the waste, and each one is detectable in advance.
The use case with no owner. A use case gets selected because it demos well. No single person carries the metric it improves, so no budget line exists for the production version. The pilot succeeds technically and dies at the funding conversation.
Data that exists in principle. The field is in the schema. Getting a representative sample requires a legal review, a vendor data-sharing agreement, and a person on parental leave. Six weeks of a twelve-week pilot go to access.
No agreed definition of correct. The team reports 91% accuracy on a test set that three experts labeled inconsistently. The number cannot be defended, and the review turns into a debate about labels.
Nowhere for the output to land. The model produces a classification. The system of record has no field to hold it and no API to write it with. The pilot ends as a spreadsheet someone copies by hand.
Governance arrives last. Legal sees the system two weeks before launch, classifies it as high-risk under the EU AI Act, and asks for documentation, logging, and oversight that were never designed in. Launch slips a quarter.
With vs. Without Assessment
Without an assessment | With an assessment | |
|---|---|---|
Use case selection | Chosen by enthusiasm and demo appeal | Ranked by value, feasibility, and dependency risk |
Data discovery | Happens inside the pilot timeline | Completed before the build is scoped |
Success criteria | Defined after results appear | Baselined and agreed up front |
Integration | Discovered late, often out of scope | Specified as a requirement |
Governance | Reviewed near launch | Classified at the start, controls designed in |
Typical outcome | A working demo with no production path | A scoped increment with a funded owner |
Cost of finding a blocker | Weeks of engineering time | Days of assessment time |
The economics are the argument. A blocker found in a two-week assessment costs a conversation. Found in month three of a pilot, it costs the pilot.
The interesting finding in a readiness assessment is rarely the technology. It is the moment a client discovers that two departments define the same customer event differently, and that the AI would have inherited the disagreement.
AI Readiness Assessment Framework
Overview of Dimensions
Six dimensions make up the AI readiness framework, each answering one question. Together they cover every dependency an AI use case has in production.
Dimension | The question it answers |
|---|---|
Use Case & Value | Is this worth building, and does anyone own the outcome? |
Data | Does the evidence the system needs exist, and can it be used? |
Process and Systems | Where does the output land, and can the systems accept it? |
Organizational | Are the people who make it work available and willing? |
Governance & Risk | Can this be deployed lawfully and operated accountably? |
The order is deliberate. A weakness in Use Case & Value invalidates strength everywhere else. A weakness in Data caps what the other four dimensions can deliver. Governance rarely blocks a build outright, and it reliably determines the launch date.
How to Use This Framework
The AI readiness assessment framework works as a scoring instrument, and five rules keep the output honest.
Score per use case. Readiness for invoice classification and readiness for demand forecasting are different scores inside the same company. Averaging them hides the decision.
Timebox it. Two to three weeks for two to five use cases. Longer engagements produce more detail and the same decision.
Require evidence. A score of 2 or 3 needs an artifact behind it: a process document, a query result, a sample export, a named owner in an org chart. Workshop opinions produce inflated scores and a false green light.
Involve six roles. The process owner, an engineer with data access, a subject-matter expert who defines correctness, the owner of the target system, legal or compliance, and a decision-maker who can commit budget. Missing any one leaves a dimension unscored.
Treat low scores as gates. The dimensions are not additive. A green total with Data at zero is still a stop.
Tooling is a minor question. A spreadsheet serves as well as dedicated AI readiness assessment tools, and the discipline of scoring against evidence carries the value.
Business & Use Case Readiness
What to Evaluate
AI use case readiness establishes whether the use case deserves the investment and whether an outcome owner exists.
Start with the metric. A ready use case names a business metric, states its baseline, and quantifies the improvement worth paying for. “Reduce average invoice processing time from 4.2 days to under 1 day” supports a decision. “Improve efficiency with AI” does not.
Then volume. AI economics depend on repetition. A decision made 40,000 times a year justifies engineering effort that the same decision made 200 times a year never will. The threshold moves with company size, and AI for small business runs on different arithmetic.
Then ownership. One person needs to hold the metric and budget authority over the outcome. Ownership split across two functions is the most reliable predictor of a pilot that never reaches production.
Finally, the definition of correct. Two independent experts, given the same input, should produce the same expected output. Any disagreement is a specification gap, and it surfaces later as unexplainable model error.
Signs You’re Not Ready
The business metric is unnamed, or named without a baseline value
Nobody can state the annual volume of the task
The sponsor is a committee
Two experts give different answers to the same input, and the difference is unresolved
The primary stated goal is to demonstrate AI capability
Data Readiness
What to Evaluate
Data readiness for AI is the dimension that most often converts a confident go into a six-month delay. An AI data readiness assessment covers four things.
Existence and history. The data has to sit in a system of record, with enough history for the pattern to be learnable. Most supervised use cases need 12 to 24 months, and seasonal patterns need at least two cycles.
Practical access. Existence and access are separate findings. The test is operational: can an engineer obtain a representative, de-identified sample within five working days by a repeatable route? If that depends on one person exporting a file by hand, access is not ready.
Ground truth. Evaluation requires labels, existing or derivable from historical outcomes. Where none exist, creating a labeled set becomes a pre-pilot work item with its own cost.
Quality, measured. Known quality problems are workable. Unknown ones carry the risk. Missing-field rates, duplicate rates, format inconsistencies, and the share of records failing basic validation should all appear as numbers from real tables.
Add the legal layer: what personal data is present, which jurisdiction it sits in, the retention rule, and whether the intended use falls inside the original lawful basis.
Signs You’re Not Ready
The relevant data lives only in free-text fields, email threads, or attachments
Getting a sample requires a manual export by a specific individual
No labeled outcomes exist, and none can be derived from history
Data quality is described in adjectives with no measured rates
The same entity carries different identifiers across systems with no mapping
Personal data is present, and the lawful basis for AI use is untested
Customer Stories
Explore What We've Built
A Race-Day Operating System for Safety and Compliance
On race day, safety depends on more than sending alerts. Organizers need proof of who received each message, who acknowledged it, and what record remains. Lumitech built a platform around that responsibility, helping protect trust, compliance, and control.
Amsterdam
Oct '25 - Mar '26
An AI‑Powered Cognitive Training and Brain Health Platform
Turning generic “brain games” into a personalized, data‑driven cognitive training experience – combining adaptive daily workouts, real health data insights, and a conversational AI assistant in one product.
Houston
Oct '25 — Mar '26
Reviving Roots: How We Built an AI-Powered African Language Learning Platform
Lumitech built an AI-powered language learning platform with speech feedback, adaptive lessons, gamification, and analytics for users in the African diaspora.
New Jersey
Aug '25 — Now
Fighting Misinformation with an AI-Driven Social Platform
Together with our client, we launched a social app designed to prevent the spread of fake news by empowering users to verify sources and flag misinformation.
Nashville
Jul ’24 – Apr ’25
EdTech & Training
A Race-Day Operating System for Safety and Compliance
On race day, safety depends on more than sending alerts. Organizers need proof of who received each message, who acknowledged it, and what record remains. Lumitech built a platform around that responsibility, helping protect trust, compliance, and control.
Client Location
Amsterdam
Duration
Oct '25 - Mar '26
Platform
Web + PWA
An AI‑Powered Cognitive Training and Brain Health Platform
Turning generic “brain games” into a personalized, data‑driven cognitive training experience – combining adaptive daily workouts, real health data insights, and a conversational AI assistant in one product.
Houston
Oct '25 — Mar '26
Reviving Roots: How We Built an AI-Powered African Language Learning Platform
Lumitech built an AI-powered language learning platform with speech feedback, adaptive lessons, gamification, and analytics for users in the African diaspora.
New Jersey
Aug '25 — Now
Fighting Misinformation with an AI-Driven Social Platform
Together with our client, we launched a social app designed to prevent the spread of fake news by empowering users to verify sources and flag misinformation.
Nashville
Jul ’24 – Apr ’25
Process Readiness
What to Evaluate
An AI output has value only when it changes what happens next. Process readiness for AI examines the workflow it enters.
Business process readiness for AI rests on documentation. Map the process end to end, with volumes, cycle times, and handoffs. Documentation quality is itself a signal: a process nobody has written down is a process nobody can measure a change against.
Locate the insertion point precisely. Which step does the output arrive at, who sees it first, and what action does it trigger? The mechanics of how decision intelligence and AI improve decision-making come down to that detail, and vagueness here is how pilots become dashboards nobody opens.
Define the exception path and measure its frequency. In the processes we have assessed, 70–90% of cases follow a standard path and the rest run through exceptions handled by experience.
Specify human oversight: which decisions need review, on what sample, and what happens when the reviewer disagrees. An operational design question first, a compliance requirement second.
Confirm measurability. Before and after have to be measurable by the same method on the same population. Without that, the pilot produces anecdotes.
Signs You’re Not Ready
No end-to-end process documentation exists
Cycle times and volumes are estimated from memory
The exception rate is unknown
Nobody can name the person who acts on the output
The process differs materially by team, region, or individual
Systems & Infrastructure Readiness
What to Evaluate
AI infrastructure readiness covers whether the output can reach the place it needs to reach, and whether a model can be operated once deployed.
Integration surface. Technical readiness for AI starts here: the system of record needs a documented API for reading inputs and writing outputs. Read-only access limits the use case to advisory output. Screen-scraping and RPA workarounds are viable, and they carry an ongoing maintenance cost that belongs in the estimate.
Deployment environment. Something has to host inference, with versioning, rollback, and environment separation. A working CI/CD pipeline puts an organization weeks ahead of one where deployment is a manual step.
Observability. Input and output logging, latency monitoring, error alerting, and drift detection. These are day-one production requirements, and retrofitting them costs more than including them.
Constraints, confirmed early. System readiness for AI also depends on decisions outside engineering’s control: cloud region, approved vendors, on-premise requirements, network isolation, and whether a third-party model API can be called at all. A data residency rule discovered in month two rewrites the architecture.
Volume and latency. Expected inference volume, peak load, and the latency the process tolerates. Sub-second interactive scoring and overnight batch scoring are different systems at different cost points.
Weak AI infrastructure readiness rarely blocks a pilot outright, and it reliably caps what that pilot can prove about production.
Signs You’re Not Ready
The target system has no API, and no vendor roadmap for one
Deployments are manual and undocumented
No monitoring or centralized logging exists for internal services
Cloud, region, or vendor constraints are unconfirmed
Every environment change requires an external vendor ticket
Organizational Readiness
What to Evaluate
Technical strength with no organizational readiness for AI produces systems that work and go unused.
Allocated capacity. Named engineers with a stated percentage of time for the pilot duration, confirmed against current commitments. “The platform team will support it” describes an absence of capacity.
Expert availability. Subject-matter experts define correctness, resolve edge cases, and review outputs. Their time needs to be booked in a calendar. Expert unavailability is the most common cause of slippage in organizations that are otherwise well prepared.
Change capacity. The people whose work the system changes should know about it before it arrives. Where AI affects headcount, throughput expectations, or performance measurement, address that openly and early. Systems introduced quietly get worked around quietly.
Track record. Prior experience with a controlled rollout — pilot group, measurement, iteration, expansion — transfers directly. Its absence means building the rollout mechanics alongside the system.
Decision path. A named forum that can approve production deployment, at a known cadence. Unclear escalation turns a successful pilot into an indefinite extension.
Signs You’re Not Ready
Engineering support is described without named individuals
Subject-matter experts have no allocated hours
Affected teams have not been informed
The approval path for production deployment is undefined
A previous automation initiative was abandoned, and the reasons were never examined
Governance & Risk Readiness
What to Evaluate
AI governance readiness determines the launch date. It rarely stops a build, and it routinely delays one.
Regulatory classification. Classify the use case before the build. Under the EU AI Act ((Regulation (EU) 2024/1689)), obligations differ sharply between limited-risk and high-risk systems, and use cases touching employment, credit, insurance, education, or essential services frequently land in the high-risk tier. Sector rules add their own layer.
Risk ownership. One named person accountable for AI risk decisions, with a route to escalate. Distributed accountability produces a review cycle nobody can close.
Third-party and data handling policy. Whether external model APIs may be called, what data may leave the environment, what the vendor’s retention and training terms are, and who approves exceptions. Absent policy, every decision defaults to a lengthy case-by-case review.
Traceability. What gets logged, how long it is retained, and how a past decision can be reconstructed. High-risk systems carry documentation obligations that are far cheaper to design in than to recreate.
Failure handling. A defined path for a wrong output that reaches a customer: detection, containment, remediation, notification, and root-cause correction. Undefined failure handling turns a contained incident into a reputational one.
Signs You’re Not Ready
The use case has never been classified against applicable regulation
No named owner exists for AI risk decisions
No policy governs sending company data to third-party model providers
No process exists for handling an incorrect AI output that reaches a customer
Legal and compliance are scheduled to review the system near launch
The dimensions above are scoreable in-house. Two parts usually need outside hands: measuring data quality against real tables, and classifying the use case against regulation before anyone writes code.
AI Readiness Checklist & Scoring
Checklist Structure
The AI readiness checklist below turns the AI readiness assessment framework into 25 scoreable items, five per dimension. Score each one 0 to 3, for a maximum total of 75. Run the AI readiness assessment checklist per use case, with evidence for every score above 1.
These AI readiness assessment questions are written to be answerable with an artifact. Copy them into a two-column AI readiness assessment template — score and evidence — before the first interview.
Use Case & Value
The target business metric is named, with a current baseline value.
The annual volume of the task is known and documented.
One person holds both the metric and budget authority for the outcome.
The cost of the current approach is quantified.
A documented definition of a correct output exists, and two experts agree on it.
Data
The required data exists in a system of record with at least 12 months of usable history.
An engineer can obtain a representative sample within five working days by a repeatable route.
Ground truth for evaluation exists or is reliably derivable from historical outcomes.
Data quality issues are documented with measured rates.
Personal data, residency, retention, and lawful basis are identified and cleared for the intended use.
Process & Systems
The target process is documented end to end with volumes, cycle times, and a measured exception rate.
The insertion point is defined: which step receives the output, who acts on it, and what the escalation rule is.
The system of record exposes APIs for reading inputs and writing outputs.
An environment exists where a model can be deployed, versioned, monitored, and rolled back.
Hosting constraints, latency, and expected inference volume are confirmed.
Organizational
Named engineers are allocated with a stated time percentage for the pilot duration.
Subject-matter expert hours are booked in a calendar.
Affected teams have been informed and involved.
A prior workflow change has been rolled out and measured in this organization.
A named forum can approve production deployment at a known cadence.
Governance & Risk
The use case is classified against applicable regulation, including EU AI Act risk tier where relevant.
A named person is accountable for AI risk decisions.
A policy governs third-party model use and data handling.
Logging, traceability, and retention requirements are defined.
A documented process exists for handling an incorrect output that reaches a customer.
Scoring Model (0–3)
Score | Level | Meaning |
|---|---|---|
0 | Absent | Nothing in place. Creating it is a project. |
1 | Ad hoc | Exists in pockets. Undocumented, person-dependent, unrepeatable. |
2 | Defined | Documented and repeatable. Gaps are known and bounded. |
3 | Operational | Measured, owned, and already supporting production workloads. |
Score what exists today. Planned work scores 0 until delivered. Roadmap credit is how assessments turn green on paper and fail in delivery.
Interpreting Results
56–75 — Pilot-ready. Conditions support a scoped pilot with a production path. Start with the highest-ranked use case and hold the scope to one process and one integration.
38–55 — Conditional. The use case is viable, and specific gaps need to close first. Typical preparation runs 4 to 10 weeks: data access, process documentation, or an integration prerequisite. Sequence that work before the build, with owners and dates.
Below 38 — Foundation work first. Three to six months of groundwork on the constraining dimensions. Piloting from here produces a demo and no production system.
Three gating rules override the total.
Data average below 1.0 is a stop, at any total score. No approach compensates for evidence that does not exist or cannot be reached.
AI use case readiness below 1.5 is a stop. A technically excellent pilot on an unowned use case has no funding path.
Governance average below 1.0 is a stop in regulated contexts. A system that cannot be lawfully deployed is not a pilot candidate, whatever it can demonstrate.
Read the shape of the scores as well. An even profile in the low 2s across six dimensions beats a profile with three 3s and a 0. The zero determines the outcome.
How Lumitech Conducts AI Readiness Assessment
The Lumitech AI readiness assessment runs two to three weeks against a shortlist of candidate use cases, with a fixed scope and a fixed deliverable set.
Key Steps
Week 1 — Scope and discovery. Candidate use cases get defined and prioritized with the business owner. Stakeholder interviews cover the process, the systems, and the constraints. Existing documentation, architecture diagrams, and data dictionaries get reviewed first.
Week 1–2 — Technical and data review. Engineers query the actual tables to measure quality, coverage, and history. Integration surfaces get tested, and ground truth availability is confirmed against real records. This step converts assumptions into measured findings, and it is where most engagements change direction.
Week 2 — Governance and risk review. The use case is classified against applicable regulation, and required controls are mapped against what already exists.
Week 2–3 — Scoring and roadmap. Each use case gets scored across the six dimensions with evidence attached. Every gap gets an owner, an effort estimate, and a place in the sequence.
Week 3 — Readout. A working session with the sponsor and the technical owners covering findings, the scored map, and the sequenced plan. Disagreement with a score is a useful outcome, and the evidence behind every score is on the table.
Deliverables
Scored readiness map across six dimensions, per use case, with evidence
Ranked use case shortlist with value ranges, effort estimates, and constraining dependencies
Data gap register with named owners and remediation estimates
Integration and target architecture requirements
Governance gap list with required controls and regulatory classification
90-day roadmap with go / conditional / hold recommendation and budget range
Bring one candidate use case and the name of the system it would touch. 30 minutes is enough to size the assessment and to say whether it is worth running at all.
What Happens After the Assessment
Ready for Pilot
Scope one use case, one process, one integration. Set the success criteria and the baseline before the build starts, and agree what result triggers the production decision. Run the pilot in the environment the production system will use. A workflow proven in a sandbox proves less than it appears to.
Sequence the delivery. AI prototyping services validate the interaction and the output format in days. PoC development services prove accuracy and integration on real data. AI/ML development services build the production increment once the pilot clears its criteria.
Needs Preparation
The most common outcome, and a productive one. Preparation work is concrete: a repeatable data access route, a documented process, a labeled evaluation set, an added API, a cleared compliance question. Each item gets an owner and a date, and the pilot decision returns when the gating items close. Four to ten weeks of this work reliably outperforms a pilot that stalls at week six.
Not Suitable Yet
Sometimes the honest finding is that the use case does not justify AI, or that the company needs foundation work first. Both results are worth having. A use case with 200 annual instances and a manual cost of a few thousand euros belongs in a process improvement backlog, and a company with no measured process baselines needs measurement first.
Redirecting budget away from a pilot that would have failed is the highest-return outcome of the whole exercise, and the one that rarely makes it into a case study.
Let’s Conclude
A structured readiness review replaces conviction with evidence at the point where evidence is still cheap. The checklist above is enough to run a credible internal review and to see where your gaps concentrate.
For a scored, evidence-backed review across your candidate use cases — with a data gap register, architecture requirements, and a 90-day roadmap — see Lumitech’s AI readiness audit services.
