Start with the eight conditions
POPIA is organised around eight conditions for lawful processing: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation. Each condition has an operational cost. In a legacy PMS those costs are absorbed by policy documents no one reads. In an AI-native system, they need to be built into the software.
A registered Information Officer with real authority
ProClinic operates with a registered POPIA Information Officer (Reg 2026-011081). This is not a job title on a compliance slide. The Information Officer has a veto on new agent capabilities that would change the processing profile — new data sources, new cross-border transfers, new automated decision-making. That veto is coded into our release process, not just written into a policy.
Purpose specification, at the agent level
Every agent in the ProClinic stack has a documented processing purpose. The prescription agent processes patient records to draft prescriptions and check for allergies and interactions. It does not, and cannot, use the same records to draft a marketing message. The purpose is not a suggestion — it is enforced by the tool-calling contract the agent is bound to.
Data residency by construction
Patient data lives on AWS. Cross-border transfer is disabled by default; enabling it for a specific purpose requires explicit clinician consent and is logged. This is not achieved by a firewall rule that a future engineer might change. It is achieved by the architecture — the data plane never leaves the region unless the control plane records a signed consent event.
Model access without model retention
ProClinic uses an OpenAI-compatible gateway to route agent calls. Every call is configured for no-retention operation with the underlying model provider. Prompts and completions are not used for model training. This is the default, not an option — and it is verified in every pre-release audit.
Consent and the audit trail
The eighth condition — data subject participation — is often the hardest to operationalise. Patients have a right to know what is held about them, how it is used, and to correct or delete it. ProClinic exposes these workflows in the practice UI. A subject-access request is a click; a correction is a signed edit with an audit entry; a deletion is a purge that is logged and reversible for the retention period.
Human approval is a POPIA lever, not just a clinical one
Every clinical, patient-facing, and financial output in ProClinic waits for clinician approval. The approval gate is a clinical safeguard, but it is also a POPIA safeguard. Automated decision-making with legal or similarly significant effects on the data subject is not permitted without a lawful basis and without the subject's right to human review. ProClinic's three-gate architecture removes that concern by construction — a human clinician signs everything before it affects the patient.
The practical takeaway
Compliance is easier to build in than to bolt on. If the architecture assumes that data can be exfiltrated, that agents can wander outside their processing purpose, or that models can be used for training with patient content — the compliance job is a firefight. If the architecture assumes the opposite from day one, the compliance job is auditing that the constraints are still holding.
ProClinic was designed with the latter in mind. That is what “POPIA-aligned” means to us — not a badge on the footer, but the shape of the system.
ProClinic AI · Field notes from the operating room of dental practice.