By Greg Nowak. Last updated 2026-06-24.
AI image generation is no longer sitting off to the side as an experimental design tool. OpenAI presents GPT-4o image generation as a practical visual communication system, with stronger prompt following, text rendering, photorealistic output, and conversational editing. Its image API documentation also frames image generation and editing as something teams can build directly into applications, using text and image inputs.
So AI visuals are starting to enter ordinary production workflows: campaign graphics, web illustrations, social assets, client decks, landing pages. That is where the problem shifts. The risky point is often not the generator. It is everything that happens after the file arrives.
A generated image may start with provenance signals attached. Then it is uploaded to WordPress or Drupal, resized into thumbnails, compressed by an optimization plugin, served through a CDN, renamed, downloaded, cropped, and reused in a client presentation. By the end of that path, the team may be looking at a visually similar file with a different evidence state.
That distinction matters. One version may still carry useful attribution, creation history, or AI-use indicators. Another may not. If nobody has tested the path, approval becomes guesswork.
Provenance is not one single mechanism either. C2PA defines technical standards for certifying the source and history of media content. OpenAI says images generated with GPT-4o include C2PA metadata identifying them as coming from GPT-4o. Adobe describes Content Credentials as an industry-standard metadata type that can show creator information and how content was made, including AI generation or edits in creative tools. Google DeepMind's SynthID works differently: it embeds imperceptible watermarks into AI-generated media, designed for detection by SynthID technology and resilience against changes such as cropping, filters, and lossy compression.
For a CMS project, those differences are not academic. A media library is not a folder of originals. It is a transformation system. It creates renditions, changes compression, exposes different URLs, and gives editors several ways to download or reuse the same image. Some transformations are useful. Some are necessary. The governance issue is whether the team knows what each one does to provenance.
What the audit should prove
A useful audit starts with files, not policy language. Take a small test set: AI-generated images with known provenance signals, images exported from creative tools with Content Credentials, and, where relevant, provider-specific watermarked assets. Then run them through the real workflow: upload, crop, thumbnail generation, page placement, CDN delivery, manual download, and re-upload.
The work is straightforward: compare the original file, the CMS-stored version, every derivative that matters, and the public URL a client or visitor would actually touch.
| Workflow stage | Question to answer | Evidence to record | Decision needed |
|---|---|---|---|
| Source asset | Which generator or creative tool produced it? | Original file, export context, and provenance signal before upload. | Accept only assets with recorded origin. |
| CMS upload | What changes during ingest? | Stored file compared with the original, including verification result. | Preserve the original or document normalization. |
| Derivatives | Do thumbnails and responsive sizes keep the signal? | Each generated size and its provenance outcome. | Define where provenance must survive and where it is optional. |
| Optimization and CDN | What happens after compression, caching, or URL rewriting? | Public CDN file, downloaded public file, and verification result. | Configure, bypass, or document the transformation. |
| Manual handling | What happens when editors download and re-upload? | Before-and-after comparison of the handled file. | Update editorial rules for client-ready assets. |
| Client delivery | Which file is approved, exported, or sent? | Final asset, verification record, and approval note. | Keep the evidence trail with the delivery package. |
The test is before and after
When an asset is expected to carry Content Credentials, check the source file and then check the public version with the Content Credentials verification tool. For images from Google AI workflows, DeepMind points users toward SynthID checks through Gemini and a detector portal; the audit should record whether those checks apply to the provider and asset type being tested.
The goal is not to force every image into one universal badge system. The goal is more practical: can the team answer what evidence the asset had before publication, and what evidence it has after publication?
That answer should separate preservation from policy. A site may normalize images for performance, privacy, compatibility, or consistent delivery. That can be reasonable. But if a workflow strips or hides provenance, it should be an explicit decision with a compensating control. Keep an untouched original in the CMS. Publish optimized derivatives. Store the provenance record in the editorial system. Require client downloads from a controlled asset library rather than a resized front-end image. The right setup depends on the site; the weak setup is the one nobody has checked.
Where teams get caught
The common blind spot is confusing an asset with a rendition. An editor uploads one file, but the front end serves another. A designer checks a desktop export, while the client sees a compressed CDN object. A campaign manager downloads an image from a rendered page and drops it into a deck. Each step can create a different file with a different provenance result.
The second blind spot is writing one policy for several different signal types. C2PA and Content Credentials are metadata-centered. SynthID is watermark-centered. A rule that only says preserve metadata does not fully describe a watermark workflow. A rule that only says check for AI watermarks does not fully cover creative attribution or version history. The audit should name the signal, the test method, and the result at each stage.
What GrN can document
For a WordPress or Drupal site, Greg's role is not to label every AI image as acceptable or unacceptable. The useful work is making the publication path observable. That usually means a media provenance map: where originals are stored, which derivatives are created, which plugins or services alter files, which public URLs serve the asset, and where editors or clients are likely to download from.
The second deliverable is a decision matrix that states which signals are preserved, stripped, or intentionally normalized at each step. That gives commercial teams something they can use. Designers know which exports are safe to hand over. Editors know whether a crop changes the provenance state. Project managers know which file should be used for approval. Marketing leads can explain, plainly, how AI-generated or AI-edited visuals are governed before publication.
The timing is important because provenance tools are becoming visible to non-technical stakeholders. Adobe positions Content Credentials around creator recognition and transparency. C2PA frames provenance as a standard response to misleading information online. OpenAI and Google are both describing provenance or watermarking as part of modern AI media systems.
Once a client asks why one version of an image verifies and another does not, the CMS cannot be a black box. Audit the path before that question arrives. Keep the creative workflow fast, but make the evidence state testable. AI images can be client-ready; the media library needs to be ready as well.
Related on GrN.dk
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
- WordPress 7.1's Media Pipeline Needs a Real Plugin and CDN Test Pass
- WordPress.org's 24-Hour Plugin Cooldown Turns Plugin Governance Into a Real Client Project
Need help with this kind of work?
Audit your CMS media workflow Get in touch with Greg.