AI Strategy & Roadmapping · Cornerstone
The diagnostic companion to the AI Readiness Assessment. The dozen questions that filter "ready to build" from "needs to do other work first."
Quantum Associates — Quantum Associates
· 9 min read
The single most predictive question we ask in the first conversation with an AU mid-market organisation considering AI investment is some variant of: “what work have you done already?” Not because we’re looking for sunk cost — we’re looking for whether the foundations are in place. The pattern is consistent: organisations that have done genuine readiness work get clean engagement outcomes; organisations that try to skip straight to the build inevitably hit the same handful of foundation problems six months in.
This piece is the diagnostic we run mentally in those first conversations. It’s the long-form companion to the AI Readiness Assessment — the same five dimensions, but with the why behind each question and what an answer that signals “ready” actually looks like.
If you want the score, take the assessment. If you want to understand what’s actually being tested, read this.
Readiness for AI isn’t a single thing. It’s five intersecting capabilities, any one of which can stall an engagement:
The 12 questions below distribute across those five dimensions in a 3-3-2-2-2 split — strategy and data get more weight because they’re the most common cause of stalls.
What a “ready” answer looks like: A specific, named list. Not “we want to use AI in operations” — “we want to (a) automate first-pass contract review in legal, (b) cut the time-to-quote in commercial sales, and (c) reduce the support volume on tier-1 tickets in customer success.”
What signals “needs work”: “We’re exploring opportunities.” “Leadership wants us to do something with AI.” “We’re evaluating where it might fit.” These answers are honest, but they mean the strategy work hasn’t been done — and trying to scope an AI engagement on top of unclear use cases is how budgets get burned on the wrong problem.
The fix for organisations in the “needs work” category: don’t go straight to a build engagement. Run a structured AI Readiness Sprint first that produces a scored backlog of 6–12 use cases. Three weeks. Then you know what to build.
What a “ready” answer looks like: “Use case A: ~$300K/year in legal time saved if we get to 80% first-pass automation. Use case B: ~$150K/year in commercial sales velocity, conservatively. Use case C: hard to quantify but the support team thinks 20–30% of tier-1 volume is automatable, which would free up roughly 1.5 FTE for higher-value escalations.”
The numbers don’t need to be precise. They need to be defensible to a CFO. See Measuring AI ROI: a CFO-grade framework for the unit economics behind getting these honest.
What signals “needs work”: “It’ll save us a lot of time.” “It’s strategic.” Without numbers, prioritisation becomes politics, and the loudest stakeholder wins the budget — not the most valuable use case.
This sounds adversarial but it’s the most positive question on the list. Organisations that have an active list of “we considered AI here and decided against it” are organisations that have actually thought about where AI applies. Organisations that don’t have such a list are organisations where AI is a hammer looking for nails.
What a “ready” answer looks like: “We looked at AI for [specific function] but decided the workflow is too low-volume to justify the integration cost.” Or “We considered AI for [specific function] but the regulatory exposure is too high to be worth the marginal efficiency gain.” Both are signs of a clear-eyed view.
This is the single most common cause of pilot stalls. The use case is clear, the value is real, the model architecture is right — and the data lives in a SaaS system whose API is rate-limited to 100 requests/minute, or in an on-prem database that requires VPN access from a non-domain-joined workstation, or in a CSV that gets manually exported each Monday.
What a “ready” answer looks like: “Yes — the data lives in [system X], we have OAuth credentials, the rate limit is N/min which is well above our expected query volume, and the integration pattern is documented.”
What signals “needs work”: “We have all the data we need” (true but irrelevant if it can’t be reached) or “we’ll figure out access during the build” (this is how 4-week builds become 14-week builds).
For any data that’ll be sent to a foundation model — particularly an external one — the question of what classification it carries (public, internal, confidential, restricted, regulated) determines the architecture. Send health data through an unredacted prompt to a US-hosted LLM and you’ll have an Australian Privacy Act problem very quickly.
What a “ready” answer looks like: A documented classification scheme, applied to the relevant data, with clear rules about what can and can’t leave the AU sovereignty boundary.
What signals “needs work”: “We’ll think about that when we get to the build phase.” That’s late — the architecture decisions are typically locked in by then.
A simple, often-overlooked test. If your sales team has to manually correct the CRM data before they use it for reporting, an AI system using the same data will produce the same noise — but at scale and without humans noticing the corrections weren’t made.
What a “ready” answer looks like: “Yes — we run regular data-quality reviews, the relevant fields are >95% populated, and the entries that drive the use case have been validated.”
What signals “needs work”: “We know the data has issues but we mostly work around them.” That’s a foundation problem that needs to be solved before AI sits on top, not after.
Not a steering committee. Not a tiger team. A single person who, when something goes wrong with the AI system in production, the org knows to call.
What a “ready” answer looks like: “Yes — [name], whose role is [specific], who’s accountable for the system and has [N hours/week] dedicated to AI-related work.”
What signals “needs work”: “We’ll figure that out during the engagement.” “It’ll be a shared responsibility across the team.” Both are reliable predictors of an AI system that gets shipped, then quietly degrades over the following 12 months because no one’s holding it.
You don’t need a PhD. You need someone who can read a vendor pitch, identify the load-bearing assumptions, and ask the questions that test them. Without that capacity in-house, every AI procurement becomes an act of faith.
What a “ready” answer looks like: A named person whose background includes meaningful technical depth — a senior engineer, a quant, a data scientist, a technical product manager. Or, if you don’t have that in-house, an explicit plan to bring it in (a fractional technical advisor, an external partner who’s mandated to do knowledge transfer, etc).
Not “we’re working on one.” A document that exists, is current, defines what employees can and can’t do with AI, names the acceptable systems, and has a process for adding new ones.
What a “ready” answer looks like: A version-controlled document approved by an accountable executive, reviewed annually, with audit-trail evidence of changes and exceptions.
What signals “needs work”: No policy, or a policy that’s 18 months out of date and references ChatGPT 3.5 as if it’s the only system to worry about. The Voluntary AI Safety Standard guide covers what a current policy needs to address.
If you don’t have a policy: don’t hand-craft one from scratch — start from a tested template. We publish a free AI Policy Template aligned to the Voluntary AI Safety Standard that’s designed to be customised in a few hours rather than a few weeks.
Distinct from your enterprise risk register. A specific, named view of the AI-related risks the org carries: model risk, third-party risk on AI vendors, data leak risk through prompts, hallucination risk in customer-facing outputs, regulatory change risk.
What a “ready” answer looks like: A documented register reviewed at least quarterly, with named owners for each risk and current mitigation status.
What signals “needs work”: Either no register, or a register so generic (“AI may produce incorrect outputs”) that it doesn’t help anyone make a decision. For APRA-regulated entities particularly, the register isn’t optional — CPS 230 expects it.
A simple test of whether the org’s engineering operating model supports AI in production. AI systems require frequent updates — prompt tuning, model upgrades, evaluation criteria adjustments. If every change requires a 6-week ITIL-style change-approval process, the system will be perpetually behind.
What a “ready” answer looks like: “Yes — we have CI/CD in place, we deploy to production multiple times per week, and we have a change-management process that supports rapid iteration with appropriate guardrails.”
What signals “needs work”: “All production changes go through monthly release windows.” That’s a foundation problem that needs to be addressed — not necessarily before the AI engagement, but the engagement needs to design around it explicitly.
Standard production monitoring works for deterministic systems — the kind where the same input produces the same output. AI systems aren’t deterministic. You need observability tooling that can sample outputs, score them against criteria, and flag drift. Without it, you’re flying blind in production.
What a “ready” answer looks like: “We have logging and tracing for AI-related calls, we capture inputs and outputs for evaluation, and we have a process to score samples against rubrics on a regular cadence.”
What signals “needs work”: “We have standard application monitoring.” That’s necessary but insufficient. The first scoped piece of work in any production AI engagement should include the evaluation infrastructure, not bolt it on later.
If you can answer “yes” to 10+ of these questions, you’re ready to build. The next conversation should be about which specific use case to ship first.
If you can answer “yes” to 6–9 of them, you have foundation work to do — but it’s doable in a focused 3-week sprint. A productised AI Readiness Sprint is designed exactly for this gap.
If you can answer “yes” to fewer than 6, the right next move is not an AI engagement at all. It’s the underlying organisational work — strategy clarity, data foundations, hiring an internal owner — that needs to happen first. The good news: those investments compound. The org that does this work goes on to get clean outcomes from every subsequent AI investment, not just the first one.
For the full diagnostic with scoring built in, take the AI Readiness Assessment. For a structured engagement that produces the answers, see the AI Readiness Sprint.
Related insights
AI Strategy & Roadmapping
The pattern is consistent enough to be useful. What separates AI pilots that ship into production from the ones that quietly die six months in.
AI Strategy & Roadmapping
What AU buyers actually pay for AI consulting in 2026 — who's pricing what, where the bands are moving, and how to read a proposal.
Next step
30 minutes, no pitch, no deck — just a working conversation about how this applies to your situation.