The word "citizen" has been doing double duty in this series. In the delivery model it means a non-engineer who builds software. In public service it means the person a department exists to serve. Both meanings apply here, and the second one raises the stakes on everything the series has argued so far.
When a private company deploys a tool that produces a wrong answer, it costs money and possibly a customer. When a department does it, the person on the other end may have no alternative provider, limited ability to challenge the outcome, and a legal entitlement to the service. That asymmetry is the reason public-sector AI needs to be more careful, and — awkwardly — it is also the reason public-sector AI is often more valuable, because the workflows are frequently the ones where delay does the most harm.
The middle band is what is usually missing
Look at that diagram again, specifically at the second row. Every step in a public service has somebody who answers for it, or should.
A striking number of the workflows we encounter cannot fill that row in. Requests arrive and are classified by rules nobody currently owns. They are routed by a table last updated by someone who left. They sit in a queue that is nobody's specific responsibility to watch. And a status is eventually reported by an official who is reconstructing what happened from incomplete records.
Adding AI to that workflow does not make it accountable. It makes it faster at producing outcomes nobody will answer for, which is a worse position than the one you started in — because now the department has also lost the ability to say a person looked at this.
This is the first governance question for any public-sector AI project, and it is not a technology question: for each step in this service, who answers for it? If several steps come back blank, that is the project. The AI can wait.
Where AI genuinely helps
None of that is an argument against using AI in public service. It is an argument about sequencing. There are several places where it earns its cost immediately, and they cluster at the edges of the workflow rather than in the middle.
Intake. Turning what a person actually wrote — often in a hurry, often in their second or third language, often missing the reference number — into a structured, complete, correctly classified case. This is the highest-value application in public service and it is almost never the one that gets demonstrated, because it is invisible.
Language. South Africa has eleven official languages and most services operate in one or two. A system that lets someone report a problem in the language they think in, and lets an official read it in the language they work in, removes a barrier that policy has been trying to remove for thirty years.
Simplification. Turning a regulation into something a person can act on, and turning a citizen's account of a problem into a summary an official can triage in fifteen seconds.
Completeness checking. Telling someone what is missing from their application before they submit it, rather than three weeks later. The volume of avoidable rework in public service caused by incomplete submissions is enormous, and this addresses it directly.
Notice that in all four, the AI is assisting a transaction that a person still owns. None of them involve the system deciding an outcome.
The order that keeps going wrong
The top lane is the one that gets funded, because it demonstrates well. A chatbot on the department's website is visible, photographs nicely, and can be launched in weeks.
Then it meets the actual conditions. It cannot see the case management system, so it cannot tell anyone the status of their own application. It answers policy questions accurately but cannot do anything. Citizens use it, get a good answer, and then join the same queue as before — at which point the department has spent a budget to make its unresponsiveness more efficiently communicated.
The bottom lane is unglamorous and works. Fix the routing and the service standard first. Make status visible, even if the mechanism is crude. Then add AI at the intake step, where it removes real friction. Then, once cases genuinely close faster, add the conversational front door — which now has something true to say.
The chatbot is not the mistake. It appears in both lanes. Starting with it is the mistake.
What has to be governed
For a citizen-facing AI system, the governance list is specific and mostly non-negotiable.
Personal information. What is collected, on what basis, where it is stored, how long it is kept, and whether any of it reaches a third-party model provider. Under POPIA this is not advisory. Our piece on POPIA, data and AI strategy goes into the detail.
Escalation. Which categories always reach a human immediately — safety, health, anything involving a child, anything where the citizen indicates distress. These should be enforced in the routing rules, not left to a model's judgement about tone.
No invented answers. A commercial assistant that improvises is embarrassing. A department's assistant that invents a policy has told a citizen something about their rights that is untrue. The system must be able to say it does not know and route the question onward, and that behaviour has to be tested deliberately, not assumed.
An audit trail. What the citizen said, what the system classified it as, where it went, who acted, what was decided, when. This is what makes oversight possible, and oversight is not optional in public administration.
Accessibility and bandwidth. A service that requires a modern browser and a good connection has excluded a substantial part of the population it serves. This is a design constraint from the first sprint, not a remediation item.
Human decision on consequence. Anything affecting a person's money, rights, or access to a service is decided by a person. The AI prepares; it does not determine. We have made this argument at more length in public-sector AI workflows and in why public digital services are not websites.
A realistic first project
If a department wants a defensible starting point, we would suggest this shape: pick one service with high volume and clear rules. Fix its routing and publish its service standard. Add AI-assisted intake — capture, classify, check completeness, translate. Keep every decision with an official. Log everything. Report monthly on cases closed within standard.
That project is unremarkable in a press release and produces two things a chatbot does not: citizens who get answers faster, and a department that can prove it. The second one is what makes the next project fundable.
How CloudNala can help
Our public-sector work almost always starts with the workflow and the accountability rather than the model — mapping the service as it actually runs, identifying which steps have owners and which do not, and finding the one or two points where AI removes genuine friction without moving a decision away from a person. From there it is ordinary delivery discipline: data rules that satisfy POPIA, escalation paths that are enforced rather than requested, an audit trail that survives an oversight committee, and a service that works on a low-end phone.
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