Telling people it is a machine, and being able to say where their data went
Customer-facing AI in the United States runs into three things at once. Several states now expect people to be told when they are talking to a machine. Automated calls and texts are governed by consent rules written long before chatbots. And whatever the assistant sees goes to a vendor whose contract decides what happens to it next.
American buyers ask two questions about an AI feature that buyers elsewhere often do not. Does it say it is a bot, and where does what I typed end up. Neither is hard to answer well, but both have to be answered at design time, because retrofitting a disclosure into a conversation flow or rewriting a data path after launch is far harder than deciding it up front.
The pattern repeats. An assistant ships with a human first name and a greeting that never says what it is. It collects a phone number and starts sending follow-up texts, because nobody separated the number given for a callback from consent to receive automated messages. Transcripts carrying account numbers, health details or payment information flow to a model vendor whose terms nobody read, retained for whatever the default was. Then an enterprise customer asks which subprocessors see their data and how long it is kept, and nobody knows.
When this work makes sense
Questions worth asking any supplier
Does the assistant disclose that it is not a person, because several states now expect that and a disclosure added later reads as an apology?
Is consent for automated outbound messaging captured separately from a phone number given for another purpose, because those are different permissions?
Do you know exactly which fields reach the model vendor, because a reviewer will ask and a diagram drawn afterwards is rarely accurate?
What do the vendor's terms say about training, retention and subprocessors, because the answer differs by plan and is the part buyers actually read?
Is there a fast path to a human, because the quickest way to turn an assistant into a complaint is to make it the only option?
Deliverables
Disclosure written into the conversation design rather than buried in a footer, in language a customer reads as normal
Consent capture for automated messaging kept distinct from the contact details a customer gives for other reasons
A data flow document showing which fields leave your systems, to which vendor, under which terms and for how long
Redaction or exclusion of sensitive fields before anything is sent to a model
Prompt and response logging you own, retained to a period you chose rather than a vendor default
A handoff to a human that is visible, fast and measured, with the escalation rate reported
A security review pack, subprocessors, data handling, retention, access, assembled with the build rather than after it
Built with
Process
We start by writing down what the assistant is allowed to see, and confirming what the vendor's terms permit, before choosing a model. That ordering matters because the data decision constrains the technical one rather than the other way around. If payment details or health information must never leave your environment, that rules options out and makes a smaller self-hosted model or a strict redaction layer the sensible answer. Teams that pick the model first discover this in the security review, once the choice has been built around.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three places to run the model
Standard hosted API
Fits: Low-sensitivity use where speed matters and the data involved is not confidential
Limits: Retention and training terms are the vendor's defaults, and a buyer's security team will read them even if you did not
Hosted under enterprise terms
Fits: Most businesses selling to other businesses, where the contract needs to be shown to someone
Limits: Costs more, and the terms still need reading rather than assuming. What is committed varies by vendor and plan
Self-hosted open-weight model
Fits: Regulated categories, or data that genuinely must not leave your environment
Limits: You take on the infrastructure, the updates and the evaluation work, and capability on hard tasks is usually behind the frontier
Case studies
No published US AI case study yet. Our New York office is at 1 Liberty Street, 23rd Floor. Client work will be published when we have permission to name the business and outcomes that can be evidenced rather than described.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do we legally have to say it is a bot?
In some states and some contexts, yes, and the direction of travel is clear enough that we design for disclosure regardless, which rules reach your business is a question for your counsel. What we can say is that disclosure costs nothing in conversion when it is written as a normal opening line rather than a legal notice.
Can the assistant text customers after the conversation?
Only with consent for that, which is not the same as having their number. Automated outbound messaging is governed by consent rules that predate chatbots, and carriers separately require registration for business messaging. We build the consent capture and keep the record; whether a campaign is permitted is for your counsel.
Will our customer data be used to train someone's model?
It depends entirely on which vendor and which plan, and the terms differ more than people expect. Some commit not to train on your data by default, some only under a particular agreement, and some retain content for a period regardless. We read the terms that apply to your account and write the answer down.
What does a customer's security review actually ask about AI?
Which model vendor, what data reaches it, whether it trains on that data, how long it is retained, who can read the logs, and what happens if the vendor changes terms. None of these are hard if the answers were decided during the build. All are hard if the project has to be reverse engineered under a deadline.
Can we keep sensitive data out of the model entirely?
Usually, and it is often the right call. Redaction before the request, retrieval that returns references rather than raw records, and a design where the assistant asks the system for an answer instead of being handed the file all help. Where data must never leave your environment, a self-hosted model is cleaner than a very careful pipeline.
How do we stop it making things up to customers?
Narrow it, ground it and measure it. An assistant answering from your own documented content fabricates far less than one answering from general knowledge, and one that can say it does not know and pass the person to a human beats one that always produces something. We test against real transcripts before launch.
Should we build this at all?
Sometimes not. If the volume is low, the questions are varied and the answers are judgment calls, an assistant will disappoint everyone and create a disclosure and consent obligation for the privilege. We would rather say that in the first conversation than after the build. Where volume is high and repetitive, the case is straightforward.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.