AI Transformation foundations · 1,306 words · 6 min read · Updated
AI Readiness Workflow Scorecard
A workflow-level readiness scorecard for deciding whether to discover, prototype, pilot, or prepare an AI system for production.
Readiness is not a company-wide personality test
Organizations are often labeled AI-ready or not ready based on broad signals such as executive enthusiasm, cloud maturity, data platforms, or the number of licenses already purchased. Those signals can matter, but they are too distant from the work to decide whether a particular workflow should move forward.
A useful readiness review stays close to one workflow. It asks whether the team understands the job, can access appropriate inputs, can judge output, can contain mistakes, and has the capacity to operate what it builds. This produces a decision the team can act on: discover, prepare, prototype, pilot, or launch.
Score evidence, not confidence
A high score needs an artifact or an observed fact. A named owner is stronger than stakeholder support. A representative evaluation set is stronger than good demo output. A written review policy is stronger than saying a human will remain involved.
Use the weakest critical dimension
Averages can hide blockers. Strong data and technical skill do not compensate for an output no one can review. Executive sponsorship does not compensate for an unavailable source system. Treat ownership, data permission, reviewability, and consequence containment as critical dimensions that can cap the decision.
The seven-dimension readiness rubric
Rate each dimension as weak, workable, or strong, then attach the evidence behind the rating.
Workflow clarity
- Weak
- The initiative is described as a broad capability or department goal.
- Workable
- The team can outline the current process, users, and output but important exceptions remain unclear.
- Strong
- Trigger, inputs, decisions, handoffs, exceptions, output, baseline, and owner are documented.
Ownership and authority
- Weak
- An innovation or technical team is searching for a business sponsor.
- Workable
- A business owner supports the work but operating responsibilities are not assigned.
- Strong
- Business, technical, review, and change-control responsibilities are named with decision authority.
Input access and permission
- Weak
- Sources are unknown, inaccessible, or inappropriate for the proposed model route.
- Workable
- Core inputs are available with cleanup, permission, or retention questions still open.
- Strong
- Approved sources, fields, ownership, quality limits, and evaluation-use permissions are documented.
Output evaluation
- Weak
- Quality is based on stakeholder reaction to a small demo.
- Workable
- Examples and reviewer guidance exist but failure categories or acceptance thresholds need work.
- Strong
- Representative examples, expected outcomes, failure labels, acceptance rules, and reviewer calibration are ready.
Risk and review
- Weak
- The model may act externally or affect material decisions without a clear intervention point.
- Workable
- Human review exists but routing, authority, or escalation remains informal.
- Strong
- Allowed actions, mandatory review, override, escalation, refusal, and rollback are built into the boundary.
Technical path
- Weak
- The workflow depends on undefined integrations, identity, logging, or infrastructure.
- Workable
- A prototype path is clear, but production observability, support, or security work remains.
- Strong
- The smallest integration boundary, environments, access, logs, support, and release path are understood.
Adoption and operations
- Weak
- Users have not been involved and no one owns the workflow after delivery.
- Workable
- Users see value, but training, feedback, support, and operating cadence are incomplete.
- Strong
- The workflow fits real work, users have a correction path, and owners can monitor quality, cost, adoption, and exceptions.
How to run the scorecard
A readiness review should create a decision record, not a slide with one composite number.
- 01
Choose the workflow boundary
State the trigger, user group, task class, model action, output, and downstream action. Score only that boundary. - 02
Invite the people who hold evidence
Include the workflow owner, frontline reviewer, source-system owner, technical lead, and the person accountable for risk or policy where relevant. - 03
Rate independently
Ask participants to score dimensions before discussion. Differences reveal hidden assumptions and ownership gaps. - 04
Attach artifacts
Link workflow maps, source samples, review guidance, evaluation examples, architecture notes, and operating plans to the score. - 05
Resolve critical blockers
Do not average away weak ownership, unavailable data, unreviewable output, or uncontrolled material action. - 06
Choose the next stage
Record whether the workflow should enter discovery, preparation, prototype, controlled pilot, or production planning, with conditions for the next review.
Readiness decision bands
The band is a routing tool. It does not certify the organization or guarantee a project outcome.
- Decision
- Discover
- Evidence pattern
- Workflow, owner, or outcome is still broad or contested.
- Next move
- Map the current process, name the decision owner, and narrow the model action.
- Decision
- Prepare
- Evidence pattern
- The workflow is valuable, but source access, examples, review, or integration needs bounded work.
- Next move
- Complete the missing artifacts before model comparison.
- Decision
- Prototype
- Evidence pattern
- Inputs and desired output are clear enough to test capability, but operating controls remain incomplete.
- Next move
- Test representative examples without promising production scope.
- Decision
- Pilot
- Evidence pattern
- Evaluation, review, and a limited technical path exist for a controlled user and task boundary.
- Next move
- Run with explicit measures, support, and stop conditions.
- Decision
- Production planning
- Evidence pattern
- Critical dimensions are strong and operating ownership can accept the workflow.
- Next move
- Complete release, observability, support, rollback, and change-control evidence.
Evidence packet for a readiness review
The packet can be short. Its purpose is to replace assumptions with inspectable material.
- ✓
Current workflow map
Shows trigger, actors, systems, decisions, wait states, exceptions, and output. - ✓
Representative source set
Includes normal, difficult, incomplete, and sensitive examples with use permission understood. - ✓
Expected-output guide
Explains what a good result contains, what is unacceptable, and who can judge it. - ✓
Risk boundary
Names allowed model actions, prohibited actions, mandatory review, and escalation. - ✓
Technical boundary note
Names integrations, environments, access, logging, and rollback assumptions for the next stage. - ✓
Operating owner note
Assigns workflow health, user support, corrections, model changes, and review cadence.
How to interpret disagreement
A readiness score is most valuable when participants disagree. A technical lead may rate data access as strong because an API exists, while the source owner knows that the required fields are incomplete or restricted. A business owner may rate reviewability as strong because experts can recognize good output, while reviewers have never written down how they resolve ambiguous cases.
Do not force consensus too quickly. Record the evidence each person used, identify the decision owner, and convert the disagreement into a preparation task. The score should improve because the workflow became clearer, not because the room negotiated a more comfortable number.
Re-score when the boundary changes
A workflow can move from ready to unready when the release expands to new users, new data, external action, or a different model role. Readiness belongs to the approved boundary. Re-score material changes rather than treating the original review as permanent permission.
Readiness language for decision records
Use stage language that states what is true now. Avoid labels that imply a certification or a broad organizational verdict.
Ready to prototype
- The team has enough workflow and example clarity to test model capability, but has not completed production controls.
Ready to pilot
- A limited user, task, data, review, and measurement boundary can run with explicit stop conditions.
Ready for production planning
- The workflow has strong critical evidence and named owners can complete release, support, observability, and change control.
Questions this article answers
Should the scorecard produce one total score?
A total can help sort candidates, but it should never hide a weak critical dimension. Ownership, approved inputs, reviewability, and consequence containment can block progression even when the average looks strong.
Who should own the readiness decision?
The accountable workflow owner should accept the decision with technical, data, security, and policy partners supplying evidence. A delivery team should not approve production readiness for a business workflow it will not operate.
How often should readiness be reviewed?
Review at stage changes and whenever the boundary materially expands. New users, data, actions, integrations, or model behavior can change readiness even if the workflow name stays the same.
Can a workflow proceed with a weak dimension?
Yes when the weakness is explicitly bounded and the next stage is designed to resolve it safely. No when the weakness removes ownership, makes output unreviewable, uses inappropriate data, or permits uncontrolled material action.