Questions we are asked before an engagement starts.

Choose a decision that is made often, documented poorly and reviewed by someone senior. Frequency gives you enough examples to evaluate quality, poor documentation means the AI is adding structure rather than replacing judgment, and senior review gives you a human check while confidence is still being built.

Avoid the highest-value decision in the organisation for a first deployment. The scrutiny is disproportionate to the learning.

Avoid anything customer-facing until the internal control pattern has survived a quarter.

A first governed use case in production typically takes weeks rather than quarters, because the constraint is rarely the model. It is deciding which decision the AI supports, which data it may read, who owns the output and what happens when it is wrong. Once those four answers exist, deployment is engineering.

Organisations that stall usually started with a technology selection instead of a decision. The model choice is reversible; an undefined accountability boundary is not.

We sequence the first deployment so that the control pattern it establishes can be reused. The second use case should be materially faster than the first.

An agent that acts on business data needs the same controls as a junior employee with system access, expressed in software: a scoped identity, least-privilege permissions, an immutable action log, a spend and rate boundary, and a human approval gate on anything irreversible. If you cannot answer who the agent was acting as, the deployment is not ready.

Give agents their own service identity rather than borrowing a person credential. Attribution collapses the moment an agent runs as a named user.

Separate read autonomy from write autonomy. Most useful agent work is read-heavy, and read-only agents carry a fraction of the risk.

Log the input, the tool call and the result, not just the final answer. Post-incident review needs the intermediate steps.

On-premise AI means the models, the orchestration and the data they read all run inside infrastructure your organisation controls, whether that is your own data centre or a private tenancy you administer. No prompt, document or embedding leaves your boundary, and access is governed by your existing identity and audit systems rather than a vendor console.

The practical test is whether you can answer three questions without contacting a vendor: where is the data at rest, who can read the logs, and what happens to inference if the internet drops.

Most enterprises land on a hybrid position. Sensitive workloads stay inside the boundary while lower-risk work uses hosted models under a documented data-handling rule.

On-premise wins when the data cannot leave the boundary for legal, contractual or sovereignty reasons, when you need reproducible inference for evidence, or when the workload is steady enough that fixed capacity beats per-token pricing. Hosted APIs remain the better answer for bursty experimentation and for frontier capability you are not ready to operate yourself.

Contractual restrictions are the most common trigger. Client agreements, regulatory undertakings and cross-border data terms often prohibit third-party processing long before any law does.

Reproducibility matters in investigations and audit. A pinned model in your own environment can be re-run months later to produce the same output; a hosted endpoint that has been silently updated cannot.

Pilots stall because they are evaluated on demonstration quality rather than on operability. A pilot proves the model can produce a good answer; production requires an owner, a control, an audit trail, a failure path and a budget line. Nothing in the pilot design produces those, so the work restarts at the point of handover.

The tell is a pilot with no named accountable owner outside the innovation team. If the business unit that would use the output was not in the room, there is no route to production.

Treat the first deployment as an operating model exercise that happens to include a model, not a technology trial that later acquires governance.

It can. The AI Act reaches providers and deployers outside the EU where the output of the system is used in the Union, so a South African or wider African enterprise serving EU customers may fall in scope. Obligations are phased, with prohibited practices and AI literacy duties applying first and most high-risk system obligations landing later.

Classification drives everything. Most enterprise back-office AI is not high-risk, but recruitment, credit and access-to-services use cases frequently are.

The cheapest compliance posture is an inventory. Knowing which systems exist, what they decide and who owns them satisfies the first request from any regulator.

Crypto assets were declared a financial product under the FAIS Act, which means providers offering advice or intermediary services need FSP licensing from the FSCA. Separately, crypto asset service providers are accountable institutions under the Financial Intelligence Centre Act, so they carry customer due diligence, record-keeping and reporting duties to the FIC.

The two regimes are often confused. FSCA licensing addresses market conduct; FICA obligations address financial crime, and both can apply to the same business.

FATF standards on virtual assets, including the travel rule for originator and beneficiary information, shape what the FIC expects operationally.

POPIA governs AI deployments through the same principles it applies to any processing: a lawful purpose, minimality, and accountability resting with the responsible party rather than the vendor. Section 71 also gives a data subject rights where a decision affecting them is based solely on automated processing, which is why a documented human review step matters in practice.

Purpose specification is the constraint most AI programmes trip over. Data collected for servicing is not automatically available for model training.

Cross-border processing brings section 72 into play, which is a common reason enterprises choose to keep inference inside the country.

The Information Regulator supervises compliance. Board-level documentation of AI decision rights is easier to produce before it is requested than after.

Six questions cover most of the risk: which decision does this system affect, what data may it read, who is accountable for its output, how would we detect that it is wrong, what is the reversal path, and what does it cost to run at full volume. If any answer is a name of a technology rather than a person or a number, the paper is not ready.

Ask for the failure case in writing. A deployment proposal that cannot describe how the system fails has not been tested.

Ask what the system will be permitted to do without human approval, and require that the answer be narrow at the start.

ISO/IEC 42001 is the certifiable management system standard and suits organisations that already run ISO management systems. The NIST AI Risk Management Framework is not certifiable but maps risks to functions more usefully during design. Most enterprises use NIST language while building and ISO structure when they need to demonstrate the system to a third party.

In South Africa, King IV Principle 12 on technology and information governance is usually the instrument the board already recognises. Anchoring AI governance there shortens the approval path.

Do not adopt a standard before you have one deployed use case. Abstract frameworks produce abstract controls.

Usually not. Most enterprises already own most of what a first deployment needs, and replacing a platform is a slower path to a governed capability than configuring the one you have. Where a genuine gap exists we build it in your estate and leave you the source, so the dependency created is on your own engineers.

We are explicit about the small number of cases where existing tooling cannot meet an evidence standard, and we say so early rather than working around it.

Engagements run in four movements: frame the mandate with leadership, establish the facts from data and systems, deploy the capability inside your environment, then transfer competence to your team. Each movement has an exit condition, so the engagement can stop at a defensible point rather than running to a fixed calendar.

The framing stage is deliberately short and senior. It exists to name the decision, the risk boundary and the outcome that matters.

Deployment happens in your estate from the start. We do not build in our environment and migrate later, because the migration is where governance assumptions break.

Capability transfer means your team can operate, govern and extend the deployed capability without the consultancy present. In practice that is four artefacts: a runbook your engineers execute, a control set your risk function owns, a decision record your board can read, and a working period where your people run it while we watch rather than the reverse.

The exit test we use is simple. Your team performs a full operating cycle unaided while we observe, and any intervention we make becomes a documentation defect to fix.

Transfer fails most often because no named individual on the client side had capacity allocated. The receiving role has to exist before the work starts.

The work is sector-agnostic because the underlying problem repeats: a consequential decision, incomplete data, and a control environment that has to hold. Engagements have covered public sector and regulators, banking and payments, professional services and assurance, and enterprises pursuing strategic transactions, alongside data platform work in operationally heavy industries.

What changes by sector is the evidence standard and the regulator, not the method.

Sectors with heavy operational data, such as mining, energy, logistics and healthcare, tend to reach value fastest because the decisions are frequent and measurable.