Riesgos y limitaciones

Model extraction (robo de modelo)

Model extraction es un ataque en el que alguien con acceso solo a las respuestas de un modelo (vía API o UI) intenta entrenar un modelo propio que replique sus capacidades, sin pagar por el entrenamiento original. La técnica está bien documentada y motiva muchas restricciones de uso de los proveedores comerciales.

Por Ana María González Actualizado: 9 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

Si tienes acceso a la salida de un modelo, puedes generar grandes volúmenes de pares pregunta-respuesta y usarlos para entrenar tu propio modelo más pequeño que aprende a imitar al original. Esto es básicamente destilación, pero hecha sin permiso del proveedor del modelo "profesor". Para modelos cerrados con APIs comerciales, los términos de servicio prohíben explícitamente esta práctica, pero sigue ocurriendo. La defensa por parte del proveedor es difícil: detección por patrones de uso (volúmenes muy altos de consultas similares), watermarking de las salidas (ciertos patrones invisibles que se transfieren al modelo robado), restricciones de tasa, monitorización de cuentas. La fama del modelo DeepSeek-V3, lanzado en diciembre de 2024 con calidad cercana a GPT-4 a coste 10-50x menor, generó un debate intenso sobre si parte de su entrenamiento incluía outputs de modelos cerrados —sin pruebas concluyentes públicas, pero con sospechas de OpenAI y otros proveedores. La realidad es que la línea entre "destilación legítima de modelos abiertos" y "extracción no consentida" depende del licenciamiento del modelo profesor.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa la palabra importa por dos lados. Como usuaria de un modelo cerrado, los términos de servicio prohíben extraer; violarlos puede costar la cuenta, una demanda y reputación. Como propietaria de un modelo propio (fine-tuned, entrenado), debe saber que no puede impedir totalmente la extracción si lo expone vía API: puede dificultarla pero no impedirla, así que el modelo no debería contener datos confidenciales que su exfiltración vía outputs sería un problema. Para modelos sensibles, conviene desplegar capas de seguridad: rate limiting agresivo, monitorización de patrones, advertencias contractuales claras.

Ejemplo concreto

Caso real

Una startup que ofrecía un servicio de clasificación legal con un modelo fine-tuned propio observó tráfico anómalo: una IP recibía 80.000 consultas al mes con prompts repetitivos y diversos, manifiestamente automatizado. Investigaron: era un competidor lanzando millones de pares pregunta-respuesta para entrenar su clon. La startup endureció el rate limit por cuenta a 1.000 consultas/día por defecto, añadió detección de patrones (consultas casi idénticas con pequeñas variaciones) y watermarking sutil en respuestas. Aun así, la cuenta atacante había recogido material para un fine-tuning útil; la lección fue que el modelo no debía contener tanta diferenciación competitiva en el modelo en sí, sino en el sistema y los datos que lo alimentan.