Generative content in CRM, and the rules around it

A lifecycle team we spoke to recently had built something sensible. A model generated forty subject-line variants per campaign, a person picked six, and the six went into a test. Send volumes were unchanged, the copywriter spent her time on the body rather than on the twentieth attempt at a subject line, and results were slightly better.

Then someone in legal asked a reasonable question: what customer data goes to the model, where does it run, and can we show how a given message was produced. Nobody had an answer written down. The work paused for five weeks while three teams reconstructed it.

That pause is avoidable, and it is the main thing worth planning for right now. The EU AI Act entered into force on 1 August 2024, and obligations for general-purpose AI models applied from 2 August 2025. Most CRM uses of generative models are nowhere near the high-risk categories, but the expectations around transparency and data governance now have a legal shape rather than being a matter of internal taste. We are practitioners, not lawyers, and everything below is about operational practice rather than legal advice.

What these models are actually good at in a CRM programme

Being specific about the use cases makes the governance question smaller, because most useful applications touch very little personal data.

The ones that repay the effort.

• Variant generation. Producing many drafts of a subject line, a push title or a call to action, for a human to select from and a test to settle. The model widens the search space; it does not choose.
• Translation and localisation drafts. A first pass in each market language, reviewed by someone who speaks it. This is where the time saving is largest for multi-market teams.
• Summarising into a template. Turning structured product or content data into a consistent block of copy, at a volume no copywriter could sustain.
• Editorial consistency checks. Flagging where a draft breaks the brand's own rules on tone, claim language or reading level.

The ones that disappoint, consistently: writing a whole campaign unsupervised, inventing product benefits, and generating anything that states a price, a date or an availability. Anything factual has to come from your systems as a variable, not from the model as a sentence.

That distinction between generated wording and system-supplied facts is the single most useful line to hold. It keeps generated text firmly in the same category as any other dynamic content: a template with variables, where the variables are authoritative and the surrounding words are style.

High-volume, structured catalogues are where this pays off most obviously. We described the mechanics in the piece on marketplace journeys, where the content problem is thousands of listings rather than one hero message, and templating is the only workable answer.

Write down the data flow before the first pilot

The question that stopped the team above is the one to answer first, and it takes an afternoon.

Three things need recording per use case. What data is sent to the model. Where the model runs and under whose contract. Whether anything sent is retained or used for training by the provider.

For most CRM use cases the honest answer to the first question should be "no personal data at all". A subject-line generator needs the campaign brief, the offer, the tone rules and the audience description. It does not need names, addresses, order histories or identifiers. Designing the prompt so personal data never leaves your systems removes most of the GDPR surface before you have to reason about it.

Where personal data genuinely is involved, the ordinary rules apply in the ordinary way. You need a lawful basis, the processing has to be within what people were told at collection, and the arrangement with the provider has to be papered. Teams relying on legitimate interest for personalised marketing should expect the balancing assessment to be revisited when the processing method changes materially, and adding a third-party model is a material change. Your privacy team owns that judgement, not the CRM team.

Two operational habits make the rest easier. Keep a register of every generative use case in the programme, with the three data-flow answers attached. And prefer providers and deployment options where retention and training settings are contractual rather than a checkbox someone might change.

Transparency is now a design requirement, not a preference

The direction of travel across the current rules is consistent. People should be able to tell when they are dealing with an automated system. Providers of the underlying models carry documentation duties towards the businesses that build on them.

For a CRM programme the practical readings are narrow but real.

A generated marketing email that a person reviewed and approved is not a conversation with a machine, and treating it as one would be odd. An automated chat or reply agent that a customer converses with is different, and people should be able to tell.

Where synthetic images or voice appear in a campaign, plan for disclosure as a design element rather than a retrofit. Deciding where the label goes while the layout is being built is far cheaper than adding it afterwards across forty templates.

Ask your model provider for their documentation, and keep it. Downstream duties are much easier to meet when the upstream paperwork exists in your own file. A business that deploys a system generally cannot discharge its obligations by pointing at a vendor's website.

Keep human review where the risk actually is

Blanket approval of every generated sentence is expensive and it trains people to click approve. Put the review where a mistake would cost something.

We tier it roughly like this. Anything making a claim about price, availability, eligibility, safety or a regulated product gets full human sign-off, every time, without exception. Anything customer-facing but non-factual, such as a subject line or a push title, gets human selection from generated options. Anything internal, such as a brief summary or a test plan, needs no formal review at all.

Add one automated gate before any of that: a rule-based check for banned claims, competitor names, prohibited words and required disclaimers. It runs in milliseconds, it never gets tired, and it catches the category of error that reviewers miss on the fortieth variant.

Log what was approved, by whom, and against which version of the prompt and template. Not for its own sake, but because the first time a customer complains about a message, someone will ask how it was produced, and a five-week reconstruction is a bad answer.

Measurement does not change, and that is the point

None of this alters how you decide whether the content is any good. Generated copy competes against human copy on the same terms, in the same tests, measured on the same outcome.

Resist the temptation to report on adoption. The share of campaigns using generative tooling is an activity metric and it tells you nothing about value. Report the outcome the content was meant to move, with the usual controls, and be prepared for the honest result that many generated variants perform about the same as the human baseline. Performing the same at a fraction of the production time is still a good outcome, and it is a different claim from performing better.

Where generation does tend to earn its keep is breadth. It makes it economic to write proper copy for the long tail of segments that previously received the generic version. That is where a propensity model finally has somewhere to send its output. The lift comes from covering the tail, not from better words at the head.

Start with the register. List every place in your programme where a generative model already touches customer-facing output, including the ones individual team members adopted quietly, and write the three data-flow answers next to each.