A Beirut clinic's WhatsApp assistant handled 340 patient messages last month, mostly appointment confirmations, prescription refill questions, and requests for opening hours. This is a composite example, built from patterns I have seen repeat across several small clinics and service businesses in Lebanon and the Gulf, not a single named client. Fourteen of those 340 messages contained some version of one specific question, asked in Arabic, in the French-inflected Arabic common in Beirut, or in plain English: am I talking to a real person? The bot answered honestly seven times. The other seven, it deflected, changed the subject, or replied in a way that let the patient keep believing they were texting a human receptionist.
Nobody at that clinic decided, in writing, what the bot should do when asked that question. The evasive answers were not malicious. They were the accidental output of a script nobody had stress-tested against the one question patients actually ask. That gap, not the bot's accuracy on refill requests, is what I want to talk about.
Why This Isn't a Legal Problem
Most owner-operators I talk to across Lebanon and the Gulf treat disclosure as a line buried in the terms of service, or a checkbox their vendor already handled. Their real worry is whether the bot gives a wrong answer. That worry is reasonable, but it is solving the wrong problem first. A customer who gets a wrong answer from a bot they knew was a bot forgives quickly. A customer who realizes, after the fact, that they spent ten minutes describing a symptom or negotiating a refund with software they believed was a person, does not forgive quickly. That is a trust injury, and it happens regardless of whether the bot's underlying answers were accurate.
This is also not, yet, primarily a compliance problem for most SMEs in this region, and I do not want to overstate the legal exposure. But the direction is clear. The EU AI Act includes transparency obligations for AI systems that interact directly with people, and that regulatory instinct, that a customer has a right to know when they are talking to a machine, is spreading faster than most regional platforms and marketplaces expect. Consumer-protection scrutiny of digital interactions is rising across the Gulf and Lebanon as well, even where AI-specific rules have not caught up yet. Waiting for a law to force this is a bad plan, because the fix costs nothing. It is a checklist, not a compliance hire, and it is far cheaper to run before launch than to explain after a customer posts a screenshot of a bot that lied to them.
The Checklist
Before any customer-facing AI system goes live, in my work I now insist on eight specific, testable conditions. None of these require a lawyer. All of them require someone to actually sit down and write the answer, then test it against real phrasing.
- The first substantive reply states, unprompted, that the customer is talking to an AI system. Not buried three screens into a terms-of-service link, not implied by a small "bot" icon. Stated, in the actual first message that does real work, in language the customer will read before they start describing their problem.
- There is a plain, non-evasive answer ready for "am I talking to a robot?" and it has been tested against that exact phrasing, in Arabic, in English, and in the code-switched forms customers actually type, things like "ok bas ana bahki ma robot wala insan?" A vendor's default script rarely handles this phrasing gracefully. You have to test it yourself, with the exact words your customers use, not the polished English version a vendor demo shows you.
- Disclosure repeats at high-stakes moments, not only at first contact. Before payment, before anything resembling medical, legal, or financial advice, and at the point a complaint escalates, the system should restate plainly that the customer is dealing with software. A single disclosure at the start of a long conversation is easy to forget by the time money or a diagnosis is on the table.
- A visible, working path to a human exists within a defined number of exchanges, or on request, and someone outside the build team has actually tested that path end to end. A line in a vendor spec sheet claiming "human handoff available" is not a tested feature. Have someone who did not build the bot try to reach a person, on a Friday evening, and see what actually happens.
- One named person, not "IT" or "the vendor," has signed off on the disclosure wording before launch and owns it after launch. If nobody can tell you who is responsible for that specific sentence, the sentence does not have an owner, and things without owners drift.
- Every session where a customer asks "are you human," or the local-dialect equivalent, is logged, so leadership can audit the actual answer given rather than assume the bot behaved. I have seen teams believe their disclosure was solid because the training script said so, without ever pulling a log to check what the system said in a live conversation.
- The disclosure trigger is re-tested after every vendor model or prompt update. Tone and evasiveness can drift silently with a version bump that has nothing to do with disclosure at all. A model update aimed at making responses "warmer" can quietly make the honest answer sound more like a dodge, and nobody notices until a customer does.
- There is a written answer for what happens if a customer proceeds without realizing it's AI. Not a hope that it never happens, a remediation step: how the business identifies the affected conversation, what it offers the customer, and who authorizes that offer. A checklist that only prevents the problem, with nothing for when prevention fails anyway, is half a checklist.
What Honest Disclosure Actually Sounds Like
Honest disclosure is short and does not apologize for existing. Something like: "Marhaba, I'm the automated assistant for [clinic name] — I handle bookings and general questions after hours, and I'm software, not a person. Want me to connect you to our front desk team during working hours?" That single message does three things at once: it states what it is, states what it can and cannot do, and offers the human path without being asked.
Compare that to what an evasive system often produces instead, usually not by design: "I'm here to help you with that! Let me check your appointment details." Nothing in that sentence lies outright, and that is exactly the problem. It is written to sound like a helpful colleague, and a patient asking a follow-up medical question after that exchange has every reason to assume they are speaking to clinic staff. The gap between those two replies is not a matter of politeness. It is the entire disclosure decision, made or unmade, in one line of copy.
Before You Launch
None of this requires new technology, a bigger budget, or a legal review. It requires one afternoon, a named owner, and the discipline to test the exact phrasing your customers will actually use, in the languages and code-switched combinations they actually use, before the system goes live rather than after a customer notices. Run this checklist before your next AI deployment goes live, not after.
Frequently asked questions
Isn't a small disclosure line in the terms of service enough to cover this?
No. A line buried in terms of service protects a business legally in theory, but it does nothing for the customer who never reads terms of service and forms an impression from the conversation itself. Disclosure has to live in the conversation, in the first substantive reply, not in a document nobody opens.
What if my vendor already includes a "the assistant is AI" disclaimer by default?
Test it against the exact question your customers ask, in their actual phrasing, before assuming it works. Many default disclaimers are written for a generic English-speaking customer and go vague or silent the moment someone asks in dialect or in a code-switched sentence. A default is a starting point, not a verified answer.
How often should I re-test the disclosure trigger once it passes?
Re-test it after every model or prompt update your vendor pushes, even updates that have nothing to do with disclosure on paper. Tone changes aimed at making a bot sound friendlier can make an honest answer read as evasive without anyone intending that outcome.
What's the difference between this and an incident-disclosure policy for when the AI makes a mistake?
They are separate decisions. This checklist governs whether a customer is told, up front, that they are speaking to software at all, before anything goes wrong. A separate question, worth its own checklist, is how quickly and honestly a business discloses after an AI system has already produced a bad outcome. Conflating the two lets a business feel covered on identity disclosure because it has an incident policy, when the two problems require different answers.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
For more on this and related work, see BrianServes, the platform for deploying autonomous AI e-mployees and Webspot, the AI strategy firm in Beirut.
Related evidence: Article 50 of the EU AI Act requires providers to design AI systems that interact directly with people so that those people are informed they are interacting with an AI system, unless that is already obvious in the circumstances and context of use. (EU AI Act Article 50 transparency obligations)
The UK government's introduction to AI assurance defines AI governance as a range of mechanisms, including laws, regulations, policies, institutions and norms, used to outline processes for making decisions about AI. (the UK government's introduction to AI assurance)
