An ODPC Readiness Checklist for AI Systems
A self assessment you can run against any AI deployment before it touches customer data, with the evidence a regulator would actually ask for.
What this is, and what it is not. This is a self assessment you can run against an AI deployment before it touches personal data. It is not legal advice, and it is not a certification. Compliance is a property of your organisation, assessed against your processing, by your regulator. No vendor can hold it on your behalf, and any vendor telling you their product makes you compliant is selling you something that does not exist. Verify every legal reference here against the current text of the Act and take advice from qualified counsel.
Start with the obligation nobody mentions
Before any checklist, one question that catches out a surprising number of organisations already running AI pilots.
Are you registered with the Office of the Data Protection Commissioner as a data controller or processor?
Registration is a statutory obligation under the Data Protection Act 2019, with thresholds set out in regulations, and it is entirely independent of any technology you deploy. An organisation that has not registered but is running an AI assistant across its customer database has a problem that no architecture fixes.
Check first. It is inexpensive and quick, and it is the first thing anyone looking at you will look at.
What the Act asks of an AI system
The Act has no AI chapter and does not need one. It regulates the processing of personal data, and an AI assistant querying your customer records is processing personal data. The existing obligations apply unchanged.
In practice four of them do most of the work.
Purpose limitation and minimisation. Data collected for a stated purpose cannot be quietly repurposed, and you should be processing the least you need. An assistant with broad read access across every system in the building is difficult to reconcile with either idea.
Security measures. The Act requires appropriate technical and organisational measures to protect personal data against unauthorised access, alteration, disclosure or destruction. Note the word appropriate. It scales with sensitivity, and customer financial records sit at the high end.
Accountability. You must be able to demonstrate compliance, not merely assert it. This is the one that AI makes materially harder, because it multiplies the number of people who can extract a broad slice of customer data from a single sentence of natural language.
Cross border transfer. Moving personal data outside Kenya requires an appropriate basis and safeguards. Most consumer AI tools process outside the country by default, which is a transfer whether or not anyone characterised it that way.
There is also a breach notification duty running to a tight timeline, commonly understood as 72 hours from becoming aware. The practical problem is not the deadline. It is that without logs you do not become aware, so the clock never starts and you discover the breach when somebody else tells you.
On penalties, one correction worth having
The Data Commissioner may issue a penalty notice. The figure usually quoted is up to KES 5 million, or in the case of an undertaking up to one per cent of annual turnover for the preceding financial year.
The part usually dropped is whichever is lower. Materials in circulation routinely present this as though the regulator picks the larger number, which is both wrong and unhelpful, because it produces a board conversation about a catastrophic penalty rather than the real exposure.
The real exposure is not the fine. It is being unable to produce records. Accountability is demonstrated with evidence, and an organisation that cannot show who accessed what has failed the test before any question of penalty arises.
Why consumer AI tools fail this test
The workflow is the same in every organisation.
Someone exports the M-Pesa statement to CSV. Someone exports the unpaid invoices. Both get pasted into a consumer chat window with a request to reconcile them and flag discrepancies. An answer comes back in half a minute. The chat history gets cleared, because the person doing it knows they should not have.
Run that against the four obligations above and it fails every one. No record of what was sent, no attribution to a person, no control over where it was processed, no way to demonstrate anything afterwards.
The instinct is to ban it. Banning does not work, for a reason worth stating plainly: your team is not trying to breach anything. They are trying to close the month. Block the tool and the work moves to personal phones, where you have no visibility at all, and the organisation is measurably worse off than before the ban.
What works is making the compliant route the easy one.
The checklist
Six sections. Run it against any AI deployment before it touches personal data, and again annually. The evidence column is the important one, because at an audit the question is never whether you have a control. It is whether you can show it working.
A. Identity and access
| Requirement | Evidence to hold |
|---|---|
| Every user resolves to a named individual | User identifier present on every log entry |
| No shared service accounts for AI access | Authentication records, account inventory |
| Role based access enforced at tool level | Role definitions and permission matrix |
| Access scoped to the records the role needs | Scope rules, and evidence they run before retrieval |
| Access reviewed on a set cadence | Dated review records with sign off |
The fourth row is the one that separates a real control from a described one. Filtering results after retrieval means the data was already pulled. The constraint has to apply before the query runs.
B. Purpose and transparency
| Requirement | Evidence to hold |
|---|---|
| Processing purpose documented for each AI use case | Internal policy, privacy notice |
| Data subjects informed that AI processing occurs | Published privacy notice, version history |
| Minimisation enforced technically, not by policy alone | Field level rules, redaction configuration |
| Purpose limitation enforced at the connector | Tool scoping configuration |
| A DPIA completed where processing is high risk | The assessment itself, dated and reviewed |
On the last row: an AI system processing customer personal data at scale is a strong candidate for a data protection impact assessment. If you have not done one, that gap is usually more consequential than any technical control on this list, because it is documentary evidence that you thought about the risk before deploying.
C. Security
| Requirement | Evidence to hold |
|---|---|
| Encryption in transit and at rest | Configuration, certificate inventory |
| Prompt injection screening on write capable tools | Security logs showing blocked attempts |
| Sensitive fields stripped from responses | Redaction rules and sample outputs |
| Rate limiting per user and per tool | Configuration and triggered events |
| Secrets held outside application code | Secret manager configuration |
D. Audit and accountability
| Requirement | Evidence to hold |
|---|---|
| Every AI query logged, including denials | Log samples covering both outcomes |
| Logs carry user attribution and timestamp | Log schema |
| Logs record which systems were touched | Log schema |
| Logs record volume returned | Log schema |
| Query text held as a hash, not plain text | Log schema |
| Logs exported to your monitoring platform | Integration test result |
| Retention set to the longest applicable obligation | Retention configuration and the mapping behind it |
Two of these are easy to get wrong in a way that creates a new problem.
Log denials, not just successes. A refused request is the record proving the control was live rather than documented. It is the most useful entry in the log at audit.
Do not log raw identifiers. The instinct is to record the National ID so you can answer who accessed a given customer’s data. Do not. You would be building a permanent, widely readable, high volume store of exactly the identifiers you are protecting, inside the control meant to protect them. Log a pseudonymous reference and hold the mapping separately under tighter access.
E. Data location
| Requirement | Evidence to hold |
|---|---|
| Processing location known and documented for every component | Architecture document, region configuration |
| Every subprocessor listed with its location | Subprocessor register |
| Transfer basis and safeguards documented where data leaves Kenya | Contractual terms |
| Location disclosed in the privacy notice | Published notice |
The row that catches people is the second. Transactional mail, error tracking, product analytics and, in any retrieval system, the embedding model. Embedding is not an exception to data location: to produce the vector, the provider receives the text. A residency claim that overlooks the embedding step is not accurate.
F. Breach response
| Requirement | Evidence to hold |
|---|---|
| Detection capable of surfacing anomalous access | Alert configuration, triggered examples |
| Notification procedure with named owner and timeline | Incident response plan |
| Data subject notification procedure | Incident response plan |
| Breach register maintained | The register |
| Procedure tested, not just written | Dated tabletop exercise record |
Three situations this prepares you for
A request for documentation
A letter arrives asking you to document AI processing activities for a period.
Without this in place, there is nothing to produce. Not incomplete records, none, and the honest answer is that you do not know what was sent to which tool by whom.
With it, you export the period, show attribution on every call, demonstrate that sensitive fields were removed, and evidence where processing occurred. The request closes on documents rather than assurances.
Customer data appearing where it should not
Something surfaces publicly and the source is unknown.
Without logs, you cannot rule anything in or out. You cannot establish when, or whether an AI tool was involved at all, and the notification window passes while you are still trying to work out what happened.
With them, you query access to that customer’s records, establish the timeline, and confirm whether redaction applied. Frequently the useful outcome is ruling the AI path out entirely, which you can only do if it was instrumented.
An allegation about an employee
Someone reports that a colleague is sending sensitive material to external tools.
Without logs there is no investigation, only an accusation and a denial. With them there is a factual record, which protects the employee as often as it implicates them. That is worth saying internally when you introduce logging, because it is true and it changes how people receive it.
Assessing an AI vendor
Whoever you buy from, including us, put these in writing.
Where does each component run, and which subprocessors are involved? Ask for the full list. If the answer is a region name without a subprocessor register behind it, keep asking.
What exactly is logged, and can I see the schema? Vague answers here usually mean the logging was added late and captures less than you need.
Can you produce every access to one customer’s data over a period, and how long does it take? This is the question a regulator asks, so make the vendor answer it during evaluation rather than during an incident.
What certifications do you hold today, and what is on the roadmap? Ask for current status in writing. A vendor who answers precisely, including where they have gaps, is telling you something useful about how they operate. A vendor who says their product makes you compliant is telling you something too.
What happens to my data if we leave? Export format, deletion timeline, deletion evidence.
A sequence that works
Weeks 1 and 2, find out what is actually happening. Survey departments about AI use, honestly and without blame, because the answer is only useful if people tell the truth. Map what data reaches which tools. Run this checklist against current state and record the gaps.
Weeks 3 to 6, build the governed route. Deploy access infrastructure with attribution, role based control and logging. Connect the systems people are already exporting by hand, because those are the ones the shadow workflow is built on. Set retention against the longest applicable obligation.
Weeks 7 and 8, policy and people. Publish an AI usage policy naming approved routes and prohibited ones. Train on the workflow rather than on prompting. Give accountability to a named person. Set a review cadence.
Then keep going. Quarterly access reviews, annual reassessment against this checklist, and monitoring for anomalous volume, which is your best early signal of anything going wrong.
The point of all this
Governance is not the obstacle to AI here. The absence of it is, because it forces compliance to refuse every use case that would actually be worth something, which pushes the work into tools where nobody can see it.
Build the governed route and the calculation inverts. The compliant path becomes the fast path, the shadow workflow loses its reason to exist, and the question of who accessed what last Tuesday has an answer.
This article is general information, not legal advice. Verify all statutory references against the current text of the Data Protection Act 2019 and take advice from qualified counsel on your own processing.
Msharti is the AI access layer for African enterprise, connecting AI assistants to M-Pesa, KRA, Sage, core banking and Microsoft 365 through one governed endpoint with role based access and query level audit. Built in Nairobi. Talk to us.
See it running against your own systems.
Book a 20-minute demo. We'll connect one of your systems live.
Talk to Us