AI Readiness Assessment: The Pre-Flight Check Before You Deploy an AI Agent

What Is an AI Readiness Assessment?

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 the podcast, 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

These two terms get used interchangeably, and the difference matters.

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. For ROI on a given project, readiness is the better predictor.

Why 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 or the technology. 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. It is the same root cause behind the pattern in why so many AI projects fail on scoping discipline: 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: Data, Context Dependencies, and Hidden Requirements

Ossman borrows a term from aviation and consulting: 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. Ossman notes this is often where things fail before security is even a concern.

• Context dependencies. An agent that does, say, 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 a bill of materials for what a system needs.

• Risk and access. What the agent will touch, and whether exposing it is acceptable. This is where readiness meets governance.

The theme is that 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 a Readiness Assessment 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, which means 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 meaningless in the abstract; it 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 risk, the same exposure behind 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.

Run this before you deploy budget, and the mid-flight surprises that kill ROI turn into a checklist you cleared in advance.

A Practical AI Readiness Checklist

A short version you can take into the 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.

Listen to the Full Episode

On this episode of the Security Podcast of Silicon Valley, host Jon McLachlan (co-founder of YSecurity and Cyberbase.ai) talks with Ged Ossman, founder and CEO of Interf, about why AI onboarding is a security problem, not a feature, and why readiness is what separates the deployments that pay off from the ones that stall.

Ossman explains why more than 60% of AI implementations never reach meaningful ROI, and why the fix is a pre-flight check on data, context, and dependencies rather than blind faith that the vendor will sort it out during onboarding.

It is a practical conversation for anyone being pushed to deploy AI fast, who still wants it to actually work.