Google Shipped an Earth Deepfake Tool. It Lasted 24 Hours.

Google put an AI image generator inside Google Earth on a Thursday. By Friday it was gone. One day. The tool let anyone edit satellite images with a text prompt, and it took one researcher a few tries to turn a trusted map into a weapon. Let me catch you up on what went wrong and what it tells you about shipping AI on your own team.

The demo that sold it

The pitch was warm and easy to nod at. Type a prompt, and Google Earth's satellite and 3D imagery becomes something new. Rebuild Pompeii in 78 AD for a class. Turn an empty Tokyo lot into a shopping district. Sketch a lakeside dream home before you build it.

Google offered five suggested use cases, all friendly, all creative. The model, Nano Banana 2, was billed as a real step up in quality and accuracy. On paper it read like a fun feature bolted onto a familiar app. That was the whole problem.

The base you were building on

Google Earth is not a toy. Journalists and researchers treat it as visual evidence. Google's own rollback statement admitted people "uniquely trust Google Earth for a reliable view of the world." So when you add a prompt box that warps that view, you are not adding a feature. You are spending trust you did not build.

That trust is exactly what makes the fakes dangerous. A BBC journalist posted, sarcastically, that there was no way one of the most reliable sources of visual evidence could be abused to spread misinformation. He was making the point Google's launch team should have made first. The stronger your platform's reputation, the more a fake riding on it can do.

What one tester proved in a day

Henk van Ess of Digital Digging did not need a lab. He generated images of refugees near the Mexican border and a bomb crater by a hospital in Gaza. Real places, fake events, believable enough to spread.

Google's first defense was the SynthID watermark and blocks on harmful topics. Both leaked. Van Ess fooled Hive's AI detector with a video made in the tool. And on the guardrails, he was blunt: "Nothing was refused, nothing was softened, and nothing suggested I try a different prompt." The safety story existed in the blog post, not in the product.

When the feature barely worked anyway

Here is the part that should sting. The tool was not even good. ZDNet got early access and found the Bring History to Life case was not historically accurate. It rendered the wrong buildings around Independence Hall. Infographics came out with garbled AI text and rearranged the actual layout of places.

So Google took on real reputational risk to ship a feature that missed its own suggested use cases. The upside was thin. The downside was a front-page misinformation story. That trade should have been visible before launch, not after.

The deep cut

The fastest misuse test was not a red team. It was one reporter with a laptop and an afternoon. If a curious outsider can break your AI feature in a day, your own team can break it in an hour, and you should make them, before ship. Put a named person on adversarial prompting for any feature that touches trusted data, images, maps, identity, money. Give them a real block list, not a blog paragraph. And TechCrunch's point stands: anyone can now make semi-credible fakes without Photoshop skill. So the gate is not whether the model is capable. It is whether your platform's trust can survive being the source of the fake.

Three questions for your team

1. Before we ship any AI feature, who on this team is paid to break it, and what did they actually try? If the answer is nobody, we are not ready.
2. What trust are we spending when we add generation to this product, and does the feature's payoff cover that bill?
3. Do our safety claims live in the product or only in the launch post? Watermarks and topic blocks we cannot demo under a hostile prompt do not count.