A Bilingual Customer Chatbot That Will Not Get You in Trouble
This publication is publicly available with an advisory disclaimer but has not yet received recorded CLO approval. Verify current law and procedure before relying on it.
General information only, current at the time of writing. Rules for foreigners and small businesses in Vietnam change - please confirm your own situation before acting on it.
Direct answer
A bilingual customer chatbot is safe once a business decides in advance what it is permitted to see, and for most small operations the workable answer is prices, policies, common questions, and no personal details at all. The risk rarely originates in the technology. It originates in connecting the tool to customer records without having made that decision.
The decision takes an afternoon and costs far less before launch than afterwards, when staff and customers already depend on the arrangement.
Where the risk actually sits
Not in the tool, but in three decisions made around it.
Which data it can reach. Whether customers were informed. And whether anyone can locate and delete a particular person's information if asked to.
Each of these is a choice, usually made in a few minutes and usually without being recognised as a choice at all. A chatbot answering from a document the business wrote is a very different arrangement from one connected to a customer list, and both are configured with roughly the same number of clicks.
The distinction matters because the obligations attach to the second arrangement and not meaningfully to the first. A business that has never articulated which one it built cannot answer a question about either.
What the tool should be permitted to see
The material the business has already published. Prices, opening hours, service descriptions, policies, delivery terms, and the questions staff answer twenty times a week.
This accounts for most of the value. The overwhelming majority of customer messages to a small business are questions that have already been answered somewhere, and a tool that handles those competently removes real work from real people.
What this configuration requires is notable: no personal information at all. A genuinely useful assistant can be built from material containing no customer data, which means the entire category of data obligation does not arise. Businesses that begin here and expand deliberately are in a considerably better position than those that connect everything and narrow it later.
What it should not see by default
The following should be treated as out of scope unless a deliberate decision has been made otherwise.
| Not connected | Reason |
|---|---|
| Names and contact details | Identifies an individual, which is the basis of any data obligation |
| Addresses | The same, with higher sensitivity |
| Identity document details | High potential harm, almost never required |
| Payment information | Not appropriate for a general customer assistant |
| Individual conversation history | Builds a profile the business did not decide to hold |
The final row is the one that catches businesses out. Conversation histories accumulate without anyone choosing to create them, and a year later the business holds a detailed record of individual customers that nobody planned, cannot easily search, and would struggle to delete on request.
Disclosing that it is automated
Customers should be told. It is good practice, increasingly expected, and it prevents the situation that produces actual harm.
That situation is straightforward: a customer believes they are speaking to a person, shares something personal or urgent, and it arrives in a system nobody is monitoring. The damage in the first instance is not regulatory. It is a person who needed assistance and did not receive it, and who will describe that experience to others.
A single line at the start of the conversation resolves it, together with a clear route to a human being. Both are inexpensive, and both distinguish a business that thought about the arrangement from one that enabled a default setting.
The bilingual element: a supervision problem
Operating across languages does not create a data problem. It creates a supervision problem, which is different and easier to overlook.
Where a tool answers customers in a language the owner does not read, there is no practical way to judge whether it is accurate, appropriately cautious, or confidently wrong. Small businesses typically discover this when a customer quotes back a commitment nobody intended to make - a delivery date, a discount, a refund policy that does not exist.
The correction is a review habit rather than a technical control. For the first weeks, someone who reads both languages should check a sample of conversations. The tool should be configured to be cautious rather than helpful where it is uncertain, and to offer a human contact in both languages.
Setting it up safely
- Write down which questions the tool will answer - the actual list.
- Gather the source material from documents the business already holds.
- Record explicitly what it may not access, in writing.
- Add the disclosure line and a route to a person.
- Run it internally for a week before customers encounter it.
- Sample real conversations in both languages for the first month.
Step three is the one most often skipped and the one that makes the difference. Written down, the boundary is a decision the business can point to and revisit. Left implicit, the boundary is whatever the default configuration happened to be, chosen by a vendor rather than by the business.
When real customer data is genuinely needed
Sometimes it is: order status, booking details, account queries. These are legitimate uses and should be deliberate decisions rather than drift.
Where a tool needs real data, it becomes a disclosed part of how the business handles customer information. It belongs in the privacy notice, it needs a proper basis, and the ability to locate and delete one person's information must survive the connection. Adding a system does not remove an existing obligation.
Keeping the scope narrow usually preserves most of the benefit. Access to a specific order record on presentation of an order number is very different from access to an entire customer database, and the narrower configuration typically delivers the same customer experience with a fraction of the exposure.
Frequently asked questions
Is it safe to use a chatbot for customer service in Vietnam? Yes, if you decide in advance what it is allowed to see. A chatbot working from your prices, policies and common questions is low risk. One connected directly to your customer records is a different proposition and needs to be handled deliberately.
Do I need to tell customers they are talking to a bot? It is good practice and increasingly expected. Beyond any formal requirement, it avoids the situation where a customer shares something sensitive because they believed they were speaking to a person, which is the scenario that causes real damage.
What should a chatbot never be given access to? As a default: names, phone numbers, addresses, identity document details and payment information. Most small business chatbots deliver nearly all of their value without any of these, so the restriction costs less than people expect.
What if the bot needs real customer data to be useful? Then treat it as a disclosed part of how you handle customer information: say so in your privacy notice, make sure you have a proper basis, and apply the same access and deletion practices you apply elsewhere. Decide this before you connect it.
Does a bilingual bot create extra risk? Not in itself, but it does raise the stakes on accuracy. If your bot answers in a language you cannot check, you may not notice it giving wrong or over-confident answers, so build a review habit into your first few weeks.
Conclusion
Most of a customer assistant's value comes from material the business has already written, which means a useful tool can be built that touches no personal data. The decision about what it may access should be recorded before launch, because otherwise a vendor's default settings make it. And a bilingual tool requires a reviewer who reads both languages, at least for the first month.
For a review of a proposed configuration before it goes live, talk to LotusGuard. We do not resell the tools we recommend.
