Building AI Systems Under East African Data Protection Law

Why you are permitted to process this data, and for what purpose, should be written down before the schema is designed. Purpose limitation is the obligation most often broken accidentally: data collected for service delivery is reused for analytics or model training that nobody described to the people it concerns.

Recording purpose per dataset, and enforcing it in access controls rather than in policy documents alone, is the difference between a defensible system and a hopeful one.

The cheapest way to reduce exposure is to not hold the field. Many systems collect full identifiers because a form template included them, then spend the rest of their life protecting data nobody uses. Where an identifier is genuinely needed for reconciliation, pseudonymisation at ingestion keeps the analytical value without carrying the identity everywhere.

Retention is the same argument over time. A dataset with no deletion rule becomes a growing liability by default.

Where data may live determines hosting, model selection and vendor choice, so it belongs in the first design conversation. Transfers outside the country, including inference calls to a model hosted abroad, need to be identified explicitly and assessed against the applicable regime rather than discovered in an audit.

For some public sector and health workloads this pushes toward in-country or on-premise deployment, which changes cost and operations. That is a decision to make deliberately at the start.

Who read which record, when, and why is a requirement in practice for any system holding citizen or patient data, and it is far cheaper to build in than to retrofit. It is also the control that makes internal misuse detectable, which is the risk most institutions actually experience.

Audit trails serve a second purpose: when a decision is challenged, they are the only way to reconstruct what the system saw at the time.

Any system that affects a person's access to money, service or entitlement should record why it produced its output, and there should be a route for that person to have the decision reviewed by someone accountable. This is both a legal expectation in several regimes and an operational necessity, because models drift and errors need a channel.

Designing for contestability early also improves the system. A model whose reasoning can be summarised to an affected person is usually one the institution understands well enough to operate.

A written purpose and lawful basis per dataset, a data inventory with retention rules, documented residency and transfer positions, access logging that someone reviews, a defined process for data subject requests, and a named internal owner for the whole of it. None of this is exotic, and all of it is much less work at design time.