Architecture
Reference architectures for private, governable AI
Three patterns that hold up under the Cyber and Data Protection Act, the Reserve Bank's third-party and emerging-technology requirements, and Zimbabwe's bandwidth and power realities. Each diagram is original and shows where the controls live.
01 · Five principles
- 01
One door for models
Every model call, internal or external, passes through a gateway you operate. That is where identity, policy, personal-data filtering, logging and cost accounting live. Applications never hold a vendor API key.
- 02
Access control at retrieval, not in the prompt
A model cannot be trusted to enforce who may see what. Retrieval is filtered by the requesting identity's entitlements before any document reaches the model. The prompt never sees a record the user could not open in the source system.
- 03
Personal data classified before it moves
Section 28 of the Act and SI 155 s.10(2)(c) make cross-border transfer a decision, not a side effect. Classify data at ingestion; route personal and sensitive data to in-country or in-adequacy models only; redact or tokenise before anything else leaves.
- 04
Agents act through gates
Anything that writes to a system of record goes through a tool gateway with an allow-list, a per-action approval policy and an audit record. Read paths and write paths are separate adapters.
- 05
Design for the outage and the link
Zimbabwe's used incoming international bandwidth was 545,123 Mbps in Q3 2025 across the whole country, and ZESA was still targeting the end of load shedding for December 2026. Anything a branch, plant or mine needs at 02:00 must run locally, degrade gracefully and reconcile later.
02 · Private AI gateway
The gateway is a small service, not a platform purchase: an authenticating reverse proxy with a classifier, a policy table and a log sink. The classifier does not need to be a large model; a rules-plus-NER pass that flags national ID numbers, account numbers, phone numbers, names and health or biometric terms is enough to route correctly. The policy table is where the Act becomes code: "class = personal → allowed_models = in-country" is a single row. The log is what lets the DPO answer an access request under s.14 and what evidences "ongoing monitoring and testing of AI models" under RBZ PS 01-2024 para 7.2.8.
03 · Retrieval over internal data, with access control enforced at retrieval
Two Zimbabwean specifics. First, embedding is a transfer: if you compute embeddings with a hosted API, every chunk of every policy and contract has left the country. Open-weight embedding models run comfortably on a single server, so there is no reason to do that. Second, the index is a "critical database" in the ordinary sense of the Act's definitions and holds copies of whatever you ingested; it needs the same retention, access and breach controls as the source systems, and it must be included in the processing you have notified to the Authority (SI 155 s.10(2)(a)).
04 · Agent platform with approval gates before core systems
The pattern deliberately separates three things vendors often bundle: the runtime that plans, the gateway that permits, and the adapters that touch systems. The gateway is yours. Its allow-list is short, its policy table is reviewable by internal audit, and its audit record is the evidence the RBZ Guideline asks institutions to maintain for "risk assessments, approvals, vendor due diligence, and technology audit trails" (para 6.4(c)). For control patterns in more depth see enterprise agent patterns.
05 · Integrating with core banking, ERP and SCADA
| System | Read path | Write path | Data classes | Notes |
|---|---|---|---|---|
| Core banking | Read replica or API with row-level entitlements | Propose only, or approved action types through the bank's own API under the approver's identity | Personal, financial | Prior written RBZ approval before a new technology platform or significant ICT change (Guideline 6.4); model register entry (PS 02-2023) |
| ERP / finance | Reporting views | Propose; approved journal or PO types through workflow | Commercial, some personal (payroll, suppliers) | Segregation of duties must survive: the agent may not both raise and approve |
| CRM / contact centre | Case and interaction history, ACL-filtered | Drafts and case notes; customer-facing sends after approval or under a tested policy | Personal, sometimes sensitive | s.25 applies if the system decides outcomes for customers |
| SCADA / plant historian | One-way historian tap or OPC-UA read-only | None | Operational; usually non-personal | Decisions surface as recommendations to control-room staff; see the mining briefing |
| Document and email stores | ACL-copied retrieval | Drafts only | Mixed | Index is a copy: same retention and breach obligations as the source |
06 · Component choices that survive here
Prefer components you can run on two mid-range servers in a Zimbabwean colocation facility: an open-weight LLM in the 7–70 billion parameter class, an open-weight embedding model, a vector index inside your existing database engine, and a gateway you can read the source of. Use hosted frontier models through the gateway for non-personal classes where quality justifies the forex cost, with a budget cap. For the choice between open and hosted models, on-premises and regional cloud, and the cost model, see model strategy; for the threat model behind these diagrams see security; for where data may legally sit see the data residency briefing.
Sources
- Data Protection Act, Act 5 of 2021 (Cyber and Data Protection Act [Chapter 12:07]) — s.14, s.18, s.25, s.28–29
- SI 155 of 2024 — s.10(2)(a), s.10(2)(c)
- RBZ Cybersecurity and Resilience Guideline (August 2025) — paras 5.12–5.14, 6.3, 6.4
- RBZ Prudential Standard No. 01-2024/BSD — para 7.2.8
- POTRAZ Q3 2025 abridged sector performance report, via Techzim (19 December 2025) — international bandwidth
- New Zimbabwe via allAfrica (11 May 2026) — ZESA load-shedding statement