SAWA Programme — women in Ghana's aquaculture sector
Research Paper

Designing AI and Data Infrastructure for Women in Ghana's Informal Aquaculture Sector

A case study from Mastercard Foundation's SAWA Programme, by Internet People

Published

September 29, 2026

Author

Internet People Research

Programme

SAWA / Mastercard Foundation

Technicality

← Back to Cases & Research
Abstract

Abstract

Programme data systems in development finance tend to fail in one of three ways: they arrive too late to inform decisions, they are too coarse to trust, or they take data from beneficiaries and give nothing back. The SAWA Programme aims to create 60,000 jobs for young women in Ghana's aquaculture sector, and implementing partners need a system that avoids all three at scale. Internet People built a single data layer with three surfaces: an AI-powered WhatsApp admin channel for participants, an AI-powered WhatsApp sales channel, and a blockchain-backed database with a dashboard for managers and implementing partners. This paper covers the design reasoning, the technical choices and what the work shows about deploying AI in Ghana. Our central claim is that AI succeeds in low-infrastructure, high-diversity settings because of careful architecture and AI contextualization, not because of the size of the model.


Disclosures

Disclosures

SAWA (Sustainable Aquaculture for Women Advancement) is funded by the Mastercard Foundation and led in implementation by Agri-Impact Limited. Internet People was engaged by a member of Agri-Impact's implementation consortium to design and build this digital layer for its own operations within programme implementation. This paper is written by the team that built the system, so it is a practitioner's account and not an independent evaluation. Figures come from platform records and have not been independently audited.

The views expressed are Internet People's alone and do not represent the Mastercard Foundation, Agri-Impact or any other consortium member. Statements about what each party needs reflect our understanding from delivering the work and are not statements made by them.

This system is currently in its early deployment phase and all adoption and performance metrics are preliminary, unaudited, and subject to change. This document does not constitute a guarantee of financial or livelihood outcomes for participants.


Women participants in the SAWA aquaculture programme
Section 1

Background

SAWA (Sustainable Aquaculture for Women Advancement) runs from July 2026 to June 2030. It targets 60,000 dignified jobs for young women across the aquaculture value chain and 50,000 metric tonnes of additional fish production, in support of national food security and nutrition. Four pillars underpin it: gender and disability inclusion with safeguarding and capacity building, production expansion, value addition and market development, and ecosystem strengthening.

The data problem beneath these goals is an information problem with a well-studied structure. Lenders struggle to tell good borrowers from bad among smallholders and micro-enterprises, because these enterprises lack verifiable records. The lender's rational response is to ration credit or price it prohibitively, which penalises the good borrowers along with the bad. Verifiable records, in effect, work as collateral for people who have no other. A women-owned fish enterprise can keep meticulous production records on paper and still be invisible to formal finance, because no one can verify them.

Aquaculture sharpens this. Production cycles run for months, so a decision made on bad information is paid for late and at high cost. Feed is typically the largest expense, so small differences in feeding, stocking and mortality decide whether a farm makes money. The quantities that matter most, such as stocking density, feed use, growth, mortality, harvest and sales, are the hardest to capture consistently in the field.

A four-year programme with 60,000 participants has to solve capture, trust and access together. Paper registers and periodic surveys can't do that at this scale, and they leave participants out of the loop.


Section 2

Design Thesis: One Data Layer, Three Surfaces

We broke the requirement into three problems.

  • The interface problem: how do 60,000 people with varied literacy, languages and devices contribute and retrieve data at near-zero training cost?
  • The trust problem: how does field data become something a funder or lender can rely on without a central administrator vouching for it?
  • The visibility problem: how do managers see the whole system in near real time without a reporting process that adds delay and error?

The architecture answers each with one component, all tied to one source of truth. Conversational AI on WhatsApp handles the interface. A tamper-evident data layer handles trust. A dashboard reading directly from that layer handles visibility. The key design choice was to refuse separate systems for participants, staff and funders. Every reporting pipeline that copies data between systems adds delay, transcription errors and room for dispute.

System architecture diagram

Programme participants during their first week of training.


Section 3

Key AI Technology

3.1 Language models as interpreters, not authorities

Both WhatsApp channels use large language models, but the models have a narrow job. Every inbound message passes through the following pipeline:

  1. Normalisation: detect language and handle code-switching, spelling variation and shorthand.
  2. Interpretation: classify intent and extract the entities the action needs, such as product, quantity, price, date or record identifier.
Conversational AI on WhatsApp — meeting users inside the channel they already use.

Conversational AI on WhatsApp — meeting users inside the channel they already use.

3.3 The blockchain data layer

Blockchain is often misapplied, so the case for it needs stating precisely. A shared ledger is justified when several parties write to or rely on a dataset, when no single party is trusted by all the others, and when tamper-evidence and an audit trail carry real value. SAWA meets all three conditions. Tens of thousands of participants, several implementing partners and external financiers all touch the data.

Three properties matter:

  • Provenance: each record carries a verifiable origin and history, so a lender can see when a production record was entered, by whom, and that it has not been altered since.
  • Consent and access control: participants can see who has requested their data and can grant or withhold access. This turns data sharing from something done to them into something they authorise.
  • Auditability: changes are logged immutably, which makes the data credible to parties outside the programme.

Immutability sits uneasily with data protection law, including Ghana's Data Protection Act, 2012 (Act 843), which gives individuals rights over their personal data. The standard resolution keeps personal data in access-controlled storage off-chain and anchors only cryptographic proofs, consent records and access logs on the chain. A record can then be verified without exposing the personal data, and personal data can be corrected or removed without breaking the audit trail.

3.4 The dashboard as a read model

The dashboard reads from the same database participants write to, so there is no export, no reconciliation step and no second copy. Views are scoped by role. Managers see operational aggregates; financiers see verified records for enterprises that have consented to be assessed. The dashboard is a view of the record rather than a report about it, so what it shows is current by construction.

3.5 Evaluation

We evaluated the AI components on real messages, not synthetic examples. Four measures mattered: intent accuracy, confirmation-rejection rate (how often users corrected the system's interpretation), handoff rate to a human, and time to resolution. Confirmation-rejection is the most informative in production, because it measures misunderstanding as users experience it.


Section 4

Application to the Local Context

Much AI deployment in emerging markets fails because it imports a design that assumes conditions that don't exist locally. We started from the conditions instead.

Channel.WhatsApp is already the default channel for informal commerce and coordination in Ghana. Building inside it means no new app to install, no new login to remember and no extra data cost. Familiarity replaces training: the instruction is simply "send a message". Adoption at this scale depends on that.

Language. Participants write in English and shorthand, often mixing the two in a single sentence, with inconsistent spelling. Many prefer voice notes. Ghanaian languages are low-resource for speech and language technology, so off-the-shelf accuracy is uneven. We responded with a hybrid interaction design: free text where the model is reliable, guided prompts and quick-reply options where precision matters, and a confirmation step before anything is recorded. This narrows the room for misunderstanding without forcing users into rigid forms. Support for local language interaction goes further and is set to roll out in phase 2 of the project.

Inclusion. Conversational and voice-friendly interfaces lower barriers for participants with disabilities and for those with limited literacy, which form-based interfaces do not.

Connectivity. Conversations over messaging are asynchronous. A dropped connection pauses the exchange rather than ending it, which suits the intermittent connectivity common in rural and peri-urban areas.

Data ownership. Data about smallholders has traditionally flowed one way, to the institutions collecting it. Giving participants visibility and control changes their incentive to keep accurate records, because the records now serve them. Data quality improves with participation, so we treat ownership as a design principle and not a rights-based add-on.

WhatsApp conversational interface

Sales participant preparing goods for market.


Section 5

Research and Findings

Research questions. We approached the deployment as applied research on three questions:

  • Does a conversational interface inside an existing channel achieve sustained adoption among a diverse, low-touch population?
  • Can AI-mediated data capture reach the accuracy that a verifiable record requires?
  • Does a single shared data layer reduce the latency and disputes of multi-party reporting?

Methodology.

This evaluation draws on platform data and field interviews conducted in person with participant leaders, client operations and field managers. Participant leaders were interviewed at farm sites and community meetings, using semi-structured conversations covering how they use the WhatsApp channel, where they get stuck, trust in the system and how their data is handled, language and literacy barriers, and mobile data costs.

Results.

These findings come from field interviews and describe how the system is experienced on the ground. They are indicative, not representative.

  1. Participants described the WhatsApp channel primarily as a practical point of access to information and support rather than as a standalone digital platform. In practice, use centred on submitting daily logs, asking questions, checking prices and receiving reminders.
  2. Mobile data costs were a constant theme. Some participants were very aware of data costs and tried to economise by sending messages and checking daily sales data in the morning. In their own words, "I turn on my data in the morning and evening".

Findings.

  1. Channel choice is the largest determinant of adoption. Meeting users inside an app they already use removed the barrier that typically limits digital programmes, and did more for adoption than any feature of the AI.
  2. Constrained AI outperforms open-ended AI on record-keeping tasks. Limiting the model to interpretation, validating its output against a schema and requiring confirmation before writing produced reliable data. Open-ended assistants suit advice better than record-keeping.

Limitations. The programme is in its early phase, so long-term retention, financial outcomes and production impact cannot yet be assessed. Early adoption may be inflated by novelty and by programme staff actively onboarding participants, and accuracy figures depend on the language and input mix in the sample. Support for local languages is expected to improve more slowly than for English because these languages are low-resource: there is little digital text and labelled speech to train on, informal spelling is non-standard, and users often switch between English, Pidgin and a local language within one message.


Programme field operations
Section 6

Learnings

  1. Architecture matters more than the model. What the AI may do, what it must hand to deterministic code and where humans confirm determine reliability far more than which model is used.
  2. Separate interpretation from decision. The model understands what the user wants; the system of record decides what happens.
  3. Match error tolerance to consequence. Put probabilistic components where mistakes are cheap and deterministic checks where they are expensive.
  4. Ownership is a quality mechanism. People maintain data that benefits them, and participant access improves accuracy in a way enforcement cannot.
  5. Justify blockchain by the test, not the trend. It earned its place here because of multiple writers, low mutual trust and the value of an audit trail. Without those conditions, a conventional database is the better choice.
  6. Design for the median message. Real input is informal, mixed-language and ambiguous, and systems built and tested on clean examples fail in production.
  7. Serve every stakeholder from one truth. A system that pleases participants but can't satisfy funders won't survive, and neither will the reverse. A shared data layer made the system defensible to both.
  8. Local context is a technical requirement. Language, channel, device sharing, connectivity and unit cost are engineering constraints that shape the design as much as the model does.

Section 7

Implications for Organisations Deploying AI in Ghana

Banks, telecoms, agribusinesses, insurers and development programmes share the same underlying problem: large, distributed, low-infrastructure user populations and institutions that need verified data about them. What transfers is a set of choices. Build on the channel people already use. Confine AI to tasks where its errors are cheap. Keep records in a system that can be audited. Give the people who generate the data a stake in it. Treat local language and context as first-order requirements from day one.


Conclusion

Conclusion

SAWA suggests that responsible AI deployment in Ghana comes from careful architecture built around how people already communicate, and not from frontier models. Internet People designed and delivered this system end to end, from the conversational interface through the verified data layer to the institutional dashboard, and applies the same approach for organisations that need AI to work across large, diverse populations in Ghana and the wider region.

About Internet People

Internet People is a technology and AI solutions provider and research partner for startups, enterprises, governments and NGOs with project scope across Africa. Based in Accra, we design and build software for Africa and within Africa: AI and Intelligent systems, data infrastructure and analytics, cloud and solution architecture, and the full-stack products that connect them.

We act as both engineering partner and applied research partner, taking a problem from design reasoning through delivery to measured evaluation. Our guiding idea, designing connections, means linking people, data and institutions in ways that hold up in practice.

Learn more at myinternetpeople.com.