Prompt & Product
EN ES
Trust & Safety

Audit AI features that can fake your product before launch

If a feature can generate content that looks like your product's own output, treat it as a trust surface and audit provenance, refusal, and verification before launch.

ByPrompt & Product — Newsroom
Filed10 September 2026
Read3 MIN
Illustration: Audit AI features that can fake your product before launch

Credibility is inherited by the output

Before you ship a generative feature, decide whether its output can be mistaken for the product's own record. Bryan Horowitz, Google Earth's product manager, announced on July 30, 2026 that Google Earth users could create custom images by combining the platform's satellite, aerial, and 3D imagery with Nano Banana. Google removed the Google Earth AI image-generation feature on Friday, July 31, 2026, more than 24 hours after launching it. The feature did not need a fake logo to feel plausible; it inherited the map's authority.

Independent investigator Henk van Ess said on July 30, 2026 that he used Google Earth's AI to create images showing refugees near the Mexican border, a nuclear plant in Iran, and a fatal crash on an Amsterdam street. Run the three-question credibility-inheritance test before you build the demo:

  • Can the feature generate content that looks like the product's own output?
  • Can a user circulate it without a visible AI label?
  • Can the product's own tools verify it in the user's hands?

If any answer is yes, the output is a trust surface. Name it in the design file where you mark payments, privacy, or safety, and review the provenance state before the button color. The finished state is a one-page note that names the output, the circulation path, and the verification path.

The label must survive the user's path

In a July 30, 2026 X post, Google stated that Nano Banana images made in Google Earth carried SynthID watermarks and that people could use the Gemini app or Lens in Search to check for AI generation. A watermark alone does not replace a user interface. The trust surface breaks when the AI state disappears after export, screenshot, or a camera shot.

Map the export path before choosing the label. Start at the generated image and follow it through copy, download, share, screenshot, print, and re-upload. The diagram should show where the AI state survives and where it dies. Teams often design the label for the happy path, then let the user's real path erase it.

Put the AI state on the image itself, in the share sheet, and in metadata that survives the first handoff. A product that cannot show the label after a screenshot has a gap, not a platform limitation. A user should be able to share the output and still see the AI state without opening a settings page.

Verification has to work in the user's hands

In Ars Technica's test, Google's SynthID could not verify an AI-altered image made with the Google Earth feature after the image was photographed with a smartphone camera. In a test by Tal Hagin of Golden Owl, Google's Gemini chatbot could not determine the origin of Henk van Ess's faked Gaza hospital image when asked to look for SynthID. CNA reported that it could capture screenshots of fabricated Google Earth AI images and start posting them to Facebook, Instagram, and TikTok without any prompt to label them as AI-made. Those failures are the paths a user will actually take.

Build a verification loop a user can complete without specialist tools. Provide a check inside the product, a clear result, and a fallback when the result is uncertain. A user can take a suspicious image, run the check, and see one of three states: verified, unverified, or unknown. The product should say what each state means.

Design the refusal path before an abuse report arrives. A feature that can place people, disasters, or infrastructure into a false scene needs a hard stop for high-risk prompts. The artifact is a documented list of refused categories, a user-facing explanation, and a log that the team can review.

No launch is a design decision

Decide the launch gate before the launch date. Require user-visible provenance, hard refusal, or no launch whenever the output can be read as the product's own record. Do not let the team ship a watermark and call the risk closed. A pre-launch credibility-inheritance audit should be short enough to run in a sprint. The ticket should name the test, the screenshot, the verification result, and the owner who accepted the risk.

Advertisement