What an AI readiness audit actually catches
Everyone wants an AI strategy. Fewer teams stop to ask whether they can absorb new automation without damaging trust, compliance, or operating discipline. A readiness audit is not a maturity-model poster. It is a structured look at whether your organisation can own what it is about to ship.
Why audits fail when they stay in IT
If the outcome is a slide deck owned solely by engineering, you learned whether APIs exist—not whether anyone will escalate model mistakes correctly on a Friday afternoon. Readiness spans legal, customer-facing teams, finance (for usage economics), and leadership nerves. The audit should surface who decides when confidence is low, not only what model you can call.
The four lenses we use
1. Intent and harm
What decisions might an agent influence? Who gets hurt if it’s wrong—in dollars, safety, or reputation? If you can’t name the failure modes, you’re not ready to automate the workflow; you’re ready to experiment in private sandboxes.
2. Data and lineage
Do you know where truth lives? Many teams discover mid-project that “the CRM” is actually four spreadsheets and a forgotten Zap. Readiness means inventory—systems of record, refresh cadence, PII boundaries, and whether humans already argue over the numbers.
3. Operations
Who maintains prompts, tools, and evaluations after launch? If the answer is “whoever has time,” expect drift. Readiness assigns roles the way you’d assign on-call for payments—not as an afterthought.
4. Economics
Token costs and latency aren’t academic. An audit builds a rough model: interactions per day, expected growth, failure reroutes to humans. If unit economics only work at unrealistic volumes, better to learn that before you fund a rebuild.
What happens next
An audit doesn’t commit you to a vendor or stack. It commits you to honesty about gaps. Some teams leave with a green light for a narrow pilot; others leave with homework: consolidate customer records, write escalation policies, or hire the role that will own evaluation metrics.
If you’re a founder, the same discipline applies at smaller scale: fewer committees, but sharper trade-offs. You still need to know which assumptions about data and users would collapse first contact with reality.