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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Private AI gateway reference architectureUsers and applications call one internal AI gateway. The gateway authenticates with the identity provider, applies policy, classifies and redacts personal data, logs every request, then routes to either an in-country model or a regional or global hosted model. Personal and sensitive data may only route in-country or to an adequate jurisdiction. All logs feed monitoring and the model register. Staff, branches,customer channels Internal applications(core, CRM, ERP, agents) Identity provider(SSO, groups, entitlements) AI GATEWAY (you operate this) 1 Authenticate · authorise by role 2 Classify data · redact or tokenise PII 3 Policy: which model may see this class 4 Prompt-injection and output filters 5 Log prompt, identity, model, cost, output hash Vendor keys held here only In-country modelsOwn servers or Zimbabwe colocationOpen-weight LLMs, embeddings, visionPersonal and sensitive data allowed Regional or global hosted modelsCape Town / Johannesburg regions, or global APIsFrontier models, burst capacityOnly after s.28 adequacy or s.29 basis + redaction Monitoring · model register · audit storeDrift, quality, cost; 24 h / 3 h incident paths Dashed boundary = the only place vendor credentials, policy and logs exist. Applications talk to the gateway, never to a vendor.
Figure 1. Private AI gateway. Every call is authenticated, classified, policy-routed and logged before a model sees it. Personal data stays with in-country models unless a s.28/29 basis exists and the data is redacted.

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

Retrieval-augmented generation with entitlement filteringInternal sources such as policies, contracts, tickets and core-system extracts are ingested through a classifier that tags each chunk with data class and an access control list. Chunks are stored in an index inside Zimbabwe. At query time, the user's identity resolves entitlements; the retriever returns only chunks the user may see; the gateway assembles a prompt with citations and calls a model; the answer is returned with citations and the retrieval is logged. INGESTION (batch) SourcesPolicies · contracts · ticketsCore / ERP extracts · manuals Classify and chunkdata class · owner · retentionACL copied from source system Embed (in-country)Open-weight embedding modelNo text leaves Zimbabwe Index + metadata storechunk · vector · class · ACL · source idHosted in Zimbabwe QUERY (per request) Useridentity + entitlements Retrieverfilter: ACL ∋ user AND class allowedthen rank Gateway assembles promptsystem rules + cited chunks+ injection screen on chunks Modelin-country by default;hosted only for non-personal classes Answer with citations to source idsRetrieval log: user · chunks returned · model · output hash (audit trail, s.14 requests) The model never decides who may see a document. The retriever does, using the ACL copied from the system that owns the record.
Figure 2. Retrieval over internal data. Access control lists travel with each chunk at ingestion and are enforced by the retriever, so the prompt only ever contains records the requesting identity is entitled to open.

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

Enterprise agent platform with tool gateway and approval gatesAn agent runtime plans and calls tools only through a tool gateway. The gateway holds an allow-list of tools per agent, checks each action against a policy that classifies it as read, propose or write, routes write actions to a human approval queue, and records every call. Read adapters connect to core banking, ERP, CRM and a SCADA historian in read-only mode. Write adapters exist only for approved action types and go through the system's own API with the approving user's identity. Triggerticket · message · schedule· event from a system Agent runtimeplans · calls model via AI gatewayholds no credentialsbounded steps and budgetCategory explainers: aiagent.co.zw TOOL GATEWAY Allow-list of tools per agent Classify action: read · propose · write Argument validation and limits Write → human approval queue Audit record per call Core bankingread adapter · write via own API ERP / CRMread adapter · approved writes only SCADA historianread-only tap · no write path Document / knowledge indexACL-filtered retrieval Approver (human)sees proposed action + evidenceapproves under own identity Outcome to requesterwith the audit reference A SCADA or plant historian is read through a one-way tap. No agent, and no model, holds a write path to control systems.
Figure 3. Agent platform. The runtime reasons; the tool gateway decides. Writes to systems of record are proposed by the agent and executed only after a named human approves under their own identity, which is what makes s.25 and the RBZ prior-approval requirement satisfiable.

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

Integration posture by system class. "Propose" means the agent drafts an action that a human executes.
SystemRead pathWrite pathData classesNotes
Core bankingRead replica or API with row-level entitlementsPropose only, or approved action types through the bank's own API under the approver's identityPersonal, financialPrior written RBZ approval before a new technology platform or significant ICT change (Guideline 6.4); model register entry (PS 02-2023)
ERP / financeReporting viewsPropose; approved journal or PO types through workflowCommercial, some personal (payroll, suppliers)Segregation of duties must survive: the agent may not both raise and approve
CRM / contact centreCase and interaction history, ACL-filteredDrafts and case notes; customer-facing sends after approval or under a tested policyPersonal, sometimes sensitives.25 applies if the system decides outcomes for customers
SCADA / plant historianOne-way historian tap or OPC-UA read-onlyNoneOperational; usually non-personalDecisions surface as recommendations to control-room staff; see the mining briefing
Document and email storesACL-copied retrievalDrafts onlyMixedIndex 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

  1. Data Protection Act, Act 5 of 2021 (Cyber and Data Protection Act [Chapter 12:07]) — s.14, s.18, s.25, s.28–29
  2. SI 155 of 2024 — s.10(2)(a), s.10(2)(c)
  3. RBZ Cybersecurity and Resilience Guideline (August 2025) — paras 5.12–5.14, 6.3, 6.4
  4. RBZ Prudential Standard No. 01-2024/BSD — para 7.2.8
  5. POTRAZ Q3 2025 abridged sector performance report, via Techzim (19 December 2025) — international bandwidth
  6. New Zimbabwe via allAfrica (11 May 2026) — ZESA load-shedding statement