Data Protection

DPIA Requirements in Kenya: 8 Critical AI Checks

DPIA requirements in Kenya apply when data processing is likely to create a high risk to people’s rights and freedoms. If your organisation uses artificial intelligence to score, rank, recommend, monitor or make decisions about people, it may need a data protection impact assessment before the processing begins.

That duty does not depend on Kenya passing a new AI statute. It already exists under section 31 of the Data Protection Act, 2019. The Office of the Data Protection Commissioner has also published a draft Guidance Note on Artificial Intelligence, signalling how the regulator expects existing data protection duties to apply across the AI lifecycle.

The practical question is no longer whether AI creates privacy risk. It is whether your organisation can show that it identified and addressed that risk before deployment.

Key point: Draft guidance is not law. The Data Protection Act, 2019 and the Data Protection (General) Regulations, 2021 are already in force.

Quick overview

• The DPIA requirements in Kenya come primarily from section 31 of the Data Protection Act, 2019 and regulations 49 to 53 of the General Regulations.
• The assessment must be completed before high-risk processing begins.
• AI systems used for automated decisions, biometrics, large-scale monitoring or sensitive data deserve early screening.
• A vendor’s security certificate does not replace your organisation’s own DPIA.
• The eight checks below provide a practical starting framework, not a substitute for advice on a specific deployment.

What do the DPIA requirements in Kenya mean?

A data protection impact assessment, usually called a DPIA, is a documented review of proposed processing that is likely to create a high risk to the rights and freedoms of individuals.

Under section 31 of the Data Protection Act, a DPIA should describe the proposed processing and its purpose, assess whether the processing is necessary and proportionate, identify risks to data subjects, and record the safeguards that will address those risks.

The assessment must take place before the processing. If the DPIA shows that a high risk remains, the controller or processor must consult the Data Commissioner before proceeding. The Act also requires DPIA reports to be submitted 60 days before processing.

This timing matters. A DPIA completed after a system is already screening candidates or scoring customers is a record of an existing problem, not evidence that privacy risk shaped the deployment.

Meeting the DPIA requirements in Kenya therefore starts at project design, not at launch.

When do DPIA requirements in Kenya apply to AI?

The legal test is whether the nature, scope, context and purpose of the processing make it likely to result in high risk to a data subject’s rights and freedoms.

The General Regulations identify several warning signs that frequently appear in AI projects. These include automated decision making with legal or similarly significant effects, large-scale processing, biometric or genetic data, combining data from different sources, systematic monitoring, repurposing personal data and innovative uses of new technology.

In practice, you should screen an AI deployment for a DPIA if it does any of the following:

• scores people for credit, insurance, fraud or eligibility;
• screens or ranks job applicants;
• monitors employee activity or productivity;
• uses facial recognition or other biometric data;
• analyses health or patient records;
• recommends content or offers based on behavioural profiles;
• combines customer, employee or public datasets to infer new information; or
• makes or materially influences a decision with significant consequences for an individual.

The ODPC’s draft AI guidance reportedly gives concrete examples across finance, health, employment, education, authentication, recommendation systems and employee monitoring. Those examples are useful indicators of regulatory direction. Until the final note is issued, however, the safest publication position is to apply the statutory high-risk test rather than describe every reported example as a new mandatory rule.

Automated decisions need more than a privacy notice

Section 35 of the Act and regulation 22 address automated individual decision making. Where a system makes a decision without human involvement, organisations may need to provide meaningful information about the logic involved, explain the significance and likely consequences, prevent and correct errors, reduce discriminatory effects, and allow the data subject to obtain human intervention.

A nominal human approval step does not necessarily solve the problem. The reviewer must have the authority, information and time to challenge the system’s recommendation. If staff routinely accept a score without examining it, the process may remain automated in substance.

Your DPIA should therefore identify:

• what the model recommends or decides;
• which data influences the result;
• the likely consequences for the person affected;
• how accuracy, bias and model drift are tested;
• who can override the output and on what basis; and
• how a data subject can question or appeal the result.

Publicly available data is not automatically free training data

AI teams often assume that personal data may be used for model training because it appears on a public website, social network or registry. That assumption is unsafe.

Kenya’s data protection principles still require a lawful basis, a specified purpose, transparency, data minimisation and appropriate retention. Public availability does not erase those duties. Nor does consent collected for one purpose automatically authorise a different use.

For example, customer calls recorded for quality assurance do not automatically become lawful training data. Employment records gathered to administer payroll do not automatically become inputs for a performance model. A public professional profile does not automatically authorise scraping for an unrelated commercial system.

Before using personal data to train, fine-tune, evaluate or ground an AI system, document where the data came from, the original purpose of collection, the lawful basis for the new use, the retention period, and whether anonymised or synthetic data could meet the same need.

Your AI vendor does not carry your DPIA duty for you

A third-party platform may provide security reports, model cards or compliance certificates. These documents can support due diligence, but they do not assess the risks created by your specific use of the tool.

The controller remains responsible for understanding the deployment. That means knowing what personal data is sent to the vendor, where it is processed, whether sub-processors are involved, how long prompts and outputs are retained, whether submitted data is used to improve models, and how the vendor supports data subject rights.

If the vendor will process personal data on your instructions, the engagement should also be governed by a written controller-processor contract that meets regulation 24. This is a separate obligation from the DPIA, and it should be addressed during procurement rather than after signature.

8 checks for meeting DPIA requirements in Kenya

A useful AI DPIA should answer eight practical questions. These checks turn the DPIA requirements in Kenya into an operational review:

1. What is the system meant to do? Define the business purpose and the decision or workflow it affects.
2. What personal data enters the system? Include prompts, attachments, logs, outputs, embeddings and inferred data.
3. Where did the data come from? Record the source, original collection purpose and lawful basis.
4. Who may be affected? Identify customers, employees, applicants, patients, children or other vulnerable groups.
5. What could go wrong? Assess inaccurate outputs, bias, exclusion, data leakage, unauthorised reuse and inability to explain decisions.
6. Is the processing necessary and proportionate? Consider less intrusive data, narrower access, shorter retention or meaningful human review.
7. What does the vendor do? Document hosting locations, sub-processors, training practices, security controls, deletion and incident support.
8. Who owns the controls? Name the accountable business owner, privacy lead, security lead and human decision-maker.

The result should be a living governance record. Review it when the model, data source, purpose, vendor or affected population changes.

Documenting these decisions is central to meeting the DPIA requirements in Kenya and showing why the residual risk was accepted.

A 30-day AI data protection plan

Week 1: Build an AI system register

List every tool that scores, ranks, predicts, recommends, transcribes, generates, matches, flags or monitors. Include software bought directly by HR, marketing, finance and operations.

Week 2: Map the data flows

Record the categories of personal data involved, data subjects, processing locations, recipients, sub-processors, retention periods and cross-border transfers.

Week 3: Prioritise high-risk uses

Start with employment, credit, health, biometrics, systematic monitoring and decisions with significant effects. Confirm whether each deployment has a current DPIA.

Week 4: Close the contracting and control gaps

Complete or update the highest-priority DPIAs. Review AI vendor contracts against regulation 24. Confirm human oversight, incident notification, deletion, audit and transfer safeguards.

Frequently asked questions about DPIA requirements in Kenya

Is a DPIA mandatory in Kenya?

Yes, where a processing operation is likely to result in high risk to a data subject’s rights and freedoms. Section 31 sets the legal test. The facts of the proposed processing determine whether it applies.

Must a DPIA be completed before using an AI tool?

If the proposed AI processing is likely to create high risk, the assessment must be carried out before processing. Procurement and pilot testing should therefore include DPIA screening before live personal data is used.

Does an overseas AI vendor’s DPIA cover a Kenyan customer?

Not necessarily. A vendor’s assessment may provide useful evidence, but it does not evaluate your purpose, users, data subjects, decisions or local legal duties. Your organisation must assess the risk created by its own deployment.

Who should conduct an AI DPIA?

The work should bring together the business owner, privacy or data protection lead, information security team, procurement or legal team, and the people responsible for meaningful human oversight. Technical and operational input is essential.

Do not wait for the final AI guidance

The ODPC’s draft note may change before it is finalised. The statutory duties behind it will not disappear.

An organisation that acts now can show that it identified high-risk processing, tested necessity and proportionality, documented safeguards and assigned accountable human oversight. An organisation that waits may have to assemble the same evidence after an incident, complaint or regulatory inquiry.

The DPIA requirements in Kenya are designed to make that assessment happen before an AI system begins making decisions about people.

MNL Advocates advises banks, fintechs, health providers, employers and technology businesses on DPIAs, automated decision making and responsible AI deployment. To assess a proposed system or review tools already in use, contact our Data Privacy & Protection team.

Suggested internal links before publication

• Link “controller-processor contract” to Article 2 below.
• Link “cross-border transfers” to the firm’s existing cross-border data transfer service or insight page.
• Link the closing CTA to the firm’s Data Privacy & Protection practice page.

Primary sources for editorial review

• Data Protection Act, 2019, including sections 31, 35, 43, 48 and 49
• Data Protection (General) Regulations, 2021, including regulations 22, 24, 25 and 49 to 53
• ODPC draft guidance notes consultation page

Pre-publication note

Confirm whether the ODPC has issued a final Guidance Note on Artificial Intelligence. If it has, update the draft-status language and verify any named examples against the final document.

Updated guidance for organisations on building a defensible data protection record: what to document, what to measure, and what to show regulators, partners, and customers.

In 2026, data protection compliance is no longer judged by what your privacy policy says. It is judged by what you can prove on demand: decisions, controls, logs, contracts, and records. Organisations that cannot produce a credible privacy evidence pack quickly will struggle under regulator questions, enterprise procurement scrutiny, or post-incident review.

Bottom line: Build a privacy evidence pack that lets you answer due diligence and audit questions fast, without scrambling across email threads and spreadsheets.

Contents

1. What a privacy evidence pack is and why it matters in 2026
2. The 10 privacy artifacts every organisation should have
3. Cross-border data transfers: document it in 5 steps
4. AI and privacy: 7 controls for teams using AI tools
5. How to run privacy as a system: cadence and KPIs
6. FAQ

1. What a Privacy Evidence Pack Is and Why It Matters in 2026

A privacy evidence pack is the set of materials that demonstrate how your organisation manages personal data in practice, not just in policy. It is what makes data protection auditable and defensible internally (board oversight), externally (partners and enterprise customers), and regulator-facing (when questions arise).

This matters globally because privacy regimes differ in their details but converge on a shared expectation: accountability, transparency, and demonstrable controls. Whether you are subject to Kenya’s Data Protection Act, the GDPR, or equivalent frameworks, the evidence standard is broadly the same.

2. The 10 Privacy Artifacts Every Organisation Should Have (2026)

If you want a documentation standard that travels well across jurisdictions, focus on artifacts that satisfy multiple regulatory frameworks simultaneously. These ten items form a practical baseline for any organisation handling personal data.

What “Good” Looks Like Across All 10 Artifacts

• Owned: each artifact has a named owner and a defined review cadence.
• Current: updated whenever vendors, products, or data flows change.
• Provable: you can show records and decisions, not just policy statements.

3. Cross-Border Data Transfers: Document It in 5 Steps

Most organisations transfer personal data across borders without recognising it as a transfer. Cloud hosting, CRMs, helpdesks, analytics platforms, marketing tools, and AI vendors can all create cross-border data flows that require documentation and appropriate safeguards.

Practical Tip

Start with your top ten vendors ranked by data sensitivity and volume. Do not attempt to perfect the entire map at once. Get a defensible baseline documented first, then iterate as you onboard new tools or expand into new markets.

4. AI and Privacy: 7 Controls for Teams Using AI Tools

In 2026, many organisations face a data protection risk that did not exist at the same scale a few years ago: everyday data leakage into AI tools through prompts, file uploads, meeting notes, transcripts, and customer tickets. AI adoption also increases vendor complexity and creates new cross-border transfer obligations.

Minimum Documentation for AI Use

• AI use register: tool name, purpose, owner, data input types, and risk classification.
• Data entry restrictions: a clear record of what categories of data cannot be entered into external AI tools.
• Vendor controls: data retention terms, training-use clauses, incident notification obligations, and sub-processor lists.

5. How to Run Privacy as a System: Cadence and KPIs

Monthly Review

• Vendor changes and newly adopted tools, especially AI tools.
• New processing activities arising from product or service changes.
• Open data subject rights requests and incident log review.

Quarterly Review

• High-risk processing review: DPIAs and PIAs for new or changed activities.
• Cross-border transfer review for top vendors.
• Board and leadership privacy report covering risks, incidents, and remediation status.

KPIs That Are Practical to Track

• Average time to complete data subject rights requests.
• Percentage of critical vendors with signed DPAs and documented transfer safeguards.
• Time-to-triage for incidents and time-to-close for remediation actions.
• Percentage of teams trained and completion rate of AI-use controls.

Need This Implemented in Your Organisation?

MN Legal supports privacy evidence-pack readiness, vendor and cross-border transfer contracting, AI governance controls, and breach readiness so your organisation can demonstrate compliance efficiently when it matters most.

Make an enquiry  |  Explore Practice Areas

Key References

• Council of Europe: Data Protection Day
• EDPB guidance
• ICO (UK) guidance
• OECD privacy resources
• NIST Privacy Framework

Frequently Asked Questions

What is a privacy evidence pack?

A privacy evidence pack is the set of documents, logs, and records that prove how your organisation manages personal data in practice, going beyond policy statements alone. It typically includes your processing register, DPIAs, vendor DPAs, incident log, data subject rights log, retention schedule, and staff training records.

Does our organisation need a DPIA?

A DPIA is most valuable when processing is likely to create high risk for individuals. For example, large-scale processing of sensitive data, profiling, automated decision-making, or the use of new technologies. It is also strong evidence that you assessed risks and implemented appropriate controls before processing began.

How should we handle cross-border data transfers in 2026?

Map your transfers by system, vendor, and destination country. Identify the legal mechanism and safeguards applicable to each transfer, document your risk assessment, ensure appropriate contractual clauses are in place, and maintain an evidence trail of approvals and periodic reviews.

What should we do about staff using AI tools with personal data?

Maintain an AI use register, establish clear restrictions on what data categories may be entered into external tools, implement vendor procurement and contractual controls, require human review for high-impact AI outputs, and keep an audit trail for high-risk use cases.

What do regulators and procurement teams ask for during due diligence?

Common requests include your processing register, privacy notices, completed DPIAs, vendor DPAs and transfer documentation, a security measures summary, your incident response plan and incident log, and records of data subject rights requests and staff training completion.

How can MN Legal help with data protection compliance?

MN Legal supports privacy programme design and evidence-pack readiness, vendor and cross-border transfer contracting, AI governance controls, and incident readiness so organisations can demonstrate compliance efficiently when facing regulators, partners, or post-incident scrutiny.

Disclaimer: This article is for general information only and does not constitute legal advice. Requirements vary by jurisdiction and specific facts. For advice on your organisation’s situation, contact MN Legal.