In most retail marketing teams the sequence has been the same. First one person started letting an assistant suggest subject lines. Then product copy, then the image for an ad, then the weekly market recap. At some point half the copy production ran through AI, and nobody had ever written down what was allowed.
This rarely goes wrong spectacularly. It goes wrong in small places. Someone uploads an export containing customer addresses into a tool nobody can say stores data where. A draft goes into review without the reviewer knowing that 90 percent of it came from a model. A connector holds write access somewhere, and no one remembers who set it up.
This guide gives you the page that prevents all three: a policy a marketing team can agree on in one afternoon, with a template to adopt. Not legal advice, a working basis, as of 2 November 2026.
Why one page beats a handbook
The common first response is a large document: principles, roles, risk classes, a committee. Those papers get written, presented once, never opened again. In day-to-day marketing they fail at a simple hurdle: nobody needing a subject line at eleven in the morning reads twenty pages.
A policy works when it answers four questions memorably: which data into which tool, what a connection may read and write, what you label and where, and who approves something new. Everything else is an appendix.
The second reason for brevity: a sentence everyone knows holds, while a rule in section 4.3 gets bypassed because nobody can find it.
What the legal frame asks for
Two points matter for marketing teams in the EU, and both sit in the AI Act, Regulation (EU) 2024/1689.
The first is AI literacy under Article 4, which obliges organisations deploying AI systems to see that the people working with them also understand them. It has applied since 2 February 2025. Its wording was softened in the summer of 2026: it aims at fostering competence rather than guaranteeing a level, but the duty to act remains. For a marketing team this is not a certification question. A documented briefing on where a model tends to be wrong, and what the team therefore checks, serves better than a training certificate.
The second point is the transparency obligations under Article 50, in effect since August 2026. Two of them show up in marketing work: people have to be told when they are interacting with an AI system and that is not obvious, and synthetically generated or manipulated content has to be marked as such, machine-readably included.
On top of that sits data protection law, which AI did not change. Personal data in a tool needs the same legal basis and processing agreement as with any other vendor. The detail belongs with whoever reviews contracts at your company; the consolidated text of the Regulation is the only reliable source for wording and deadlines.
Question 1: Which data goes into which tool?
This is where most goes wrong in practice, and four classes answer it. Sorted by data, not by tool, because tools change faster than the classes do.
| Data class | Retail examples | Allowed in |
|---|---|---|
| Public | Competitor newsletters, press releases, your own shop pages, ad libraries | Any approved tool |
| Internal, non-critical | Campaign plan, subject-line archive, style guide, range lists | Approved tools under a business agreement |
| Personal | Customer lists, order histories, support threads, job applications | Only with a processing agreement and a documented purpose |
| Confidential | Buying prices, margins, supplier contracts, figures before publication | Not into an AI tool unless something else is approved in writing |
Two notes carry this table through the week. First, the difference between a private account and a business one is a contract question, not a price question: anyone working with internal material needs access where it is settled what happens to the inputs. Second, the most common breach is not bad intent, it is an export file. It almost always holds more columns than the question needs, and deleting those before upload solves most of the problem.
Question 2: What may a connection read, and what may it write?
As soon as a team hooks AI clients up to its own systems, the topic shifts from text to permissions. A model that writes prose can do little harm. A model that writes into a system can. That difference belongs in the policy, in three tiers.
| Connection | What it may do | Approval |
|---|---|---|
| Read only | Retrieve, analyse, summarise data | By the person who owns the tool |
| Write inside your own account | Create drafts, entries and comments | Named approval, one named owner |
| Send outward | Publish emails, ads or posts | Never automatic, always a human first |
The rule behind it: reading is the default, writing the exception, sending never automatic. Whoever sets up a server checks first whether it can run read-only, because many can. And every write connection gets a name in the team, not just an entry in a config file. Connections without an owner are unexplainable two quarters later.
What such a server is, and how it differs from an API, is covered in What is an MCP server?. Which ones exist for the usual marketing tools, and which write by default, is in the overview of MCP servers for marketing. That second part matters more: with several connectors, writing is the default rather than the exception.
Question 3: What do you label, and where?
Labelling splits into two things that often get mixed up.
Internally it is about traceability. A draft that came out of a model is flagged as such when it goes into review. That is not about blame, it is information for the reviewer: in an AI draft you look harder at numbers, product names and promises, because that is where the errors sit. A line in the ticket is enough.
Externally it is about the transparency obligations. In practice: images and video a model generated or altered get marked, visibly and in the metadata. Pure text work, where a human owns and checks the content, is a different case from a generated image. Platform rules apply on top and are often stricter. For your own templates the effort pays once: if the label is built into the image and email templates, nobody has to remember it.
We do the same with this blog's hero images: generated illustrations, labelled in the image, named as such in the alt text.
Question 4: Who approves?
This decides whether the policy stays a piece of paper. Three sentences will do.
Using approved tools within the data classes is free, no case-by-case approval. A new tool, connector or write connection needs named approval by someone who has checked contract and data class first. And every outward publication has a human in front of it who owns it.
That needs a register, and a spreadsheet qualifies: tool, purpose, data class, permissions, owner, approval date. Barely more than accounting holds anyway. It is the only part of the policy needing upkeep, and the part that counts in an audit. How Reyo itself handles data and access is on the trust and security page.
The template
The ten points below are the policy. Adopt them, cut what does not fit, and put your tools into point 2.
# Marketing AI policy, effective <date>
1. Purpose: we use AI for drafts, analysis and research. Responsibility
for the result stays with the person who approves it.
2. Approved tools: <list>. Other tools only after approval under
point 7.
3. Data: public and non-critical internal material may go into the
approved tools. Personal data only with a processing agreement and
a documented purpose. Buying prices, margins, contracts and
unpublished figures do not go in.
4. Exports: before uploading, delete the columns the question does
not need.
5. Connections: reading is the default. Writing connections need
named approval and an owner.
6. Nothing automated sends outward. A human stands before every
publication.
7. Approval: <name or role> approves new tools and write connections
and keeps the register.
8. Internal labelling: AI drafts are named as such in review.
9. External labelling: generated or altered images and video are
marked visibly and in the metadata. Platform rules apply on top.
10. Briefing: new colleagues get this page and half an hour on
typical failure modes. Reviewed every quarter.
The template deliberately comes without risk classes and without a committee. You need both if you build AI into products or automate decisions about people, not for a team drafting copy and reading the market.
How to roll it out
Four steps, none longer than one meeting.
Inventory. Ask the team which tools are actually in use. The answer is longer than the official list everywhere, and that is the insight. Take it without blame, or you will not get it next time.
Draft. Use the template and decide three things: approved tools, who approves, where the register lives.
Thirty minutes with the team. Do not read it out. Walk through two real cases: one where somebody was unsure, one that already went wrong. That half hour is also the briefing from point 10, and therefore the practical part of AI literacy. Note date and attendees, and it is documented.
Review quarterly. Go through the register, switch off unused connections, add new tools. Fifteen minutes, and the policy stays true.
Where Reyo sits in the policy
If you use Reyo, the register entry is short. Reyo MCP connects Claude, ChatGPT or Claude Code to your Reyo account. Your client reads your competitors' campaigns and emails, creates entries in the Campaign Planner and writes comments, always only within your account. In the table above that is a read connection on public data plus a write connection inside your own account: tiers one and two, not tier three, because nothing goes outward. The setup guide shows the steps per client.
Two limits belong in the same line, because they decide what an assistant may claim. With competitor data we see what was sent, not how it performed: opens, clicks and revenue of other shops are not available to anyone. And in analyses we do not name the shops, the point is the patterns, not the senders. Where the observations come from is shown by competitor monitoring.
Four mistakes we keep seeing
- The ban as a policy. Prohibit AI and you get private accounts, not compliance. Permit clearly, draw the line at the data.
- The tool list as the core. Tools change within a quarter. Sort by data class and the page keeps holding.
- Write access as an afterthought. It is the only point where a model changes something, so it belongs in approval, not in a config file.
- No review. A policy without a quarterly slot describes a team that no longer exists.
In short
An AI policy for marketing is not a compliance project. It is one page with four answers and a table: which data, which permissions, which labelling, whose approval. Teams that have it stop arguing about every new tool and argue about its data class instead.
How to lay down the subject-matter context next to it, so the drafts sound like you in the first place, is covered in the guide on Claude for marketing. The policy says what is allowed, the context says how it is done at your company. Together they separate a team that uses AI from one that has it under control.
As of 2 November 2026. Not legal advice. Statements on the AI Act, Regulation (EU) 2024/1689, reflect 2 November 2026; for wording and deadlines the consolidated text of the Regulation governs.