Most South African government departments have already been through at least one round of digitisation. The forms moved onto a portal, the files moved into a document system and the approvals moved into email. In many cases the citizen still waits as long as before, because the process kept every step it had on paper and added a login.
AI-native government creates a new version of the same temptation. It is now easy to put an AI assistant beside each step of the old process: one to read the uploaded documents, one to summarise the file for the supervisor, one to draft the letter. Each looks like progress, and each makes an unexamined step a little faster. The process as a whole stays the same shape, and some of its failure modes become harder to see, because the AI makes them look tidy.
We covered the general version of this problem for enterprises in Digitalisation is not moving a broken process onto a screen. This part applies it to administrative decisions, where a step often exists because a law, a delegation or an old audit finding once required it, and where removing a step needs a reason that will survive an auditor or a court.
Why government processes accumulate steps
Administrative processes grow by addition. A fraud case leads to a second signature. An audit finding leads to a checklist. A new regulation leads to a new form, and nobody removes the old one because nobody is sure it is no longer needed. Over a decade, the process becomes a record of every problem the organisation has ever had.
Three kinds of step dominate most licensing and permit processes:
- Paper-era steps that exist because information once travelled on paper: collecting a form at an office, re-capturing it into a system, certifying copies of documents the state already holds.
- Coordination steps that exist because data sits in another department or sphere of government: asking the applicant to fetch a zoning letter from the municipality, or a tax clearance from another system.
- Authority steps that exist because someone must take the legal decision: assessing whether conditions are met, deciding, and giving reasons.
Only the third kind carries public authority. The first two are overhead. Digitisation programmes often automate all three at the same level of enthusiasm, and AI programmes are now repeating that pattern.
The step-treatment test
Before the Thukela Provincial Licensing Authority, a fictional provincial body that issues liquor trading licences and event permits, adds any AI to its licence-renewal process, it runs every step through one question: why does this step exist? The answer decides one of five treatments.
| Treatment | When it applies | Example |
|---|---|---|
| Remove | The step exists only because the process was once on paper or a control was never retired | Re-capturing a paper form |
| Merge | The state already holds the information; fetch it once instead of asking the citizen | Zoning confirmation from the municipality |
| Automate | The step applies a precise rule with no discretion | Fee paid, required documents present |
| AI-assist | The step needs judgement, and AI can prepare evidence or a recommendation for an official | Assessing whether the premises meet licence conditions |
| Keep human, rethink scope | The step carries authority or risk that must stay with a named person | Supervisor sign-off, but only for high-risk renewals |
The order matters. Removing and merging come before automating, because automating a step that should not exist makes it permanent. AI assistance comes last, and only for steps where judgement is genuinely required.
Two rules keep the test honest. First, a step cannot be removed on the say-so of the project team. Someone with authority over the underlying requirement, usually the rule owner or the delegating official, must confirm that the step is no longer needed and record why. Second, "AI-assist" is not a treatment for a step whose rule is vague. If officials apply a condition inconsistently today, an AI assistant will learn the inconsistency. That step goes back to the rule owner first, which is the subject of From PDF policy to executable government.
The delegation question nobody asks
The most persistent government steps are sign-offs. Thukela's process required a supervisor to sign every licence renewal, including routine renewals for licence holders with clean records. When the project team asked why, the answer was a delegation of authority written fifteen years earlier, when applications were fewer and entirely paper-based.
AI makes this question urgent in two directions. If AI assistance makes the officer's assessment faster, a blanket second signature becomes the bottleneck, and the pressure grows to sign without reading. That is the worst outcome: the signature still exists, and it now certifies nothing. In the other direction, teams sometimes propose letting the system approve routine cases outright. That may be possible for some decisions, but it changes who exercises public authority, and it needs a deliberate legal and policy decision, not a configuration change.
The practical answer is to treat the delegation as part of the redesign. Review who holds which authority, for which class of case, under which instrument. Concentrate senior review where the risk is, and make sure every decision still has a named official who could explain it. Human-in-the-loop is not administrative justice covers what that official needs to make the review real.
Measure the citizen's outcome, not the portal
Digitisation projects often report the wrong numbers: forms submitted online, documents uploaded, users registered. None of these tell you whether the service improved.
For an administrative process, the measure that matters is working days to a lawful, reasoned decision, together with the rate at which decisions are overturned on appeal or review. If the first falls and the second does not rise, the redesign is working. If the first falls and the second rises, the process has been made faster at producing wrong decisions.
In Thukela's illustrative redesign, removing the paper-era steps and fetching the zoning confirmation directly took more time out of the process than any AI component. The AI assistant, which prepares an evidence summary of each premises' compliance with licence conditions for the officer, mattered, but it was the fourth-largest improvement, not the first. That pattern is common in process redesign: the biggest gains usually come from steps that disappear, not from steps that are accelerated.
Where AI genuinely belongs in the redesigned process
Once the process has been cut back to the steps that carry authority or real judgement, AI has three useful roles:
- Preparing the evidence. Pulling the relevant records, the applicable rule version and prior decisions for similar cases into one view, so the official spends time on judgement rather than searching.
- Checking against the rule. Flagging where an application appears not to meet a machine-readable condition, with the rule reference attached, so the official can confirm or override.
- Drafting the reasons. Producing a draft decision notice that cites the rule and the evidence, which the official edits and signs.
In each role the official decides, and the system records what the official saw. That is the pattern the series has argued for since What an AI-native government actually means: AI participates in the work, while authority and accountability stay with people.
Signs a programme is digitising rather than transforming
- The project plan starts with a platform or model choice, and the process map comes later.
- No step has been removed, only automated.
- Citizens still supply information that another government body already holds.
- Every case receives the same level of review regardless of risk.
- The success measures are counts of online transactions, not time to decision or appeal outcomes.
- Nobody can name the official who decided to retire a control, because no control has been retired.
If three or more of these are true, pause the AI work and run the step-treatment test first. The process map is usually fiction explains how to find out what the process actually does before redesigning it, and Public-sector digital services are not websites covers the service model the redesign should serve.
Next: Part 7, Procurement is the first test of AI-native government. All parts are on the series page.
How CloudNala can help
CloudNala runs process redesign sprints for public-sector services before any AI is introduced. We observe how the process works today, run each step through a treatment test with the officials who own the rules and delegations, measure the current time to decision, and produce a redesigned process with a clear, limited role for automation and AI assistance. We work with your legal and governance teams on any change to delegations or controls, and the output is a process and evidence plan you can take into procurement.
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.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za