When Personalisation Stops Feeling Helpful: AI, Customer Data and the Trust Gap

A customer chooses to receive stories about design history. The next email contains design history. That feels straightforward: a preference was expressed and the business respected it.

Now imagine the same customer receives a message based on a sensitive interest they never knowingly shared with that business. The recommendation might be relevant. It might also raise a much more important question: how did you decide that about me?

These are illustrative situations, not reported customer cases. They expose the tension behind personalised marketing. Relevance can be helpful, but relevance alone does not establish permission, fairness or trust.

AI adds another complication: a system can make a guess instead of looking up a preference. A business may know what someone asked for, record what they did or predict what they might want. These are three different kinds of information. Mixing them up can make a clever service feel uncomfortable.

The useful question is not whether personalisation is good or bad. It is whether the customer can understand the relationship: what information is being used, why it is being used and how much control they genuinely have.

Personalisation did not begin with AI

A shop assistant remembering a regular customer's preferred product is a form of personalisation. So is a website allowing visitors to select a subject, or a mailing list sending different articles to people who chose different interests.

Neither requires a system to make a prediction about the customer. A simple rule can connect an expressed choice to a useful response.

AI-assisted marketing introduces other possibilities, such as generating different versions of a message or predicting which offer may appeal to someone. Those activities should not be grouped together merely because the same software package offers them.

Writing a clearer product description and building a profile of an identifiable person raise different questions. So do suggesting a category based on a current request and combining information collected across several contexts.

Before considering the technology, describe the actual job. Is the business answering a question, adapting content, selecting recipients or making an inference about a person? A precise description is more useful than announcing that the marketing is now intelligent.

Our practical interpretation at Time for Designs is that a helpful experience should reduce the customer's work without quietly expanding the relationship beyond what they understood.

What the customer told you is not what you guessed

Suppose someone asks about clothing for a team. That tells the business about the enquiry. It does not automatically establish the person's occupation, interests, spending power or future buying plans.

A page visit is also ambiguous. Someone could be researching for another person, comparing suppliers or simply reading an interesting article. A prediction can be useful without being a reliable description of that individual.

A guess can become a problem when it is saved as a record. A label inside a system may look like a fact. Other people may then use it without knowing how uncertain it was.

A sensible customer-facing distinction is between:

• Stated information: something the person actually supplied.
• Observed activity: something recorded during an interaction.
• Inferred information: a conclusion drawn from other signals.

This is an explanatory framework, not a legal classification. Its value is that it prevents a business from confusing “the customer asked for this” with “the software thinks the customer might want this”.

The more consequential the use, the more important that distinction becomes. A suggested article and an important decision about a person should not receive the same casual level of scrutiny.

The Avast case: when the promise and the data use diverged

In June 2024, the US Federal Trade Commission finalised an order concerning Avast's browsing-data practices. It banned the sale or licensing of browsing data for advertising and required a $16.5 million payment.

The FTC alleged that Avast collected browsing information through extensions and antivirus software, sold detailed, re-identifiable data through Jumpshot and failed to provide adequate notice and consent. The central contradiction was the privacy protection consumers had been promised.

This is a documented data-and-advertising case, not evidence that AI caused the conduct. It is relevant because it makes the trust problem visible: the apparent purpose of a product and the use of information gathered through it can point in opposite directions.

For the customer, the issue is not simply whether the data could support useful advertising. It is whether that use belonged to the relationship they believed they had entered.

A business can lose the meaning of its own promise when the activity behind the interface contradicts it. A reassuring sentence is not a substitute for checking what actually happens.

Start with a purpose, not a collection of possibilities

Software demonstrations often begin with what can be done. Responsible planning begins with what needs to be done.

The Irish Data Protection Commission's overview of data-protection principles includes purpose limitation, data minimisation, accuracy, storage limitation and accountability. In plain terms, personal information should have a defined purpose, be relevant to that purpose and be handled with appropriate care.

For a small business, that creates a useful question before a new tool is introduced: what customer problem would this additional information solve?

If the problem is that visitors cannot find the right product, a clearer category may help. If readers want different topics, allowing them to choose may help. Neither problem automatically requires a detailed profile assembled from unrelated activity.

More information is not necessarily a better brief. It can make the system more complicated, create more uncertainty and increase the consequences of mistakes.

A restrained design begins with the smallest useful interaction. It should be possible to explain why each requested detail belongs there, rather than defending it afterwards because the software happened to collect it.

Consent is important, but it is not a universal explanation

It is tempting to simplify privacy into a single instruction: ask for consent and everything is settled. That can be misleading in both directions.

The DPC's guidance on legal bases explains that GDPR provides several possible bases for processing personal data, including consent, contract and legitimate interests. The appropriate basis and accompanying obligations depend on the processing. A business cannot select one casually because it sounds convenient.

Different activities can also have additional rules. The DPC's cookie and tracking guidance explains the interaction between ePrivacy requirements and GDPR. A general discussion of GDPR legal bases is not permission to ignore tracking requirements.

This article does not determine the correct basis for a particular campaign or approve a cookie setup. Those decisions require the actual activity, technology and circumstances to be assessed.

From the customer's viewpoint, however, the communication should still be understandable. What will happen if they agree? What happens if they do not? Does an optional choice really remain optional?

A prominent button and a reassuring label cannot answer those questions unless the underlying behaviour matches them.

Removing a name is not the same as removing a person

“The data is anonymous” is a powerful reassurance. It should not be used merely because a name has been replaced with a number.

The European Data Protection Board distinguishes pseudonymisation from anonymisation. Pseudonymisation reduces the link to a particular individual without completely cutting it. Truly anonymised information is no longer linkable to an individual and is not personal data under EU data-protection law.

The practical lesson is to ask what the method actually achieves. Changing a visible label is not, by itself, evidence that identification is impossible.

For a business commissioning a system, a vague assurance should lead to a more precise conversation. What information remains? Who holds the additional information? What can be connected across records? What evidence supports the claim being made?

This is not an invitation for a marketer to certify anonymisation. It is a reason not to repeat a technical guarantee that has not been established.

Careful language protects the customer and the business. “We removed the names” and “no individual can be identified” describe different claims.

The prompt can be a new destination for customer information

An employee using an AI tool to polish a message may think of the task as writing. If the prompt contains customer information, it is also a data-handling decision.

The DPC's July 2024 guidance on AI and large language models advises organisations to understand what personal data a tool uses, where it goes, whether a provider retains or reuses it and how relevant rights can be supported. It also stresses that publicly accessible personal data remains within GDPR's scope.

A useful boundary is therefore established before staff start copying material into a tool. What kinds of information are permitted? Which product and account are approved for the task? Who has checked the actual arrangements?

For testing, invented sample information can often help demonstrate a workflow without exposing a real customer's details. That is a proposed practical approach, not proof that every test is risk-free.

The important point is ownership of the decision. A convenient text box should not become an unexamined route through which private material leaves the business.

Privacy, bias and copyright are different questions

One ethical label can conceal several distinct problems.

The US National Institute of Standards and Technology's 2024 generative-AI risk profile treats data privacy, harmful bias, intellectual property and confabulation as separate risk areas. Confabulation concerns confidently presented false or erroneous content.

That separation is useful when reviewing marketing work. A message might reveal private information. It might make an inaccurate claim. It might use an unfair assumption about a group. Or its imagery might raise questions about rights. Fixing one does not establish that the others have been resolved.

For example, removing customer names does not make a generated statement accurate. Checking spelling does not establish image rights. A privacy notice does not demonstrate that a recommendation treats different people fairly.

These are review questions, not conclusions about a particular tool. The work needs to be inspected according to the actual risk, rather than approved under a broad promise that the system is ethical.

A human review should also have a clear purpose. Asking someone to glance at the output is less useful than asking them to check specific claims, assumptions and information that must not appear.

Transparency should help someone make a decision

A privacy explanation can be technically available and still be difficult to use.

The DPC's transparency guidance identifies information people should receive about processing, including the organisation, purpose, legal basis, sharing, storage and relevant rights. Where consent is relied on, the explanation must include how it can be withdrawn.

The design question is where that information helps the customer understand the choice in front of them. A long policy elsewhere on the site does not make every nearby label clear.

A useful explanation should avoid implying that a preference does more than it actually does. Choosing a topic is not necessarily agreeing to every future marketing activity. Turning off one feature should not be described as stopping everything unless that is true.

The interface also needs to work after the choice. Can the person find the preference again? Can they ask a question without navigating a maze? Does the business know who handles the request?

Transparency is a continuing relationship, not merely a sentence added at launch.

What a genuinely helpful experience looks like

There is no single layout that makes personalisation appropriate. There are, however, useful questions a customer-first review can ask:

• Does the person understand what they are choosing?
• Is the information requested relevant to that choice?
• Are a stated preference and an inferred interest kept distinct?
• Can someone use a reasonable route to help?
• Do explanations describe the system's real behaviour?
• Is there a process for identifying and correcting mistakes?

These questions do not replace a legal or technical assessment. They help prevent a project from being judged only by the sophistication of its features.

It is also worth asking whether a simpler experience would serve the reader better. Clear categories, useful related stories and voluntary preferences can make a website feel relevant without pretending to know everything about the visitor.

Our design interpretation is that relevance should be earned by listening before it is attempted through inference. A business does not need to make the customer feel watched to help them find something worthwhile.

The trust gap is the part the technology cannot hide

The most revealing moment in personalised marketing is not when the recommendation is accurate. It is when the customer asks how it was produced.

Can the business give an honest, understandable answer? Does that answer agree with the promise that brought the person there? Can someone decline, correct information or seek help without being treated as an obstacle?

AI can change the methods used to produce a message or select an offer. It does not remove those questions. Nor does a relevant result prove that the information behind it was collected or used appropriately.

For another perspective on the relationship between technology and creative decisions, read Before the AI Prompt: The Artists Who Taught Computers to Draw. The history is different, but the useful distinction remains: a machine's output and the choices made around it are not the same thing.

A helpful business relationship should survive an explanation of how it works. That is a better ambition than making the customer marvel at how much the system seems to know.

Sources and scope

This article draws on official guidance from Ireland's Data Protection Commission, the European Data Protection Board, the US Federal Trade Commission and NIST. The Avast account describes the FTC's allegations and final settlement order; it is not presented as an AI incident. The customer scenarios are explicitly illustrative, and the design interpretation is Time for Designs' own.

This is an educational article, not legal advice, a compliance assessment or a claim that Time for Designs provides specialist AI-governance services. Particular uses of customer information require assessment of their actual circumstances.