The pitch for AI in testing is persuasive, and much of it is true. A test generator can read an acceptance criterion and draft a dozen cases in seconds. An agent can run a regression suite overnight, cluster the failures by likely cause and write a tidy summary for the morning stand-up. Some tools now go one step further and offer a recommendation: "Release 4.12 is ready to ship."
That last step is where the line sits. Everything up to the recommendation is preparation. The recommendation itself is a decision about risk to patients, customers or citizens, and a decision needs someone who can be held to it. AI can prepare almost all of the evidence for a release. It cannot own the release. The useful design question is not whether to use AI in testing, but how to arrange the work so the preparation is fast and the accountability is unmistakable.
Kudu Pharmacies is fictional, and its systems and figures are illustrative. As in Part 1, Kudu ships its Kudu Repeat app every two weeks, uses an AI test generator, and treats requirement RX-214, the pharmacist hold on review-required medicines, as high risk.
The two columns
The cleanest way to draw the line is to sort every release activity into one of two columns.
The left column is work an agent can do and a person can check. Drafting test cases from criteria, generating synthetic data, running suites, collecting logs, grouping failures and drafting a summary are all bounded tasks with inspectable outputs. If the agent gets one wrong, the error is visible in the artefact and can be corrected before anything ships.
The right column is different in kind. Accepting the risk of a known defect, approving an exception, deciding GO or NO-GO, signing the record and owning the call to roll back are not tasks with a correct answer that can be checked afterwards. They are judgements made under uncertainty, on behalf of an organisation, about harm that has not happened yet. Somebody has to be the person who made them.
This is not a statement about how capable the models are. A model may well produce a sensible recommendation most of the time. The point is that "most of the time" is exactly the situation in which accountability matters, and accountability does not attach to software. Our AI Before the Rulebook series makes the same argument for decisions about people: AI may assist the decision, but it must not inherit the authority.
Where teams blur the line without noticing
Few organisations decide to let AI own the release. They drift there. The common routes are:
The summary becomes the decision. The agent writes "no blocking issues found". The release owner, busy, approves on the strength of that sentence. The record shows a human approval, but the judgement was the agent's. The fix is to make the approver look at the evidence for high-risk criteria, not the summary: the release record lists each high-risk criterion, its tests and their results, and the approver confirms each line.
The agent marks failures as flaky. A test that fails intermittently is retried until green, and the agent annotates it "flaky, not a product defect". Sometimes that is right. Sometimes the flakiness is a real timing defect that will appear in production under load. Classifying a failure is a judgement that changes what the release owner sees, so the classification must be reviewable and must not delete the original failure. Part 6 covers this in detail.
The agent edits the test to match the code. When code and test disagree, an agent asked to "make the build green" may change the test. If the test was right, the agent has just removed the evidence that something is wrong. Test changes on high-risk criteria need the same review as code changes, by someone other than the agent that wrote the code.
The pipeline auto-promotes. A green pipeline triggers deployment. That is fine for low-risk changes with strong automated gates. It is not fine when the pipeline's definition of green does not include the high-risk criteria, the non-functional evidence or the exceptions register.
Each of these is a small convenience. Together they move the decision out of human hands while leaving a human signature on the record.
Three honest outcomes
The release decision itself should have three possible outcomes, each with clear conditions.
GO means every high-risk criterion has passing evidence on this build and no blocking defect is open.
Conditional GO means a known gap has been accepted. This is a legitimate outcome, not a failure. Releases often go out with known minor defects. But a conditional GO is only honest when the accepted gap has three things: a named owner who accepted it, a mitigation (a workaround, a monitoring alert, a feature flag) and an expiry date by which it will be fixed or re-decided.
NO-GO means a high-risk criterion is unmet or has no evidence. The fix is made, the tests rerun and the decision taken again.
At Kudu, release 4.12 went out as a conditional GO. An intermittent timeout on the medical aid claim journey was known and accepted by the product owner, mitigated by a manual claim fallback in stores and given a two-week expiry. RX-214 itself had full evidence. The record named the release manager as decision-maker and the clinical owner as the person who reviewed the RX-214 evidence. The agent's role, which was considerable, appears in the record too: it generated 41 of the tests cited and drafted the summary. Being clear about what the agent did is part of being clear about what the people did.
Designing the hand-off
A practical arrangement has four parts:
- The agent produces an evidence pack, not a verdict. The pack lists each high-risk criterion, the tests citing it, the results on this build, open defects and open exceptions. It may include a draft summary, clearly labelled as a draft.
- The approver confirms high-risk lines individually. Not a single "approve" button, but a short checklist where each high-risk criterion is ticked by a person who has looked at the evidence.
- Exceptions are owned by name. The system will not record a conditional GO without an owner, a mitigation and an expiry.
- The record shows who did what. Agent-generated tests, agent classifications and human decisions are distinguishable in the release record.
None of this slows a well-run release by more than a few minutes. What it removes is the slow, expensive conversation after an incident about who actually decided.
When full automation is the right answer
There are releases where no human should be in the loop: a dependency patch with no behaviour change, a copy edit, a configuration change behind a flag. Requiring a human signature on these trains people to sign without reading. The answer is to classify changes by risk and let the low-risk class release automatically under strong automated gates, while the high-risk class keeps the human decision. The classification itself is a human policy decision, made once, reviewed periodically and owned by name. That is still a person owning the release: they have simply decided in advance which releases may decide themselves.
Next: Part 3, From work item to release decision: the minimum traceability metadata. All parts are on the series page.
How CloudNala can help
We help teams decide where AI should sit in their test and release process: which activities an agent can own, how its output is reviewed, how exceptions are recorded and how the release record distinguishes agent work from human decisions. The outcome is a release workflow that uses AI for speed without leaving accountability ambiguous.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Release Evidence Review or write to us at consult@cloudnala.co.za