Interactive assessment
AI readiness assessment: measure whether the operating foundation is ready
Assess trusted context, workflow clarity, integrations, measurement, and governance.
Introduction
What this assessment is for, and what it is not.
AI initiatives rarely fail because the model was insufficient. They fail because the workflow they were pointed at had no agreed definition of done, or the data they read was authoritative in three places at once, or nobody could tell afterwards whether anything had improved.
This assessment scores the five operating dimensions that determine whether an AI effort has something solid to stand on: trusted context, workflow clarity, systems connected, outcome measurement, and governance. None of them are about models, which is the point.
Read the lowest score as the constraint. A team with excellent data and no workflow definition will produce impressive demonstrations that never enter production. A team with a clear workflow and unconnected systems will spend its effort on manual integration. Knowing which one you are is worth more than a model comparison.
The problem
The problem this is trying to surface.
The readiness question gets answered at the wrong layer. Teams evaluate models, vendors, and features — all of which are comparatively easy to assess — while the factors that actually determine outcomes sit underneath: whether the records can be trusted, whether the workflow is defined, whether the systems are reachable, and whether anyone would be able to tell if it worked.
The second problem is that demonstrations are not evidence. A pilot on curated data, run by the people who built it, proves the technology functions. It says almost nothing about whether the same thing survives contact with real records, real permissions, and the exception cases that make up most of the volume.
The third problem is that unclear governance stops projects late rather than early. Work proceeds, a demonstration succeeds, and then somebody asks who approves the customer-facing action and what happens when it is wrong. Answering that at the end is expensive; answering it at the start is a conversation.
You're likely here because
- You have been asked whether the business is ready for AI and are not sure how to answer
- A previous pilot worked in a demo and never reached production
- Different teams believe different systems are authoritative
- Nobody can say how you would prove an AI initiative had worked
How the inputs work
What each input does to the result.
Every input is something you supply, so the result is only as good as the honesty of the answers. Knowing how each one is weighted is what makes the output arguable rather than opaque.
Step 01
Score trusted data and record coverage
Rate how consistently the team can find current, authoritative records for AI adoption. Everything else depends on this: automation reading uncertain data produces confident wrong answers faster.
Step 02
Score workflow clarity
Rate how explicitly the triggers, owners, next actions, and completion states of AI adoption are defined. Ambiguity here is the most common reason automation stalls after the demo.
Step 03
Score systems connected
Rate how much of the workflow can move without copy/paste or manual reconciliation. Every unconnected step is a place where a person is currently acting as the integration.
Step 04
Score outcome measurement
Rate how well activity in AI adoption can be tied to cycle time, conversion, quality, or revenue. Without this you cannot tell afterwards whether a change helped.
Step 05
Score governance and exception handling
Rate how explicit permissions, approvals, escalation paths, and human review are. This determines how much of the workflow can safely run without a person in the loop.
Step 06
Read the lowest score, not the average
The average is a summary; the lowest dimension is the constraint. That is where the next piece of work belongs, regardless of how much more appealing the other four look.
Implementation path
What to do with the result.
- 01
Score each dimension from observed evidence rather than intent. Optimistic input produces a score that agrees with you and helps nobody.
- 02
Take the lowest dimension. That is the constraint on AI adoption, and work anywhere else will be absorbed by it.
- 03
Define one measurable target outcome for AI adoption — a cycle time, a conversion step, or an exception rate — and record its current baseline.
- 04
Fix the workflow and control gap at the constraint before expanding automation. Automating around an unresolved constraint relocates the problem rather than removing it.
- 05
Connect the systems that step depends on, and verify what the workspace actually reads before building anything on top of it.
- 06
Re-score after one full cycle. If the same dimension is still lowest, the work did not land and the next attempt should be different rather than larger.
Controls
Controls that matter.
Control 01
Scores taken from observed evidence, not from how the team would prefer to be described
Control 02
One named owner per dimension, so a low score has somebody accountable for moving it
Control 03
Human review kept in front of any customer-facing or consequential step in AI adoption, regardless of the score
Control 04
A baseline recorded before changes, so the re-score is a comparison rather than an opinion
Examples
How teams read this in practice.
Patterns that recur when this is scored honestly, and what each one is actually telling you.
The pilot that never shipped
A demonstration worked on curated data and stalled on real records with real permissions. A low score on trusted context predicted this before the pilot was commissioned.
Three authoritative systems
Two teams point at different systems as the source of truth for the same concept. That is a data-coverage finding, and no model resolves it — it is a decision somebody has to make and own.
No way to prove it worked
An initiative ships and the debate about whether it helped runs for two quarters. Measurement scored lowest, and the missing step was recording a baseline before anything changed.
Governance question arrives last
A working system stalls at the question of who approves a customer-facing action. Scoring governance early makes that a design input rather than a late blocker.
Limitations and considerations
What this tool cannot tell you.
- This is a directional self-assessment, not a measurement. Most of its value is in the conversation the scoring produces rather than in the number it returns.
- Results are only as honest as the inputs. Teams routinely rate workflow clarity higher than their own exception volume supports.
- The five dimensions are weighted equally, which is a simplification. In some businesses governance or data coverage dominates everything else.
- A high score does not mean automation will succeed. It means the operating foundation is less likely to be the reason it fails.
- The result reflects one workflow. Scoring AI adoption across a whole company produces an average that hides the specific constraint worth acting on.
- Nothing here substitutes for the security, privacy, and approval requirements that apply to your business.
FAQ
Questions about this tool.
How should we score this honestly?
From evidence rather than intent. Look at exception volume, how often records turn out to be stale, and how much of the workflow currently requires a person to move data between systems. Teams that score from how the process is meant to work get a number that agrees with them and helps nobody.
What does the score actually mean?
It is a directional read on whether the operating foundation is likely to be the reason an automation effort fails. It is not a prediction of success and should not be presented as one.
Why does the lowest dimension matter more than the average?
Because the lowest dimension is the constraint. Work invested in the other four gets absorbed by it, which is why teams with strong tooling and unclear workflow definitions keep buying software that does not help.
Does a low score mean we should not start?
No. It tells you where to start. A low data score means begin with one workflow where the records are trustworthy. A low workflow score means define the process before automating it. The score directs the first step rather than blocking it.
Why is there nothing here about models?
Because model choice is rarely the reason initiatives fail. Unclear workflows, untrusted records, unreachable systems, and absent measurement are. Those are the things worth assessing before anything is selected.
How often should we re-score?
After each completed workflow, not on a calendar. The useful question is whether the constraint moved, and that only has an answer once a full cycle has run.
Start with ARIA
Ask ARIA to act on the result.
A score is a starting point. Describe the outcome you want and ARIA works out the capabilities, systems, and data needed to get there.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Start where the constraint is, not where the demo is.
Describe the workflow on the public ARIA path, or model what fixing it would be worth before committing budget.