AI & Machine Learning
AI as a layer on top of a trustworthy system
I treat AI features the way I treat any other backend dependency: define the contract, validate what comes back, and design for the case where it's wrong.
How I approach an AI project
Problem
Define exactly what needs to be extracted, predicted, or classified and why a rules-based approach isn't sufficient.
Data
Identify what real input looks like, including its inconsistencies mixed languages, informal notes, incomplete records.
Processing
Structure the input for the model: prompt design, formatting, and any pre-cleaning needed before it reaches the model.
Model
Select and call the right model for the task often an API-based LLM like Gemini, chosen for the task's structure and cost profile.
Evaluation
Validate output against an expected schema, checking for missing fields, malformed structure, or low-confidence results.
Deployment
Integrate the pipeline into the surrounding backend asynchronously, so model latency doesn't block the rest of the system.
Monitoring
Track failure modes in production use where extraction quality drops, and which input types need better handling.
Responsible AI
Where I draw the lines
- Model output is validated, never trusted as final a structured schema check sits between the model and the database write.
- AI features are scoped to augment a human's work (a clinician reviewing extracted entities), not replace their judgment.
- Where a project touches sensitive data like clinical notes on Uzima Link access to both raw input and model output is scoped by role.
- Concept-stage AI features (like EWaste Hub's batch analysis) are labeled as unvalidated until tested against real data.
Case studies
AI & ML-focused projects
Uzima Link
A multilingual, AI-assisted digital health records platform built for Kenyan clinics and community health settings.