Destilación de LLMs: el cazador cazado y la doble moral que nadie quiere nombrar

La receta sin acceso a la cocina

Imagina que quieres replicar el menú estrella de un restaurante con tres Michelines. No tienes acceso a la cocina, no conoces al chef y desde luego nadie te va a dar el recetario. Pero puedes sentarte a la mesa cien mil veces, pedir todos los platos en todas las combinaciones posibles y, con suficiente paciencia y un bloc de notas, acabar reconstruyendo los sabores con una precisión bastante aceptable.

Eso es la destilación de LLMs. Sin metáforas corporativas: lanzas millones de consultas a un modelo ajeno (GPT-4o, Claude, Gemini, lo que sea), recopilas todos los pares entrada-salida y usas ese volumen de datos para entrenar tu propio modelo. No necesitas el código fuente. No necesitas los pesos. No necesitas hackear nada. Solo necesitas una API, presupuesto para tokens y tiempo.

El resultado es un modelo que se comporta de forma estadísticamente similar al original, pero que te ha costado una fracción del desarrollo. Los equipos que llevan años refinando arquitecturas, pipelines de datos y técnicas de alineamiento han construido, sin saberlo, el dataset de entrenamiento de su competidor.

Esto no es teoría de laboratorio ni paranoia de investigadores. HiddenLayer, empresa especializada en ciberseguridad para aplicaciones de IA (modelos predictivos, generativos y agentivos), documenta estas prácticas bajo el nombre técnico de model stealing attacks y las cataloga como una amenaza real y presente para cualquier organización que haya invertido en desarrollar un modelo propio.

La conclusión de HiddenLayer es directa: si alguien puede replicar el comportamiento de tu modelo con queries suficientes, tu ventaja competitiva tiene una fecha de caducidad que no controlas.

Cómo funciona el ataque de verdad

El mecanismo técnico es menos sofisticado de lo que parece desde fuera, y eso es precisamente lo que lo hace peligroso.

El modelo víctima vive detrás de una API. No expone sus pesos, no revela su arquitectura, no deja ver nada del proceso de entrenamiento. Desde fuera solo ves una caja negra que acepta texto y devuelve texto. Eso parece suficiente protección. No lo es.

Lo que sí puedes ver es el comportamiento. Cada respuesta que devuelve el modelo es una ventana a cómo razona, qué patrones sigue, cómo pondera las instrucciones del sistema frente a las del usuario, cómo gestiona la ambigüedad. Con suficientes ejemplos de ese comportamiento, puedes entrenar otro modelo para aproximarlo.

El proceso tiene tres fases:

1. Generación de consultas: diseñas un conjunto de prompts que cubra el dominio que te interesa. Si quieres replicar las capacidades de programación, generas miles de variaciones de problemas de código. Si te interesa el razonamiento lógico, construyes baterías de puzzles y preguntas de múltiple paso.

2. Recopilación de respuestas: lanzas esas consultas contra la API del modelo objetivo y almacenas cada par entrada-salida. A escala. Millones de ejemplos si el objetivo lo merece.

3. Entrenamiento del modelo destilado: usas esos pares como dataset de fine-tuning o entrenamiento completo de un modelo más pequeño. El modelo aprendiz no aprende del mundo; aprende del comportamiento del modelo maestro.

Lo que emerge no es una copia exacta. Hay pérdida de precisión en los bordes, en las tareas más exigentes, en los casos extremos. Pero para la mayoría de los casos de uso prácticos, el delta de rendimiento no justifica la diferencia de coste de desarrollo. Y ahí está el problema para quien invirtió años en el original.

Lo que no sabemos (y conviene decirlo claro) es cuánto cuesta exactamente ejecutar un ataque de este tipo a escala suficiente para que el resultado sea competitivo. No hay cifras públicas verificadas. Cualquiera que te suelte un número concreto sobre el impacto económico total de estos ataques te está vendiendo humo: HiddenLayer documenta la amenaza, pero no existe un cómputo global auditado de pérdidas.

El problema ético: por qué no lo hago

Tengo que ser directo aquí porque es la parte que más me importa del asunto.

No uso esta técnica. No voy a usarla. Y no es por miedo a las consecuencias legales (que existen y son difusas, porque el marco jurídico que regula específicamente la destilación de modelos no está resuelto en ninguna jurisdicción relevante). Es porque me parece éticamente indefendible.

Detrás de cada modelo grande hay equipos de ingenieros, investigadores y especialistas en datos que han invertido años de trabajo. Gente que ha resuelto problemas de arquitectura que no estaban en ningún paper. Que ha construido pipelines de datos que se han caído veinte veces antes de funcionar. Que ha iterado sobre técnicas de alineamiento durante meses para que el modelo no se comporte como un psicópata. Extraer ese trabajo a base de consultas masivas y llamarlo "investigación" o "competencia legítima" me parece una racionalización cómoda.

Hay un coste humano real detrás. Y eso no desaparece porque la API sea técnicamente pública.

Dicho esto, tampoco voy a ponerme a llorar con las big tech cuando lloran por esto. Porque aquí es donde el debate se pone interesante de verdad.

La doble moral que nadie quiere nombrar

OpenAI, Google y Meta (los mismos actores que hoy blindan sus modelos y hablan de propiedad intelectual con cara de funeral) llevan años entrenando sus modelos con datos de internet, libros digitalizados, código de repositorios públicos y, en muchos casos, datos generados por los propios usuarios de sus plataformas. Sin pedir permiso explícito. Sin compensar a los creadores originales.

No es un rumor. Es el motivo por el que estas tres empresas acumulan demandas judiciales en varios países. Escritores, artistas, programadores y medios de comunicación llevan meses o años en los tribunales intentando que alguien responda por el uso de su trabajo como combustible de entrenamiento.

Aún no hay condenas firmes que yo pueda citarte (los procesos siguen abiertos), pero las demandas están ahí y la práctica está documentada.

Ahora metamos eso en contexto con la destilación.

La diferencia estructural entre "datos de internet sin permiso para entrenar un modelo" y "las respuestas de una API para entrenar un modelo" es más fina de lo que el marketing corporativo quiere que parezca. En ambos casos estás extrayendo valor de un trabajo ajeno para construir el tuyo. En ambos casos el propietario original no ha dado un consentimiento explícito. En ambos casos hay un coste económico y humano real para quien puso el trabajo.

La diferencia es quién lo hace y desde qué posición de poder lo hace.

Cuando una big tech raspa libros de Project Gutenberg más los tuyos de Goodreads más el código de tu repositorio de GitHub, lo llama "uso de datos públicamente disponibles". Cuando alguien hace queries masivas a su API para replicar su comportamiento, lo llaman "model stealing attack" y llaman a los abogados.

La indignación moral tiene mucho mejor aspecto cuando no llevas años en el otro lado de la misma ecuación.

Esto no es un argumento a favor de la destilación. Es un argumento contra la hipocresía selectiva. Puedes pensar que ambas prácticas están mal (posición coherente y respetable). Lo que no puedes hacer con credibilidad es defender que una es innovación y la otra es robo, cuando la única diferencia relevante es el tamaño de tu balance.

Las defensas existen, pero nadie las detalla bien

Si eres una empresa que ha desarrollado un modelo y te preocupa esto, hay medidas. El problema es que la literatura pública sobre técnicas de defensa contra model stealing attacks es escasa y fragmentada.

Lo que se sabe a nivel general: los proveedores pueden implementar detección de patrones de consulta anómalos (alguien que lanza millones de queries con distribuciones estadísticamente extrañas levanta banderas), pueden añadir ruido calibrado a las respuestas para degradar la calidad del dataset de destilación sin afectar la experiencia del usuario normal, y pueden limitar el rate de acceso por token o por cuenta.

Ninguna de estas medidas es perfecta. Un atacante con recursos y paciencia puede distribuir las consultas a través de múltiples cuentas, espaciarlas en el tiempo y filtrar el ruido si tiene suficientes ejemplos. El juego del gato y el ratón está abierto y no tiene solución técnica definitiva a la vista.

Lo que sí existe es el argumento legal: los términos de servicio de la mayoría de los grandes proveedores prohíben explícitamente sus APIs para entrenar modelos competidores. Eso convierte la destilación en una violación contractual, independientemente de su estatus legal más amplio. Pero perseguir esas violaciones requiere detectarlas primero, y la detección tiene sus propios límites.

El marco legal específico (más allá de los términos de servicio) sigue sin estar resuelto. No hay jurisprudencia clara en ninguna jurisdicción relevante que defina exactamente qué constituye "robo de modelo" ni qué consecuencias tiene. Quien te diga lo contrario está especulando.

Qué cambia esto para quien trabaja con IA a día de hoy

Si construyes productos sobre APIs de terceros, la destilación es un riesgo que tienes que entender aunque no seas tú quien la ejecute. Si un competidor puede replicar las capacidades que ofreces a una fracción del coste, tu moat técnico es más frágil de lo que piensas. Esto aplica especialmente a startups que han construido su diferenciación entera sobre el comportamiento de un modelo que no controlan.

Si desarrollas modelos propios y te preocupa que alguien te destile, la respuesta honesta es que no tienes una defensa técnica perfecta. Puedes poner capas de fricción, pero un adversario con recursos y motivación tiene las herramientas para sortearlas.

Y si eres usuario de cualquiera de estas plataformas, el debate sobre quién tiene derecho a el trabajo de quién te afecta directamente. Tus conversaciones con ChatGPT, tus interacciones con Gemini, el código que has pegado en Copilot: hay una pregunta abierta sobre qué pasa con esos datos y si están siendo usados para entrenar los modelos de mañana. Las políticas de privacidad dicen cosas. Lo que ocurre en la práctica es más difuso.

Para entender mejor los riesgos de seguridad más amplios que rodean a los sistemas de IA (más allá de la destilación), el artículo sobre seguridad en IA generativa para empresas cubre el panorama completo con más detalle técnico.

La pregunta que se queda sin respuesta cómoda

El debate real sobre la destilación de LLMs no es técnico. Es político, en el sentido más literal: quién tiene derecho a qué, bajo qué condiciones y con qué consecuencias.

Y ese debate no puede resolverse con los argumentos actuales de las big tech porque sus argumentos tienen un problema de credibilidad estructural. No puedes construir tu posición de liderazgo usando el trabajo de otros sin su consentimiento y luego reclamar la protección máxima de la propiedad intelectual cuando alguien aplica una lógica similar contigo.

O las reglas se aplican igual para todos (lo que implicaría revisar seriamente las prácticas de entrenamiento que han construido toda la industria) o reconocemos abiertamente que estamos aplicando estándares distintos según el tamaño del actor. Lo segundo es más honesto. También es más incómodo de defender en público.

Yo no uso la destilación. Creo que hay un coste humano real en extraer años de trabajo ajeno a base de consultas, y eso me importa más que la legalidad ambigua del asunto. Pero esa posición personal no me hace cómplice de la narrativa de las víctimas corporativas que llevan una década construyendo sus modelos con datos que tampoco eran suyos.

La pregunta no es si la destilación está bien o mal. Es si somos capaces de aplicar el mismo criterio cuando el que extrae valor eres tú y cuando eres el extraído. Esa pregunta no tiene respuesta cómoda. Si trabajas con IA, es mejor que te la hagas tú antes de que las circunstancias te obliguen a responderla en público.