Field notes · Francis Osih

Before an AI pilot, check the operating reality.

A demo shows the tool can work on the inputs someone chose. A pilot has to show your team can trust it on the inputs that arrive on a Tuesday in the rainy season.

Lagos, Kinshasa and Bamenda run on different networks, languages and habits. Use these seven checks for one country, one workflow and one team at a time.

1. Name the workflow first

Choose one recurring task: triaging a service request, extracting fields from a document, finding a relevant operating procedure, or matching a customer with a local service. Identify who owns it, who reviews the result and what happens if the system is wrong.

Record today's volume, time per task and common errors. Without that baseline, nobody can say whether the pilot made anything better.

2. Inspect representative inputs

Test with approved samples that reflect real variation: incomplete records, different document layouts, scans, misspellings and missing fields. Separate public, synthetic and confidential data. Agree permission before sending anything to a model provider.

3. Test the languages people actually use

Clean English results tell you little about French, mixed-language records, local place names or SMS shorthand. Build a small evaluation set for the languages and formats in the agreed workflow. Write down every failure. An average score hides them.

4. Treat location as an input with uncertainty

A coordinate, a landmark and a postal address are different kinds of evidence. A model may generate a plausible-sounding location without resolving it correctly. Define which location sources can be trusted, how uncertainty is displayed and when a human must confirm. See OSIH's location-context approach.

Two fishermen in a wooden canoe on Lake Kivu at dusk, with the town of Goma on the shore behind them
The work starts long before the network does.

5. Design for interruption and cost

Check how the workflow behaves when a request times out, connectivity drops or a provider is unavailable. Define retry limits, duplicate prevention, a manual fallback and an expected cost per completed task. Test each of these before launch.

6. Keep consequential actions under control

Drafting a reply is different from sending it. Extracting an invoice amount is different from authorising a payment. Start with reviewable suggestions, explicit permissions and a record of what the human approved. Treat retrieved documents as data. They must never be able to issue instructions to the system.

7. Agree what happens after the demo

Set acceptance criteria before testing: which cases must work, which failures are tolerable, who signs off, and what remains out of scope. Assign ownership for access, data retention, monitoring, third-party costs and changes to the model or workflow.

The next step

Bring one workflow in one African country, a decision-maker and a handful of approved example inputs. The Africa AI Feasibility Assessment tells you whether the next step is an AI prototype, a conventional integration, more local testing or no build. Commission it online. Not sure the idea itself holds up? Start with an Africa Pre-Mortem.

Send your brief · fixed proposal in two business days