AI implementation for South African businesses: a practical roadmap

Every board pack now has an AI slide. Most of them describe a pilot that has been "in evaluation" for months, an assistant a few people tried once, or a vendor demo that impressed everyone and changed nothing. The pattern we see most often is not a technology failure. It is a sequencing failure: the organisation started with a tool instead of a problem, tested it on made-up data instead of real data, and never agreed what "working" would look like.

This is the order that actually works. It is deliberately unexciting.

Step 1: pick one narrow, measurable use case

Resist the platform. Resist "AI across the business". Choose one process that is expensive, repetitive, and already produces a number you can measure. Good candidates for South African businesses tend to look like these:

• Document processing. Invoices, delivery notes, claims forms and contracts arriving as PDFs and photographs, currently retyped by someone.
• Customer support triage. Classifying, routing and drafting first responses to email and WhatsApp queries, with a human sending the final reply.
• Lead scoring and follow-up. Ranking inbound enquiries and drafting the first touch, so sales spends its time on the ones that will close.
• FICA and KYC document checks. Extracting and cross-checking details from identity documents and proof of address before a compliance officer signs off.
• Internal knowledge assistants. Answering staff questions from policies, product manuals and past tickets, with citations back to the source.

For whichever you choose, write down the baseline today: how long it takes, how much it costs, how often it goes wrong. If you cannot measure it now, you will not be able to prove the AI version is better, and the project will die in a meeting.

Step 2: get honest about your data

AI systems are only as good as what you can feed them. Before any model is chosen, answer three questions.

Where does the data for this use case live? If the answer is a mix of spreadsheets, shared drives and email threads, that is not disqualifying, but it is the first piece of work. Who is allowed to see it? A support assistant that can read every customer's history is a data breach waiting to happen. Is it structured enough to evaluate against? For document extraction, that means a few hundred real, anonymised examples with the correct answers attached. Without that set you cannot run step 4.

Much of the value of an AI project comes from this stage, whether or not the model ever ships. Cleaning up how a process captures its data pays for itself.

Step 3: choose the model per use case, not per company

There is no single best model, and the ranking changes every few months. We work across providers by design: Claude, OpenAI, Gemini and Amazon Bedrock all have use cases where they are the right call, and a good architecture lets you swap without rewriting the product.

The questions that decide it are practical. How good does the output need to be, and how much are you willing to pay per document or per conversation? Does the task need long context, strong reasoning, or just fast classification? Where must the data stay? If data residency or contractual restrictions matter, running models through Amazon Bedrock inside your own AWS account is often the cleanest answer, with Azure's equivalent as the alternative if your estate is already there.

Build an abstraction layer from day one so the model is a configuration choice. It costs little now and saves a rewrite later.

Step 4: build a proof of value in weeks, with an evaluation harness

A proof of value is not a chatbot demo. It is the real use case, on real data, with a scoreboard.

The scoreboard is the evaluation harness: a repeatable set of real inputs with known correct outputs, run automatically every time a prompt, model or retrieval step changes. It tells you whether version twelve is actually better than version eleven, and it stops the project regressing quietly. It also gives you the number that goes back to the board: extraction accuracy against a human, percentage of tickets routed correctly, time to first response.

Keep the scope tight enough to finish in weeks. A proof of value that takes six months is a product with no launch date.

Step 5: take it to production properly

This is where pilots usually stall, because production is a different job from prototyping.

• Guardrails. Input validation, output checks, and hard limits on what the system may do on its own. An assistant that can read is a different risk from one that can send.
• Human in the loop. Decide explicitly which outputs a person reviews, which are sampled, and which run unattended. Start conservative and loosen as the evaluation numbers earn it.
• Monitoring. Log every request with its cost, latency and outcome. Alert on error rates and on quality drift, not just on downtime.
• Cost telemetry and a cost model. Token-based pricing surprises finance. Know the cost per document or per conversation, cap spend per key, and be able to show the unit economics next to the baseline you captured in step 1.
• Change control. Prompts are code. Version them, review them, and run the evaluation harness before anything reaches users.

POPIA, without the hand-waving

Personal information will flow through most of these use cases, so the Protection of Personal Information Act applies from the first prototype, not from launch. The engineering practices that help are well understood:

• Send the model the minimum it needs. Strip or mask identifiers, account numbers and contact details where the task does not require them.
• Keep purpose limitation real: data collected for FICA checks is not automatically available for marketing analysis.
• Use provider tiers and settings under which your data is not used to train models, and get that in writing. Where a provider processes data on your behalf, your operator agreements need to cover it.
• Control access to the AI system as carefully as to the underlying data, and keep the logs from step 5 free of personal information.
• Prefer deployment options that keep data in the regions and accounts you already govern when the classification of the data calls for it.

None of this is legal advice. Involve your information officer and legal counsel early, show them the data flow diagram, and they will usually be relieved that someone drew one.

Step 6: operate and iterate

An AI system in production drifts. Inputs change, providers update models, the business changes the process around it. Someone has to own it day to day: watching the evaluation numbers, reviewing the sampled outputs, retiring prompts that no longer earn their keep, and deciding when the second use case starts. Budget for that person before launch. The projects that compound are the ones where the first use case funds the second.

Where QLTech fits

We implement AI the way we build everything else: one measurable problem, a proof of value on your data, then production with evaluation, guardrails, monitoring and a cost model you can defend. If you have a use case in mind, or want help choosing one, see our AI implementation and integration service or send us a brief and we will reply with a written scope.