Reverse engineering SynthID: ¿qué pasa con el watermark de Gemini cuando el modelo corre en tu browser?

Hace un mes metí Gemma corriendo en el browser usando WebGPU. Esta semana aparece un paper haciendo ingeniería inversa a SynthID — el sistema de Google para detectar si un texto lo generó Gemini. La comunidad reaccionó con el entusiasmo de siempre: "watermarks rotos, IA indetectable, el futuro es libre". Yo también lo leí. Y mi reacción fue bastante más tranquila, porque me quedé pensando en algo que nadie en el hilo de Twitter estaba discutiendo: ¿qué pasa con SynthID cuando el modelo corre localmente? ¿El watermark sobrevive al edge?

Fui a probarlo. Lo que encontré es más interesante —y más incómodo— de lo que esperaba.

SynthID watermark detección IA: cómo funciona el sistema que están rompiendo

SynthID Text no funciona como un sello invisible que se agrega al final del texto. Funciona modificando las probabilidades de sampling durante la generación. A grandes rasgos:

1. Google define un scoring function criptográfico vinculado a cada token
2. Durante el sampling, el modelo favorece tokens que maximizan ese score
3. El detector, después, analiza la distribución estadística del texto y calcula si hay una señal no-aleatoria que indica watermarking

El paper que está circulando ("Watermark Stealing in Large Language Models") demuestra que con suficientes queries a la API, podés reconstruir la scoring function y eventualmente generar texto que pasa el detector sin haber pasado por el modelo watermarkeado, o eliminar el watermark del texto generado.

Eso es serio. Pero es un ataque contra la API de Google. Y ahí es donde mi pregunta se vuelve relevante.

# Esquema simplificado de cómo SynthID modifica el sampling
# Fuente: paper de DeepMind (2023)

import numpy as np

def synthid_sampling(logits, scoring_key, temperatura=1.0):
    """
    En lugar de samplear directo de la distribución,
    SynthID aplica un score criptográfico a cada token
    para sesgar la elección hacia tokens 'marcados'
    """
    # Distribución base del modelo
    probs = np.softmax(logits / temperatura)
    
    # Score pseudo-aleatorio por token (determinístico dado el contexto)
    # Este es el secreto que el paper dice poder reconstruir
    scores = compute_tournament_scores(scoring_key, context_hash)
    
    # El sampling se sesga hacia tokens con score alto
    # El sesgo es pequeño — por eso el texto sigue siendo coherente
    adjusted_probs = probs * (1 + sesgo * scores)
    adjusted_probs /= adjusted_probs.sum()
    
    return np.random.choice(len(logits), p=adjusted_probs)

El attack funciona porque podés hacer miles de queries a la API y reconstruir estadísticamente esa scoring_key. El paper dice que con ~500 queries ya tenés suficiente señal.

Gemma en el browser: dónde entra el edge en esta historia

El mes pasado corrí Gemma 2B en Chrome usando WebGPU y la API de transformers.js. Si no lo viste, el post anterior tiene el setup completo. Lo relevante acá: cuando Gemma corre en tu browser, no hay API de Google en el medio. Los pesos del modelo están en tu máquina. El sampling lo hace tu GPU.

Entonces la pregunta que me hice es: ¿los pesos de Gemma que descargás de HuggingFace tienen SynthID implementado?

Fui a ver el código fuente de Gemma en transformers y en la implementación de referencia de Google:

// Así se inicializa Gemma en transformers.js (versión simplificada)
import { pipeline } from '@xenova/transformers';

// El modelo se descarga de HuggingFace — pesos puros
// No hay endpoint de Google en ningún lado
const generador = await pipeline(
  'text-generation', 
  'Xenova/gemma-2b-it',
  { 
    device: 'webgpu',  // corre 100% local
    // No hay parámetro de watermarking acá
  }
);

const resultado = await generador('Explicame qué es Docker en dos párrafos', {
  max_new_tokens: 200,
  temperature: 0.7,
  do_sample: true,
  // Ningún callback de SynthID
});

Respuesta corta: no. Los pesos open-weight de Gemma no tienen SynthID. El watermarking de Google vive en la capa de servicio — en los servidores que manejan la API de Gemini. Cuando corrés el modelo vos, ese código no existe.

Esto tiene implicancias que van más allá del debate sobre watermarks.

Lo que el reverse engineering no puede romper (y lo que sí)

Aquí es donde quiero frenar el hype en seco. Hay dos cosas distintas mezcladas en la conversación:

Cosa 1: El watermark en texto generado por la API de Gemini Este sí es vulnerable al ataque del paper. Con suficientes queries, podés estadísticamente reconstruir la clave y evadir detección. Es un ataque real contra Google-the-service.

Cosa 2: Detectar si un texto lo generó cualquier modelo de lenguaje Acá SynthID no ayuda para nada si el modelo corre localmente. Y el ataque del paper tampoco es relevante — no hay watermark que evadir.

Este segundo caso es el que me parece que nadie está pensando bien. Cuando corrí Gemma en el browser para el experimento anterior, generé texto que:

• No pasó por ningún servidor de Google
• No tiene SynthID
• Es estadísticamente indistinguible del texto generado por la API
• No deja ningún rastro en ningún log

Si te preocupa la detección de contenido generado por IA en contextos donde importa (exámenes, periodismo, legal), el edge computing lo hace irrelevante mucho más rápido que cualquier ataque de ingeniería inversa. Esto conecta directamente con algo que escribí sobre los costos ocultos de depender de APIs de IA — el día que el modelo está en tu máquina, todas las políticas de uso de la API son papel mojado.

Lo que encontré probándolo en vivo

Para cerrar el loop, quise ver qué pasa cuando pasás texto generado por Gemma local por el detector público de SynthID. Google tiene un demo en Vertex AI.

Generé 50 textos con Gemma 2B corriendo local, 50 con la API de Gemini 1.5 Flash, y los pasé todos por el detector:

El detector es honesto: no reclama detectar "AI-generated" en general. Solo detecta su propio watermark. Eso es más integridad intelectual de la que esperaba.

Pero también significa que como herramienta de detección de contenido IA en general, SynthID es inútil contra modelos edge. El paper de reverse engineering es interesante académicamente. En la práctica, si alguien quiere evadir SynthID, lo más simple es usar Ollama con Llama o Gemma local — ni siquiera necesita el ataque sofisticado.

Esto no es diferente a lo que vi cuando analicé el historial de git del kernel de Linux: los sistemas complejos tienen bypass absurdamente simples si sabés dónde mirar.

Gotchas y cosas que me confundieron en el camino

Confundí SynthID Text con SynthID Image/Audio Google tiene SynthID para varios tipos de contenido. El de imagen funciona diferente — modifica píxeles imperceptibles en el espacio de frecuencias. Ese sí viaja con el archivo. El de texto NO viaja con el texto, porque el texto no tiene espacio de frecuencias. Es una distinción que el 80% de los artículos que leí no hacía.

El paper no "rompe" SynthID para usuarios normales Requiere acceso a la API con suficiente volumen como para hacer ~500 queries de calibración. No es algo que alguien haga accidentalmente. Es un ataque que requiere intención y recursos.

WebGPU tiene límites de memoria que cambian el sampling Cuando corrí Gemma en el browser, los textos largos (~1000 tokens) a veces mostraban degeneración porque la gestión de KV-cache en WebGPU es diferente. Los textos que usé en mi experimento fueron todos de ~300 tokens para evitar este problema. Detalle importante si querés reproducir el setup.

SynthID no es el único sistema en juego Microsoft, Meta y OpenAI tienen o están desarrollando sistemas similares. El C2PA (Content Credentials) de Adobe va por un ángulo diferente — metadata criptográfica en el archivo. Ninguno de estos resuelve el problema del edge de manera satisfactoria. Lo que está pasando con MegaTrain entrenando LLMs grandes en hardware accesible solo va a acelerar el problema: más modelos capaces corriendo en hardware personal, sin pasar por ninguna API.

Y si te preguntás qué datos está enviando tu modelo local y a dónde — tema que toqué cuando hablé de monitoreo de tráfico outbound en Linux — la respuesta con modelos corriendo vía transformers.js o Ollama es: básicamente nada, y eso es exactamente el problema de detección.

FAQ: SynthID, watermarks y modelos edge

¿SynthID puede detectar si un texto lo generó ChatGPT o Claude? No. SynthID solo detecta su propio watermark — el que Google inserta cuando generás texto con la API de Gemini. No es un detector genérico de contenido IA. Para eso existen clasificadores entrenados (como GPTZero o el detector de OpenAI), que tienen sus propios problemas de precisión.

¿El watermark de SynthID afecta la calidad del texto generado? Mínimamente. El sesgo introducido en el sampling es pequeño por diseño — si fuera grande, el texto se volvería incoherente. En mis pruebas, textos watermarkeados y no watermarkeados eran indistinguibles en calidad. El precio es que el watermark es estadístico, no determinístico: textos muy cortos a veces no tienen señal suficiente para ser detectados.

¿Si descargo los pesos de Gemma y los corro localmente, mi texto va a tener watermark? No. Los pesos de Gemma open-weight en HuggingFace no incluyen la lógica de SynthID. El watermarking está implementado en la capa de servicio de Google, no en los pesos del modelo. Corriendo Gemma local con transformers.js, Ollama, o cualquier otro runtime, generás texto sin watermark.

¿El paper de reverse engineering hace que SynthID sea inútil? Depende de qué uso le des. Como sistema de detección forense para un proveedor que quiere rastrear el origen de texto generado por su propia API, SynthID sigue siendo útil contra usuarios no sofisticados. Como barrera contra actores motivados con acceso a APIs o modelos locales, ya era débil antes del paper. El paper lo demuestra formalmente, no lo inventa.

¿Existe algún sistema de watermarking que sobreviva al edge computing? Esto es un problema abierto. Los watermarks en modelos de imagen tienen alguna esperanza porque el artefacto viaja con el archivo. Para texto, el watermark es una propiedad estadística de la distribución de tokens — y si el adversario controla el modelo completo, puede resamplear sin restricciones. No veo una solución técnica limpia en el horizonte cercano. Algunos researchers proponen watermarks basados en hardware (TPM, secure enclaves), pero requieren que el hardware coopere — lo cual asume un nivel de control de la cadena de suministro que no existe para modelos open-weight.

¿Esto tiene alguna implicancia legal o de compliance? Es una pregunta que varios reguladores están empezando a hacerse. La EU AI Act menciona watermarking de contenido sintético como requisito para ciertos usos de alto riesgo. Pero si el modelo corre en hardware del usuario y no pasa por ningún servidor del proveedor, ¿quién es responsable de implementar el watermark? El marco legal todavía no tiene respuesta para esto. Es el mismo problema de auditoría que toqué cuando hablé de lo que la IA no te dice cuando genera tu código: cuando el proceso es local y opaco, la cadena de responsabilidad se corta.

Qué me llevo de todo esto

El reverse engineering de SynthID es un paper interesante. Pero el ángulo que más me importa como alguien que está corriendo modelos en el browser y explorando el edge es este: el watermarking como sistema de accountability tiene un problema estructural que no es técnico, es arquitectónico.

Los watermarks funcionan cuando hay un servidor que controla la generación. El momento en que los modelos se descentralizan — y ya están — la pregunta de "¿generó esto una IA?" se vuelve un problema de confianza, no de detección técnica. No muy diferente de cómo no podés saber si alguien usó un procesador de texto para escribir una carta.

Lo que sí me queda claro después de medir esto: si estás diseñando un sistema donde la detección de contenido IA importa, no construyas sobre SynthID como única capa. Y si estás pensando que el reverse engineering es el único vector de ataque, te estás olvidando del más obvio: simplemente correr el modelo vos mismo.

Si querés reproducir el experimento con Gemma en el browser, mandame un mensaje — tengo el setup documentado y lo comparto con gusto.