Un modelo expuesto por API es, desde el punto de vista de un atacante, una interfaz de consulta sobre todo lo que ese modelo aprendió. No hace falta vulnerar nada para obtener información: basta con preguntar muchas veces y observar con cuidado las respuestas. Esa es la particularidad de esta familia de ataques y la razón por la que no aparecen en los tableros de seguridad: cada consulta individual es legítima y el conjunto es el problema.
El riesgo no es teórico ni uniforme. Depende mucho de cómo esté construido tu sistema, y en particular de si entrenaste o ajustaste con datos propios, de cuánta información devuelve la interfaz más allá del texto y de qué tan valioso resulta el modelo como activo en sí mismo. Lo que sigue separa cuatro cosas que suelen mezclarse bajo el mismo nombre.
Qué puede reconstruir alguien que solo consulta
Memorización literal
Los modelos de lenguaje retienen fragmentos exactos del material con el que fueron entrenados, sobre todo cuando ese material aparece repetido o es poco frecuente y muy estructurado. Esto importa poco si ajustaste con documentación pública de producto e importa mucho si el conjunto de ajuste contenía direcciones, números de identificación, claves de acceso pegadas en un ticket o cláusulas de contratos. El fenómeno está bien documentado en la literatura técnica, aunque la magnitud varía según el modelo, el tamaño del conjunto y cuántas veces aparece cada dato, y no existe una regla simple que permita predecirlo.
Inferencia de pertenencia
Es más sutil y a menudo más grave en términos regulatorios. En lugar de recuperar el dato, el atacante determina si un registro concreto formó parte del conjunto de entrenamiento, comparando cómo se comporta el modelo ante ese registro frente a datos que sabe que no estaban. El daño no está en el contenido sino en la pertenencia: confirmar que una persona figura en un conjunto de entrenamiento de un modelo de detección de fraude, de scoring crediticio o de diagnóstico revela un hecho sensible sobre esa persona aunque no se recupere ni un campo.
Extracción funcional por destilación
Aquí el objetivo es el modelo como activo. El atacante envía un volumen alto de consultas diseñadas para cubrir el espacio de entradas, registra las respuestas y entrena con ese par pregunta-respuesta un modelo propio que aproxima el comportamiento del original. No obtiene los pesos: obtiene una réplica funcional, que suele ser suficiente para competir con tu producto o para preparar ataques con más comodidad contra el modelo real. La calidad de la réplica mejora cuanto más información devuelve la interfaz: probabilidades, puntajes de confianza o clasificaciones detalladas facilitan mucho la tarea frente a una respuesta escueta.
Inversión de atributos
Una variante menos conocida en la que el atacante no busca un registro completo, sino inferir un atributo sensible a partir del comportamiento del modelo. Es especialmente relevante en modelos ajustados sobre poblaciones pequeñas, donde el sistema aprendió patrones que identifican a grupos reducidos de personas.
En estos ataques no hay intrusión: el atacante usa el sistema exactamente como fue diseñado, solo que muchas más veces y con un objetivo distinto.
Por qué esto no se ve como incidente
Los programas de seguridad están construidos para detectar eventos: un acceso no autorizado, una transferencia anómala, un proceso que no debería estar corriendo. La extracción no produce ninguno de esos eventos. Produce tráfico legítimo, autenticado y facturado, distribuido en el tiempo y a veces repartido entre varias cuentas para no destacar.
Eso tiene una consecuencia incómoda en el plano legal y de cumplimiento. Si un modelo ajustado con datos personales reproduce información de las personas que estaban en el conjunto, hay una divulgación aunque no haya habido brecha en ningún sistema. Y si el modelo se entregó a un tercero o se expuso públicamente, esa divulgación puede haber ocurrido sin ningún registro que permita acotarla. Es una de las razones por las que el tratamiento de datos personales en el ajuste fino merece una decisión formal y documentada, no una elección de implementación.
Cómo limitar la exposición
Los controles se ordenan en dos grupos, y el primero es mucho más efectivo que el segundo.
Reducir lo que hay dentro del modelo
Todo lo que no entró al entrenamiento no se puede extraer, y esta es la única defensa que no depende de detectar al atacante. En concreto: revisar el conjunto de ajuste para eliminar identificadores, credenciales y datos personales que no aportan a la tarea; deduplicar, porque la repetición es el factor que más aumenta la memorización; y, sobre todo, preguntarse si el ajuste fino era necesario. En una parte importante de los casos que revisamos, el objetivo era que el sistema conociera información interna, y para eso la recuperación en tiempo de consulta con control de acceso —descrita en nuestro artículo sobre RAG seguro— resuelve el problema sin incorporar nada al modelo y conservando la posibilidad de revocar el acceso a un documento.
Reducir lo que la interfaz entrega
El segundo grupo encarece el ataque sin eliminarlo. Devuelve la mínima información necesaria: si el caso de uso no requiere probabilidades ni puntajes, no los expongas. Aplica límites de tasa y de volumen por identidad, con autenticación obligatoria, de modo que la extracción masiva tenga un costo y deje rastro atribuible. Monitorea patrones de consulta más que consultas individuales, porque la señal está en la distribución: cobertura inusualmente sistemática del espacio de entradas, series de variaciones mínimas sobre un mismo caso, volumen sostenido sin relación con el uso normal del producto. Y ordena por contrato lo que la técnica no cubre, prohibiendo explícitamente el uso de las salidas para entrenar modelos derivados.
Hay dos herramientas adicionales que conviene situar bien. Las marcas de agua y las firmas en el comportamiento del modelo no impiden la extracción: sirven para demostrar después que un modelo ajeno derivó del tuyo, lo que es un control de detección y de prueba, no de prevención. Y las técnicas de privacidad diferencial durante el entrenamiento sí acotan de forma demostrable cuánto puede inferirse sobre un registro individual, a costa de precisión y de complejidad operativa; es una decisión sensata en modelos entrenados sobre datos personales y desproporcionada en la mayoría de los demás casos.
La pregunta práctica con la que conviene revisar cada modelo propio es directa: si un competidor o un atacante consultara este sistema un millón de veces, qué obtendría que no debería tener, y cómo lo sabríamos. Si la respuesta a la primera parte es "nada especialmente sensible", el asunto es de costo y disponibilidad, no de confidencialidad. Si la respuesta involucra datos de personas o el modelo es un activo diferenciador del negocio, el trabajo empieza por revisar qué entró al entrenamiento, y no por poner un límite de tasa.