Everything in this series so far has been background. This article is the actual exercise, and it is the one I would do first if I could only do one thing.
Take a single, specific, real interaction. One person, asking one question, of one service you run or are planning. Then follow it, stage by stage, and write down where each stage happens.
That is it. No tooling, no framework, no assessment template. A whiteboard and the right people in the room for ninety minutes.
Why this beats a policy document
Most organisations approach AI governance by writing a policy. The policy says sensible things about protecting personal information and complying with POPIA, everyone signs it, and it changes nothing — because it operates at a level of abstraction where nothing can be checked.
Tracing one real interaction does the opposite. It forces every abstraction to resolve into a specific answer, and it surfaces the things nobody knew. In my experience the most valuable outputs are never the boxes people fill in confidently. They are the two or three where the room goes quiet.
The trace
Here is a worked example: a member of the public asking a service about the status of an application they submitted.
Walk through what each row actually means.
1. The question. Someone types it on their own phone. Already interesting: what have you told them about how it will be handled? Is there a notice, and does it match what actually happens?
2. Your front door. Your website or app receives it. This is your infrastructure, in a region you chose. Usually the easiest row to answer.
3. The lookup. To answer usefully, the service fetches their record — application number, status, dates, maybe the name of the office handling it. This is your database. Also usually straightforward.
4. The package. Here is the row that surprises people. The question and the retrieved record are bundled together into a single block of text before being sent onward. That bundle now contains personal information that the person did not type. They asked "what's happening with my application" — and what gets sent includes their record.
Almost nobody pictures this step, and it is the step where the amount of personal information leaving your systems is decided. It is also, happily, the step you have the most control over: you choose what goes into the bundle.
5. The thinking. The bundle goes to the model. This is the box from the first article, and this is the row where the country most often changes.
6. The safety check. Most services screen text for harmful content, going in and coming back. That screening is itself processing, often in the same place as the model, sometimes elsewhere. It is routinely forgotten in residency assessments because nobody thinks of it as a separate thing.
7. The answer. Back to the person's screen.
8. The record. Logs of what happened, kept so that somebody can reconstruct it later. Where do they live, who can read them, and how long are they kept? Note that logs of an AI conversation contain the conversation — which means your log retention policy is now a personal information retention policy.
The column that matters
The right-hand column is the entire exercise. For every row: which country, and how do you know?
"How do you know" is doing real work in that sentence. Acceptable answers are a contract clause, a configuration setting someone can show you on screen, or a provider documentation page. Not acceptable: "I assume so", "it's in our tenant", or "the supplier said it's fine".
Do not be discouraged if you cannot fill in every row on the first pass. Nobody can. The blanks are the output — each one is a specific, answerable question with a specific person who can answer it. That is a dramatically better position than a vague sense that AI might be a problem.
Who is holding it, at each moment
There is a second way to read the same trace, and it is the one an auditor will use.
Notice how your degree of control degrades across those rows. The first two are genuinely yours. The third is governed by a contract and a configuration choice. The fourth — support staff at a provider who may access data during an investigation — is the one almost nobody asks about, and the one that most often appears in an audit finding.
That last row is not sinister. Every serious provider has a documented access process with approvals and logging, and you can ask for it. The failure is not that the process exists; it is that most organisations have never read it.
What the exercise typically finds
Across the times I have run this, the same handful of things surface.
The bundle is bigger than anyone realised. Step four is sending far more personal information than the use case needs, usually because it was easier to attach the whole record than to select fields. This is nearly always fixable in an afternoon, and it shrinks both the privacy exposure and the running cost at the same time.
Logs were never considered. The conversation is being retained somewhere nobody has classified, sometimes for far longer than the underlying records themselves.
The safety check is a separate service. In a different place, under different terms, that nobody had assessed.
Failover was never asked about. The service normally runs where you think. What happens when that region is unavailable is in the documentation, and nobody has read it.
Nobody owns the answer. Everyone assumed someone else had checked.
None of these are disasters. All of them are cheaper to find on a whiteboard than in an audit.
Do it before you need it
The best time to run this trace is while the service is still being designed, because every finding is then a design decision rather than a change request.
The second best time is now, for a service you already run. It is uncomfortable to discover that a live service has an unanswered row. It is considerably more uncomfortable to discover it because a data subject has asked, or because a regulator has.
What to take from this article
One real interaction beats a policy document. Trace it end to end.
Eight rows, one question each: which country, and how do you know?
The blanks are the finding. They are not failures; they are your next set of questions, each with an owner.
Step four — the bundle — is where the volume of personal information leaving your systems is decided, and it is the step you control most cheaply.
Plain-language explainer, not legal advice. This trace is what you hand to your privacy and legal people so they can make a determination on facts.
For the technical companion to this — how to verify a provider's regional claims, deployment types and inference routing — see AI models available in South Africa: what "available" really means.
How CloudNala can help
We facilitate this trace, and the reason it helps to have an outsider run it is unglamorous: an outsider is allowed to keep asking "how do you know?" without it sounding like an accusation. The output is a single annotated diagram plus a short list of open questions with named owners — which is exactly what a privacy officer needs and almost never gets.
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