The previous articles gave you a way to think. This one shows the thinking applied, because in my experience the frameworks only land once someone sees three worked cases side by side.
These are composite illustrations, not accounts of specific clients. The patterns are real; the organisations are not.
The 30-person professional services firm
What they wanted. Their team spent hours a week on proposals, marketing copy and rewriting technical material for non-technical clients. They wanted an AI assistant to speed that up.
The nervous conversation. A director had read about POPIA fines and asked whether they needed a South African data centre before they could start. The answer would have been a five-figure consulting exercise and a six-month delay.
What the trace showed. Every one of the intended tasks operated on the firm's own material — service descriptions, public case studies, draft copy, technical explanations. No client names, no personal information. The one exception was proposal covering letters, where a client contact's name appeared.
What they did. They started immediately with a standard commercial assistant on a business plan, for everything except the covering letters. For those, they adopted a simple rule: write the letter with a placeholder, insert the real name afterwards.
Time from question to working: about a week, most of which was training people on the placeholder habit.
The lesson is not "small firms can ignore POPIA". It is that the classification exercise revealed that almost none of their use cases engaged it. Six months of paralysis was avoided by an afternoon of sorting.
The medical practice
What they wanted. Clinicians were spending evenings writing up consultation notes. They wanted help summarising and structuring them.
Why this is different. Health information is special personal information under section 26. The starting posture is a prohibition with specific exceptions, not a permission with conditions. This is genuinely the hard tier.
What the trace showed. The proposed design would have sent full consultation notes — name, date of birth, presenting complaint, history — to an overseas service. Every row of the trace from step four onward involved special personal information leaving the country.
What they did. They did not abandon it, and they did not build a data centre. They changed step four.
The design was reworked so that identifying details never enter the bundle. The clinician's notes are stripped of name, date of birth and identifying numbers before anything is sent; the AI works on the clinical text alone and returns a structured summary; the practice's own system re-attaches the identity locally. The AI never learns whose notes these are.
They also took legal advice before building, not after. That advice shaped the design rather than judging it.
What made it work: recognising that "can we use AI on patient notes" and "must patient identities leave the country" are two different questions. The answer to the first was yes. The answer to the second was no — and they were separable.
The public-sector service
What they wanted. A citizen-facing assistant to answer status queries about applications, reducing pressure on an overwhelmed call centre.
Why this is different again. Two layers apply on top of POPIA. The organisation processes government data, so the National Data and Cloud Policy is in scope. And the service is public-facing, so every answer is attributable to the state.
What the trace showed. Steps one through four and seven and eight could all be kept in-country without difficulty. Step five — the model — was the constraint, and the available in-country options were narrower and more expensive than the global ones, exactly as the technical article in this series describes.
What they did. Three things.
They kept everything they could in the country: the application, the database, the retrieval, the logs and the audit trail.
They minimised what left. The assistant answers status questions using a reference number and a status code, not a name and a full application record. The bundle sent onward contains far less personal information than the first design would have.
They wrote it down. A short, dated record of what data moves, where it goes, which route under section 72 applies, where that is contractually stated, and who approved it — reviewed on a set date rather than "periodically".
The cost of the constraint was real, and it went into the business case as its own line, visible to the people approving it, rather than surfacing later as an overrun.
What actually decided each case
Look at the middle column. In every case a single, checkable fact about the data determined the answer. Not a view about whether AI is trustworthy. Not a vendor's marketing. Not the general anxiety level of the executive team.
And notice what none of the three deciding facts is: a fact about artificial intelligence. They are facts about information — what kind it is, whose rules attach to it, and what would happen if it moved. That is why the classification exercise in article three is worth more than any amount of technology comparison.
The pattern across all three
Three different organisations, three different answers, one consistent method.
They classified the data before choosing the tool. In each case that step alone resolved most of the uncertainty.
They separated the questions. "Can we use AI here?" is unanswerable. "Must this specific field leave the country?" has an answer.
They redesigned rather than abandoned. Two of the three changed what gets sent instead of changing whether to proceed. That is the most under-used move available, and it is nearly always cheaper than either giving up or building sovereign infrastructure.
They wrote it down. Which is the subject of the final article.
What to take from this article
There is no organisational answer to "can we use AI", only per-use-case answers. A blanket yes or a blanket no is wrong in one direction or the other.
Minimising what you send is usually cheaper than relocating where it goes. Ask what the smallest bundle is that still produces a good answer.
Special personal information changes the starting posture, not the possibility. Get advice early enough that it shapes the design.
Public-sector obligations stack on top of POPIA. Find out which apply to you before designing, not during.
Composite illustrations for teaching purposes, not accounts of specific engagements. Plain-language explainer, not legal advice — your legal and privacy people make the determination.
How CloudNala can help
The most common thing we change on a project like these is step four: what actually goes into the bundle. Teams reach for the full record because it is easier, and then inherit a residency problem they did not need to have. Trimming it usually improves the privacy position and the running cost at once, which makes it an unusually easy recommendation to get approved.
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 an AI Readiness Workshop or write to us at consult@cloudnala.co.za