AI Readiness: Gather Evidence Before Committing to a Build

Reviewed and updated October 8, 2026.

Assess readiness for a specific AI task, not for AI in general. A useful assessment produces evidence and an action list. It should make missing prerequisites visible rather than compress every issue into an unexplained maturity score.

Begin with the completed outcome, the person accountable for it and the decision the system may assist. Compare the proposed system with the current process and simpler alternatives. If the outcome is unclear, scope is the first readiness problem to solve.

Five evidence areas

Workflow evidence includes normal cases, exceptions and a baseline. Data evidence includes availability, quality, permitted use, retention and access. Evaluation evidence includes representative cases, review criteria and the consequences of different errors. Integration evidence includes system access, supported operations and recovery. Operating evidence includes owners, support capacity, training and a manual fallback.

NIST's AI Risk Management Framework is a voluntary framework for risk management. It can inform the review, but completing this worksheet is not certification or evidence of legal compliance.

Illustrative readiness review

A hypothetical service team wants a source-grounded internal assistant. It has a named task owner and a reviewed case set. However, policy files conflict, and access differs across roles. The readiness decision is to establish authoritative sources and permission rules before building broad retrieval.

The team can still test a limited set of approved documents while those blockers are addressed. It records the limitation so the test is not later described as evidence that the full information estate is ready. This is an illustrative readiness decision, not a measured deployment result.

Fill in the assessment

For each area, record the evidence, owner, unresolved question and next action. Use statuses such as “evidenced,” “needs verification” and “blocked.” A claimed capability without an artifact remains unverified.

• Task: what outcome and authority boundary are defined?
• Data: which records can be used, by whom and for what purpose?
• Baseline: what quality, time and cost does the current process produce?
• Evaluation: which difficult cases and failures must be included?
• Systems: which reads and writes are supported and approved?
• Operation: who owns incidents, revisions and fallback?

A blocker can outweigh a strong score elsewhere. Excellent model performance does not compensate for unauthorized data access. Good documentation does not compensate for an unusable fallback.

Turn findings into a scoped next step

Separate actions required before any test from actions needed before production. Assign each action to someone with authority and specify the evidence that will close it. Review readiness again when scope, data or permissions change.

The assessment should end with a decision: proceed with a bounded test, repair identified prerequisites or choose a simpler approach. Avoid promising readiness through a branded methodology whose results cannot be inspected.

Use the AI readiness assessment to record prerequisites and missing information. Its guidance is a planning aid, not approval to deploy.

Bring the decision into a project review

Bring the proposed task and any missing data, access or ownership requirements. The review can separate a testable scope from prerequisites that need repair. Explore ALLTIPLY AI roadmap and enablement, or request a project review with the workflow, systems and constraints you need to assess.