An AI readiness checklist for South African businesses

Most of the AI projects that quietly fail in South African businesses do not fail because someone chose the wrong model. They fail because the data turned out to be in three systems and an inbox, because two people did the same task differently and nobody had noticed, or because somebody asked halfway through whether the customer records could lawfully be used this way and no one knew.

None of those are technology problems. All of them are findable before you spend anything. Here is the checklist.

1. Name one problem, and attach a number to it

“We should be using AI” is not a project. Pick one task: matching remittances to invoices, triaging incoming service requests, drafting the first version of a quote.

Then put a number on it. How many hours a week does it consume? What does a mistake cost when it happens? How long does the customer wait? The number does not have to be precise. It has to exist, because in three months it is the only thing that will tell you whether the pilot worked.

You have passed this check when you can finish the sentence: “This works if X goes from A to B by date C.”

2. Find out where the data actually lives

Write down every place the relevant information sits. Be honest about the awkward ones: the spreadsheet on the finance manager’s laptop, the scanned delivery notes, the WhatsApp group where site issues get reported.

Then look at the least accessible item on that list. That is your real constraint, not the best-organised system you own. A business with an excellent ERP and one critical process running through personal email has an email problem, not an ERP.

The question that settles it

Could someone technical get at this data programmatically, through an API, a database connection, or at minimum a scheduled export? If the answer is “only by someone copying it out by hand”, or “we would have to ask the vendor”, that is a cost and a delay you should know about now.

3. Look at the data honestly

This is the step most often skipped, and it explains more disappointing pilots than any other single factor.

Export a few hundred rows and actually read them. Count how many records are duplicated. Count blank fields in columns that matter. Look for free text where a category was expected, dates in three formats, and customer names spelled four ways.

You are not looking for perfection. You are looking for whether the errors are systematic, which can be corrected in bulk, or arbitrary, which cannot. Arbitrary inconsistency is the expensive kind.

Also ask how much history you hold. Anything that needs to learn from past cases, or that you want to measure an improvement against, needs a baseline. Under six months of usable history limits your options considerably.

4. Write down the process

Sit with two or three people who actually do the task, and have them walk through real cases rather than describe the procedure in the abstract. The description and the practice are rarely the same document.

Where they disagree about the correct handling, stop and note it. You have just found something that has to be settled by a person before any system can be given the job. Automating an unsettled process encodes one person’s habits as though they were policy.

This exercise usually pays for itself regardless of whether the AI project proceeds. It routinely surfaces steps that exist only because someone left in 2019.

5. Establish the lawful basis before the data moves

Work out what personal information is involved, and on what basis you hold it.

The trap under POPIA is purpose. Information collected for one purpose cannot automatically be used for a different one. Customer contact details gathered to fulfil orders are not automatically available to train a system that scores those customers. That may be fine, but it is a question to answer deliberately rather than discover later.

Ask three things: what personal information is in scope, who inside the business is formally responsible for privacy, and has anyone looked at whether this specific use is covered. If the answer to the third is “we assume so”, treat that as a gap requiring verification.

We have written this up in more detail in POPIA and AI.

6. Check who can approve and who can correct

Ask the awkward question: if this system produced a wrong answer that reached a customer, who would notice, who would review it, and how would it be put right?

“We would work it out at the time” is a real answer, and it is a red flag. A named reviewer and a defined correction path are what make a pilot controlled. They also make it possible to run the pilot at all in a regulated sector.

Related: is there anywhere you could test something safely, on a copy of the data rather than against the live system? Piloting directly against production is a risk in its own right.

7. Confirm someone actually has the time

Pilots fail on capacity more often than on technology. Someone has to answer the questions the project throws up, review the output while it is being tuned, and make decisions when the answer is unclear.

Ask specifically: who is that person, how many hours a week do they genuinely have, and does their manager know. Enthusiasm from someone already at capacity is not availability.

It is also worth asking how the last new system you introduced went. If it was adopted and is still used, that is the best available predictor. If people worked around it, understand why before repeating the pattern.

What to do with the answers

If checks 2, 3 or 5 came back badly, fix those before starting anything. They are not preliminaries to the real work; on most projects they are most of the real work, and doing them first is considerably cheaper than doing them after a pilot has produced output nobody trusts.

If they came back reasonably, you are in a position to run one narrow pilot with a measurable outcome. Choosing which one is its own question, covered in how to choose a first AI pilot.