How to use this AI readiness scorecard
Name one workflow precisely: the eligible trigger, the work performed, and the destination outcome. “Use AI in finance” is not scoreable. “Receive eligible supplier invoices, validate required fields, route approval, and confirm the accepted accounting record” is. Use the same bounded statement for all ten rows.
- Gather evidence. Bring the current workflow map, volumes, examples, systems, policies, roles, exceptions, performance baseline, costs, and correction history.
- Choose one score per row. Award the highest level whose entire description is supported today. Do not average across departments or give partial credit for a planned control.
- Record the proof. Beside each score, link the source, owner, test, API read, policy, dashboard, queue, or financial record that supports it.
- Apply stop conditions. A high total cannot cancel a missing owner, undefined authority, unverified write path, or absent exception lane.
- Turn gaps into prerequisites. Fix the lowest-scoring material rows before expanding scope or buying implementation capacity.
0–30 points
The workflow-level AI readiness assessment
Print this page or copy the table. Add one score and one evidence reference for each row.
| Area | 0 — absent | 1 — assumed | 2 — defined | 3 — verified |
|---|---|---|---|---|
| 1. Outcome | No accepted outcome | A broad goal | A measurable outcome | Baseline, target, owner, and observation window |
| 2. Workflow owner | No owner | Interested sponsor | Named process owner | Owner has authority over policy, exceptions, and release |
| 3. Eligibility | Undefined inputs | Examples only | Eligible trigger and exclusions | Normal, adverse, and stop conditions are written |
| 4. Source quality | Unknown sources | Sources identified | Owned current sources | Freshness, permissions, corrections, and provenance are managed |
| 5. Record identity | Names or free text | Partial matching | Stable identifiers exist | Precedence, duplicate, merge, and conflict rules are tested |
| 6. Authority | Model may act broadly | Informal approvals | Permitted actions are listed | Roles, consequence tiers, minimum permissions, and read-back are enforced |
| 7. Integration | Destination unknown | Vendor name known | Current access verified | Tenant, API, identity, fields, limits, errors, and recovery are tested |
| 8. Evaluation | Demo examples | Happy-path tests | Representative evaluation set | Adverse, privacy, security, accessibility, failure, and recovery cases pass |
| 9. Operations | No exception lane | Manual monitoring | Named human handoff | Queues, alerts, service expectations, reconciliation, and rollback are rehearsed |
| 10. Economics | No baseline | Time-saving guess | Costs and value driver known | Provider, review, correction, support, and outcome economics are measured |
Interpret the total without hiding a fatal gap
- 0–9: define the work first. Clarify the outcome, owner, current process, sources, and baseline. Do not start a production AI build.
- 10–17: prepare the foundation. Resolve identity, source quality, policy, access, or measurement gaps. A manual or deterministic process improvement may be the better first investment.
- 18–24: conditionally ready. Write prerequisites for the lowest rows, verify integrations, build evaluations, and keep the first release in draft, assist, approval-required, or limited-volume mode.
- 25–30: ready for a bounded pilot. Convert the evidence into acceptance tests, operating controls, a fixed scope, and an observation window. The score does not authorize a broad autonomous release.
Mandatory stop conditions
Do not release autonomous production action when there is no accountable owner; no stable way to identify the subject record; no explicit action authority; no verified customer-tenant integration; no accessible human exception path; or no way to confirm and reconcile the destination outcome. Sensitive or consequential work may require approval even with a high score.
What a readiness review should produce
The useful output is not a colorful maturity label. It is a decision record: workflow statement, baseline, evidence register, constraints, risk owners, test cases, allowed and denied actions, integration proof, exception operation, pilot population, acceptance threshold, rollback trigger, and economics. That packet lets a buyer compare an ordinary rules workflow, a model-assisted workflow, and a manual improvement on the same terms.
Cognautic’s AI consulting service can turn the scorecard into a scoped recommendation, while the AI implementation service executes an approved use case through production acceptance and operating ownership. The AI implementation roadmap assigns evidence, acceptance rules, owners, and stop conditions across six phases. The AI project failure statistics dataset shows why forecasts, abandonment, production, broad adoption, and impact need separate thresholds. The AI pilot program guide turns a strong score into a bounded cohort, observation window, acceptance threshold, expansion rule, and stop decision. The AI agent evaluation guide defines tasks, graders, repeated trials, and release gates. The business process automation page explains end-to-end ownership, while the data entry, accounts payable, and CRM automation pages show how the contract changes by workflow.
Sources and operating context
The NIST AI Risk Management Framework organizes work around governance, context mapping, measurement, and management. Its Generative AI Profile adds risks and actions specific to generative systems. The NIST Secure Software Development Framework informs the application lifecycle, and the NIST Privacy Framework supports privacy-risk decisions. These sources inform the questions; they do not certify a Cognautic project or turn this score into compliance advice.
Assessment questions
How to apply the score responsibly
What is an AI readiness assessment?
An AI readiness assessment tests whether a specific business workflow has a measurable outcome, accountable owner, usable sources, explicit authority, verified integrations, representative evaluations, operating support, and credible economics. It should produce evidence, risks, and next actions—not a generic maturity label.
What score means a workflow is ready?
A score of 25–30 supports a bounded pilot after the evidence is verified. A score of 18–24 means fix the lowest control areas first. A score of 10–17 needs workflow and data preparation. Below 10 means the problem is not yet defined well enough for an AI build.
Should a company assess its whole AI maturity?
Enterprise maturity can be useful for portfolio governance, but build decisions should be made at workflow level. A company may be ready for one bounded knowledge or intake workflow while being unready for autonomous financial or customer decisions. Score each materially different workflow separately.
Does a high score guarantee an AI project will work?
No. The score is a preflight, not proof of performance. Provider behavior, source drift, user adoption, model changes, integration failures, edge cases, and economics still require evaluation in a bounded release. Production expansion should follow observed acceptance and failure evidence.
What should happen after the assessment?
Preserve the evidence behind every score. For a strong workflow, write acceptance cases and a pilot scope. For a medium workflow, resolve the lowest-scoring dependencies. For a weak workflow, improve ownership, process definition, data, or measurement before selecting software or models.
Use the evidence
Turn the weakest score into a prerequisite—not a hidden project risk.
Bring one completed scorecard and its evidence. Cognautic will challenge the assumptions, identify the smallest viable workflow, and provide a written scope and measurement plan.
Request the free consult