The Engineer Who Started With the Data

Before Sam Waweru was building artificial intelligence for a government ministry, he was running Raspberry Pi code clubs in Kiambu County, recruiting and training mentors, and getting computers into schools that had no labs, no Wi-Fi and little to work with. “I think it contributed a lot to me having this opportunity,” he says.

Sam Waweru is a software and AI engineer based in Nairobi, and these days his work is more technical, and he prefers it that way. As the AI expert on Kenya’s prototype, Sam leads the build of the “golden record”, a tool to clean up the records the Ministry of Education holds on its learners and schools. “I’m more of a techie,” he admits, “but I don’t mind getting out of my comfort zone.”

Across the ministry’s data, the same pupil can appear twice. A child can be missing altogether because they don’t have a valid birth-certificate number. Elsewhere, the recorded numbers don’t match the pupils actually in class. Because schools are funded per pupil, through a system called capitation, these inaccuracies mean funding is sent to the wrong places: a school whose pupils aren’t all recognised can be underfunded, while funding can be released against numbers that don’t reflect real enrolment. Get the data wrong, Sam argues, and everything you build on top of it is wrong too. 

And the results are promising: during tests with synthetic data, the tool caught over 95% of duplicate entries. It also cut the time it took for data officers to verify records from almost seven minutes to less than a second, and every ministry officer reporting they preferred working with it.

Colleagues on the programme came to lean on him heavily, describing him as the engine of the project: someone so agile and creative that, as one put it, “you could throw down a challenge and he just hurdles over it.”

Over six months and across six countries, six ministries of education joined EdTech Hub’s Ministry of Education AI Challenge. Each Ministry worked with embedded AI experts to build their first AI prototypes. Meet the AI Experts introduces the people behind those tools: who they are, how they think, and what it takes to build AI a ministry of education can actually use. For this first profile, we’re featuring Sam Waweru in Kenya.

Let’s start with you. How did you end up doing this?

I’m a software and AI engineer based in Nairobi. I’d worked with the Ministry of Education before, through the Raspberry Pi Foundation, which runs an initiative here in Kenya setting up code clubs. I was the master trainer and coordinator for Kiambu County, the county I live in, next to Nairobi. We worked with the ministry to find under-resourced schools, places without enough computers, without Wi-Fi or internet, then trained mentors, deployed them and evaluated them. That role was more administrative. This project, however, is very solution-oriented: I’m building, brainstorming the problem, finding the gaps, fixing the bugs. I prefer the technical side. 

If you were explaining this challenge to someone who’d never heard of it, how would you put it?

The way I see the AI challenge, especially in the Ministry of Education, is about coming up with solutions that are really intentional, that genuinely address problems in education using AI. For us in Kenya, that’s the golden record. We’re cleaning up the records the ministry holds on students and schools, and making sure they’re accurate. Other countries are doing other things, like healthcare or pathway selection, but it’s the same idea: intentional AI which is applied to real problems in education.

When you say “records”, what’s actually going wrong?

It cuts across the board. When schools collect information on students, you can get duplication e.g. a student entered twice. You can also get under-reporting: the system won’t recognise a child because they don’t have a valid birth-certificate number, so it rejects them. So, sometimes a school’s recorded numbers are higher than the pupils actually enrolled, or are lower. All of this affects capitation, the funding that follows pupils. Some schools end up receiving more than they should, and others less, because the records don’t reflect the real number of pupils. Think about communities along the borders, families moving from Somalia into Kenya because of conflict, for instance. Those children need an education, but getting valid identification takes time, so some children have birth-certificate numbers that aren’t valid, meaning the system rejects the data entry. We’re trying to deal with all of that.

So how does the golden record actually fix it?

It has two parts. The first is entity resolution: finding the duplicates and inconsistencies and resolving them. If I have two records, can I compare them and decide whether they’re the same person or not? Names are often spelled differently, Sam with one ‘l’ or two, so we use phonetic matching that turns names into numbers and measures how close they are, rather than needing an exact match like a spreadsheet search. We weight the different fields based on what ministry officers told us matters most: a birth-certificate number carries a lot of weight, a first name much less. If the combined score passes a threshold, the pair gets flagged. 

The second part is report and insight generation: once the records are clean, the system turns them into an executive summary, something an official can actually read and make a decision from. 

Who makes the final call on a match, you or the system?

Not me, and not the system on its own. On our team we have data officers from the ministry. One of them spotted this problem in the first place, and applied to the Ministries of Education AI Challenge. So she’s the one who works with the flagged records and makes the final decision: merge them, or leave them. The model flags; the human decides. You’re always going to need a person in the loop on the hardest cases.

Other teams built chatbots whereas you focussed on the data itself. Why?

Data integrity is the foundation. It influences everything, including any AI solution you build on top of it. Poor data, poor results. Garbage in, garbage out. Once the data is clean, you can do a lot more with it: predictive models, working out how to disperse capitation to schools fairly, without leakage. That’s what makes our solution different and so important – data is the thing underneath all of of these AI prototypes, and data quality is something that is an issue for ministries of education.

Money is a factor in all ministry work. Working in sprints lets you test and learn early. How else did cost factor into what you built?

Sustainability was one of the biggest drivers. The question we kept asking, right from the ideation stage back in November, was: can this be maintained affordably after the challenge ends? We could have used a large language model to do the matching, putting two records in and asking the model if they’re the same, but that’s expensive, with constant maintenance and inference costs that grow the more you use it. So we went with a combination of classical machine learning and a mathematical approach instead. It’s more plug-and-play: it doesn’t need constant retraining. For the report generation we use one of the cheaper models on the market, because summarising doesn’t need heavy reasoning. Longer term, if the ministry hosts its own model, report generation could be essentially free.

You built all of this on synthetic data. What would you tell the next expert starting out?

I would say to make data access the first workstream. For us, access to the ministry’s data was the major bottleneck. The real data was being audited, the systems were down, and it became a very big public issue, with the ministry finding inconsistencies tied to millions in capitation losses. We couldn’t get direct access, so we created synthetic data instead. We made it with the ministry, so it’s realistic: real Kenyan names, plausible phone numbers, county and school names. My advice is don’t treat data as something you plug in once the system is built; make getting access to it the very first thing you do.

Looking back, how did you work effectively with the Ministry team?

We ran it in phases and kept the ministry in the room throughout. We started with discovery, understanding the problem and the possible solutions, then a phase of experimentation to really understand the data we were dealing with. The build itself ran in two-week sprints: one on the matching, one on the reporting, then one to bring it all into a single application. After each sprint we’d hold a retrospective with the ministry team, look at what was working and agree the way forward. Early on we met weekly; once we were building, it was every couple of weeks around the sprints. And we worked particularly closely with the ministry’s data officers. One of them had spotted this gap in the first place, and they were the ones who set the parameters that mattered, tested the system and gave us the feedback that shaped it. So it was their problem, defined with them, not something handed over at the end.

Do you think that ministry officials changed how they saw AI, through the process of working alongside you?

I think so. With AI, you don’t trust it at the start; you come to trust it over time, once you’ve seen it work. They saw that the system could do in a fraction of the time what they’d do manually, and just as accurately, and they appreciated that. But they also learned to keep cross-checking it. We talked a lot about the “black box” nature of these models, and that’s exactly why human validation matters, however much you trust the output. They got more curious too, about the difference between a pre-trained model and one you build yourself.

And how did your particular mix of skills shape how the project turned out?

A lot, I think. I come from an engineering background, and one thing I always take from that is weighing everything up: the design considerations, the different priorities a project brings. My training experience, from the Raspberry Pi Foundation, came in handy too, especially for running the workshops and writing the documentation. Bringing that together is what made me effective here. I could look at what the ministry actually wants and the challenges they face, while also asking whether it makes economic sense, whether it can be integrated into the existing system, and then testing it in practice. Someone who only knows software might focus on building the thing and not evaluating it. Someone strong on ideas but not on building would struggle to actually make it. It was holding both, and being able to train the team to maintain it, that let me push the project through to completion.

Last one. If you had unlimited time and funding, what would you want to do?

I’d start by proving this idea properly at home, here in Kenya, by showing how much our solution actually reduces inconsistencies, and how much capitation leakage it saves. Money and resources are always the real challenge. So, get it working locally, save as much money as possible locally, and from there it’s smooth sailing. Then scale it, horizontally and vertically. This isn’t only a Kenyan problem, or only an education problem. A lot of African countries, a lot of countries across the global south, face the same inconsistencies in their data, in other sectors too. So scale it every way possible. And beyond the golden record, I’m interested in using AI agents to deploy teachers. If a school doesn’t have a teacher for the new competency-based curriculum, can an agent find a qualified one, send them what they need and direct them to that school? Getting the right teachers to the right places. That’s what I’d want to build next.

Sam Waweru was the AI expert on Kenya’s prototype in the Ministry of Education AI Challenge, an EdTech Hub programme.

< Back to all interviews