OUR DISCIPLINES
AI and Machine Learning
in South Africa.
Nobody hires an engineer to build something that’s wrong 4% of the time. In AI, that’s exactly the job, the skill is in knowing which 4%, and what it costs your business.
This is how AI and machine learning hiring actually works in South Africa: the people who build, deploy and govern the models, the market they sit in, and what separates a demo from something the business can stand behind.
A LOOK AT THE MARKET
The AI and machine learning market in South Africa.
The (current) scarce skill in this market is not building models, but rather knowing whether the one you built is good enough to put in front of a customer, and being able to prove it to someone accountable if it’s not. A number of AI projects in South African businesses have stalled at exactly that point. Things work more or less, in a demo, but nobody can say with confidence how often it’s wrong, what it costs when it is, or what happens the first time it’s wrong about something that matters. That’s not a modelling build problem, it’s a gap in your team that requires a hire.
Part of how the local market has arrived here is that as the way hit, many business found themselves bolstering capability before the problem was fully defined. Boards asked for an AI strategy, teams were assembled quickly, and the hiring went towards the most visible skills rather than the ones that make a system safe to operate. The market is course correcting and as a result it’s changed what a good specification looks like.
If you’re hiring in AI, you’ll notice the roles that are hardest to fill are less focused on model architecture depth than before. Today it’s more geared towards hiring someone who can design an evaluation, run a system in production where the inputs keep shifting, and explain a compromise to a risk committee without overselling it or hiding behind the maths.
South Africa has a specific complication on top of that, which is that this skill set is typically sold in dollars. The senior end of this pool is small, internationally legible and actively recruited from abroad, and a strong machine learning engineer in Cape Town and/or Johannesburg can take a fully remote role for a European or American business without moving house. This has compressed the market at the top and made counter offers routine.
However, it has also created real opportunity below it. The useful AI hires in most South African businesses are the applied people who can take existing capability and infrastructure, and make it work inside a real operation. This group of people is bigger, more findable, and often overlooked in favour of a profile the business does not actually need.
THE TITLE
What 'AI engineer' in a job title actually means.
There is probably no title in technology carrying more weight and less information right now than AI engineer. Data scientists rebranded, backend engineers who shipped a feature using a model API rebranded, and a genuine new discipline appeared alongside them that needed a name and took that one.
Four different jobs sit under the label, and they are separated by what the person is actually working on.
Build: building and training models themselves. Research or applied science, and is a smaller field than the noise suggests.
Apply: pointing models that already exist at a business problem. Where most commercial value gets created, and where the work is mostly engineering, evaluation and product judgement.
Operate: keeping models deployed monitored and retained as the data shifts underneath them.
Govern: deciding what a model is allowed to do, what gets written down, and who answers when a decision is challenged
If you’re hiring, describe the work rather than the label, and say plainly whether the person is expected to build, apply, operate or govern. If you’re moving, be clear with yourself about which of those you have really done, because this is a market where the interviews have caught up and the questions are more specific than they were two years ago.
THE ROLES
The roles, and what each one involves.
These roles divide less by seniority than by what the person is accountable for: the model itself, the system around it, the problem it is pointed at, or the decision it is allowed to make. The tooling in this field turns over faster than in any other discipline, but the kinds of accountability do not.
AI engineer
Builds products and features on top of existing models rather than training new ones, which in practice means retrieval, orchestration, evaluation and a great deal of careful engineering around an unpredictable component. Currently the highest-demand role in the discipline, and the one most often filled by someone who has only done the demo version of it.
Common tools: Python, LLM and model APIs, retrieval and vector databases, orchestration frameworks, evaluation harnesses, and prompt and context engineering.
AI governance and risk specialist
Works out what the business is allowed to do with models, what has to be documented, and how a decision would be defended if challenged. Sits between legal, risk and engineering, and matters most where automated decisions affect customers. Still a rare role in South Africa, and increasingly a required one.
Common tools: POPIA and automated decision-making requirements, model risk and documentation frameworks, bias and fairness testing, audit and evidence trails, and emerging international standards including the EU AI Act.
AI product manager
Owns what the model is for, which is a harder product job than most because the thing being shipped has no fixed behaviour. Defines what good enough looks like, decides where a human stays in the loop, and manages the expectation gap between a demo and a live system.
Common tools: evaluation design and success criteria, user research, model capability assessment, roadmap and scoping, and cost and latency trade-off analysis.
AI solutions architect
Designs how AI capability fits into an existing business and its systems, including the unglamorous constraints: data access, integration, cost per call, latency, and what the security and compliance position allows. Usually the role that determines whether an AI programme is viable before anyone writes a model.
Common tools: cloud AI platforms on AWS, Azure or GCP, architecture and integration design, cost modelling, data governance, and vendor and build-versus-buy assessment.
Computer vision engineer
Builds systems that interpret images and video, which in this market usually means industrial, mining, agricultural, retail or security applications rather than consumer products. A specialism where physical deployment conditions matter as much as model quality, and where edge constraints shape everything.
Common tools: PyTorch or TensorFlow, OpenCV, object detection and segmentation architectures, edge deployment and optimisation, and annotation pipelines.
Data engineer, AI and ML platforms
Builds the data foundation the models depend on, which is where most AI programmes quietly succeed or fail. Increasingly includes the pipelines for features, embeddings and retrieval rather than only analytics and reporting.
Common tools: Python and SQL, Spark, Airflow or Dagster, feature stores, vector and embedding stores, and cloud data platforms.
Data scientist
Frames a business question, works out whether the data can answer it, and builds the model or analysis that does. The role most often mistitled in both directions, and the one where commercial judgement separates people far more than technical range.
Common tools: Python or R, pandas and scikit-learn, statistical modelling and experiment design, SQL, and visualisation tooling.
Machine learning engineer
Takes models from working to working in production, and owns them once they are there: performance, retraining, drift and the behaviour of the system as real data moves away from the training set. The closest thing this discipline has to a load-bearing role.
Common tools: Python, PyTorch or TensorFlow, model serving and inference optimisation, feature pipelines, experiment tracking, and cloud ML platforms.
ML platform, MLOps engineer
Builds the infrastructure that lets everyone else ship and operate models repeatably: training and deployment pipelines, model registries, monitoring and the compute underneath. Where DevOps discipline meets machine learning, and scarce precisely because it needs both.
Common tools: Kubernetes and Docker, MLflow or Kubeflow, CI/CD for models, GPU infrastructure and cost management, and monitoring and drift detection.
NLP and speech engineer
Works on language and speech systems, which in South Africa carries a problem most of the world does not have: eleven official languages, several of them poorly served by the models everyone else relies on. A specialism with real local relevance in customer service, public sector and financial inclusion.
Common tools: transformer architectures and fine-tuning, speech recognition and synthesis toolkits, low-resource language techniques, evaluation for multilingual systems, and Python.
Research scientist, applied
Works on the model itself, developing or adapting approaches rather than applying existing ones. A genuinely small group in South Africa, concentrated in a handful of institutions and research-led businesses, and rarely the role a commercial business actually needs even when it is the one written into the specification.
Common tools: PyTorch or JAX, experiment design and ablation studies, distributed training, the research literature, and strong mathematical and statistical foundations.
Other disciplines we recruit in
Software engineering · DevOps and cloud engineering · Fintech · Project and programme management and more
IF YOU'RE HIRING
Hiring for systems that are confidently wrong sometimes.
Most technical interviews are built to find out whether someone can make a thing work. That is the wrong question here, because in this field things work in the demo almost by default, and the difference between a capable hire and an expensive one only shows up in how they handle the part where it does not.
The most revealing question to ask is how they knew their work was any good. Not what accuracy they reached, which is easy to quote and hard to interpret, but how the evaluation was designed, what it deliberately left out, and what they did when the numbers looked fine and the users did not agree. Anyone who has taken a model into production has a story about that gap. People who have only built prototypes usually do not, and the absence is noticeable within a few minutes.
Ask what they did when a model degraded after launch. Ask about a time they recommended against using a model, because the ones worth hiring have done this at least once and will say so plainly. Ask how they decided where a person stays in the loop. And ask what a wrong answer cost, because the strongest candidates think in terms of the business consequence rather than the metric, and that habit is what makes them safe to give real problems to.
Be careful of two failure patterns while you’re at it.
The first is hiring research capability for an applied problem, which is expensive, frustrating for everyone, and more common than it should be.
The second is the opposite: hiring someone fluent in the current tooling who has never had to own a system past launch, which reads well in interview and shows up six months later when nobody can explain why performance has drifted.
The useful filter is not how much they know about models. It is whether they have ever been responsible for one after the applause stopped.
WHY LEVELS MATTER
Understanding seniority.
Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A junior does well-scoped work inside someone else's framing: preparing data, running experiments that have been specified, building evaluation sets, implementing a component of a pipeline. The trait to hire for is scepticism about their own results. The good ones check whether a number is too good before they present it, and want to know why something worked rather than just that it did.
-
A mid-level professional owns a model or a service end to end, from the data through to what happens after deployment. They can be trusted to design a reasonable evaluation, to notice when performance is drifting, and to say when a problem is not actually a machine learning problem. That last judgement is worth more than it sounds and saves businesses a great deal of money.
-
A senior professional sets the approach and is trusted with the questions that have no clean answer: whether the data supports what the business wants to do, what the acceptable error rate is and who agreed to it, when to stop improving a model and ship it. Seniors here are judged on the systems still working a year later and on the projects they talked the business out of.
-
A lead or principal professional sets direction across the portfolio and carries the calls where capability, cost, risk and commercial ambition disagree. At this level the work is deciding what the business should build rather than buy, what it can responsibly automate, and how to explain all of it to an executive team whose expectations have been shaped by the market's loudest claims.
Where the money is, and where it isn't
The premium in this field has moved away from model building. Training a model from scratch is a rarer requirement every year, because the capability is increasingly bought rather than built. What has become scarce, and expensive, is everything that turns that capability into something a business can rely on.
The specific combinations worth paying for: production ownership, meaning someone who has run models in live systems through drift, retraining and failure rather than delivering them and moving on; evaluation design, which is an underrated craft and the single clearest marker of experience; inference cost and latency engineering, which matters enormously once volume arrives and which almost nobody thinks about until the bill does; and GPU and compute infrastructure skill, which is scarce in South Africa because relatively few local environments have needed it at scale.
Domain depth also pays here in a way it does not in every discipline. A machine learning engineer who understands credit, or clinical data, or industrial processes, is worth considerably more than a generalist, because in this work the hardest part is usually knowing what the data actually means and where it lies to you.
And the quietly valuable skill, the one that shows up in every senior search and is rarely specified: the ability to explain a probabilistic system to people who have to make a deterministic decision about it. Executives, auditors, regulators and customers all need that translation. Very few technical people can do it well, and the ones who can end up with the most influence in the room.
What the package is really worth
This discipline has the widest and least predictable pay spread in South African technology, and base salary comparisons between two apparently similar roles will mislead you more often than not.
The reason is that the same title covers very different work at very different value. A data scientist producing monthly analysis and a machine learning engineer owning a production system that touches revenue are priced in different markets, whatever the org chart calls them. Before comparing numbers, be sure you are comparing jobs like for like.
Two things specific to this field tend to shape the decision. The first is access: to compute, to real data at meaningful volume, and to problems with actual consequences. This is the single strongest non-cash lever employers have, and candidates weigh it heavily, because a year on interesting problems does more for a career here than a year of incremental salary. The second is the offshore market, which pays in hard currency for fully remote work and has changed what a senior local offer competes against. Businesses that ignore this are frequently surprised at offer stage.
The usual structural elements still matter, and matter more than they get credit for: retirement and medical contributions, bonus structures, and equity where it is real. Beyond that, this is a field where people move for conference and publication freedom, for time to keep current, and for the chance to work somewhere the AI programme is genuinely supported rather than tolerated. Those are cheap to offer and unusually persuasive.
THE COST
Contract vs Permanent.
The AI contract decision has a specific trap in it that is worth naming, because a lot of South African businesses have already walked into it. The pattern goes: the business contracts a specialist to build a model or a pilot, the specialist delivers something that works, the engagement ends, and the business is left owning a system nobody internally understands, cannot evaluate and is afraid to change. The model then quietly degrades, and within a year it is switched off. The build was fine, but the handover was never designed.
That is an argument for how you contract rather than against contracting. There is a lot of work in this discipline with exactly the right shape for it: a proof of concept that needs specialist depth for three months, a platform build that needs MLOps skill the team does not yet have, a computer vision deployment, a one-off piece of research to establish whether something is feasible before the business commits. Bringing in someone who has done it before is usually faster and cheaper than a permanent hire learning on your problem, and it lets you find out whether the capability is worth building permanently before you commit to a headcount.
The line worth holding is that you can contract the build, but you cannot contract the understanding. Whatever the arrangement, someone permanent has to be able to explain the system, evaluate it, and decide when it needs to change. If that person does not exist yet, the first permanent hire matters more than the contractor does, and the contract engagement should be structured around teaching them.
For the professional, contract in this field is strong and getting stronger, especially in MLOps, platform work and vision. The trade is real though: contract work tends to end at deployment, and the deepest learning in this discipline happens in the year afterwards, when the data moves and the model has to survive it.
AI & Machine Learning
salaries in South Africa.
The spread inside each band is wider in this discipline than in any other we recruit for. Research-level roles, production ownership of revenue-critical systems, and scarce platform and GPU infrastructure skill all sit at or above the top of these ranges, and the offshore remote market pulls senior packages upward in a way local benchmarks do not always reflect.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Junior AI & ML engineer
R700 – R800
> Mid-level AI & ML engineer
R800 – R1100
> Senior AI & ML engineer
R1100 – R1300
> Lead or Principal AI & ML engineer
R1300 – R1500
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Junior AI & ML engineer
R880K – R1M
> Mid-level AI & ML engineer
R1M – R1.4M
> Senior AI & ML engineer
R1.4M – R1.7M
> Lead or Principal AI & ML engineer
R1.8M – R2.2M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: September 2026
IF YOU'RE BUILDING A CAREER
Pilots don't build a career in AI
The most valuable thing you can accumulate in this field is not a list of models or frameworks. It is evidence that you have been responsible for something real, and that you know what happened to it after launch. Tooling has a short half-life here. Judgement about when a model is good enough, and what to do when it stops being good enough, keeps its value.
So weigh a role on three things. What data you will actually get your hands on, since the interesting problems live in data you cannot see from outside. What you will personally own, because owning a system in production teaches you things a year of prototypes will not. And who you will learn from, which matters more in this discipline than most, because a lot of the craft is unwritten and is picked up from people who have been wrong before and remember why.
Be wary of the role that is all demonstration. It is easy to spend two years building impressive pilots that never carried any weight, and it is surprisingly hard to explain that away later. One system in production that you can talk about honestly, including what went wrong with it, is worth more in an interview than five pilots that were all successes.
And here’s how we work with you. We take the time to understand where you’re trying to get to, not just what’s already on your CV, and we only put you forward for roles that move you that way. You stay in control the whole way through, and we’d rather point you at the right role than hurry you into the nearest one.
COMMON QUESTIONS
AI & Machine Learning questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
Do we need a data scientist, a machine learning engineer or an AI engineer?
It depends on which part of the problem is unsolved. If you don’t yet know whether the data can answer your question, that is a data scientist. If you know it can and the work is getting it running reliably, that is a machine learning engineer. If you are building a product on top of models that already exist, that is an AI engineer. Most businesses that ask us this need the second or third and have written a specification for the first.
Our AI pilot worked but never went further. Is that a hiring problem?
It can be, pilots are built to demonstrate; production systems are built to be operated, evaluated and maintained. Those are different jobs and often different people. The hire that unblocks it is typically someone with real production ownership experience rather than more model-building capability.
Should we build AI capability in-house or use a vendor?
Both, at different layers. The judgement about what the business should automate, what the acceptable error rate is, and whether the output can be trusted has to sit inside your organisation, because it is your risk. The infrastructure and the underlying models increasingly do not need to. The critical hire is whoever holds that judgement.
We can't compete with what overseas companies are paying. What can we do?
Compete on what they cannot easily offer: ownership of a whole system rather than a slice of one, access to data and problems that matter, proximity to decision makers, and a programme with real executive support. Those move more senior candidates in this field than most employers expect. Where the gap is purely financial, we would rather tell you early than run a search that cannot land
What does a good AI job spec actually look like?
It names the work rather than the label. Say whether the person will build models, apply existing ones, operate them in production or govern what they are allowed to do, because those are four different hires. Then say what they will own, what data they will have access to, and what already exists for them to work with. Specs that list frameworks instead of responsibilities attract people who list frameworks instead of results.
Need help building your job spec? Get in touch with your vacancy and we’ll formalise it with you before taking it to market.
Should our first AI hire be senior?
Almost always, yes. A first hire in this discipline is making judgement calls with no one to check them: what the business should attempt, what the error rate can be, whether the data supports the ambition at all. Hiring junior first usually means paying twice, because someone senior eventually has to come in and undo the foundation.
Do certifications, Kaggle rankings or a strong GitHub mean anything?
They tell you someone is engaged with the field, which is worth something, and very little beyond that. Competition and portfolio work uses clean data, a fixed target and no consequences, which is close to the opposite of the job. Ask about a system that ran in front of real users instead.
Should we hire a data scientist before we have proper data engineering?
Usually not, and this is one of the most common expensive mistakes we see. A data scientist without reliable pipelines spends most of their time doing data engineering badly and slowly, at a data scientist’s salary. If the foundation is not there, the first hire is the person who builds it.
How long does it take to hire a strong AI or machine learning person in South Africa?
Longer than the equivalent software engineering search, because the pool with genuine production experience is small and mostly employed. The bigger variable is usually the specification rather than the market. A brief asking for research depth on an applied problem will stay open far longer than one that describes the real job, so it is worth spending an hour on the spec before spending three months on the search.
FOR PROFESSIONALS EXPLORING
Do I need a masters or PhD to work in AI in South Africa?
For research roles, usually. For the large majority of commercial roles, no, and the market has shifted noticeably towards demonstrable production experience. What gets tested now is whether you can build something that works, evaluate it honestly and keep it working.
I'm a software engineer. How do I move into AI?
It is one of the more achievable moves right now, because the applied end of this field is short of people with real engineering discipline. Depth in evaluation, data handling and production systems will take you further than a collection of courses. Build something that runs, measure it properly, and be able to talk about where it fails.
Is it better to specialise or stay broad?
Specialise in a problem rather than a tool. Vision, language and speech, forecasting, recommendation and risk modelling are durable areas with their own depth. Frameworks turn over every couple of years, and a career built on one of them ages badly.