The Short Answer
Kenya's draft AI policy proposes allocating liability across the whole deployment chain — developers, deployers, operators, vendors, and users — so "our vendor handles that" would stop discharging responsibility. Meeting it requires reconstructing what your AI actually did, which is only possible when you own all the code and the data. On ibl.ai that stack is model-agnostic, self-hosted, and carries no per-seat pricing.
It is a draft, not binding law — the Ministry of Information, Communications and the Digital Economy published it for comment, with the window closing 4 August 2026. The direction it signals is what matters for anyone renting AI infrastructure.
What does Kenya's draft AI policy actually say?
It proposes spreading legal responsibility for AI outcomes across every party in the chain: the developer who built the model, the deployer who put it into a workflow, the operator who runs it, the vendor who supplied it, and the user who acts on its output.
The document itself creates no binding obligation. It follows Kenya's National Artificial Intelligence Strategy 2025–2030 and signals the shape of future legislation, and it is reported to reach foreign providers whose systems are used in Kenya.
That differs from the more common approach of concentrating obligations on whoever is nearest the harm, or on the largest provider. Full-chain liability says the question "who is responsible?" has more than one correct answer at once.
It is a short rule with a wide surface. Any party that touched the system may be asked to account for its part.
Why would a smaller jurisdiction write a cleaner rule?
Because clarity is cheapest to write where nobody powerful is lobbying against it.
Full-chain liability is structurally unattractive to large model providers: it removes the option of shipping a capability and locating responsibility downstream with whoever integrated it.
In jurisdictions where those providers are significant employers and taxpayers, that position is argued against hard and early.
Kenya does not have that concentration of incumbent interest, and the resulting rule is correspondingly blunter.
This is not a claim that the draft is beyond criticism — full-chain liability has real costs, particularly for small deployers who would carry obligations they may lack the capacity to meet. It is also a proposal, so what survives into law may look different.
It is a narrower observation: regulatory capture shapes text, and text written outside its reach tends to state the obvious thing more plainly.
What does full-chain liability change for a deployer?
It converts vendor selection into legal exposure.
Under a regime that attaches responsibility to the deployer regardless of who built the model, every dependency in the stack is a party whose failures you may answer for and whose internals you cannot inspect.
The contract may allocate risk between you and the vendor, but it does not bind the regulator.
Three practical consequences follow:
- "Our vendor handles that" stops being a defense, because the rule names you as the deployer independently.
- Diligence has to reach the architecture, not only the terms — where inference runs, what is retained, and by whom.
- Evidence becomes your obligation, not something you request from a supplier after an incident.
What evidence does a liability regime actually require?
The same artifacts a regulator or a court would ask for in any other model-risk context, captured at the moment of generation:
| Evidence | Question it settles | On rented infrastructure |
|---|---|---|
| Prompt + retrieved context | What did the system see? | Vendor retention setting |
| Model version | Which system produced it? | May change without notice |
| Action taken | What did the agent do? | Your logs, if you built them |
| ibl.ai (self-hosted) | All three | Logs on your own disk |
Liability you cannot evidence is liability you absorb by default.
Is this framing likely to spread?
The direction of travel already points this way, even where the mechanism differs.
The EU AI Act, in force since 2024, assigns distinct obligations to providers and deployers rather than treating deployment as a passive act.
The NIST AI Risk Management Framework, published in 2023, is voluntary but built on the same premise: risk is managed by whoever operates the system, in context, not only by whoever trained the model.
Kenya's contribution is directness. It states as a single proposition what other regimes arrive at through separate duties — which makes it easier to reason about, and harder to argue your way out of, if it survives into law.
The broader pressure is covered in why government AI must be sovereign, where this policy sits alongside the EU's sovereign-compute rules and a breach that reached 85 Taiwanese government accounts.
What should a deployer do about it now?
Assume the liability attaches to you, then work backwards to what you would need to produce.
- Decide where inference runs. This determines what you can prove afterwards, not merely what you can promise.
- Log actions, not just conversations. In a liability regime the action is what creates the obligation.
- Pin model versions. An answer you cannot reproduce is one you cannot defend.
- Keep the evidence on your side of the boundary, so producing it is a query rather than a support request.
The parallel for regulated filings is worked through in when compliance AI hallucinates.
Where ibl.ai fits
ibl.ai is the agentic AI platform where you own all the code and the data.
You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.
Under full-chain liability that architecture is the difference between producing evidence and requesting it. The prompt, the context, the model version, and the action are all recorded where you can reach them.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.