El 12 de febrero de 2026, el equipo de inteligencia de amenazas de Google reveló que alguien había interrogado a Gemini más de cien mil veces con un objetivo concreto: reconstruir su lógica de razonamiento para entrenar un modelo competidor.
Lo interesante no es la cifra, sino lo que no hubo. No hubo intrusión. No hubo credenciales robadas, ni malware, ni un servidor comprometido. Nadie cruzó ningún perímetro. La propiedad intelectual empezó a salir por la puerta principal, en forma de preguntas, respondidas educadamente por el propio sistema.
Google atribuyó la campaña principalmente a actores con motivación comercial —empresas de inteligencia artificial y centros de investigación buscando ventaja competitiva— y la calificó de robo de propiedad intelectual. Y esa es la parte que debería llegar al comité de dirección de cualquier empresa que haya puesto una capacidad de IA en producción.
Lo esencial
- La destilación extrae el conocimiento de un modelo consultándolo de forma sistemática, sin necesidad de comprometer ningún sistema.
- No hace falta ser Google: cualquier organización que exponga una capacidad de IA por API o dentro de un producto tiene la misma superficie.
- Lo que se fuga no son los pesos del modelo, sino el criterio que lo hace valioso y, con frecuencia, rastros de los datos con los que se ajustó.
- Los controles perimetrales no lo ven, porque técnicamente no ocurre nada anómalo: son peticiones legítimas de un cliente autenticado.
Qué es la destilación, explicado para quien decide
Un modelo de lenguaje es, en el fondo, criterio codificado. Ha costado dinero, datos y tiempo llegar a que responda como responde. Ese criterio es el activo.
La destilación consiste en aprovechar que el modelo responde. Quien quiere copiarlo le formula muchas preguntas cubriendo de forma metódica el terreno que le interesa, recoge lo que contesta y usa ese material para entrenar un modelo propio, más pequeño y mucho más barato, que se comporta de forma parecida. No se copia el original: se aprende de él hasta aproximarlo.
La analogía que mejor funciona en una sala de dirección es la del empleado que se marcha a la competencia. No se lleva los servidores: se lleva el criterio. La diferencia es que aquí el proceso es automatizable, escala a cien mil consultas y no deja huella de intrusión.
Conviene señalar lo que esto no es. No es un fallo de software que se corrija con un parche, ni una vulnerabilidad con su CVE. Es una consecuencia del comportamiento normal del sistema, y por eso no tiene solución completa: un modelo que deja de responder deja de servir.
Por qué esto no es solo un problema de las grandes tecnológicas
La reacción habitual al leer el caso de Gemini es archivarlo como cosa de gigantes. Es un error de lectura, y merece la pena deshacerlo con tres escenarios que sí aparecen en empresas normales.
Has expuesto una capacidad de IA en tu producto
Un clasificador que decide si una operación es fraudulenta, un asistente que responde a tus clientes con el criterio de tu compañía, un motor que puntúa expedientes. Si un competidor puede consultarlo —contratando el servicio como cliente, sin más— puede aproximar su comportamiento sin haber invertido en construirlo.
Has ajustado un modelo con datos propios
Aquí el riesgo cambia de naturaleza y se agrava. Cuando un modelo se afina con documentación interna, historiales o expedientes, parte de ese material queda reflejado en cómo responde. La investigación académica lleva tiempo documentando que consultas dirigidas pueden hacer aflorar fragmentos de los datos de ajuste. Ya no hablamos de propiedad intelectual: hablamos de datos personales o confidenciales saliendo por un canal que nadie clasificó como salida de datos.
Tu proveedor es el objetivo, no tú
Si tu operación depende de un modelo de un tercero, su exposición es tu exposición. Un proveedor cuyo modelo se destila pierde ventaja competitiva, y con ella la viabilidad del servicio que te presta. Es riesgo de terceros clásico, con un activo nuevo, y encaja en la gestión del riesgo de proveedores que ya deberías estar haciendo.
Por qué los controles habituales no lo detectan
El motivo por el que esto pasa desapercibido es que no se parece a un ataque. No hay inicio de sesión fallido, ni escalada de privilegios, ni tráfico hacia un destino sospechoso, ni fichero que un antivirus pueda marcar. Hay un cliente autenticado, con su contrato en regla, haciendo exactamente aquello para lo que se le dio acceso.
El cortafuegos no tiene nada que objetar. El EDR tampoco. Y la prevención de fuga de datos vigila los ficheros que salen, no el criterio que se infiere de miles de respuestas correctas.
Es el mismo punto ciego que describimos al hablar del LLMjacking, donde el abuso también se disfraza de uso legítimo, y el que hace que la IA en la sombra sea tan difícil de acotar.
Qué mirar: señales que sí distinguen
Aunque cada petición sea legítima, el conjunto no lo es. Los patrones que separan a un cliente de un extractor están en el agregado, no en la consulta individual:
- Volumen desproporcionado respecto al caso de uso contratado. Un cliente que consulta mil veces más de lo que su negocio justifica está haciendo otra cosa.
- Cobertura sistemática en lugar de uso real. El uso legítimo se concentra en unos pocos patrones; la extracción barre el espacio de entradas de forma metódica, incluidos casos que a nadie le interesan en producción.
- Consultas construidas para revelar el proceso, no el resultado. Peticiones que insisten en obtener el razonamiento paso a paso, la justificación o el grado de confianza, en vez de la respuesta que el producto ofrece.
- Regularidad de máquina. Cadencia constante, sin los picos y valles del horario laboral, sostenida durante días.
- Concentración temporal desde una misma cuenta o rango. Especialmente si la cuenta es reciente o de un plan de entrada.
Ninguna de estas señales es concluyente por separado. Combinadas, y con una línea base de lo que es normal para cada cliente, permiten levantar la mano a tiempo. Es trabajo de detección continua, no de una regla estática.
Defensa: qué se puede hacer de verdad
No existe una medida que lo impida del todo, y quien la venda como tal está exagerando. Lo que sí existe es un conjunto de decisiones que encarecen mucho la operación y la hacen detectable antes.
- Devolver lo justo. Cuanta más información acompaña a la respuesta —puntuaciones internas, alternativas, razonamiento explícito—, más barato sale copiar el criterio. Si el producto no lo necesita, no debería exponerlo.
- Cuotas y escalones de precio por volumen. El objetivo no es recaudar, es que reunir el material necesario cueste dinero y tiempo.
- Línea base y vigilancia por cliente, no global. El agregado esconde al extractor; el comportamiento comparado con su propio histórico lo delata.
- Condiciones contractuales explícitas. Prohibir el uso de las salidas para entrenar modelos no impide el hecho, pero convierte un problema técnico irresoluble en un incumplimiento perseguible.
- Control de acceso a los artefactos del modelo. Pesos, puntos de control y conjuntos de ajuste son propiedad intelectual concentrada. Merecen el trato de una joya de la corona, con acceso mínimo y trazado.
- Cuidado con lo que se usa para ajustar. Si el conjunto de ajuste contiene datos personales o confidenciales, ese riesgo viaja con el modelo. Es una decisión de diseño, no una configuración.
Estas decisiones son las que revisamos en una auditoría de seguridad de agentes de IA y MCP y las que sostienen un programa de seguridad de la inteligencia artificial que no se quede en la política escrita.
Dónde encaja esto en los marcos que ya usas
No hace falta inventar una categoría nueva. El proyecto GenAI de OWASP recoge el robo de modelos entre los riesgos de aplicaciones con modelos de lenguaje, y en su revisión más reciente lo integró junto al consumo no acotado, precisamente porque el mecanismo de extracción y el de agotamiento de recursos comparten señales. Su recuento de incidentes del primer trimestre de 2026 da una idea de con qué frecuencia aparece esto en el mundo real.
En el plano regulatorio, el Reglamento Europeo de Inteligencia Artificial obliga a gobernar los sistemas de IA con transparencia, gestión de riesgos y supervisión humana. Un modelo del que se puede extraer criterio o datos de ajuste es, en términos de gobierno, un sistema cuyo riesgo no está gestionado. Y si además se ajustó con datos personales, el problema se traslada al terreno de la protección de datos.
La norma ISO/IEC 42001 ofrece el marco para ordenarlo, y lo desarrollamos al hablar de cómo elegir una plataforma de cumplimiento con IA y en el servicio de implantación de ISO/IEC 42001, junto con el cumplimiento del Reglamento de IA.
La conversación que toca tener en el comité
El error de encuadre más caro es tratar esto como un asunto técnico. Si la destilación se presenta como un problema de la API, se resuelve con un límite de peticiones y se olvida.
Planteado correctamente, es una cuestión de propiedad intelectual: cuánto vale el criterio que hemos codificado en ese modelo, qué pasaría si un competidor lo tuviera a una fracción del coste, y qué estamos dispuestos a hacer para que copiarlo salga caro. Esa conversación no la lidera el responsable de seguridad, la lidera quien responde del activo.
Y hay una pregunta previa que casi nadie se ha hecho: ¿sabemos qué capacidades de IA hemos expuesto ya, quién las consume y con qué volumen? En la mayoría de organizaciones que empiezan a mirar, la respuesta incompleta es el primer hallazgo.
Lo que deja el caso
Lo relevante de lo ocurrido con Gemini no es que le pasara a Google, sino que el mecanismo es viejo y conocido: preguntar mucho y aprender de las respuestas. Lo nuevo es que ahora hay activos cuyo valor entero consiste en saber responder.
Mientras la seguridad siga midiendo lo que entra, seguirá sin ver salir lo que más cuesta construir. Y en una empresa que ha invertido en inteligencia artificial, eso ya no es una metáfora: es una línea del balance.