AI Readiness Assessment: The Pre-Flight Check Before You Deploy an Agent
More than 60% of AI implementations never reach meaningful ROI — usually because the enterprise was never ready to feed the agent what it needed. Run the check before you sign.
An AI readiness assessment is a structured check of whether your organization can actually support an AI deployment before you commit to it. It looks at the data the system will need, the context and systems it has to connect to, the access it requires, and the risk it introduces. The output is a plain answer to one question: are we ready to make this specific thing work?
Most published readiness assessments are broad. They score the whole company on strategy, culture, data, and talent, and hand back a maturity level. That has its place. But on episode 99, Ged Ossman, founder and CEO of Interf, made the case for a sharper version: a readiness check tied to one specific agent you are about to deploy. Not “is the company AI-ready” in the abstract, but “can this agent actually succeed here,” answered before the contract is signed.
Readiness vs. maturity: what actually predicts ROI
The two terms get used interchangeably, and the difference matters.
| AI maturity assessment | AI readiness assessment | |
|---|---|---|
| Question | How advanced is our overall AI capability? | Can this specific agent succeed here? |
| Scope | Company-wide | One deployment |
| Output | A maturity level or score | A go / not-yet decision with gaps to close |
| Timing | Periodic strategy exercise | Before you deploy capital on a project |
| Best for | Long-term planning | Preventing a failed rollout |
A company can score low on maturity and still be perfectly ready for one narrow, well-scoped agent. It can also score high on maturity and still fail a specific deployment because the exact data that agent needs was never connected. Maturity tells you where you are heading. Readiness tells you whether the next step will hold your weight.
Most AI deployments fail readiness, not technology
Ossman’s blunt claim on the show: more than 60% of AI implementations get no meaningful ROI. And in his experience, the cause is usually not the vendor’s model. It is that the enterprise was never ready to feed the agent what it needed.
He described the pattern from both sides. Enterprises blame vendors for over-promising. Vendors, through their forward-deployed engineers, tell a different story: they show up to implement, and the data is not there, the context is scattered, and nobody knows where the required inputs live. The agent cannot do its job because the inputs it assumed never existed in usable form.
This is a readiness failure wearing a technology costume — the same root cause behind the pattern in why 95% of AI projects fail. The problem is rarely the model; it is everything around the model. When the ROI does not show up, both sides point at each other, and the real answer — “we were not ready” — rarely gets said out loud.
The pre-flight check
Ossman borrows a term from aviation: a pre-flight check. Before you deploy capital, you run a proactive assessment of what it will actually take for the initiative to succeed. The parts that trip people up are rarely the obvious ones.
- Data quality and availability. Not “do we have data,” but is the specific data this agent needs present, accessible, and clean enough to use. This is often where things fail before security is even a concern.
- Context dependencies. An agent that does scenario modeling might need ten different context entities connected before it works at all. These dependencies are usually hidden, and enterprises discover them only when the vendor’s engineers start asking.
- Hidden vendor requirements. The prerequisites that never make it into the security questionnaire. Ossman’s push is to make these visible and machine-readable up front, in the same spirit as an AI data bill of materials.
- Risk and access. What the agent will touch, and whether exposing it is acceptable. This is where readiness meets governance at onboarding.
The theme: the expensive gaps are dependency gaps, and they are invisible until someone goes looking. A readiness assessment is that looking, done on purpose and early.
How to run one before you deploy
You can apply this without a consulting engagement. The goal is to surface the gaps while they are still cheap to fix — before the contract, not during onboarding.
- Define the specific job. Name the exact agent and the exact outcome it is supposed to produce. Readiness is always readiness for something.
- List the inputs it needs. Every data source, system, and context entity the agent depends on. Ask the vendor to declare these in advance rather than discover them live.
- Check each input against reality. Is it present, connected, clean, and accessible? Mark each as ready, fixable, or blocker.
- Score the risk. What does the agent touch, and are you willing to expose it? Loop in security and compliance now, not after go-live. Unmanaged experimentation is its own exposure — see shadow AI.
- Decide: go, fix-first, or not yet. A readiness assessment that cannot return “not yet” is not an assessment. It is a rubber stamp.
A practical checklist
The short version to take into your next vendor conversation. If you cannot answer yes to these, you are not ready yet:
- We can name the specific outcome this agent is supposed to deliver.
- The vendor has declared every data source and dependency the agent needs.
- Each required input exists, is accessible, and is clean enough to use.
- The context entities the agent relies on are actually connected, not theoretical.
- Security and compliance have reviewed what the agent will access.
- We have an honest “not yet” option, and leadership will accept it.
Saying no to AI is rarely the smart move; saying yes without readiness is worse. The middle path — running the check first — is how you get to yes without losing control.