AI readiness assessment: five evidence gates before a build

An AI readiness assessment should answer one practical question: is a named workflow ready to be scoped for a controlled build? The evidence is a defined job, usable source records, an accountable owner, proportionate risk controls, and a credible operating path. A company-wide maturity label cannot substitute for those five things.

This guide is for Australian operators assessing a workflow, not for scoring an entire organisation against a generic adoption curve. It is not legal, privacy, cyber security, or regulatory advice. Apply the scorecard with the obligations and controls that govern your organisation.

The five-gate AI readiness scorecard

Use the scorecard in a working session with the process owner and the people who run the job. Mark a gate ready only when the listed evidence can be reviewed. Mark it hold when the workflow may be viable but a named artefact or decision is missing. Mark it stop when the condition is absent or cannot be made acceptable.

1. Workflow boundary. Evidence: start, finish, normal path, exceptions, systems, and excluded cases. Ready when: one operational job is clear enough to map and test. Hold or stop when: the target is a department, ambition, or tool rather than a job.
2. Evidence and access. Evidence: volume source, sample method, source records, system access, and data constraints. Ready when: the current state and future test can be reproduced. Hold or stop when: important inputs are unknown, inaccessible, or unsuitable for the proposed use.
3. Owner and oversight. Evidence: process owner, system owners, reviewers, and decision authority. Ready when: named people can approve access, exceptions, and a pause. Hold or stop when: sponsorship exists but nobody owns the operating result.
4. Risk and control boundary. Evidence: impact questions, privacy and security review, human stops, and prohibited actions. Ready when: controls match the job and its possible effects. Hold or stop when: the team cannot say what the system must never do or who reviews uncertainty.
5. Production and change path. Evidence: KPI, acceptance method, support owner, monitoring, rollback, and change approval. Ready when: the team can test, operate, challenge, and reverse the change. Hold or stop when: the plan ends at a demo or assumes operation will be designed later.

Do not average the gates. A workflow with good records but no accountable owner is not “mostly ready”. The missing owner is the decision.

1. Define the workflow boundary

Name the work in operational language. Record the event that starts it, the system or record that proves it is finished, the normal path, the exceptions, and the cases outside scope.

“Use AI in operations” is not a workflow. “Read a new service request, check the required fields, draft a job record, and route incomplete requests to review” is bounded enough to inspect. The boundary does not decide that AI is the right answer; it gives the team something real to assess.

Process mapping is the first artefact because the map exposes hand-offs, re-keying, judgment, and hidden review work. If operators disagree about how the job starts or finishes, hold the assessment and resolve the process before selecting a tool.

The boundary should also state what remains human. Approvals, contested decisions, sensitive communications, or unusual cases may need to stay outside the automated path. That is a design constraint, not an implementation failure.

2. Prove the evidence and access path

List the records used to understand the current workflow and the records a future system would need. For each source, record its owner, quality limits, access method, relevant fields, and any privacy, confidentiality, contractual, retention, or security constraints.

Use system history where it is trustworthy. Where it is not, define a structured sample: selection window, included and excluded cases, coding method, reviewer, and limitations. An unknown is acceptable assessment evidence. A confident number with no method is not.

The Australian Government’s proof-of-concept-to-scale readiness checklist asks whether required data is available and governed, integration points are understood, success criteria exist, and there is a clear pathway to production. The checklist is written for government agencies, but those evidence questions are useful for a business workflow too.

Hold when access depends on a shared login, an undocumented export, or knowledge that exists only in one person’s memory. The next step may be process or data work rather than an AI build.

3. Name the owner and human oversight

The process owner is accountable for the operating result. System owners control access to connected tools. Reviewers handle exceptions. An incident decision-maker can pause or reduce scope. Write those roles down and confirm their authority.

The National AI Centre’s Guidance for AI adoption calls for documented accountability across development, deployment, testing, ongoing human control, incidents, and updates. It also asks organisations to define the authority and capability of accountable people.

A steering group is not a substitute for an operational owner. If nobody can approve access, make operators available, accept the test evidence, resource the review queue, or order a pause, stop. The workflow is not ready for a production scope.

4. Set the risk and control boundary

Describe who and what the workflow can affect. Identify personal or sensitive information, customer-facing actions, financial or regulated decisions, safety consequences, and foreseeable misuse. Then state the controls in operational terms: prohibited actions, permission limits, human approval points, escalation rules, and the conditions that stop work.

Risk depends on context. The National AI Centre guidance notes that the same system can carry different risks as its use, scale, and human oversight change. It recommends documented system scope, intended use, foreseeable misuse, limitations, impact assessment, risk treatment, data governance, cyber security, and mechanisms for human intervention.

For an agent that can use tools or change records, review the AI agent implementation checklist before increasing access. The assessment gate passes only when the proposed boundary can be explained and reviewed by the relevant owners. It does not pass because a vendor provides a generic security statement.

5. Define the production and change path

Choose the primary KPI and write its method before recommending a build. Name the start event, finish event, unit, source, measurement window, exclusions, and owner. Define the acceptance cases, including exceptions and prohibited actions, so a later reviewer can reproduce the decision.

Evaluations should exist before the agent, not after users find the edge cases. The production path also needs an exception queue, support owner, monitoring that answers workflow questions, a pause control, failed-write recovery, change approval, and rollback evidence.

The government readiness checklist separates initial readiness, post-proof-of-concept value assessment, the pathway to production, controlled pilot testing, and ongoing operation. That separation is useful because evidence from a promising test does not prove that the organisation can operate the system safely or maintain it through change.

Hold when the plan ends at a demonstration. Stop when the team cannot define an acceptance method, a human intervention path, or a return path for changes to access and workflow state.

The readiness decision: proceed, hold, or stop

End the assessment with one of three decisions and the evidence behind it:

• Proceed to a bounded scope. All five gates have reviewable evidence and the owners accept the proposed boundary. This authorises scoping and testing, not an outcome claim.
• Hold and close named gaps. The workflow may be suitable, but an owner, access decision, data artefact, control, or operating method is missing. Record who closes it and what evidence is required for reassessment.
• Stop or choose a simpler option. The job has no stable boundary, usable evidence, accountable owner, acceptable control path, or production method. A process change or existing product may be more appropriate.

The value of the assessment is the decision boundary. A low score with no action is just another label; a hold with a named artefact and owner is useful.

What the assessment pack should contain

Keep the decision evidence together:

• current-state workflow map, systems, roles, normal path, and exceptions;
• KPI definition, measurement method, source records, sample, and limitations;
• data and access register with relevant constraints and owners;
• responsibility map for operation, review, incidents, and changes;
• impact, risk, prohibited-action, human-stop, and escalation notes;
• acceptance cases and the result required before production;
• proposed support, monitoring, recovery, change, and rollback boundaries; and
• the proceed, hold, or stop decision with unresolved questions.

This pack should be understandable to the process owner and operators as well as technical reviewers. It should remain useful even if the eventual build approach changes.

When Workflow Scoping is the next step

Use the scorecard internally if the owners can gather and challenge the evidence. If a candidate workflow is clear but the map, KPI method, control boundary, and production scope are not yet decision-ready, Workflow Scoping is the single commercial path. The service page remains the source for current deliverables, scope, timing, and pricing.

Bring one workflow, its normal volume source, the systems it touches, and the person accountable for the result. The first decision is whether the work is measurable and governable enough to scope. If it is not, the assessment should say so.