Enterprise Capability Knowledge Chatbot

A public-facing knowledge assistant over a consulting capability’s thought leadership and credentials - where my role was not building it, but making it safe and accurate enough to launch.

1. Context and my role

This system was built and hosted by an external vendor. My contribution was on the side that determines whether a client-facing AI product should actually go live: architecture review, adversarial quality testing, safety assessment, and launch readiness.

Worth stating plainly because it’s a distinct and often under-valued skill set. Reviewing someone else’s AI system for safety and accuracy - and holding a launch until specific issues are closed - is a different discipline from building one, and arguably the one that matters most for reputational risk.

2. The problem

A public-facing chatbot representing a consulting capability carries reputational exposure that an internal tool does not. It must:

• Speak in the organisation’s voice, with correct positioning of the sub-brand’s relationship to its parent
• Recommend genuinely relevant experts, matched to the user’s question and industry
• Never surface confidential material, internal systems, or draft content
• Resist prompt-injection attempts from public users
• Decline gracefully rather than inventing an answer or exposing internal plumbing

Getting the identity and voice wrong is a brand problem. Getting the safety boundary wrong is a serious incident.

3. What I contributed

Architecture and access review

Reviewed the vendor’s technical architecture against the requirements. Handled the enterprise-networking reality throughout: corporate firewall changes blocked the vendor’s convenience URL even from inside the network, requiring a shift to direct cloud hostnames, plus documented VPN-profile and browser-specific access paths - the unglamorous work that determines whether stakeholders can actually reach a system to review it.

Structured adversarial testing

Ran a systematic prompt-testing pass across the assistant’s responses, documented against a shared log. Four failure themes emerged:

1. Identity and voice - the assistant referred to the capability in the third person (“it”) rather than the first-person institutional voice, and mispositioned the sub-brand’s relationship to the parent organisation.
2. Recency and content-type weighting - no evidence that more recent publications were prioritised over older material, and no distinction between thought leadership and client credentials as source types. For an advisory assistant, citing a five-year-old view as current is a substantive accuracy failure, not a cosmetic one.
3. Expert matching failure - only three contacts were ever surfaced regardless of question or industry. Root cause identified through the vendor’s explanation: article authors appear only when a related public article matches, whereas explicitly-registered contacts are treated as first-class references - and only three had been registered. A retrieval-shaped symptom whose actual cause was a data-registration gap.
4. Fallback wording leaking internals - responses referenced the “knowledge base” and “contact support”, exposing implementation detail to public users.

Safety and integrity outcomes

The findings drove substantial system-prompt revisions, delivered without altering retrieval architecture:

• Consistent first-person institutional voice and corrected brand positioning
• Hardened safeguards around confidential material, internal content, and prompt-injection attempts
• Improved handling of unsupported claims, competitor questions, and requests for expert guidance
• Internal system references removed from all user-facing messaging
• Publication dates suppressed entirely from being shared, compared, or used to rank content - because the knowledge base held no reliable date data. Rather than surface a number that looked authoritative and wasn’t, the correct engineering answer was to withhold the capability. This is the decision I’d point to: choosing a visible gap over a plausible falsehood.

Launch readiness

Tracked the remaining gate items and the delivery-window constraint (vendor availability), keeping launch dependent on approval and closed issues rather than on schedule pressure.

4. What I’d highlight

• Adversarial testing as a discipline - systematically probing an AI system for identity, accuracy, and safety failures, documented so findings are actionable rather than anecdotal.
• Diagnosing root cause across an organisational boundary - recognising that a “retrieval problem” was a data-registration gap, which changes who fixes it and how.
• Recognising accuracy failures that look cosmetic. Stale content presented as current is a correctness bug in an advisory assistant.
• Withholding a capability rather than shipping an unreliable one - suppressing date claims when the data couldn’t support them.
• Prompt-injection defence treated as a launch requirement for a public-facing system.
• Holding a launch gate on closed issues rather than calendar pressure.

5. Skills demonstrated

AI quality assurance · adversarial prompt testing · prompt-injection defence · LLM safety review · RAG failure-mode diagnosis · system-prompt engineering · vendor technical management · enterprise networking and access troubleshooting · launch-readiness governance · brand and voice compliance in generative systems