AI Readiness Audits Start With Work, Not Vendors

Most AI initiatives begin with a vendor evaluation spreadsheet. Someone builds a grid of platforms, features, and pricing tiers, and the team spends six weeks comparing capabilities against requirements nobody has written down yet.

Start from the other end. Find a piece of work people already do, a bottleneck everyone in the room can name, and an outcome the business already tracks. Model and platform choice is a downstream decision, and it gets easy once the work is understood.

Map the job end to end — including the parts nobody documented

Write down the trigger, the inputs, the systems involved, the decisions, the handoffs, the exceptions, and what done means. Then find the shadow process: the spreadsheet someone maintains on the side, the Slack thread where the real approval happens, the export somebody does manually every Friday morning.

That shadow layer is not a detail. It is usually where the actual integration requirements live, and it is invisible in every process diagram the company has on file.

• Volume and time spent per case, measured rather than estimated
• Quality errors, rework, and waiting time — waiting is usually the largest and least tracked
• Whether the source data exists, who owns it, and whether it is accessible in practice
• Which decisions genuinely require judgment or a formal approval
• Every system the solution must read from or write to, including the ones IT does not know about
• A baseline metric that can prove improvement three months from now

Pick a bounded first win

Good pilots share four traits: they happen often enough to generate evidence quickly, their output is observable, their data is reachable without a six-month access project, and there is a human recovery path when something goes wrong.

The anti-pattern is choosing the rare, heavily regulated, company-wide process because it sounds strategically important in a board deck. Low frequency means slow learning. Heavy regulation means slow approvals. Company-wide means every stakeholder can veto. That project will take a year and teach you nothing you could not have learned in a month elsewhere.

Data access is the schedule risk

The technical build is rarely what slips. What slips is getting a database credential approved, discovering the API is read-only, finding out the records are in a format no one has parsed since 2019, or waiting on a security review nobody scheduled. Audit data access as a hard dependency with a named owner and a date, at the same time you audit the workflow.

Plan the operating model before you plan the build

Decide now who reviews failures, who updates the knowledge base, who approves permission changes, who watches spend, and who owns the result after the launch email goes out. Readiness is an operations question at least as much as a technical one, and the projects that quietly die are usually the ones nobody was assigned to keep alive.