Readiness is a decision about a specific business area
A founder hears three versions of the same request in one month. The sales team wants an AI assistant. Operations wants automated reporting. A software vendor says the whole business can be transformed. The immediate decision isn't which tool to buy. It's whether one defined part of the business can support useful, governed and measurable AI work.
An AI readiness assessment should examine one business area or proposed capability. A company-wide maturity grade flattens the evidence that matters. The finance reporting process may have stable inputs, clear review and strong baselines while a customer advisory process has uncertain permissions, inconsistent decisions and much greater consequences when it is wrong.
The Australian Government Digital Transformation Agency's guidance for moving AI from proof of concept to scale connects readiness with strategic alignment, measurable outcomes, accountable ownership, technical foundations and organisational capacity. It is written for government agencies, so its agency-specific requirements don't automatically apply to a private growing business. Its questions still provide a useful Australian benchmark for deciding whether an initiative has foundations beyond a promising demonstration.
Peer-reviewed research reaches a similar conclusion from a different direction. The Business Horizons AI readiness framework treats readiness as sociotechnical. Technology sits alongside activities, organisational boundaries and goals. For a growing business, that means an inventory of software and data will miss the people, operating rules and commercial purpose that determine whether adoption can work.
This assessment comes before portfolio comparison. Once a business area clears its minimum readiness conditions, the separate framework for prioritising business AI use cases can compare candidate problems and decide which project deserves attention first.
Choose the scope before you assess it
Name a boundary that a real owner can understand and influence. “Customer service” may still be too broad. “Classify incoming support requests and propose a queue for human approval” gives the team a process, outcome, affected people and decision boundary it can inspect.
Write down the following scope fields before interviewing people or reviewing systems:
- the business area or proposed capability
- the intended outcome and present baseline
- the accountable business owner
- the staff, customers or other people affected
- the systems and information that would enter or receive output
- the decisions AI may support and the decisions that remain with a person
- the point at which the assessment will be reviewed again
Keep the scope stable during the assessment. If the proposal expands from drafting internal summaries to sending customer advice, create a new assessment. The users, information, consequences and controls have changed.
Assess seven capabilities using evidence
The assessment should produce evidence rather than confidence theatre. For each capability, record what exists, where it was observed and who can confirm it. Interviews explain the work. Process records, source documents, system settings, baselines and actual exceptions show whether the explanation holds.
Strategic ownership
A ready initiative has a named outcome, a baseline and one business owner with authority to change the surrounding work. Evidence might include a current operational measure, an agreed problem statement, budget ownership and a written decision boundary.
An amber finding means the problem is credible but the outcome, baseline or decision authority needs definition. A red finding applies when nobody owns the business result, the proposed benefit can't be observed or the initiative exists mainly because a tool is available. Tool access can wait until the owner can explain what should improve and what the business will stop if it does not.
Process clarity
Look for a process that can be described through real cases, including common exceptions and the human judgement that resolves them. Useful evidence includes current inputs, handoffs, decision rules, turnaround times, rework and examples outside the usual path.
Amber means the core path is visible but exceptions or ownership need repair during a bounded pilot. Red means staff perform materially different work under the same label, or the proposed automation would encode a process the business cannot yet explain. The guide to choosing business workflows to automate owns the deeper work of mapping repeatability, inputs, exceptions and review.
Knowledge and data
Usable information has a known source, owner, permission boundary and maintenance expectation. Sample the actual material the capability would use. Check whether it is findable, current enough for the decision, sufficiently complete and available to the right people and systems.
Amber can support a limited pilot when the team can name the missing material, restrict the source set and assign its repair. Red applies when critical sources conflict, permissions are unknown, personal information would be used without appropriate review or nobody can keep the material current. Repair ownership, permissions, freshness and source structure through the guide to an AI-ready business knowledge base.
People and change capacity
Readiness includes the people who will use, review, correct or be affected by the capability. Evidence includes an available process owner, subject-matter reviewers, training time, an escalation path and a realistic account of how workload will change.
Amber means the people are known but their capacity or new responsibilities need to be secured. Red means the design relies on invisible review work, removes a necessary decision owner or gives affected staff no safe way to question an output. A pilot cannot produce reliable learning when the team has no time to review its cases or record corrections.
Governance
Governance should match the context and continue throughout the lifecycle. The voluntary NIST AI Risk Management Framework 1.0 Core organises this work through Govern, Map, Measure and Manage. This keeps ownership, context, evaluation and response connected rather than treating approval as a one-off gate. NIST states that version 1.0 is being revised, so record the framework version when using it.
For Australian organisations, the Guidance for AI Adoption implementation practices provides practical direction across accountability, impact awareness, risk management, transparency, fairness and protection of AI systems. Those themes turn into evidence such as a named accountable owner, an impact record, approved use boundaries, testing criteria, incident escalation and review dates.
Amber means proportionate controls can be completed within a bounded test before exposure expands. Red means material privacy, safety, fairness, security or accountability questions remain ownerless. The AI governance policy guide for growing businesses covers the register, risk tiers, review rules and stop authority in detail.
Privacy needs a specific check when personal information enters a product or may appear in its output. The OAIC's guidance on commercially available AI products recommends intended-use due diligence, privacy by design, understanding data flows, human oversight and ongoing lifecycle review. These are prudent readiness practices. Particular legal duties depend on Privacy Act coverage, the organisation, the information and the proposed use, so seek qualified advice where the activity requires it.
Technology and integration
Technical readiness means the team understands how approved information moves, where outputs go and what happens when a component is unavailable or wrong. Evidence includes access controls, integration documentation, test environments, vendor data terms, logging, fallback routes and an owner for ongoing operation.
Amber is appropriate when a narrow manual handoff can keep a pilot reversible while one integration question is tested. Red applies when the team cannot trace the data flow, protect the required access, recover from failure or identify who will maintain the capability. Delivery model comes later. Once the use case is approved, compare ownership and sourcing through the business AI delivery model guide.
Measurement
A ready capability has a baseline, an observable business outcome and conditions for scale, repair or stop. Add quality, reliability, exceptions, review effort and harm indicators that fit the use. A faster draft has limited value if specialists spend longer correcting it.
Amber means the measure is credible but the baseline or collection method must be completed before the pilot produces a decision. Red means success is defined as tool usage, output volume or a general feeling that the system saves time. The guide to measuring AI workflow ROI and reliability covers baselines, intervention cost, reliability thresholds and scale, fix or stop reviews.
Record the evidence behind each readiness finding
Use red, amber or green as a decision signal for each capability within the stated boundary.
Green means current evidence supports proceeding within that boundary. Amber means a named repair and owner are needed before or during a bounded pilot. Red means a material prerequisite must be repaired before the initiative proceeds. A colour is a concise status, not the finding itself.
Keep the colours separate. Seven greens in low-consequence areas can't cancel a red privacy or accountability gap. A composite score also hides the repair that should receive funding first.
The evidence record matters because it gives the team something concrete to challenge and reassess. Capture the complete reasoning in the same place.
Different business areas can be ready in different ways
Consider a hypothetical professional services business assessing two capabilities. One would prepare a weekly internal performance report from approved finance and project systems. The other would draft customer-facing advice from enquiry details and a collection of consultant documents.
The same company supplies the people, systems and leadership for both. Their readiness profiles are still different because the work, information, affected users and consequence of error differ.
| Capability | Internal reporting | Customer advice |
|---|---|---|
| Strategic ownership | Green. The operations lead owns a defined reporting outcome and baseline | Amber. The service goal is clear, but advice quality and final authority need definition |
| Process clarity | Green. Inputs, review and weekly exceptions are documented | Red. Consultants use materially different judgement for similar enquiries |
| Knowledge and data | Green. Approved sources and access roles are known | Red. Document ownership, permissions and freshness are inconsistent |
| People and change | Amber. Finance review capacity must be reserved for the pilot | Amber. Specialist review is possible, but workload and escalation need agreement |
| Governance | Amber. Logging and a stop owner need to be recorded | Red. Privacy, professional risk and customer disclosure need qualified review |
| Technology and integration | Green. Read-only access and a manual publishing step bound the test | Amber. The intake path is known, but source access and output retention are unresolved |
| Measurement | Green. Preparation time, corrections and delivery time have baselines | Red. The team has no agreed measure of safe, useful advice |
The reporting capability may proceed after two small amber repairs receive owners. The advisory capability should wait. Its red findings expose different work. The team needs to stabilise the decision process, repair its knowledge sources and define governance before choosing a tool or pilot design.
If the reporting gap sits in unreliable forms, customer intake or system handoffs, the repair may involve website and journey design. The evidence should determine whether those interfaces need work.
Turn each gap into the smallest useful repair
Rank repairs by their effect on safe learning. Start with gaps that could make a test unlawful, harmful, uninterpretable or impossible to stop. Then address the dependency that prevents the team from learning whether the capability works.
The NIST AI RMF Playbook presents voluntary suggested actions that organisations select for their context. It explicitly avoids prescribing a checklist or required sequence. That proportionate approach suits a growing business. The assessment should identify the applicable action and evidence, rather than creating framework compliance work with no effect on the proposed capability.
A useful repair statement is small and testable. “Improve data” is too broad. “The service owner will approve one current source for each offered service, record its permission and add a quarterly review date” names the owner, action and completion evidence.
Use the specialist guide that owns the repair:
- inconsistent steps and exceptions go to workflow assessment and redesign
- weak sources, permissions or freshness go to knowledge readiness
- missing controls, review or stop authority go to AI governance setup
- absent baselines or decision thresholds go to ROI and reliability measurement
Reassess the affected finding when the promised evidence exists. A task counts as complete when the process produces consistent cases and the owner can exercise the control.
Move into use case prioritisation when the gates pass
A business area is ready to move forward when it has a named outcome and owner, a sufficiently stable process, usable and permitted information, proportionate governance, feasible integration, team capacity and a baseline with review and stop conditions. Amber findings can remain when each has a bounded repair, named owner and explicit condition that prevents exposure from expanding too early.
At that point, use the AI use case prioritisation framework to compare viable candidate problems. After one candidate earns approval, the delivery model guide helps decide whether to buy, configure, integrate, build or defer. Build the pilot's evidence plan with the ROI and reliability framework before work quietly becomes production.
If the team cannot gather the evidence or agree on the first repair, an AI capability discovery should focus on that constraint. The useful outcome is a bounded assessment, an accountable repair plan and a clear decision about whether the business area is ready to progress.