Audita las funciones de IA que pueden falsificar tu producto antes del lanzamiento

La credibilidad se hereda en la salida

Antes de lanzar una función generativa, decide si su salida puede confundirse con el registro propio del producto. Bryan Horowitz, gerente de producto de Google Earth, anunció el 30 de julio de 2026 que los usuarios de Google Earth podrían crear imágenes personalizadas combinando la imagen satelital, aérea y 3D de la plataforma con Nano Banana. Google eliminó la función de generación de imágenes con IA de Google Earth el viernes 31 de julio de 2026, más de 24 horas después de su lanzamiento. La función no necesitaba un logotipo falso para parecer verosímil; heredaba la autoridad del mapa.

El investigador independiente Henk van Ess declaró el 30 de julio de 2026 que utilizó la IA de Google Earth para crear imágenes que mostraban refugiados cerca de la frontera mexicana, una planta nuclear en Irán y un accidente mortal en una calle de Ámsterdam. Aplica la prueba de herencia de credibilidad de tres preguntas antes de construir la demo:

• ¿Puede la función generar contenido que se parezca a la salida propia del producto?
• ¿Puede un usuario difundirlo sin una etiqueta de IA visible?
• ¿Pueden las propias herramientas del producto verificarlo en manos del usuario?

Si alguna respuesta es afirmativa, la salida es una superficie de confianza. Nómbrala en el archivo de diseño donde marcas pagos, privacidad o seguridad, y revisa el estado de procedencia antes que el color del botón. El estado final es una nota de una página que nombra la salida, la ruta de circulación y la ruta de verificación.

La etiqueta debe sobrevivir a la ruta del usuario

En una publicación en X del 30 de julio de 2026, Google declaró que las imágenes de Nano Banana creadas en Google Earth llevaban marcas de agua SynthID y que las personas podían usar la app de Gemini o Lens en Búsqueda para verificar la generación con IA. Una marca de agua por sí sola no sustituye una interfaz de usuario. La superficie de confianza se rompe cuando el estado de IA desaparece tras la exportación, una captura de pantalla o una foto con cámara.

Traza la ruta de exportación antes de elegir la etiqueta. Comienza en la imagen generada y síguela a través de copiar, descargar, compartir, captura de pantalla, imprimir y volver a subir. El diagrama debe mostrar dónde sobrevive el estado de IA y dónde muere. Los equipos suelen diseñar la etiqueta para el camino feliz y luego dejan que la ruta real del usuario la borre.

Coloca el estado de IA en la propia imagen, en la hoja de compartir y en metadatos que sobrevivan a la primera transferencia. Un producto que no puede mostrar la etiqueta tras una captura de pantalla tiene una brecha, no una limitación de plataforma. Un usuario debe poder compartir la salida y seguir viendo el estado de IA sin abrir una página de ajustes.

La verificación debe funcionar en manos del usuario

En la prueba de Ars Technica, SynthID de Google no pudo verificar una imagen alterada con IA creada con la función de Google Earth después de que la imagen fuera fotografiada con la cámara de un teléfono inteligente. En una prueba de Tal Hagin, de Golden Owl, el chatbot Gemini de Google no pudo determinar el origen de la imagen falsificada del hospital de Gaza de Henk van Ess cuando se le pidió buscar SynthID. CNA informó que se podían capturar capturas de pantalla de imágenes de IA de Google Earth fabricadas y comenzar a publicarlas en Facebook, Instagram y TikTok sin ningún aviso para etiquetarlas como creadas con IA. Esos fallos son las rutas que un usuario realmente tomará.

Construye un bucle de verificación que un usuario pueda completar sin herramientas especializadas. Proporciona una comprobación dentro del producto, un resultado claro y una alternativa cuando el resultado sea incierto. Un usuario puede tomar una imagen sospechosa, ejecutar la comprobación y ver uno de tres estados: verificado, no verificado o desconocido. El producto debe indicar qué significa cada estado.

Diseña la ruta de negativa antes de que llegue un informe de abuso. Una función que puede colocar personas, desastres o infraestructuras en una escena falsa necesita un bloqueo firme para los prompts de alto riesgo. El entregable es una lista documentada de categorías rechazadas, una explicación orientada al usuario y un registro que el equipo pueda revisar.

No lanzar es una decisión de diseño

Define la puerta de lanzamiento antes de la fecha de lanzamiento. Exige procedencia visible para el usuario, negativa firme o no lanzamiento siempre que la salida pueda leerse como el registro propio del producto. No dejes que el equipo lance una marca de agua y declare el riesgo cerrado. Una auditoría de herencia de credibilidad previa al lanzamiento debe ser lo suficientemente breve como para ejecutarse en un sprint. El ticket debe nombrar la prueba, la captura de pantalla, el resultado de verificación y el responsable que aceptó el riesgo.