AI Readiness Assessment: A 12-Point Enterprise Checklist 

Is your AI initiative actually ready to move from pilot to production? 

A funded AI pilot can still stall before production. The model may perform well in a controlled test, yet the team cannot reach production data, connect the system to the workflow, name an operational owner, or define what happens when an output is wrong. 

An AI readiness assessment tests whether one proposed workload has the business case, data, controls, technical foundation, ownership, and adoption conditions required to move to the next investment gate. It should end with a decision, not a generic maturity score: proceed, remediate, re-scope, or stop. 

This 12-point enterprise checklist can be used before a pilot is funded or before a promising pilot receives production investment. It connects directly to the enterprise AI lifecycle and the enterprise AI roadmap. 

DIRECT ANSWER: A use case is ready to advance when the required evidence is good enough for the next gate, critical blockers are absent, and every material gap has an owner and a treatment. Readiness is workload-specific. It is not a declaration that the whole organization is ready for every form of AI. 

AI readiness assessment at a glance 

Use the table as the first-pass scorecard: 

#	Readiness question	Evidence to review	What good looks like
1	Is the business problem specific?	Current workflow, users, decision point, pain measure	One operating problem with a measurable consequence
2	Is there a measurable baseline?	Cycle time, error, cost, volume, rework, or service level	A documented starting point that can be compared after the pilot
3	Is there an accountable business owner?	Named process owner and technical owner	Authority over the workflow, outcome, and next-stage decision
4	Are users and decision points known?	User groups, affected parties, action map	The system role is clear: draft, recommend, rank, approve, or act.
5	Can the team access the required data?	Source inventory, rights, owners, access path, jurisdictions	Production access is lawful, practical, and approved.
6	Is the data fit for the task?	Samples, quality tests, freshness, representation, known errors	Quality is measured against the actual workload.
7	Can lineage and permissions survive production?	Access controls, source traceability, revocation, and index tests	Users can reach only authorized sources, and changes propagate
8	Is the impact level understood?	Worst credible outcomes, scale, reversibility, contestability	Control depth matches impact and autonomy.
9	Are approval, escalation, and stop rights assigned?	Decision-rights map and release evidence requirements	Named people can approve, constrain, pause, and restart.
10	Can the system integrate and perform under real conditions?	Interfaces, identity, latency, availability, volumes, fallback	The production design works under representative load and failure
11	Is there an owner for production operations?	Support model, runbooks, monitoring, and vendor ownership	Every production layer has a named operator and escalation path.
12	Will the workflow, people, and measures change together?	Training, process design, incentives, feedback, acceptance thresholds	Adoption is measured against operating outcomes, not logins.

What an AI readiness assessment should decide 

There are two levels of readiness. Organizational readiness evaluates whether the enterprise possesses reusable capabilities, including procurement, identity, data governance, security review, and production support. Use-case readiness asks if the proposed system can produce a delineated result within its real constraints. 

Do not lump those levels into one reassuring maturity score. A mature enterprise can propose a poorly framed use case. Sometimes a less mature organization can do well with a narrow, well-controlled workload. Score the use case first, then identify which gaps are local and which need broader investment. 

The NIST AI Risk Management Framework is useful because it connects governance, context, measurement, and risk treatment. It should be mapped to the laws, standards, and internal policies that apply to the organization and workload. 

The assessment should end with one of four decisions: 

1. Proceed: Evidence supports funding the next gate, with known conditions and owners. 

2. Remediate: The use case remains worthwhile, but named blockers must be resolved before it advances. 

3. Re-scope: A narrower user group, smaller data set, reduced authority, or simpler workflow can make the workload viable. 

4. Stop: Expected value does not justify cost, exposure, or operating burden. 

The 12-point AI readiness assessment 

1. Is the business problem specific? 

Direct answer: A use case is ready for assessment when the team can name the workflow, user, decision or task, current pain, and the consequence of leaving it unchanged. 

Start with the operating problem, not the technology. “Improve productivity” is too broad. “Reduce the time claims analysts spend locating approved policy passages during a live case review” is testable because the user, task, and expected change are visible. 

Ask for a process map or a brief description of the current workflow. If nobody can point to where the AI output will enter that workflow, the proposal remains an idea rather than a fundable business case. 

2. Is there a measurable baseline? 

Direct answer: The team needs a credible starting measure before it can claim that AI changed the outcome. 

Record the current cycle time, error rate, volume, cost, rework, service level, or another measure tied to the problem. Document how the baseline was calculated and the period it covers. The baseline can be imperfect. It still needs to be sufficiently robust enough to compare against pilot results. 

3. Is there an accountable business owner? 

Direct answer: Sponsorship is not ownership. The workload needs a business owner with authority over the process and a technical owner accountable for the system. 

A senior executive may fund the initiative, but a process owner still needs to decide how the workflow changes, which outcome counts as success, and which residual risk is acceptable. The technical owner remains responsible for architecture, release evidence, and operational changes after launch. 

4. Are the users and decision points known? 

Direct answer: Readiness depends on knowing who interacts with the system, who relies on its output, who may be affected, and what authority the AI has at the decision point. 

A system that drafts an answer for review has a different control need from an agent that sends the answer or changes a customer record. State whether the system drafts, recommends, ranks, approves, or acts. That choice drives interface design, human review, logging, and release evidence. 

Data access, quality, and rights 

Data problems often appear late because teams test with convenient samples rather than the sources required in production. The next three checks turn “we have the data” into evidence. 

5. Can the team lawfully and practically access the required data? 

Direct answer: Data is ready only when the team has a lawful permitted use and a production access path that works at the required speed and scale. 

List each source system, owner, access method, jurisdiction, sensitivity class, and permitted use. Include prompts, conversation logs, embeddings, evaluation sets, and user feedback because they can contain sensitive or derived information. 

A repository that requires manual exports or months of integration work is not “available” in the sense that matters to delivery. Treat that work as a dependency with an owner and a date. 

6. Is the data fit for the task? 

Direct answer: Data quality should be tested against the workload rather than against a generic quality score. 

Review completeness, timeliness, consistency, representation, and known error patterns. For structured data, inspect schemas, missing fields, identifiers, and history. For documents, sample formats, duplicates, access restrictions, version conflicts, and scan quality. For event data, check timestamps, ordering, loss, and upstream definition changes. 

7. Can data lineage and permissions survive production? 

Direct answer: A production AI system must preserve source permissions, traceability, and revocation after data enters retrieval, indexing, caching, or other derived stores. 

Retrieval-augmented generation needs source-level access controls, current indexes, and traceable citations. A user should not receive a passage simply because the model can retrieve it. Test what happens after a document is revoked, corrected, or deleted, and measure how long the change takes to reach the index. 

Risk, governance, and human accountability 

8. Is the impact level understood? 

Direct answer: Control depth should increase with the severity, scale, autonomy, and irreversibility of a credible failure. 

Record the worst credible outcomes for customers, employees, operations, finances, safety, rights, and reputation. Consider whether an affected person can detect and challenge an error. Hard-to-reverse outcomes and higher autonomy call for stronger evaluation and approval. 

Canadian federal departments can use the Algorithmic Impact Assessment for systems within the scope of the Directive on Automated Decision-Making. Other organizations should map the requirements that apply to their sector and jurisdictions. 

9. Are approval, escalation, and stop rights assigned? 

Direct answer: A control is weak if nobody has both the authority and the evidence required to use it. 

Name the person or forum that can approve the next stage, impose conditions, pause the system, and authorize restart. Define where human review is mandatory and what the reviewer sees. Test the intervention rather than checking whether an approval button exists. 

Integration, infrastructure, and operating ownership 

10. Can the system integrate and perform under real conditions? 

Direct answer: A workload is technically ready when the production design can connect to required systems, preserve identity and permissions, meet service needs, and fail safely. 

Identify upstream and downstream interfaces, identity flows, network boundaries, latency targets, availability needs, and transaction volumes. Verify which actions are read-only and which can change records, send communications, or call tools. 

Estimate compute and storage from a stated workload, then test the estimate. Include peak demand, concurrency, context length, retrieval calls, and fallback behaviour. Infrastructure should follow the workload requirement rather than define it in advance. 

11. Is there an owner for production operations? 

Direct answer: Every production layer needs a named operator, a support expectation, and an escalation path before release. 

Assign ownership for prompts, models, retrieval indexes, data pipelines, integrations, evaluation sets, access policies, incidents, and vendor changes. If internal teams cannot provide the required coverage, compare staffing, platform, and managed AI services before launch. Delegating technical operations does not transfer business accountability or risk acceptance. 

Adoption, change, and measurement 

12. Will the workflow, people, and measures change together? 

Direct answer: Adoption is ready when the new workflow, training, management reinforcement, feedback path, and outcome measures have been designed together. 

Confirm how users will be trained, how managers will reinforce the process, and how feedback reaches the product team. Identify incentives that could cause overuse, avoidance, or superficial compliance. Set acceptance thresholds before the pilot and measure task quality, operating outcomes, and adoption together. 

Representative assessment example 

Consider a proposed internal claims assistant that retrieves approved policy passages for human analysts. The model produces acceptable answers in a sandbox, but production data permissions and index revocation have not been tested. The scoring should not average those weaknesses away. 

Assessment point	Rating	Evidence	Decision impact
Business problem	Green	Workflow and baseline are documented.	No blocker
Data access	Green	Approved source systems and owners are identified.	No blocker
Lineage and permissions	Red	Document-level authorization and revocation are untested.	Block pilot expansion until tested.
Production operations	Amber	Owner named, runbook incomplete	Condition with owner and target date
Adoption	Green	Analyst review process and feedback loop defined	No blocker

The correct outcome is “remediate,” not “8 out of 10, ready.” The red permission control blocks progression because it can expose restricted information. The amber operating gap can move with a named condition if the next gate does not depend on production support. 

Turn the result into a sequenced roadmap 

Do not finish with a coloured scorecard. Convert findings into three work queues: 

• Blockers: Missing rights, critical controls, undefined ownership or other issues that prevent the next gate. 

• Near-term remediation: Work that belongs inside the current initiative, such as a data sample, evaluation set, permission test or integration proof. 

• Scale foundations: Reusable capabilities such as identity patterns, observability, model inventory and vendor review. 

Each action needs an owner, evidence requirement, dependency and next decision gate. These outputs feed the enterprise AI roadmap. Readiness is an input to planning. It does not replace the pre-production AI risk assessment, which tests the deployed control evidence before release. 

Cylix in practice 

Cylix places assessment at the start of its enterprise AI lifecycle. Its Data Engineering approach begins with business and AI readiness before architecture and pipeline work, so data investment is tied to business outcomes and future AI workloads rather than treated as an isolated technical project. 

Fund evidence, not enthusiasm. 

An AI readiness assessment should make the next decision easier. It should show what outcome matters, what evidence exists, where the blockers sit and who owns the work. Low scores do not automatically end an initiative. They change its sequence, scope or funding conditions. 

Apply the 12 points to one real workload before approving a broad program. A use-case decision tied to evidence is more useful than a generic maturity label because it connects strategy to the data, systems, people and controls that production requires. 

NEXT STEP: Book a consultation to assess one workload against its current business case, data, controls, architecture and operating constraints.