What should an AI readiness assessment cover?

01Start with the product as it actually works

Most readiness checklists start with data, skills and strategy. Those matter, but for a company that already has paying customers, the first question is more concrete: what does the product do today, step by step, and where would the new workflow touch it? This is part of our larger guide, What is forward deployed engineering?.

We start every assessment with an actual versus required comparison. On one side, the product as it runs in production: the screens people use, the records it stores, the integrations it calls, the roles it enforces and the jobs that run at night. On the other side, the workflow the business now wants, described in the same terms. The gap between the two is the real scope.

This sounds obvious, yet it is where most AI plans go wrong. Teams write a vision of the new experience and then estimate it as if it were a new product. In a mature product, much of what the new workflow needs already exists: sign in, billing, notifications, audit events, admin screens, role checks. Rebuilding those is expensive and risky. Reusing them is usually the fastest path to production, and it keeps the pilot honest because real customers already trust those parts.

Three sources give you the "actual" side quickly:

• The code and the live database, read by an engineer who did not write them.
• The people who run the product every day: support, operations, account managers.
• The workflows customers follow in practice, which are rarely the ones in the original requirements document.

02Mark every flow as reusable, changed or new

Once you have both pictures, walk through them flow by flow. For each one, decide which of three buckets it falls into. This single step does more for an accurate estimate than any amount of model research.

The "new" bucket is where the AI lives, and it should be the smallest of the three. If most of your list lands in "new", the assessment is telling you that the product is not ready for this workflow yet, or that the workflow is really a different product.

Two habits make this table more reliable. First, record each decision with a reason, because the reason is what a reviewer will challenge later. Second, mark anything you are unsure about as "changed" rather than "reusable". Optimism in this table becomes surprise in the sprint.

03Write down what must not break

Every established product has rules that nobody wrote down because nobody ever had to. An AI readiness assessment should surface them before design starts, not after the first incident. We ask four questions for each flow the AI will touch:

1. 01

   Who is the authority for this record today, and does that stay the same once AI is involved?

2. 02

   Which data may never be seen, stored or sent to a model, even temporarily?

3. 03

   Which records need different handling because of contracts, regulation or customer promises?

4. 04

   What would a customer notice first if this flow changed under them?

The answers become a short "must not break" list. It is often more valuable than the feature list, because it sets the boundaries the AI has to respect. In practice it covers things like which party releases a document, which roles can see which fields, which records must never be deleted, and which numbers leadership treats as the source of truth.

This list also protects the roadmap. When a new idea comes up mid build, the team can check it against the list in minutes instead of debating it for a week. The NIST AI Risk Management Framework describes this work under its Map function: understanding the context a system operates in before you measure or manage it.

04Scope a pilot that reuses what already works

The last part of the assessment turns the table and the list into a pilot. A good pilot is narrow on purpose. It proves the new piece of the workflow on real data, inside the real product, while leaning on flows that customers already trust.

We shape pilots around a few rules:

• One workflow, end to end, rather than several workflows half done.
• One identifier that ties every step together, so you can trace any request from start to finish.
• Existing payment, delivery and authentication flows reused, not rebuilt.
• Human review on every AI output that leaves the system.
• A clear end state, so the team knows what "done" means before it starts.

This is the same idea Martin Fowler describes as the strangler fig approach to modernization: grow the new behavior beside the old system, one seam at a time, instead of replacing it in one risky step. For AI it matters even more, because the AI part is the least predictable piece, and you want everything around it to be boring and proven. We cover the wider pattern in how to add AI agents to existing SaaS without rebuilding.

05What we see in production

On a national legal marketplace that connects court reporting agencies with attorneys, the assessment started from a working platform: agencies uploaded transcripts, attorneys searched, paid through an existing checkout and downloaded. The new workflow required metadata only discovery, with no transcript visible before authorization and payment and no agency identity exposed in search. Our gap assessment marked payment and delivery as reusable, the request lifecycle as changed, and metadata extraction as new.

The first pilot was deliberately small: plain text transcripts and front matter extraction, the existing payment and delivery flows, and one request identifier across the whole lifecycle. The "must not break" list said agencies stay the release authority and the platform never sees transcript content. That list shaped the second phase, where extraction moved into the agency's browser and files were encrypted so that only the paying attorney can open them.

On our own internal operations platform, readiness meant data accuracy before any AI. Each dashboard calculated the same number its own way, and the counts did not match reality. We narrowed the scope to the three dashboards used every day, fixed the shared data model first, and only then connected AI assistants to enter routine updates, with a person reviewing each one.

On a high volume photography platform, our engineer worked inside the client's own data team, under its pull request reviews. Much of the first month went to waiting for catalog permissions and environment access. Access is a readiness item too: if the people doing the work cannot reach the environment, the plan is not ready, whatever the model can do.

06An AI readiness assessment checklist

Before you call the assessment finished, check that it answers these questions in writing:

• Which flows are reusable, changed and new, with a reason for each?
• What must not break, and who owns each rule?
• What is the smallest pilot that proves the new piece on real data?
• Which identifier traces a request from start to finish?
• Who reviews AI output before it reaches a customer?
• What access does the delivery team need, and has it been granted?

If any answer is missing, the gap is the next piece of work, not a reason to start building and hope it resolves itself.

Frequently asked questions