Readiness Is a Delivery Decision, Not a Technology Score
An AI automation idea can sound convincing while the work around it remains undefined. The model or platform may be capable, yet the workflow has no stable owner, the input data cannot be used safely, or nobody knows what should happen when an output is wrong. In that situation, adding technology creates a new dependency without resolving the original uncertainty.
A useful AI automation readiness assessment asks whether one specific workflow can be operated responsibly. It does not try to award an organisation a broad maturity badge. The NIST AI Risk Management Framework organises risk work around Govern, Map, Measure and Manage. The UK NCSC guidance for secure AI system development follows the full lifecycle from design through operation. Both point towards an ongoing management discipline rather than a one-off tool-selection exercise.
The five decisions below turn that principle into a practical assessment. Mark each decision Ready, Needs Evidence or Not Ready. A workflow should not move into implementation because its total looks impressive. Any unresolved decision that could expose people, data, operations or accountability is a stop condition until the evidence improves.
Decision 1: Is the Problem Specific Enough to Test?
Start with the work, not the label "AI". Name the user, trigger, input, task, expected output and next action. "Automate customer support" is too broad. "Classify incoming support requests into an agreed queue, with uncertain cases held for review" is testable.
- Ready: The current workflow is documented, the friction is observable, and the proposed assistance has a bounded role.
- Needs Evidence: People agree that the process is slow but cannot yet describe its exceptions or decision rules.
- Not Ready: The proposal is mainly a tool demonstration or a request to replace an undefined process.
Write a short baseline without inventing a business case. What work happens now? Where does it wait? Which mistakes matter? Who is affected? What evidence would show that the new process is more useful, safer or easier to operate? These questions separate a real operating problem from general enthusiasm.
The existing practical path to AI automation goes further into selecting one workflow and designing its review boundary. Use that guide after the assessment confirms that the problem itself is ready.
Decision 2: Can the Required Data Be Used Responsibly?
List every input before choosing a model. Include structured records, documents, messages, knowledge sources, user prompts and any information returned by another system. For each source, identify its owner, purpose, sensitivity, quality limits, retention expectation and permitted use.
The ICO AI and data-protection risk toolkit is designed to help organisations reduce risks to individual rights and freedoms from their AI systems. Where personal data is involved, the assessment must therefore cover more than whether an integration is technically possible. The responsible team needs to understand necessity, proportionality, access, transparency, retention and whether a data-protection impact assessment is required.
- Ready: Data sources, permissions, quality limits and handling rules are documented and approved by the appropriate owners.
- Needs Evidence: The sources are known, but access or lawful-use questions remain unresolved.
- Not Ready: The workflow depends on copying sensitive or unverified data into a tool without an agreed purpose or control.
Do not treat a clean spreadsheet as proof of readiness. Representative test data should include missing fields, ambiguous language, duplicates, outdated records and other conditions the live workflow will encounter. If the team cannot assemble a safe and representative test set, it cannot yet evaluate the system honestly.
Decision 3: Are Review, Failure and Stop Controls Explicit?
Human review is only useful when the reviewer knows what to check and can change the outcome. Define which outputs may proceed automatically, which require approval and which must be rejected or escalated. Then describe the evidence shown to the reviewer and the action available to them.
The NCSC guidance covers threat modelling, supply-chain security, responsible release, incident management, logging and monitoring across the AI lifecycle. Apply those concerns to the actual workflow rather than adding a generic security section at the end.
- Ready: Review thresholds, escalation paths, access controls, logging and a practical stop mechanism have named owners.
- Needs Evidence: Review is planned but the thresholds, evidence or response process are vague.
- Not Ready: The design assumes outputs are correct, hides uncertainty or cannot be paused without disrupting the wider operation.
Test the uncomfortable cases before the happy path: unavailable providers, malformed inputs, prompt injection, irrelevant retrieval, unexpected costs, unsafe output and conflicting instructions. The purpose is not to predict every failure. It is to confirm that a failure becomes visible, contained and recoverable.
Decision 4: Does One Person Own the Operating Outcome?
Separate three responsibilities: the business owner decides what the workflow should achieve, the technical owner maintains the system, and the risk or information owner confirms the relevant boundaries. One person may hold more than one role in a small team, but the responsibilities must still be explicit.
- Ready: Named people can approve changes, review performance, handle incidents and decide when the automation should stop.
- Needs Evidence: A project sponsor exists, but day-to-day ownership after launch is unclear.
- Not Ready: The implementation is expected to operate indefinitely once the supplier or project team leaves.
Ownership also includes suppliers. Record which model, platform, integration and data processor the workflow depends on. Identify what can change without notice, what logs are available, how access is revoked and what happens if a service becomes unsuitable. The AI and automation service can support this discovery and control design, but the organisation using the workflow must retain clear decision ownership.
Decision 5: Can the Workflow Be Maintained and Exited?
A successful pilot creates an operating obligation. Prompts, model behaviour, source data, policies, prices and user expectations can change. Readiness therefore includes monitoring, change control, support and an exit route.
- Ready: The team has defined review intervals, useful operating signals, update ownership, incident handling and a fallback process.
- Needs Evidence: The pilot can be built, but support capacity and exit arrangements are not yet agreed.
- Not Ready: The workflow would become a critical dependency without monitoring, documentation or a manual alternative.
Choose measures that reflect the process rather than the novelty of the model. Depending on the workflow, that may mean reviewing correction patterns, escalation quality, completion consistency, user complaints or time spent on exceptions. Do not reduce the decision to a single accuracy percentage. A technically strong output can still produce a poor service if it arrives late, lacks context or moves responsibility to the wrong person.
The NCSC recommends monitoring system behaviour and inputs, managing updates securely and collecting lessons during operation. Build those activities into the delivery plan and budget before launch. If the team cannot maintain them, reduce the scope or retain the manual process.
Use the Result to Choose the Next Step
The assessment should end with one of four decisions.
- Proceed to a Bounded Test: All material decisions are ready, so define a small test with representative data, explicit review and a reversible release.
- Run a Discovery Sprint: The problem looks useful, but one or more decisions need evidence. Resolve those questions before selecting the implementation.
- Improve the Underlying Process: The workflow itself is unstable or poorly owned. Fix the process before automating it.
- Stop the Idea: The value is weak, the risk cannot be controlled, or the operating burden is larger than the problem warrants. Stopping is a valid outcome of a good assessment.
For a bounded test, document the current workflow, test cases, permissions, review rules, failure paths, operating owner and exit plan in one brief. That brief becomes the boundary for design and evaluation. If the requirement grows beyond it, return to the five decisions rather than quietly expanding the system.
Where the assessment reveals a need for a purpose-built internal platform rather than a single automation, compare the option with the organisation's custom software requirements. If the problem or ownership boundary is still unclear, use the project enquiry route to describe the workflow and the evidence already gathered.
Questions for Human Review
- Confirm that the five decision labels match the way Programmers House scopes AI and automation enquiries.
- Review the data-protection wording with the appropriate privacy or legal adviser; this draft does not provide legal advice.
- Confirm whether the stop conditions and supplier-review questions reflect the controls the delivery team can genuinely support.
- Add only company-specific examples that can be substantiated and approved for public use.
- Approve a featured image and final CMS presentation before publication.