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.
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