Editing and Using Images Responsibly

Generating an image from scratch is one workflow. The other, often more common in analytics communication, is taking an image you already have and changing one specific thing about it. That's editing, and it's where AI tools save the most time: a team wiki photo that needs a former teammate removed (make sure the reason is defensible and the edit doesn't misrepresent the team), a readout-deck graphic with the wrong background, an internal-comms visual with a distracting object. But editing also concentrates the risk. The closer an edited image looks to a real photograph, the more carefully you have to handle what it says, what it implies about real people, and — for analytics work — whether any depicted chart or number reads as real company data, because a public-facing image can land as a claim.

By the end of this lesson, you'll be able to:

• Identify the edit types AI tools can support — cropping, background changes, object removal, inpainting, outpainting, and style adjustments.
• Write image-edit instructions using the Image Edit Brief to preserve required elements while changing only the targeted area.
• Evaluate AI-generated or AI-edited images for brand, audience, accessibility, accuracy, and disclosure risks before sharing.

Before you write any instruction, it helps to know what's on the menu, because the right vocabulary gets you a faster, cleaner result:

Most analytics-communication edits are some combination of these. A "fix the team wiki photo" request is usually object removal (the person who left) plus a background change plus a light color match. Naming the edit type in your head first makes the instructions you write next much sharper, because each type has its own failure modes — and when the edit touches a real person's face or the makeup of a team, drift becomes an accuracy and authenticity problem, not just a cosmetic one.

Free-form editing requests like "remove the person who left and change the background" are how good team photos get ruined. The model may not know which details need to remain stable, and it can alter a remaining person's face, shift their position, or warp the lighting. The fix is the Image Edit Brief, a four-part instruction:

• Preserve: what must remain exactly as-is.
• Change: the specific edit, described concretely.
• Avoid: artifacts, drift, or unintended modifications.
• Output: final format, dimensions, and where it's going.

Preserve is the part people skip. You have to explicitly name the faces, positions, and lighting of the people who stay — anything you're not willing to lose, especially anything that affects how real people are represented. Change should be one or two surgical edits, not a wish list. Avoid catches the predictable failure modes: face drift, warped shoulders, mismatched lighting, seams. Output ties the edit to its real use: a team wiki page has different demands than a slide.

Let's look at what an analytics-team edit conversation might sound like:

• Ryan: What's the edit?
• You: Take the person who left out of the team photo and freshen up the background to match the new office.
• Ryan: That may come back with the remaining people's faces subtly changed. What are you preserving?
• You: The faces, positions, and lighting of everyone who stays. They come back pixel-for-pixel.
• Ryan: Good. And Avoid?
• You: No face drift, no warped shoulders, no seam where the person was, no mismatched lighting between the people and the new background.

Notice Ryan's pressure: name what stays before you name what changes, and for a team photo, "what stays" includes the real people whose likeness you can't distort. That order is the whole brief.

Before you even generate or edit, run a lightweight Visual Preflight so you decide what "acceptable" means before anything exists to argue about. Write down four things: the intended use and audience, the criteria you'll judge the result against, the approved and non-sensitive source assets you'll use, and the consent, rights, and disclosure needs. A minute of preflight keeps the checks below honest instead of retrofitting a justification onto an image you already like.

A clean edit doesn't automatically mean a publishable asset. Before any AI-generated or AI-edited image goes out under your team's or company's name — especially a blog post or recruiting post — run it through five Pre-ship Evaluation checks:

• Brand: does it match the visual system, or does it read as generic stock?
• Audience: will the people seeing it interpret it the way you intend, on this channel?
• Accessibility: does it need alt text, and is the contrast high enough where a headline overlays it?
• Accuracy: does the image imply something untrue — that a fabricated dashboard shows real company metrics, that these are real employees, a team makeup that doesn't reflect reality?
• Disclosure: if the image is AI-generated or substantially AI-edited, do platform rules or your audience's expectations call for labeling it (for example "AI-generated illustration; figures shown are not real company data")?

The accuracy and disclosure checks are where analytics teams get burned. An AI image of "our analytics dashboard in action," placed next to blog or recruiting copy, reads as a depiction of real work even if you never said so — and if the fabricated dashboard shows legible KPI cards like "Revenue +38%" or "Churn 2.1%," readers can easily mistake those for real company metrics; if the faces resemble real people, it's a likeness/rights problem, and if the depicted roles or demographics don't reflect the actual team, that's a stereotype and misrepresentation risk.

When an image includes or implies real people, layer a broader Responsible Visual Use Review on top of the five checks. Walk each question:

• Do real people in or implied by the image consent to this use?
• Do you have permission to use the source assets and any referenced branding, and does the planned style align with organizational policy?
• Does the edit alter meaning or imply something false — for analytics work, does any depicted chart or number read as real company data?
• Can you trace what's generated vs. edited vs. original?
• Who signs off before publishing?
• Does the use require an "AI-generated" or "AI-edited" label?

The move when a risk surfaces is not always to scrap the asset: sometimes you revise the prompt, sometimes you change the caption or placement, sometimes you add a disclosure line, sometimes you swap in approved photography. The judgment call is yours, but it has to be a call, not a default.

The throughline of this unit: edits and AI images need a stated intent (the brief) and a stated standard (a Visual Preflight up front, the five Pre-ship Evaluation checks, and — when real people are involved — the Responsible Visual Use Review), or you'll publish something nobody actually approved — and on a public blog or recruiting post, "published" reads as a claim about your work and your people. Before this becomes real, you'll get on a call with a brand lead who wants to ship an AI image tomorrow and isn't sure the risk is worth a delay. Your job is to name the specific concerns, propose options, and land on a defensible call together: revise the prompt, change the usage plan, or kill the asset. Bring specifics — vague risk talk loses to a publish deadline every time.