AI and the Kenya Data Protection Act, 2019

What the Act covers

The Data Protection Act, 2019 gives effect to Article 31(c) and (d) of the Constitution of Kenya and regulates the processing of personal data. It establishes the Office of the Data Protection Commissioner (ODPC), sets out principles that controllers and processors must observe, creates rights for data subjects, and provides for enforcement.

Two words carry most of the weight. Personal data means information relating to an identified or identifiable natural person — which is broader than people expect, covering phone numbers, ID numbers, photographs, location, and combinations of otherwise innocuous fields that together identify someone. Processing means essentially anything you do with it: collecting, recording, storing, retrieving, using, disclosing, erasing.

Both definitions are technology-neutral, and that is the entire point for our purposes. Sending a customer record to a language model API is processing. Storing a WhatsApp conversation transcript is processing. Indexing employee files into a retrieval system is processing. Fine-tuning on historical claims data is processing. There is no AI exemption, and there is unlikely ever to be one.

The Act also recognises categories of sensitive personal data — including health data, biometric data, and data revealing race, ethnicity, religious beliefs or sex life — which attract stricter conditions. Any AI project touching health records, biometric identification or similar material should be treated as a higher-risk project from the outset, not adjusted later.

Lawful basis: the first question

Before processing personal data you need a lawful basis for doing so. The Act sets out grounds including consent, performance of a contract, compliance with a legal obligation, protection of vital interests, performance of a public task, and legitimate interests.

The question that catches organisations out is not whether they had a basis for collecting the data originally. It is whether that basis extends to the new AI use.

Consider a concrete case. You collected customer phone numbers and purchase history to fulfil orders — clearly contractual necessity. You now want to use that history to train a model predicting which customers will churn, and to send them targeted offers. Is that covered by the original basis? Possibly, under legitimate interests, if the use is compatible with the original purpose and you have weighed it against the data subjects' rights and interests. Possibly not, if a reasonable customer would be surprised by it.

The practical discipline: write down the lawful basis for each processing purpose before you build. Not after the system exists and somebody asks. It takes an hour, it forces a useful conversation, and it is the document you will want if the ODPC ever asks a question.

The principles that bite hardest

The Act's principles all matter, but three of them create real design constraints on AI systems.

Data minimisation

Process only what is adequate, relevant and limited to what is necessary. This collides directly with the instinct of most AI projects, which is to gather everything on the theory that a model might find something useful in it. That instinct is now a compliance problem as well as a security one. Design retrieval and extraction to pull only the fields required for the task, and resist the temptation to index entire document stores because it is easier than deciding what matters.

Storage limitation

Keep personal data no longer than necessary. AI systems accumulate data quietly in places nobody thinks to include in a retention schedule: conversation logs, vector embeddings, prompt and completion logs kept for debugging, evaluation datasets built from real cases. Every one of those may contain personal data, and every one needs a documented retention period implemented as an actual scheduled deletion job rather than an intention.

Integrity and confidentiality

Appropriate security, including against unauthorised access. For AI systems this specifically means: retrieval must enforce access control, so a staff member cannot obtain through the assistant what they could not obtain directly. This is one of the most common design failures we encounter — an internal knowledge assistant indexed over a whole shared drive, cheerfully answering an intern's question using the contents of a salary review document. The permission model must live in the retrieval layer, applied as a filter on what can be returned, not in a prompt instructing the model to be discreet.

Sending data to overseas AI providers

Most frontier models are operated outside Kenya, so using them means transferring personal data across a border. The Act permits this where its conditions are met — including where appropriate safeguards exist, or on the basis of consent, or where the transfer is necessary for certain specified purposes.

What this means practically:

• Have a contract. Business and enterprise agreements with the major providers include data processing terms. Read what they actually say about retention and about training on your inputs, for your specific plan, and keep a copy.
• Document the transfer. Which data, to whom, where processed, under what safeguards, for what purpose. This record is the substance of compliance.
• Disclose it. Your privacy notice should tell people that their data may be processed by service providers outside Kenya. Burying it is not disclosure.
• Minimise before sending. Redact or tokenise identifiers where the task does not need them. A summarisation task rarely requires the customer's ID number to be in the prompt.
• Consider local deployment for sensitive categories. Open-weight models running on infrastructure you control remove the transfer question entirely. They cost more and perform somewhat below the frontier models, and for health or biometric data that trade-off is often the right one.

Automated decisions and human oversight

The Act provides rights for data subjects in relation to decisions based solely on automated processing that produce legal effects concerning them or similarly significantly affect them.

The design conclusion is straightforward and, in our view, correct regardless of the law: for any decision that materially affects a person's livelihood or access to services — credit, insurance, employment, tenancy, benefits — keep a named human accountable for the outcome.

That does not neuter the technology. AI can still assemble the file, extract the fields, verify the documents, check the arithmetic, compare against policy, summarise the history and flag anomalies. All of that removes the tedium. What it must not do is issue the decision on its own. And “a human clicked approve” is not meaningful oversight if the human sees only a score with no reasoning and has no practical ability to disagree. Build the interface so the reviewer can see why, and so overriding is easy and recorded.

Data subject rights in an AI system

People have rights to be informed, to access their data, to correct it, to object to processing, and to have data erased in certain circumstances. AI systems make some of these operationally awkward, and it is better to design for them than to discover the problem when a request arrives.

• Access. Can you produce everything you hold about one person — including conversation logs, extracted fields and anything sitting in an evaluation set? Store an identifier that makes this possible.
• Correction. If a record is wrong and it has been embedded into a vector index, correcting the source is not enough. You need re-indexing.
• Erasure. Deleting the row is not deleting the data if copies exist in embeddings, caches, prompt logs and backups. Map where personal data comes to rest before you go live, and build deletion that reaches all of it.
• Objection. Can you exclude one person from a processing activity without breaking the system? Worth testing before you need it.

The risk already happening in your office

If you take one practical action from this article, make it this one.

Right now, in most Kenyan organisations, staff are using AI tools on personal accounts. They are pasting in customer lists to reformat them, draft contracts to simplify them, patient notes to summarise them, and employee grievances to help write a response. They are doing it to work faster, not to cause harm, and they have no idea it is a problem.

This is unauthorised disclosure of personal data to a third party, without a lawful basis, without a contract, without a record, and without any technical control. It is invisible to your IT function because it happens in a browser on a personal login. It is, in our experience, the single largest live data protection exposure most organisations have in relation to AI — and it is also the cheapest to fix.

The fix is not a ban. Bans move the behaviour underground and remove your visibility entirely. The fix is:

1. A written policy stating clearly what may go into which tools, in language a busy person will read.
2. A sanctioned tool with appropriate contractual terms, so people have a compliant option they actually prefer to the unsanctioned one.
3. One training session, so the rule is understood rather than merely published.

That is typically a week of work and it closes most of the exposure.

Controls to build in from day one

A checklist we work through on every project that touches personal data:

• Data map. What personal data enters the system, where it goes, where it rests, who can reach it. Without this, nothing else can be assessed.
• Lawful basis per purpose, written down before building.
• Minimisation by design. Field-level decisions about what the model actually needs to see, with redaction where it does not.
• Access control in the retrieval layer, so permissions are enforced by the system rather than requested in a prompt.
• Retention schedules as running jobs, covering logs, transcripts, embeddings and evaluation sets.
• Audit logging of access to personal data, retained for a defined period.
• Human review for any materially significant decision, with reasons visible and override easy.
• Data processing agreements with every provider in the chain.
• Privacy notice updated to reflect AI processing and overseas transfers.
• Incident procedure covering what happens if the system leaks or misuses data, including who is notified and how quickly.

None of this is exotic, and none of it is expensive when done at design time. All of it is painful when retrofitted to a system already in production. That asymmetry is the argument for doing it first.