What to do when a generated asset ships wrong

Coca-Cola's AI-assisted holiday campaign compressed a production timeline reported at roughly a year down to roughly a month, and it drew significant public backlash. Both are true about the same campaign. That is the shape of the risk at volume: the speed is real, and when generated creative goes wrong, it goes wrong in public.

At any real output volume, something will eventually ship that should not have. A disclosure label that did not survive the export. A face that resembles someone real closely enough that their lawyer notices. A music bed licensed for organic that ran as paid. These are ordinary failure modes for a pipeline moving hundreds of assets, and the difference between a bad afternoon and a bad quarter is whether you have a sequence to follow.

Step 1: Pull, before you diagnose

The instinct is to establish what happened first. Resist it. Pulling is reversible and cheap; a wrong asset accruing impressions is neither.

The operational rule: anyone who can see the problem is authorised to pull, without approval. If pulling needs a sign-off, it happens hours later, and those hours are the cost of the incident. Make un-pulling the thing that requires sign-off.

Pull every surface, not just the one you were told about. Work a fixed list so nobody has to remember under pressure:

• Paid placements across every platform and ad account, including automated variants
• Organic posts on every connected account, including cross-posted copies
• Scheduled and queued posts that have not gone out yet
• The website, landing pages, email templates, and anything embedded
• Partner, affiliate and reseller channels that received the asset
• Any batch siblings from the same generation run

That last one is the step most often skipped, and the one that turns a single incident into a second incident a week later. If the cause is a prompt, a reference image or an export preset, every asset that shared it is suspect until checked.

Then note the time. You will need it.

Step 2: Notify, in a defensible order

Order matters more than speed, because notifying in the wrong order creates problems that did not exist before.

#	Who	Why this order
1	Internal owner and whoever can pull the remaining surfaces	Containment is still in progress
2	The client, by phone or call, then in writing	They must not learn it from a third party
3	The affected person, if a likeness or voice is involved	Delay here is what converts a complaint into a claim
4	Legal or insurer, if rights, claims or a real person are involved	Many policies have notification windows
5	The platform, where its rules require it	Voluntary correction is treated differently to a caught violation

Two notes on the client call.

Lead with what you have already done, not with what happened. "It's down everywhere as of 14:20, here is what we know, here is what we are checking" is a different conversation to "we have a problem." The first tells them you run a process. The second invites them to run it for you.

Do not assign fault on the first call. Not to yourself, not to them, not to a model vendor. You do not yet know whether the label was never applied or was stripped downstream, and those answers have opposite contractual consequences. Say what is confirmed, say what is being checked, give a time for the next update.

If the incident is a platform enforcement action rather than your own discovery, the recovery path is more procedural — surviving a YouTube inauthentic content strike covers that from the receiving end.

Step 3: Log, because the record decides what happens next

Write the record while it is fresh, in one place, in a fixed shape. This is the document that decides whether the next conversation is about a mistake or a pattern, and it is what your insurer, your client and possibly a regulator will read.

• Timeline with timestamps. Published, detected, pulled, client notified. Detection-to-pull is the number that matters most, and the one you can improve.
• The asset in its shipped state. The exact file that went live, with its metadata. Not the master.
• Reach, honestly. Impressions, spend, geography, and whether an EU audience was reached — the last one changes the analysis, since Article 50 of the EU AI Act has been binding since 2 August 2026.
• The chain of custody. Which brief, prompt, model, reviewer, export preset, upload. This is where the cause lives.
• What the contract says. Pull the relevant clauses into the log now, before anyone starts negotiating.

The chain-of-custody line separates a five-minute answer from a two-week investigation, and it depends on discipline set up earlier. If the shipped asset cannot be traced to a specific batch and brief, you cannot establish whether the defect was yours, and "we cannot tell" defaults against you commercially. Verifying that provenance metadata survives your own delivery encode is a check you want to have been running before the incident — content credentials through a real pipeline shows where they get stripped.

Step 4: Remediate the class, not the asset

Fixing the asset is table stakes and takes an hour. The remediation that matters answers a different question: what change makes this category of failure impossible rather than unlikely? Sort the answer into the layer it belongs in.

Cause	Wrong fix	Right fix
Disclosure label missing	Add it to this asset	Make the label a required field at intake and a 100% pre-publish check
Credentials stripped on export	Re-export this one	Fix the preset, then verify on every delivery
Likeness too close to a real person	Reroll the shot	A clearance question at intake that routes the whole job differently
Music licensed for organic, ran as paid	Swap the track	Usage rights recorded at intake and checked at placement, not at delivery
Claim not substantiated	Remove the line	Claims route to a named approver before generation, not after

Four of the five right-hand fixes live at intake. That is not a coincidence. Almost every incident of this kind is an information problem that became a production problem, and the cheapest place to catch it is before anything is generated. The AI ad disclosure requirements for 2026 and one disclosure across five destinations give you material for that pre-publish gate.

Then close the loop with the client in writing: what happened, what changed, what specifically will now prevent it. A remediation note that names a process change converts an incident into a demonstration of competence. One that says "we'll be more careful" does the opposite.

What the contract should already say

None of this is legal advice, and your jurisdiction and insurer shape the detail. But practitioners writing on AI contracting converge on a fairly consistent minimum clause set, and if these are not in your agreement, the cost conversation after an incident is a negotiation rather than a lookup.

1. Disclosure of AI use in deliverables. Stated up front, so the client cannot later claim they did not know what they bought, and so the labelling obligation has an owner.

2. An IP warranty carve-out for AI-generated portions. The one most agencies still get wrong. The US Copyright Office position is that protection attaches to human contribution — substantial modification, human-created elements, and the creative selection and arrangement of AI material. Platform terms from the major model providers assign contractual ownership of outputs to the user, but a contract cannot manufacture copyright that statute does not grant. You cannot assign rights that do not exist. Replace a blanket "all deliverables are original works, fully assigned" with language stating that the agency does not warrant AI-generated portions qualify as copyrightable, and that status varies by jurisdiction.

3. A training-data exclusion for client materials. Client assets, brand files and data are not used to train models. Increasingly asked for by procurement.

4. A liability cap tied to the fee paid. The clause that decides the cost question. Without it, exposure on a job is unbounded and unrelated to what you earned on it.

5. Metadata preservation and audit rights. A delivery spec requiring provenance metadata to be preserved downstream, and a right to check.

The indemnity should split in two directions, which is what makes clause 5 enforceable. The agency indemnifies for using AI tools in breach of those tools' terms of service. The client indemnifies for distributing without required disclosure labels, stripping provenance metadata, or using deliverables for undisclosed purposes. That last item is why the usage field at intake is worth insisting on.

For the wider picture, legal and licensing for AI content in business is the broader guide, voice and likeness law for creator marketing covers the personal-rights side, and Denmark's likeness right shows how fast that ground is moving. Synthetic media disclosure is the term to search your own contracts for.

FAQ

Who pays when the asset was wrong but the client approved it?

Approval does not transfer a compliance failure, which is why the indemnity split matters. If the defect was in what you produced — an unlicensed track, an uncleared likeness — approval does not help you, because the client had no way to know. If it was created downstream, such as credentials stripped in their re-encode or a market they never disclosed, the usage clause puts it on their side. Genuine ambiguity is what the liability cap is for.

Should we tell the client if we caught it before anyone saw it?

Yes, briefly. A note saying you caught something in pre-publish and held the asset costs nothing and builds the reputation you want, which is that your checks work. Silence is cheap only until the second incident, at which point every previous silence becomes a question.

Is a small brand really exposed to this?

Rights exposure scales with reach; compliance exposure does not. A disclosure obligation applies to a post with a thousand views the same way it applies to one with a million, and a person whose likeness appears without clearance has the same complaint either way. What changes with size is whether anyone notices, which is not a control you own.