Communicating AI Changes to Customers

5 min read · updated August 3, 2026

“How should we tell customers we are using AI?” is three questions wearing one coat. One is a marketing decision, one is a product design decision, and one is a contractual obligation with a clock attached — and only the third can make you late.

Three different announcements

Kind	Description
the launch	You built something and you would like people to use it. Entirely yours to time, word and target. No deadline, no obligation, and the least consequential of the three despite receiving most of the attention.
the disclosure	The user is looking at something a model produced, or talking to something that is not a person. This is a product decision made at the point of use, not an announcement — a line in the interface, every time, not a blog post once.
the processing notice	Customer data will now be processed by a new party, in a new place, or for a new purpose. This is contractual: your data processing agreements usually specify a notice period and often a right to object. The clock belongs to the contract, not to your release calendar.

Confusing the first with the third is the failure that causes real trouble, because a marketing plan gets moved and a notice period does not. If the launch date is fixed, the processing notice has to have gone out weeks earlier — which means the decision to use a given vendor has to be final weeks earlier still.

What actually requires a notice

A trigger table for the second and third kinds. Confirm each row against your own contracts and your own jurisdiction; the point is which questions to ask, not a legal conclusion.

Change	Description
new sub-processor handling customer data	Almost always requires notice under the DPA, on the period the DPA states, with a possible right to object. Check whether the model provider is being added to a published list, because that list is the mechanism most agreements point at — it is one of the standard clauses in an AI data processing agreement.
processing moves to a new region	Notice if residency was committed, and possibly a new transfer basis. This is the row most often missed when a provider adds capacity somewhere new and the default routing changes.
a new purpose for existing data	Using support transcripts to build an assistant is a different purpose from handling the ticket they came from. This is a lawful-basis question before it is a communication question.
output shown to an end user	Disclosure at the point of use, not a notice. Some jurisdictions require that a person is told they are interacting with a machine; the obligations differ by place and are worth checking against the transparency rules that apply where you operate.
an automated decision about a person	A different legal regime entirely, often carrying rights to explanation, review or human intervention. Do not treat this as a communications task; treat it as a design constraint on the feature.
model swapped, everything else unchanged	Usually no notice — unless the new provider is a new sub-processor, in which case the first row applies. For an API you sell, behaviour changes are a product change and should appear in the changelog with a version, because your customers have tests.
feature retired	Contractual notice if the feature was part of what was sold, on whatever period the agreement states.

The row that most often surprises engineering is the last-but-one. A silent model change is invisible to you and extremely visible to a customer whose prompt was tuned against the old behaviour, which is the same problem in the other direction from detecting a provider-side change. If you are the provider in that relationship, the courtesy you wanted is the courtesy you owe.

Lead time is not yours to choose

Work backwards from the constraint rather than forwards from the launch date. The order is almost always the same, and it is longer than people expect.

LAUNCH DAY
  minus the DPA notice period            (from the contract)
  minus time to answer objections        (assume some arrive)
  minus your own review and sign-off
  minus time to update the published
        sub-processor list and the terms
= the date the vendor decision must be final

Objections are the term people forget. A customer with a
right to object may exercise it, and the answer cannot be
"we already launched".

One practical consequence: if you run a pilot on one vendor and switch for production, you may need the notice twice, or you may need to give it for the production vendor before the pilot has finished choosing. That is a good reason to shortlist vendors early even if the evaluation runs late, and it is one of the queue-time items that dominates an enterprise timeline.

The message

A notice that answers the questions people actually have is shorter than one that does not, because it does not generate a thread. Six elements.

1  WHAT CHANGES     in one sentence, in the first line, in
                    plain words. Not "we are excited to".

2  WHAT DATA        the specific categories involved. If the
                    answer is "the same data as today, to one
                    additional processor", say exactly that.

3  WHO              the new party, named, with its role and
                    where processing happens.

4  WHAT IS KEPT     retention, and whether the data is used to
                    train anyone's models. Say the answer even
                    if the answer is no — especially then; it
                    is the first question you will be asked.

5  WHAT YOU CAN DO  opt out, object, or nothing required. If
                    there is a deadline, it goes here in bold.

6  WHERE TO ASK     a real address, monitored by someone who
                    can answer the follow-up.

For the disclosure kind, the equivalent is much shorter and lives in the interface: what produced this, how confident you are entitled to be in it, and what a person did or did not check. “Drafted automatically — please review before sending” does more work than a paragraph in the terms, because it appears at the moment the judgement is being made.

Sentences that cause trouble later

“Your data is never stored.” Almost always false in some corner — abuse-monitoring retention, your own logs, a cache. Say what the retention is; zero retention has a specific meaning and you should only claim it if it is contractually true of every hop in your own diagram.
“Reviewed by our experts.” Only if somebody reviews every one. Implying a human check that happens on a sample is the claim most likely to become a problem in an incident.
“99% accurate.” A number you cannot defend, on a task nobody defined, that will be quoted back to you. State what it does, not how often it is right, unless you have a measurement with a published method.
“AI-powered.” Not harmful, just empty. It tells a customer nothing about what changed and pattern-matches to marketing, which makes the substantive parts of your notice less likely to be read.
A retroactive terms change. Announcing new processing as though it had always been covered. This is the one that converts a routine notice into a trust problem, and it is usually done accidentally by a legal update that ships alongside a feature.

The general principle underneath all five: write the notice so that it would still look reasonable if it were quoted back to you during an incident. That single test removes most of the sentences worth removing, and it is a cheaper editing pass than a legal review.