SOC 2 is not POPIA.

When AI vendors are asked about data protection, many point to SOC 2, ISO certifications, security pages or enterprise privacy terms. Those documents can matter. They may show that the vendor has controls around security, availability, confidentiality or internal process. They may help a procurement team understand how the service is operated.

But SOC 2 is not POPIA. It is not a South African privacy analysis. It does not answer every question a responsible party needs to ask before staff send personal information into an AI tool. A secure vendor can still be the wrong route for a particular data set, purpose or workflow.

POPIA-aware AI adoption starts closer to home. What personal information is involved? Why is it being processed? Did the organisation collect it for a purpose compatible with this use? Who will access the prompt, the file, the output and the logs? Is the information leaving South Africa? If it is, has the organisation considered the legal and practical basis for that transfer? How will records be retained or deleted?

A vendor trust page rarely answers those questions in the context of your actual workflow. It cannot know whether your staff are uploading patient notes, client ID documents, payroll records, legal opinions, school reports, debt information or ordinary public marketing copy. Those are different risk profiles. They should not all be treated as the same AI use case.

This is especially important for smaller South African organisations because the buying process is often informal. Someone subscribes to a tool, invites the team, and the workflow spreads before anyone maps the data. By the time leadership asks questions, staff may already be using AI for summaries, proposals, complaints, internal notes and client communications.

The better approach is to separate the vendor question from the workflow question. First, understand the workflow. What does the person need AI to help with? What information is required for the answer? Can the task be done with anonymised or synthetic information? Does it require personal information at all? Could the sensitive part run locally while a public model handles only general language?

Then look at the vendor. What terms apply to your account type? Is data used for training? Where is it processed? What controls exist for retention, access, deletion and logging? Can the organisation configure stricter settings? Does the vendor give enough information for a South African team to make a careful decision?

SOC 2 may support that decision, but it should not replace it. The organisation still needs a clear rule for staff: this tool is approved for these types of work, with these data limits, under these review steps. Anything outside that route needs approval or a different implementation.

In practice, the safest AI systems are usually the most explainable ones. The team knows what data goes where. Managers know which tools are approved. Sensitive workflows have boundaries. Local models are used where they reduce unnecessary exposure. Public cloud tools are used deliberately, not by default. That is the difference between buying a compliant-looking tool and running a POPIA-aware operation.