Safety by Design: Guidance for AI Bot Builders

A THiNK AI Safety Resource for Innovators and AI/ML Developers

Introduction

AI bots are increasingly shaping how people access information, make decisions, and engage with services. With this GREAT power comes responsibility. Safety by Design (SBD) ensures bots are built with trust, responsibility, quality, inclusivity, and resilience at their core.

This guidance provides practical steps for bot builders to embed safety throughout the entire lifecycle of their projects—from concept to scale.

Why Safety by Design Matters

• Unsafe bots can spread misinformation, bias, or harmful content.
• Users may suffer emotional, social, or privacy harms.
• Reputational risks to developers and organizations are high.
• Safe bots build trust, adoption, and long-term impact.
• Safety is also a competitive differentiator in the AI marketplace.

Risks & Harms in AI Bots

a) Common Risks

• Misinformation or disinformation.
• Biased or discriminatory responses.
• Privacy breaches in conversations.
• Manipulation, prompt injection, or malicious misuse.

b) Potential Harms

• Emotional distress from offensive replies.
• Exclusion of marginalized users.
• Reputational harm to creators and organizations.
• Systemic harms at scale (e.g., misinformation campaigns).

c) Features That Strengthen Safety

• Guardrails in Dialogue – Refusal logic, content filters, and safe fallback answers.
• Bias Detection – Representative datasets and fairness audits.
• User Controls – Opt-out options, report abuse buttons, and transparency on the bot's scope.
• Privacy by Design – Minimal data retention, anonymization, and compliance with the Data Protection Act (DPA) and DKS 3007 AI Code of Practice.
• Accessibility & Inclusivity – Support for multiple languages, voice and screen readers, and plain language modes.
• Transparency – Clearly explain what the bot can and cannot do.

Embedding Safety Across the Bot Lifecycle

a) Design Phase

• Map risks and harms early.
• Involve diverse users in the design process.
• Define safety goals and standards.

b) Development Phase

• Train on diverse, safe datasets.
• Build safety guardrails into the code.
• Red-team bots with adversarial prompts.

c) Deployment Phase

• Conduct controlled rollouts (pilots).
• Monitor conversations in real time.
• Provide clear user onboarding with safety guidance.

d) Iteration Phase

• Perform continuous audits and updates.
• Collect and respond to user feedback.
• Align with the evolving AI Code of Practice.

Privacy-First Compliance

Consider the following insights when creating a compliance checklist.

a) Key Items to Consider

• Strong Foundation – PII detection, anonymization, and secure API architecture.
• Partial Compliance – Privacy disclaimers are present, but the UI banner and data retention policy are still missing.
• Gaps – Analytics continue to store direct user IDs, and retention scheduling has not been enforced.

b) Compliance Checklist Example

Area: Privacy Disclaimer
Requirement: Inform users that no PII is collected.
Status: Complete.
Notes: Implemented in the system prompt and footer; UI banner is still pending.

Area: Input Filtering
Requirement: Warn users about and filter PII.
Status: Complete.
Notes: Presidio-based detection with event sanitization.

Area: Metadata & Logs
Requirement: Minimize and anonymize metadata and logs.
Status: Partial.
Notes: User IDs are still stored directly; event sanitization has been improved.

Area: Retention
Requirement: Establish retention and cleanup policies.
Status: Not Complete.
Notes: Tooling exists, but no formal policy or automation has been implemented.

Area: Access Control
Requirement: Secure endpoints and logs.
Status: Complete.
Notes: Strong role-based access control (RBAC) and API key security.

Area: Audit Trail
Requirement: Document privacy compliance.
Status: Partial.
Notes: Logs exist, but a privacy-focused audit trail is still needed.

Area: Public Sector Ethics
Requirement: Align with the Data Protection Act (DPA) and accessibility requirements.
Status: Partial.
Notes: Awareness has been documented, but an accessibility audit is still missing.

Recommended Actions for Builders

• Add UI privacy disclaimers and a link to the privacy policy within the chatbot interface.
• Implement automatic log cleanup and retention policies (for example, retaining logs for 90 days).
• Anonymize user IDs used in analytics.
• Conduct formal accessibility audits in line with WCAG 2.1.
• Establish regular compliance reviews.

Validating Safety: The Conformity Assessment Process (CAP)

At Tech Innovators Network (THiNK), we use the CAP framework to validate safe bots.

Proactive Risk Prevention

• Conduct red-team testing using harmful queries (e.g., self-harm and hate speech).
• Use human-in-the-loop escalation for sensitive topics.
• Perform regular safety updates and audits.
• Monitor misuse patterns while maintaining privacy safeguards.

Looking Ahead

• THiNK AI Safety Playbook (coming soon) – Practical tools for bot safety.
• NMWSO Safety by Design Curriculum (IREX Kenya) – Advanced training content.
• IREX chatbot on web.think.ke (currently undergoing testing) – Your go-to chatbot for Safety by Design queries. Feel free to engage with the chatbot.
• Ongoing resources and botathons for builders committed to responsible AI.

Key Takeaway

Safety by Design isn't a single feature—it's a mindset.

By embedding safety at every stage, chatbot builders can engineer AI systems that are not only functional, but also safe, responsible, inclusive, and trusted by users.