Identity & access · · 4 min read · Updated
Marketing needs a data boundary before it buys another AI tool
A plain-language data policy for marketing AI tools: classify inputs, choose allowed paths, name exceptions, and remove access when the work ends.
Marketing teams do not need a security lecture before using an AI tool. They need a short answer to a practical question: what information may enter this tool for this piece of work?
Without that answer, teams make a decision for every request. Some send sensitive material to a consumer account. Others avoid useful tools because nobody can explain the safe path. Both outcomes create cost.
A data boundary is useful when a marketer can apply it before pasting the first source into a tool.
Classify the inputs#
Start with four categories:
| Class | Marketing example | Default path |
|---|---|---|
| Public | Published help content, public product pages, public brand guidance | Approved tools with normal review |
| Internal | Unreleased launch notes, campaign plans, internal performance | Approved business account with retention settings reviewed |
| Confidential | Customer examples, pricing negotiations, partner terms | Named tool and owner, with access and retention controls |
| Restricted | Credentials, secrets, sensitive personal data, protected legal material | Exclude from general content tools; use an approved specialist path |
The labels matter less than the action attached to each one. If every category goes to “ask security,” the policy has not reduced work.
Name the allowed path#
For each category, document:
- the tools that may receive the data;
- the account or workspace that owns the data;
- whether provider training is disabled;
- the retention and deletion rule;
- who may approve an exception;
- what evidence the requester must keep;
- how access is removed after the campaign.
The marketing access policy separates requesters, source owners, approvers, and publishing authority. Add the data class to that decision so a person’s role does not become the only control.
Ask vendors concrete questions#
Procurement should get answers in writing:
- Which company receives the prompt, file, or retrieved source?
- Which subprocessors handle it?
- Is the input used to improve a model?
- How long are prompts, outputs, files, and logs kept?
- Where are primary data and backups stored?
- Can the customer delete content by workspace, user, or item?
- Which administrators can read customer content?
- What does the export contain when the contract ends?
The answers should map to the categories above. “Enterprise security” is too broad to decide whether an unreleased pricing plan may be used for a draft.
Keep access aligned with the work#
AI content access often remains after the campaign ends. Review:
| Access | Review question |
|---|---|
| User | Does this person still need to create or approve content? |
| Connector | Does the tool still need the source or publishing system? |
| Provider key | Which team owns the usage and rotation? |
| Shared folder | Can former collaborators still read drafts or sources? |
| Export | Where does copied content go, and who can use it? |
A shared login hides ownership and makes removal difficult. Give each person an identity where the tool supports it. Keep service access narrow, named, and reviewed.
Design the exception#
An exception should contain:
- the data class;
- the tool and account;
- the business reason;
- the owner;
- the expiry date;
- the reviewer;
- the deletion or cleanup step.
An exception without an expiry becomes the new default. An exception without an owner becomes a future question nobody can answer.
Capture evidence without saving everything#
The team does not need to store every private thought. It does need enough to answer:
- which source class was used;
- which tool and account received it;
- who approved the path;
- what content was accepted;
- when access ended or the exception expired.
The evidence package guide gives a compact set of fields for a published asset. Apply the same principle to the data decision: preserve the facts that explain why the path was allowed.
Make the policy easy to follow#
Put the decision near the request form or content brief:
| If the input contains... | Use... | Stop when... |
|---|---|---|
| Public facts | Approved standard tool | The source is no longer current |
| Internal plans | Business account with approved retention | The tool cannot state its deletion rule |
| Customer or partner material | Named restricted path | The owner or expiry is missing |
| Credentials or secrets | No general content tool | The data is removed and the incident path is followed |
The policy should give a marketer a next action in less than a minute. If the answer requires a meeting for every request, the team will create workarounds.
Deixic can show connected tools, current activity, approval decisions, and missing evidence around agent work. Use the product view to make the operational state visible, while your security and procurement systems remain the authority for data classification and vendor terms.