A customer AI chatbot: secure deployment guide

An LLM-based chatbot is the most common first step companies take towards AI: it works around the clock, answers in seconds and handles many conversations at once. But the same chatbot, deployed without preparation, can promise a customer a discount that doesn’t exist, give advice that contradicts your terms, or leak another user’s data. The famous mishaps — from the airline chatbot whose promises a court found binding, to car-dealer bots “selling” vehicles for a dollar — show these risks aren’t theoretical. Here’s how to deploy a chatbot that helps rather than harms.

Start with scope, not technology

The first decision isn’t “which model”, it’s what the bot should do — and what it must not do. A well-defined first-generation chatbot:

• answers questions from a defined knowledge base (offer, terms, FAQ, order statuses),
• performs at most a few safe actions (status check, ticket creation),
• recognises out-of-scope questions and hands them to a human instead of improvising.

The exclusion list matters as much as the feature list: legal and medical advice, price statements beyond the published list, delivery promises, comments about competitors, worldview topics. These boundaries later go into the system prompt, the tests and the vendor contract.

Architecture: RAG instead of “model knowledge”

The standard for company bots is RAG (retrieval-augmented generation): the model doesn’t answer “from memory” but from fragments of your knowledge base attached to each query. That solves two problems at once — freshness (you update the document, the bot answers accordingly) and hallucination (the bot cites a source instead of confabulating).

Three things matter most in RAG design:

1. Knowledge base quality. The bot will be exactly as good as the documents it draws on. Conflicting versions of your terms or an outdated price list in the base is a complaint waiting to happen.
2. Access control at the source. If the bot serves logged-in customers, the base must respect permissions — a user cannot be able to “talk the bot into” another customer’s documents. This is the most common flaw we find when testing RAG deployments.
3. Source citations. An answer with a link to the page or document builds trust and makes verification easier — for you too, when analysing complaints.

Safeguards to build in before launch

A publicly exposed chatbot will be probed by users — from the curious to the malicious. The minimum set of safeguards:

• The system prompt is not a security control. An instruction like “don’t talk about X” can be bypassed. Hard limits (data scope, available actions) must be enforced in code and permissions, not in a polite request to the model.
• Prompt injection defences. Treat user input and knowledge base documents as untrusted. The bot should hold no privileges whose abuse via an injected instruction would be dangerous — we covered this in our analysis of LLM risks in business.
• Input and output filtering. A moderation layer catching prompt-extraction attempts, harmful content and personal data in responses.
• Session isolation. One user’s conversation must not “bleed” into another’s — neither via model memory nor shared context.
• Rate limiting and budgets. Per-user query limits and a daily API cost budget. Without them, the first script spamming your bot will announce itself on your invoice.
• Conversation logging with GDPR-compliant retention — for quality analysis and complaint handling.

A human in the loop and the escalation path

The best deployments have a clearly designed handover moment: when the bot doesn’t know the answer, when the customer is upset, when a topic from the exclusion list comes up, or when keywords appear (complaint, cancellation, GDPR, lawyer). The handover should preserve the conversation context — nothing irritates more than retelling everything from scratch.

Also appoint a business owner for the bot: who reviews transcripts, who updates the knowledge base, who reacts to new question types. A chatbot without a caretaker degrades within months.

Compliance: GDPR and the AI Act in a nutshell

Two obligations are beyond debate. First, transparency: users must know they are talking to AI — this follows directly from the AI Act and good practice. Second, GDPR: conversations contain personal data, so you need a processing basis, privacy policy disclosures, defined retention and a data processing agreement (DPA) with the model provider — with training on your data disabled. If the bot handles sensitive data or makes decisions about customers, run a DPIA before launch, not after.

Pre-launch testing: treat the bot like an application

A chatbot is a web application plus a model — so you test it twice over. Alongside the classics (authentication, sessions, APIs), check the AI layer:

• prompt injection attempts — direct and via knowledge base content,
• system prompt leakage and cross-user data leakage,
• jailbreaks on excluded topics (can the bot be talked into legal advice? a discount promise?),
• resistance to harmful content and attempts to use the bot as a free API for other purposes,
• behaviour at the limits of its knowledge — does the bot admit “I don’t know” and escalate, or does it confabulate?

This is exactly the scope of our LLM application security test — we combine a classic pentest with techniques specific to language models.

Frequently asked questions (FAQ)

How much does a customer chatbot cost? The range is wide: a simple FAQ bot on an off-the-shelf platform costs a few thousand złoty plus usage fees; a bot integrated with your systems (orders, CRM) with a full security layer — tens of thousands and up. Budget for upkeep too: transcript reviews, knowledge base updates, API costs.

Can the bot answer questions about prices and availability? Yes, if it pulls them live from a system (pricing API, stock levels) rather than from the model’s “knowledge”. Add a disclaimer in your terms and in responses that the binding offer is the one in the shop or contract — case law shows companies do get held to their bots’ word.

How do we measure whether the deployment succeeded? Four metrics are enough to start: the share of conversations resolved without a human (containment rate), post-chat satisfaction, the share of escalations caused by wrong answers, and cost per conversation versus agent handling. Measure from day one — without a baseline you won’t defend the project in six months.

A model via API or self-hosted? For customer service, almost always a reputable provider’s API: lower barrier to entry, better models, DPAs and certifications. Consider self-hosting under hard data-residency requirements — remembering that you take on its security and scaling yourself.

Does an internal (employee-facing) chatbot need the same safeguards? Yes, and sometimes stronger ones — because it usually touches more sensitive data (procedures, HR records, documents). Permission-aware access control in RAG is a baseline requirement there, not an option.

Summary

A successful chatbot deployment is one-third technology and two-thirds decisions: scope, knowledge base, boundaries, the escalation path and pre-launch testing. Companies that work through this list deliberately get a tool that relieves customer service from week one. If you’re planning a deployment or want to check a bot that’s already live, get in touch — we help design secure chatbots and test existing deployments with offensive methods.