How Should a Chatbot Disclose That It Is Not a Person? Three Wordings Compared

Two people open the same chat panel on the same evening. One has used a dozen website assistants this year, reads the small type before typing anything, and adjusts their phrasing accordingly. The other has not. They see a name, a friendly opening line and a cursor, and they ask their question the way they would ask it at a counter. The second visitor is the one the interface is accountable to. If they finish the conversation still believing a member of staff read their message, the interface did that to them, and accurate copy elsewhere on the site does not undo it.

That gives a working test, and it is a harsher one than a checklist. The question is not whether a disclosure exists somewhere. It is whether a reasonable visitor, doing nothing unusual, could complete a conversation without knowing. The test is also easy to run, which is its main virtue: hand the panel to a colleague who has never seen it, ask them to get an answer to a real question, and afterwards ask them who they were talking to. If they hesitate, the wording is not the problem you thought it was.

Everything below is interface design. Placement, persistence, three candidate wordings and what each one costs you, the choices that quietly cancel an otherwise accurate notice, and what the assistant says when somebody asks it outright. The argument rests on honesty rather than obligation, because honesty needs no instrument to hold: a visitor who cannot tell has been misled, and that is true regardless of where the site is served from or who is reading it.

The most common arrangement is a sentence in a policy page confirming that the site operates an automated assistant, and nothing at all in the assistant itself. The defence offered is that the information was available. Availability is not disclosure. Disclosure is a property of the moment a person forms a belief, and the moment a visitor forms a belief about who is answering them is the moment the panel opens, not some later moment when they audit the footer.

There is a real counter-case here and it should be kept. A policy page is the correct home for the long form: what happens to a transcript, how long it is held, who inside the business can read it, what is done with an email address typed into the widget. That material is genuinely too long for a chat header and genuinely belongs somewhere stable and linkable. The mistake is treating that page as a substitute for the notice rather than as the reference standing behind it. One is a filing cabinet. The other is a label on the thing in front of you.

The tell is simple and worth writing down, because it survives arguments about intent. If somebody inside the business has to explain where the disclosure is, it is not in the interface. A notice that requires a guide is a document, and documents are not read by the person who only wants to know whether their order shipped.

There are three moments that matter, and most implementations handle only the first. The point of entry, before any exchange has happened. The state of the panel after the conversation has been running for a while. And the moment somebody asks directly. Each needs different treatment, and the second is where nearly every otherwise careful implementation fails.

At entry, the notice has to be inside the panel, visible without interaction, and reachable in the same order by a keyboard and a screen reader as by an eye moving down the panel. It cannot be a tooltip, it cannot be hover-only, and it cannot sit behind an information icon that a visitor has no reason to press. The broader question of making the panel itself operable is treated separately in the piece on building an accessible chat widget; the point here is narrower. A disclosure that only some visitors can perceive is a disclosure that has decided in advance which visitors deserve to know.

Persistence is where the design usually breaks. Implement the disclosure as the first message in the transcript and it is correct for exactly as long as the conversation is short. Transcripts scroll. The first message is the first thing to leave the viewport. By turn six the panel shows a stream of confident prose with a name attached and no indication of what is producing it, which is the precise condition the notice existed to prevent. A visitor who joins the conversation mentally at that point, or comes back to it after a phone call, has no signal at all.

A disclosure implemented as the first message in a scrolling transcript has a half-life measured in turns.

The reduced but persistent form is a short line fixed in the panel header, present for the whole session, sitting under or beside whatever name the assistant carries. It does not need to be the full sentence. It needs to be unambiguous at a glance. The cost is honest and worth stating plainly: on a 390px viewport a header line is vertical space taken from the transcript, and if the header grows to two or three lines the panel opens with room for almost nothing. So make the trade deliberately. A very short persistent line, and a fuller opening message that carries the boundary and the route.

If the notice is dismissible, decide what brings it back, and decide it before anyone asks. A dismissal that persists across sessions means a returning visitor in six months meets an assistant with no label. A dismissal scoped to the session is defensible. A dismissal stored indefinitely is a decision to stop disclosing, taken quietly, by a default nobody argued for.

There is no single correct sentence, because the sentence is a claim about a system and systems differ. What follows are three shapes, in increasing order of what they admit. Each buys something and each costs something, and the cost is usually a maintenance burden rather than a commercial one.

The plain statement

You are chatting with an automated assistant, not a person. That is the whole thing. Its great virtue is that it cannot go stale. It makes no claim about where answers come from, what the assistant can do, or who is available, so no change to the system behind it can turn it into a lie. If the widget is narrow and the answers are drawn from a small, stable set, this is often the right choice and the other two are over-engineering.

What it concedes is nothing, and that is also its weakness. The visitor now knows they are talking to a machine and has been given no basis for calibrating how much to trust it. When a wrong answer arrives, and wrong answers arrive for reasons that have little to do with the wording of the notice, it lands on a reader who had no warning. The disclosure was honest about identity and silent about reliability, and identity was only half of what the reader needed.

The statement with a capability boundary

You are chatting with an automated assistant. It answers from the content published on this site, and it can get things wrong. This version concedes fallibility, which is the more useful of the two admissions, because it changes reader behaviour. Somebody told in advance that answers come from published pages will treat a confident-sounding claim about a bespoke arrangement differently, and will more often go and check it against a page.

It has two costs. The first is that it is a factual claim about the system, so it has to stay true. Change what the assistant draws on and the sentence is now false, and nothing in a normal release process will flag that, because nobody thinks of a line of interface copy as coupled to a data source. The second cost is length. It is a longer notice at the exact point in the interaction where attention is thinnest, and every additional clause reduces the odds that the first clause is read. If you take this version, put the identity claim first and the boundary second, always, so that a visitor who reads five words has read the important five.

The statement with a route to a person

You are chatting with an automated assistant. If you would rather speak to someone, use the contact options in this panel. This concedes the most. It admits that the assistant is a stage rather than a destination, and in doing so it makes an operational commitment: the route exists, it is findable from where the visitor is standing, and it goes somewhere that answers.

That commitment is the whole risk. A disclosure that names an escape hatch which dead-ends converts one honest sentence into a second broken promise, and the second one is worse, because the visitor followed it deliberately. Two specific failures are worth naming. A route that discards what the visitor has already typed, forcing them to write the question again into a form, which most people will not do. And a route that is honest about existing but silent about timing, so somebody who needed an answer within the hour waits two days for one. If the route has hours, put the hours next to the route, not in a footer.

• The plain statement concedes identity only. Cheapest to maintain, safest against system change, weakest as a warning.
• The capability boundary concedes fallibility. Most useful to the reader, but it is a claim that must be re-checked whenever the answering behaviour changes.
• The route to a person concedes that the assistant is not the end of the line. Strongest reassurance, and the only one of the three that can fail operationally rather than editorially.
• All three fail identically if the notice does not persist past the opening turn, which makes persistence a prerequisite rather than a refinement.

A human-sounding name is not the offence. A name is a handle, and handles make interfaces legible; a panel labelled with a name is easier to talk about internally and easier to return to than one labelled Assistant. The offence is a name presented so that a reasonable visitor concludes they are speaking to a person. What produces that conclusion is almost never the name on its own. It is the accumulation around it.

Typing simulation with randomised delay, so the pause reads as a person composing a sentence rather than a system producing one. First-person claims about internal states, which are the sharpest of the lot: I remember you asking about this, I feel bad that happened, let me just check with the team. Photographic avatars of a human face. Sign-offs with a role title attached. And, running underneath all of them, a disclosure that appeared once and left. Each of these is individually defensible and somebody will defend each of them. Together they build a belief that the notice, if it is still visible at all, is no longer strong enough to correct.

The line worth holding is between conversational register and assertions of humanity. Courtesy is fine. Pronouns are fine; an assistant that refers to itself as I is not thereby claiming to be a person, and prose that contorts itself to avoid the word is harder to read and no more honest for the effort. What is not fine is any statement that could only be true of a person: memory of a previous relationship, emotion, physical location, being busy, having colleagues in the next room. Those sentences are not tone. They are claims, and they are false.

The test for this is also cheap. Print a real transcript, strip the panel chrome away, hand it to somebody who has not seen the widget, and ask who wrote the replies. If they answer confidently with a person, the interface has a problem that no header line will fix, and the fix belongs in the reply copy rather than in the notice.

The opening frame of a chat panel is contested space. The disclosure wants it. So does the notice about the transcript being retained, the consent request attached to capturing an email address, the offline state, and the business hours. Left unresolved, one of two things happens. Either they are merged into a single paragraph of small grey type, in which case none of them is read, or they are stacked as separate blocks, in which case the panel opens with a wall of notices and no visible place to type.

The ordering principle that survives contact with real panels is this: what changes the visitor's behaviour right now goes first, and everything else attaches to the moment it becomes relevant. The identity disclosure changes how the visitor phrases their very first question, so it belongs at the top. A retention notice changes whether somebody pastes an order number or a phone number, so it belongs beside the field or the moment where that becomes likely, not in an opening block read before it means anything. Consent for storing an address belongs against the address field. Hours belong against the escalation route.

The question gets sharper in panels that are more than one thing at a time. Zealsync develops Flidu, an AI chatbot and website communication product that can be presented as a contact widget, as an assistant, or as the two combined, and that combined case is where stacking stops being a layout problem and becomes a disclosure one. A panel that is sometimes a form and sometimes an automated assistant has to be honest about which it is at the moment the visitor is looking at it. A notice written for one mode and left standing through a switch has stopped describing anything.

The stack also has to survive being read, which is a separate requirement from being present. Small grey type on a light grey panel is the standard way a disclosure ends up technically there and practically invisible. WCAG 2.2 success criterion 1.4.3 sets a 4.5:1 contrast minimum for body-size text, and a notice is body text no matter how small the design wants it to be. Success criterion 1.4.4 requires text to still work when resized to 200 per cent, which a tightly packed header stack frequently does not. And 4.1.3 covers status messages, which matters as soon as the panel changes state without moving focus. A disclosure that fails these is not a disclosure with a styling issue. It is a disclosure that some visitors cannot read.

Are you a real person is the highest-stakes turn in the whole conversation, because the visitor has stopped assuming and started checking. The rule is that the answer arrives in the first clause, without preamble and without hedging. No, this is an automated assistant. Anything that opens with I am here to help you with your enquiry has already failed, whatever it says afterwards, because the visitor asked a yes-or-no question and received a deflection, and a deflection to that particular question reads as evasion even when it is only clumsiness.

Three failure shapes are worth naming so a reviewer can catch them. Answering with a question. Answering with a joke, which is the worst of the three because it is charming and non-committal at once and therefore survives review. And answering with something like as real as it gets, which is a sentence engineered to pass as a yes without being one. Note also the opposite failure, which is rarer and still a failure: overclaiming in the direction of harmlessness. I am just a simple program with no access to anything is also a factual claim about a system, and if the panel does capture an address and route it somewhere, that claim is false in the other direction.

The answer has to survive paraphrase, because the canonical question is rarely the one people type. Am I talking to a human. Is this a bot. Who am I speaking with. Are you AI. Is anyone actually there. Real transcripts are full of variants and half of them are ungrammatical. If the assistant answers only the tidy phrasing, the disclosure works for people who ask precisely, which is not the population you were worried about in the first place.

One more case belongs here. If a person can take over a conversation part-way through, the handover needs announcing as clearly as the original disclosure, and so does the handover back. A visitor who was told at the start that they were talking to a machine, and who is now talking to a colleague, holds an outdated belief that is wrong in the more forgivable direction but wrong nonetheless. The reverse transition is the one that matters: a conversation that quietly returns to automation after a person has left is the same misleading condition the notice was written to prevent, arrived at by a different route.

Disclosure copy is typically written once, approved, and then decoupled from every process that would keep it true. The sentence is coupled to the system whether anyone tracks that or not, so the useful discipline is to name in advance the changes that invalidate it.

• The source the assistant answers from changes, which falsifies any wording that describes where answers come from.
• The escalation route is removed, renamed, or given different hours, which falsifies any wording that offers a route to a person.
• The persona is renamed or given a new avatar, which changes the total impression the notice has to correct.
• The widget is embedded on a surface where the panel chrome renders differently, so the persistent header line the disclosure relied on is simply not there.
• The opening frame gains another notice, pushing the disclosure below the fold of a small panel without anyone editing a word of it.

Each of those is a normal, unremarkable change that nobody would think to route past whoever owns the wording, which is why the wording needs an owner and a file rather than a memory. Keep the sentences in source control alongside the widget configuration, review them on the same cadence as any release that touches the panel, and record the date the wording was last read against the system as it actually is. The tell that it has drifted is that nobody can say when that last happened. Product context for the combined contact-and-assistant case sits on the Flidu page, and the separate question of what an assistant should do when an answer is not the thing the visitor needed is a different argument from this one.

The objection to all of this is commercial and it deserves a straight answer rather than a dismissal. An honest notice lowers the ceiling on the first impression. Some visitors will type less, some will close the panel, and somebody will point at that and call it friction. That is a real cost, and pretending otherwise would be the same kind of dishonesty the rest of this argues against.

The reason to pay it is the asymmetry at the other end. A visitor who knew they were talking to a machine and received a wrong answer is annoyed with the answer. A visitor who believed they were talking to a person and later works out that they were not does something considerably more expensive: they re-read the entire conversation in a new light, and every reassurance inside it is re-evaluated at once. The damage does not stay scoped to the assistant. It attaches to the business, because the visitor now knows the interface was arranged so they would not notice.

Here is what would have to be true for the argument to be wrong. Visitors would have to be genuinely indifferent to who is answering them, and the suppression at the top of the funnel would have to exceed the recovery at the bottom, consistently, over a window long enough to be more than noise. Neither is claimed here in either direction, and nobody holds figures for your site but you. If somebody quotes you a number for what disclosure does to engagement, ask which site, which wording, which placement, which measure, and over what period, because a number without those five things is a decoration rather than evidence.

The practical version fits in three lines. Write a sentence that is true about the system you actually run. Put it where a visitor meets it without looking for it, and keep some form of it visible for the whole session. Answer plainly when somebody asks. The rest of the interface design follows from those three, and none of it depends on knowing what any particular jurisdiction demands.