This page is the single public statement of how AOLC runs client workloads — across Managed IT, Cloud & Security, Managed AI, Sovereign AI, and the platforms we build in-house. It is written to be readable by procurement, legal, and compliance teams. Deeper technical detail, sub-processor lists, and pen-test summaries are available under NDA.
Where data sits is not a marketing question — it is an architectural one.
| Topic | Commitment |
|---|---|
| AOLC-hosted workloads | All storage and inference for client workloads that we host (including Sovereign AI by AOLC) runs on South-African-domiciled infrastructure in Johannesburg. |
| Cross-border transfer | None for Sovereign AI workloads. For other services where you choose a global platform (e.g. Microsoft 365, Azure, CodeTwo), data may transit internationally — we disclose this before deployment and never as an afterthought. |
| Foreign AI APIs on client data path | For Sovereign AI: zero. No Anthropic, no OpenAI, no Gemini, no Bedrock on the data path. For other AOLC services that use foreign AI providers, we name them in scoping and in the contract. |
| Model training | Client content is never used to train any commercial or foreign model. Open-weights models are invoked for inference only — weights are not updated using client data. |
| Topic | Commitment |
|---|---|
| Encryption in transit | TLS 1.3 on all client-to-AOLC traffic. Certificate pinning available on request for high-assurance engagements. |
| Encryption at rest | AES-256 on all AOLC-managed volumes, including orchestration VPSs and GPU working storage. Customer-held-key (BYOK) option available for production Sovereign AI engagements. |
| Network isolation | Client workloads sit in dedicated network segments. Egress is whitelisted to named destinations. No public SSH anywhere in the stack. |
| VPN & private networking | Secure VPN tunnels available for point-to-point connectivity between client sites and AOLC infrastructure. Private networking between AOLC orchestration and compute where the architecture permits. |
| Hardening | OS hardening to the CIS Level 1 baseline. Host firewall enabled. No default passwords. Automated patching with monthly review. |
| Topic | Commitment |
|---|---|
| Authentication (AOLC side) | SSH key + MFA for all administrative access. Role-based access control; no shared credentials. |
| Authentication (client side) | Integration with client SSO / Entra ID available for client-facing surfaces. Staff and portal interfaces enforce MFA where required. |
| Least privilege | Only the named AOLC engineers listed in the engagement brief have access to client data. The access list is shared with the client and reviewed at each engagement milestone. |
| Audit logging | Immutable, append-only log of every privileged action, every inference call (Sovereign AI), and every data movement. Exportable to the client on request. |
| Session management | Idle timeouts, silent token refresh, auto-logout, and global 401 handling are built into every AOLC platform. Tokens expire; no stale sessions. |
AOLC operates under section 20 of the Protection of Personal Information Act, 2013, when processing client personal information.
| Topic | Commitment |
|---|---|
| Roles | The client is Responsible Party and determines purpose and means of processing. AOLC is Operator, processing only on the client's documented instructions. |
| Purpose limitation | Processing is limited to the purposes set out in the signed engagement brief. Scope creep requires written change request. |
| Confidentiality | All AOLC personnel with access to client data are bound by written confidentiality undertakings enforceable beyond the end of the engagement. |
| Breach notification | Security incidents involving personal information are notified to the client without undue delay, and in any case within 72 hours, with a root-cause report within 10 business days. AOLC assists the client in any required Information Regulator communication under s22. |
| Data-subject rights | AOLC assists the client in responding to access, correction and deletion requests received from data subjects. |
| Audit right | The client may audit AOLC's compliance with these terms on reasonable notice. AOLC cooperates in good faith and provides reasonable evidence of compliance. |
What procurement and internal IT teams can expect from us.
| Topic | Commitment |
|---|---|
| Vendor pack | For any engagement of material scope, AOLC provides a vendor onboarding pack covering scope, architecture, data handling, security posture, and operator terms — the document against which your vendor management function runs onboarding. |
| Insurance | Professional indemnity and public liability cover in force. Certificates available on request. |
| Accreditations | Microsoft Cloud Solution Provider (CSP). Westcon / Duxbury channel partner. B-BBEE Level 2 contributor (125% procurement recognition). |
| Penetration testing | Summary reports available on request for engagements where the scope warrants it. |
| Incident response | Named escalation path. SLA-driven response times. Documented resolution records and post-incident reviews for material incidents. |
| NDA | Mutual NDA signed before any client data, architectural detail, or sub-processor list is exchanged. |
Lock-in is not a commercial strategy. Every engagement is exit-ready.
| Topic | Commitment |
|---|---|
| Exit on notice | Engagements terminate on the notice period agreed in the master agreement. No forced extensions. |
| Data return | On termination, AOLC returns all client data — source material, derived metadata, transcripts, logs, and any models fine-tuned on client content — in open formats (JSON, CSV, original file containers). |
| Cryptographic erase | After return, all client data is cryptographically erased from AOLC systems within 30 days. A certificate of destruction is issued to the client. |
| Portability during engagement | Clients may request data export at any point during the engagement, in open formats, at no additional charge. |
| Backup destruction | Daily encrypted snapshots are destroyed together with primary data on engagement exit. No hidden retention. |
| Topic | Commitment |
|---|---|
| Engagement-specific list | Every engagement is accompanied by an engagement-specific sub-processor list naming every third party that may process client data. |
| Change of sub-processors | No new sub-processor is added to an engagement without the client's prior written consent. |
| Sovereign AI sub-processors | For Sovereign AI engagements, sub-processors are limited to South-African-domiciled infrastructure providers. No foreign AI API provider is ever a sub-processor on a Sovereign AI engagement. |
| Global services | For services that use global platforms (Microsoft 365, Azure, CodeTwo, etc.), the sub-processors are the respective platform operators and are disclosed in scoping. |
| Detailed list | The detailed, current sub-processor list is shared under NDA as part of the vendor onboarding pack for each engagement. |
For security, compliance, or vendor onboarding queries — not for general sales enquiries.
For security incidents potentially affecting an AOLC-managed system, use the same contact path and mark the subject line INCIDENT.
Direct answers, also encoded as FAQPage structured data so AI search engines and procurement reviewers can quote them accurately.
All AOLC-hosted client workloads, including Sovereign AI by AOLC, run on South-African-domiciled infrastructure in Johannesburg. There is no cross-border transfer of data on Sovereign AI engagements. For services that use global platforms (e.g. Microsoft 365, Azure, CodeTwo), data may transit internationally; AOLC discloses this in scoping and lists the platform operators as sub-processors in the engagement agreement.
AOLC enforces TLS 1.3 in transit on all client-to-AOLC traffic, with certificate pinning available on request for high-assurance engagements. Data at rest is encrypted using AES-256 on all AOLC-managed volumes, including orchestration servers and GPU working storage. Customer-held-key (BYOK) options are available for production Sovereign AI engagements.
AOLC operates as Operator under section 20 of the Protection of Personal Information Act, 2013, when processing personal information on behalf of clients. The client is the Responsible Party and determines the purpose and means of processing. AOLC processes personal information only on the client's documented instructions, implements appropriate technical and organisational safeguards, maintains confidentiality undertakings enforceable beyond the engagement end, and assists with data-subject access, correction, and deletion requests under POPIA.
Security incidents that may affect client data are reported in writing to the client without undue delay, and in any case within 72 hours of detection. A root-cause report is provided within 10 business days. AOLC assists the client in any required notification to the Information Regulator under POPIA section 22, and in any communication to affected data subjects.
Yes. Clients may audit AOLC's compliance with the operator terms on reasonable notice. AOLC cooperates in good faith and provides reasonable evidence of compliance, including access lists, audit logs, sub-processor records, and pen-test summaries where the engagement scope warrants it.
On termination, AOLC returns all client data — source material, derived metadata, transcripts, logs, and any fine-tuned model artefacts — in open formats (JSON, CSV, original file containers). All copies are then cryptographically erased from AOLC systems within 30 days. Daily encrypted backups are destroyed alongside the primary data. AOLC issues a certificate of destruction to the client. Engagements terminate on the notice period agreed in the master agreement; there is no lock-in.
Only the named AOLC engineers listed in the engagement brief have access to client data, on a least-privilege basis. The access list is shared with the client and reviewed at each engagement milestone. All administrative access requires SSH key plus multi-factor authentication. There are no shared credentials, and no public SSH endpoints anywhere in the stack.
Each engagement is accompanied by an engagement-specific sub-processor list naming every third party that may process client data. For Sovereign AI engagements, sub-processors are limited to South-African-domiciled infrastructure providers; no foreign AI API provider is ever a sub-processor on a Sovereign AI engagement. For services that use global platforms (Microsoft 365, Azure, CodeTwo), the sub-processors are the respective platform operators and are disclosed in scoping. The detailed, current sub-processor list is shared under NDA as part of the vendor onboarding pack.
How AOLC handles information collected via this website and in day-to-day business interactions.
Read →