• AI Readiness
The AI Readiness Audit: 25 Questions Leaders Should Ask Before Scaling
Most organisations do not have an AI problem. They have a scaling problem. Use these 25 questions before committing to a bigger platform contract, an enterprise-wide assistant or a fleet of agents.
By Suchetana Bauri · Published August 2025 · 18 Min Read
Most organisations do not have an AI problem. They have a scaling problem.
The tools are already in the building. Employees are using copilots, chatbots and foundation models in ways the organisation may only partly understand. Leaders have seen persuasive demonstrations. Procurement is being pressed to move faster. And the phrase “AI strategy” is beginning to do the work that “digital transformation” once did: signalling urgency while concealing a shortage of decisions.
The uncomfortable truth is that buying more licences is not scaling. Neither is launching a second pilot, appointing an AI lead, or putting a policy PDF on the intranet.
McKinsey’s 2025 survey found that roughly two-thirds of organisations remain in experimentation or pilot mode rather than scaling AI across the enterprise. The gap is not explained by a lack of models — it is explained by the harder work.
Use the 25 questions below before committing to a bigger platform contract, an enterprise-wide assistant or a fleet of agents. They are not designed to make the organisation feel advanced. They are designed to expose whether it is ready.
• Defining the Work
First: what are we actually trying to scale?
There is a strange habit in AI programmes: starting with capability rather than consequence. A model can draft, summarise, classify, search, translate, generate code and converse. Fine. But which of those activities matters enough to change? For whom? At what cost if it fails? Before you choose a tool, define the work.
1. What specific business problem are we solving?
‘Productivity’ is not a problem statement. It is a fog machine. A stronger answer names a bottleneck, a group of people and an outcome: reducing the time advisers spend locating accurate policy information; improving the first-draft quality of grant applications; cutting the administrative load in a service process without lowering safeguards. If you cannot describe the problem without using the word ‘AI’, you are not ready to scale.
2. Is this a workflow problem, a knowledge problem or a decision problem?
These are different jobs. A workflow problem may need better hand-offs, automation or integration. A knowledge problem may require trustworthy retrieval from internal documents. A decision problem may demand evidence, oversight, appeals and clear accountability. Treating all three as ‘a chatbot use case’ is how organisations create polished disappointments.
3. What would improve if this worked — and how would we know?
Choose the measures before implementation, not after the first impressive demo. Depending on the use case, that could mean turnaround time, error rate, customer resolution, revenue conversion, rework, employee confidence, compliance incidents or quality scores assessed by knowledgeable humans. Avoid counting prompts, log-ins and licences as proof of value.
4. Which work should not be automated or accelerated?
Some work relies on empathy, professional judgement, democratic accountability, confidential deliberation or a relationship that becomes thinner when mediated by a machine. Some decisions have consequences that are too serious to delegate to a probabilistic system. AI readiness is partly the ability to draw that line without embarrassment.
5. Are we improving an existing process, or preserving a bad one faster?
A poor workflow with AI bolted on remains a poor workflow. It may simply become harder to inspect. The organisations getting more from AI are more likely to redesign workflows, rather than merely attach AI to existing ones.
• Data Trust
Data: can the system be trusted with what it needs?
The sales pitch says AI turns your information into an advantage. The reality is more blunt: AI reveals how badly your information has been organised. If documents are duplicated, permissions are messy, policies contradict one another and the most useful knowledge sits in someone’s inbox, the model will not solve the problem. It will make the problem conversational.
6. What data, documents and systems will the AI rely on?
Create a practical inventory. Include not just structured data, but policies, manuals, case notes, knowledge bases, spreadsheets, customer records, code repositories and third-party sources. Then ask: which of these sources is authoritative?
7. Who owns the accuracy and maintenance of each source?
Every answer generated from internal knowledge has an upstream owner, whether you name them or not. If a policy document is outdated, a model may faithfully produce bad guidance at speed. Assign named owners for high-value knowledge sources, review dates and a process for retiring obsolete material.
8. Are permissions and access controls fit for AI retrieval?
A system that can search across internal material can surface information in combinations that were never previously visible. Old permission structures may not survive contact with semantic search and conversational interfaces.
9. Are we clear about what data may enter external tools?
Employees will use the fastest available route unless you give them a safe, workable alternative. Define plainly what may be pasted into approved tools, what must never be entered, what requires a secure internal environment and what needs explicit review.
10. Can we trace an important output back to its sources?
For high-stakes work, ‘the AI said so’ is not an explanation. People should be able to see the source material, judge whether it is current and challenge the reasoning.
NIST’s Generative AI Profile highlights risks including confabulation, data privacy, information integrity, intellectual property and non-transparent third-party components. Those risks become manageable only when leaders know what the system is using and where its outputs came from.
• Accountability
Governance: who is accountable when it goes wrong?
Every organisation has governance. The question is whether it is intentional or accidental. Accidental governance looks like this: IT owns the vendor, legal sees the contract late, teams build their own workarounds, a senior executive sponsors the launch, and nobody owns the consequences of an erroneous output. That is not speed. It is deferred responsibility.
11. Who is the named executive accountable for each scaled use case?
Not ‘the AI steering group’. Not ‘digital’. One accountable executive who can make trade-offs about cost, risk, user experience and business value.
12. Who can approve, block or stop the use case?
Set decision rights before there is an incident. Specify who approves a pilot, who authorises production use, who can halt it when controls fail, and who decides whether a use case is too risky to proceed.
13. Have we classified the use case by risk?
Not all AI deserves the same scrutiny. A tool that helps brainstorm social-media captions is different from one that influences hiring, credit, welfare, health, education or disciplinary action. Use a simple tiering approach based on impact, autonomy, sensitivity of data, affected groups and reversibility of harm.
14. What happens when the AI is wrong?
Who catches the error? How is it reported? Can the output be corrected? Can affected people challenge it? How quickly can the system be changed or switched off? Is there a record of what happened?
15. Are vendors being governed as part of the system, not treated as a black box?
Your organisation may not train the model, but it still owns the consequences of deploying it. Ask about data retention, training on customer data, security, sub-processors, intellectual-property terms, model changes, service availability, audit rights, evaluation evidence and exit options.
• Workforce Readiness
People: will anyone use it well enough to matter?
AI adoption is often discussed as a skills challenge. It is more accurately a trust-and-work-design challenge. People need to understand enough to use the system critically. They also need a reason to believe the technology will improve their work rather than quietly hollow it out.
16. Have we involved the people who do the work?
Bring them in before the tool is configured. Ask what takes too long, what is repetitive, what must never be compromised and what would make the system useful on a difficult Tuesday afternoon.
17. What new judgement will people need to exercise?
AI does not remove judgement. It relocates it. Workers may need to evaluate a draft, spot an unsupported claim, check a source, recognise bias, decide when to escalate, preserve confidentiality or refuse a recommendation.
18. Is the training tied to real tasks and risks?
Train people using their actual tools, scenarios, data constraints and accountability boundaries. A communications team may need to learn source verification and copyright judgement. A customer-service team may need to learn escalation and tone control.
The EU AI Act requires providers and deployers to take measures supporting sufficient AI literacy among staff, taking account of their knowledge, experience, training and the context of use. Even where the Act does not apply directly, the principle is sound: literacy is contextual, not a one-off course.
19. Do managers know how work, performance and quality will change?
If a team’s work is partially automated, what happens to workload expectations? How will managers distinguish strong judgement from fast output? What happens to entry-level work that used to be a route into expertise? Leaders should answer these questions openly, before employees answer them informally among themselves.
20. Is there a credible route for feedback, challenge and refusal?
Employees must be able to say: this output is wrong; this tool is unsafe; this workflow creates a new burden; this system should not be used for this decision. If the only permitted response is enthusiasm, the organisation will not hear about problems until they have already spread.
• Operations
Operations: can we run it after launch day?
The moment a tool moves from pilot to production, it stops being an experiment and becomes part of the organisation’s operating environment. That means version changes, outages, access requests, unexpected behaviour, new regulations, new data, new users and new ways to misuse it.
21. Who owns the product after the launch?
Every scaled use case needs an operational owner, not just a project sponsor. That owner should be responsible for adoption, performance, user feedback, risk reviews, change requests and decisions about whether the system still deserves to exist.
22. How will we test quality before and after deployment?
Create a representative set of tasks, prompts and edge cases. Test accuracy, relevance, safety, consistency, fairness where relevant and the quality of hand-offs to humans. Then keep testing.
23. What monitoring will show us that it is drifting or failing?
Decide what to watch: harmful or inaccurate outputs, override rates, unresolved cases, retrieval failures, user complaints, security events, latency, cost per task and changes in adoption. Monitoring must trigger action. A dashboard nobody reviews is just a screensaver with a budget.
24. Can we scale the operating model, not just the technology?
One successful pilot often depends on a heroic project team. That does not scale. Ask whether the organisation has repeatable ways to assess use cases, configure access, evaluate systems, train users, manage suppliers, log decisions and respond to incidents.
25. What evidence would make us pause, redesign or stop?
Set the thresholds in advance. A mature organisation does not regard stopping as failure. It regards stopping an unsuitable deployment as competence.
• Taking Action
Turning the audit into action
You do not need a 70-page maturity model to begin. Run these questions with the people who own the work, the data, the risk and the user experience. Score each answer simply:
Green
Evidence exists; ownership is clear; the control works in practice.
Amber
Partial evidence; a credible, active gap-closing plan exists.
Red
No evidence, no named owner, or no workable operational control.
Then resist the temptation to average the score into something reassuring.
A single red flag in a high-impact area — for example, unclear accountability, unsafe data handling or no route for human challenge — can outweigh fifteen green answers. The goal is not a flattering maturity score. The goal is an honest decision: scale, redesign, contain or stop.
There is also a political benefit to doing this well. A readiness audit turns AI from an abstract executive ambition into a shared conversation about work. It makes room for staff expertise, gives governance teams a role before the crisis and forces leaders to distinguish a useful system from an impressive-looking one.
That is the test. Not whether the organisation can say it uses AI, but whether it can explain, in ordinary language, why this use case exists, who is responsible for it and what it will do when things go wrong.
The model is rarely the hard part.
• Decision Logic
From audit score to decision
Result
Meaning
Next move
Mostly green
Evidence, ownership and controls are operating
Scale carefully and monitor continuously
Green with amber gaps
The use case is viable, but conditions are incomplete
Close defined gaps before expanding access
A red flag in a high-impact area
A serious governance, data or human-oversight gap exists
Contain, redesign or pause deployment
Persistent low value
The problem or workflow is not suited to AI
Stop and redirect investment
Do not average away a red flag.
References & Footnotes
[1] McKinsey, “The state of AI in 2025: Agents, innovation, and transformation”.
[2] National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)”.
[3] National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”.
[4] European Commission, “AI Act Service Desk: Article 4 — AI literacy”.
Looking for help with AI readiness?
Read our latest insights, or get in touch if your organisation needs a structured approach to AI scaling that goes beyond the pilot.