How I Use AI

Why this page exists

I sell AI systems for a living, which means two things are true at once: I use AI tools daily, and I have every incentive to be honest about them. Clients who hire an AI consultant in 2026 are rightly asking harder questions — "what happens to my customer data?", "did a model write this code?", "who is accountable if the system is wrong?". Vague answers like "we use AI responsibly" deserve suspicion. This page replaces the vagueness with specifics: the exact tools, the exact rules, and the exact gates every piece of work passes through before you see it.

Treat this as part of my pitch, not fine print. If any practice below doesn't fit how you want AI handled in your business, that's a discovery-call conversation — not a surprise in week three of a project.

Where AI is used in my work

AI touches my work in three distinct places, and each carries different rules:

Where	What AI does	What it never does
My workflow	Code assistance, refactoring drafts, test-case brainstorming, summarising my own research notes, debugging hypotheses	Final code ships without my line-by-line review; nothing client-identifiable goes into third-party tools
Delivered systems	The AI you're buying: RAG pipelines, chatbots, classification, document extraction, agent orchestration	Train on your data without written consent; run without evaluation suites; hallucinate silently
This website	The readiness assessment scoring runs entirely in your browser	Track you across pages, sell your data, or require an account to read content

The distinction matters because "AI-assisted" means very different things in a drafting tool versus a production system that your customers will interact with. The first is a productivity choice; the second is an engineering responsibility with uptime, evaluation and rollback obligations.

The rules I don't break

These are personal policy, applied to every engagement regardless of contract size:

• No client data in third-party models without written consent. Not "anonymised-ish". Not "just this once". If a project genuinely benefits from a hosted model seeing your data, I say so explicitly, you approve it in writing, and we agree on the provider, retention period and deletion path first.
• Local and self-hosted first, where the use case allows. On-device models, self-hosted open-weight models and private API deployments are my default for anything touching sensitive records — health, HR, financial, or personally identifying data.
• Your data stays yours. Nothing learned from your documents, workflows or domain is reused for another client. Domain knowledge in my head is the deliverable you paid for; your raw data is not mine to carry forward.
• No synthetic testimonials or fake case studies. Every metric on my case-study pages came from a real engagement. AI does not write my reviews.
• Estimates and pricing are computed by me, not generated by a chatbot. The wizards on this site use deterministic arithmetic I wrote — the number you see is the math, not a model's guess.

Your data and the law

Client engagements are structured to comply with the Kenya Data Protection Act, 2019 (DPA), and — where you operate internationally — GDPR principles, because most of the obligations overlap: lawful basis, purpose limitation, minimisation, accuracy, storage limitation, and security.

Concretely, on every project I will: process personal data only for the agreed purpose; collect the minimum the system needs; keep processing records you can audit; delete or return project data at the end of an engagement unless our contract says otherwise; and flag any cross-border transfer (for example, a US-hosted model API) before it happens, so you can decide with the facts. If your organisation needs a Data Processing Agreement, the contract builder and the engagement agreement cover the standard clauses, and I'll sign your DPA template if you have one.

Human review gates

AI-assisted speed is worthless if it ships defects, so every deliverable passes four gates that no model can skip:

• Gate 1 — Line review. Every line of AI-assisted code is read by me before it enters a deliverable. Assistance accelerates writing; it does not replace judgment about architecture, security or edge cases.
• Gate 2 — Evaluation. Delivered AI systems ship with a measurable evaluation: accuracy on a held-out set, retrieval quality for RAG, or task success rate for agents. "It seems to work" is not a gate.
• Gate 3 — Adversarial pass. I attack the system before your users or customers can: prompt injection attempts, out-of-scope questions, malformed documents, boundary conditions.
• Gate 4 — Human hand-off. Any system with consequential outputs (payments, legal text, medical-adjacent advice) includes a human approval step in the workflow, and I'll recommend not automating the final say even when it's technically possible.

Known model risks, and my mitigations

Honest AI work means naming the failure modes instead of hiding them:

• Hallucination. Generative models state falsehoods fluently. Mitigation: retrieval-grounded answers with citations, confidence thresholds, "I don't know" fallbacks, and scoped prompts — not bigger promises.
• Drift. Models and data change under you. Mitigation: monitoring in delivered systems, scheduled re-evaluation, and version pinning so behaviour is reproducible.
• Bias. Models inherit their training data. Mitigation: disaggregated evaluation where it matters (e.g. language variants, demographics in agriculture advisory content), and explicit scoping of what the system will not decide.
• Data leakage. Mitigation: the consent-first rule above, private deployments for sensitive work, and provider selection based on data-retention terms, not hype.
• Silent cost growth. Token bills compound. Mitigation: usage caps and cost dashboards in delivered systems, so surprises arrive as alerts, not invoices.

Disclosure commitments

If you ask "did AI write this?", you'll get a real answer, at this level of granularity:

• Code: I disclose the assist tools used on the engagement and stand behind every line as my work product. AI-assisted code I ship is code I have reviewed, tested and own.
• Documents: Proposals, contracts and invoices are generated by deterministic tools I built, reviewed and issued by me.
• Content: Articles on this blog are written by me. Where AI helped with research summarisation or a first-draft outline, the reasoning, structure and final text are mine.
• Systems: Delivered AI systems come with documentation that states plainly where model outputs affect business decisions and what the human override path is.

Tools currently in rotation

For transparency, the working stack as of September 2026: code assistance in VS Code and JetBrains IDEs; OpenAI, Anthropic and Google model APIs for prototypes and delivered systems where consented; open-weight models (Llama-family and others) for self-hosted deployments; LangGraph-style orchestration for multi-agent work; embeddings + vector stores chosen per project scale. Provider choices are re-evaluated quarterly — on data terms, cost and evaluation results, never on momentum.

Five questions to ask any AI consultant

Including me. If someone can't answer these crisply, that's your answer:

• Which parts of your deliverable were machine-generated, and what did you personally verify?
• Where will my data physically go, and what's the retention period?
• Show me an evaluation of the system. What does it get wrong, and how wrong?
• What happens when the model changes or the provider changes terms?
• Who is accountable when the system is confidently wrong at 2 a.m.?

My AI readiness assessment starts with your data reality, not a demo — because these questions are easier to answer before architecture exists.

Changes to this policy

As tools and the law evolve, this page will be updated with dates, and material changes to data-handling practice are always re-consented with active clients before they take effect — not applied retroactively. Questions about anything here: mututandunda@gmail.com, or raise it directly on a booking call.