Writing an AI-image policy for your team

Write the rule about where an image sits rather than about how it was made. Generated imagery is fine for decoration and not fine for anything asserting a fact, and that single line covers most of what a policy needs to say.

Why most of these policies fail

The common failure is writing about technology. A policy naming specific tools, or prohibiting artificial intelligence generally, is out of date within a release cycle and ambiguous from the day it is published, because generative features are already inside ordinary software.

The second failure is writing for lawyers rather than for the people doing the work. A designer choosing a header image at four in the afternoon will not consult a fourteen-page document, and a policy that is not consulted is not a policy.

The third is having no answer for what happens when something is found. Teams write a prohibition, discover generated imagery in their own back catalogue, and have no route that does not involve somebody being blamed.

The policies that work are short, describe the picture rather than the tool, and give people something to do rather than something to avoid.

Decision one: where it is allowed

This is the whole substance and it fits in two sentences. The dividing line is whether the image is doing the work of decoration or the work of evidence.

Generated imagery is fine

Abstract and decorative headers
Concept illustration
Backgrounds and textures
Internal decks and drafts
Anything clearly stylised

Generated imagery is not

Case studies and testimonials
Anything depicting a real customer
Before-and-after photographs
News and event coverage
Product photography of a real item

The line that does the work. Everything else in a policy is administration.

The right-hand column has a single common property: each of those images makes a factual claim. That is the test to write down, because it survives every future change in tooling and it is one a non-specialist can apply.

Decision two: who declares it

Declaration has to happen where the knowledge is, which is with whoever made or sourced the image. No downstream check recovers information that was never captured.

In practice that means one clause in every supplier brief and one field in whatever system holds your assets. Agencies, freelancers and stock subscriptions all need to say what is generated, and most will not volunteer it because nobody has asked them to.

The internal equivalent is a field rather than a conversation. A required note against each asset recording where it came from costs seconds at upload and saves an archaeology project later.

Decision three: what happens on a flag

Write the response down before you need it, because an improvised one under time pressure is where teams behave unfairly. A flagged image means ask, not accuse.

Ask the source
Whoever supplied it can usually answer in a sentence. Most flags resolve here, and most of those resolutions are ordinary editing.
Request the original
A raw file or camera original settles it far more reliably than any analysis.
Decide by placement, not by score
A generated header stays. A generated case study photograph is replaced regardless of how the number reads.
Record the outcome, not the score
What you did and why. A stored list of numbers against named suppliers is a profile nobody needs.
Fix the brief
If the same supplier is flagged twice, the problem is the instruction they were given.

The third step is the one that keeps a policy honest. A detector result is an input to a decision that is really about editorial placement, and letting the number make the decision produces inconsistent outcomes nobody can explain.

Decision four: what you keep

Retention is where good intentions turn into a data protection problem. The temptation is to log every check, and the effect is a running record of scores attached to named individuals or suppliers.

Keep the outcome with the asset: what it is, where it came from, whether it was declared. Do not keep a searchable history of who was flagged, which is a profiling exercise that will need its own justification and rarely has one.

For anything touching identity documents or people, keep less rather than more, and keep it for as long as the underlying record and no longer.

A worked example you can copy

It helps to see how short this can be. What follows is a complete policy in five sentences, which is longer than most teams need and shorter than most teams write.

Generated imagery may be used for decoration, illustration and internal material. It may not be used in anything that asserts a fact about a real person, place, event, customer or product. Suppliers must declare generated content in every deliverable.

Where an image is questioned, the person who supplied it is asked for the original file, and the decision is made on where the image sits rather than on any score. Outcomes are recorded against the asset, not against the supplier.

That is the whole thing. Everything else a longer document usually contains is either restating one of those sentences or describing a tool that will have changed by the time anybody reads it.

Getting it adopted

A policy nobody knows about is the same as no policy. Two things drive adoption more than the wording does: putting the rule where the decision is made, and making the compliant path the easy one.

The first means a line in the brief template and a field in the asset system, not a document in a shared drive. The second means having an approved source of decorative imagery ready, so that following the rule is not slower than ignoring it.

One last piece of advice from teams that have been through this. Date the policy and put a review month in it. Everything here depends on what tools do and what regulators require, and both move; a document with no review date quietly becomes wrong rather than being replaced.

Questions people ask

How long should the policy be?

One page. The four decisions here fit comfortably, and anything longer stops being consulted by the people who actually choose images. If a legal team needs more detail, put that in an annexe that the working document points at.

Should we ban AI images entirely?

It is unenforceable, because generative features are inside ordinary editing software. Noise reduction, masking and sharpening are all trained models, so a literal ban prohibits routine work. Write about what the image claims instead of about how it was made.

What is the single most useful clause?

A requirement in supplier briefs that generated content is declared in every deliverable. Declaration has to happen where the knowledge is, and no downstream check recovers information nobody captured at the time.

Should we set a score threshold?

No. A numeric cutoff turns a likelihood with a published error rate into an automatic decision, and the genres most likely to be flagged are heavily edited genuine work. Decide by where the image sits, and use the score to decide what to ask.

What about images we published before the policy?

Audit the pages carrying factual claims, replace what needs replacing, and leave decorative work alone. Doing this before somebody else does it turns a potential embarrassment into an ordinary tidy-up, and it is usually a smaller job than teams expect.

Should we log every check?

Keep the outcome with the asset and not a searchable history of scores against named people or suppliers. The second is a profiling record that needs its own lawful basis, adds no operational value, and becomes a liability the moment somebody requests their data.