Extracción de modelos: cómo proteger tu gateway de IA

Un prompt que pide resolver un problema de código, puntuar una respuesta o explicar una decisión puede pertenecer a un cliente real. La misma forma, repetida con pequeñas variaciones entre miles de identidades, también puede alimentar un dataset para copiar capacidades de otro modelo. Si el gateway decide solo por palabras prohibidas, castigará investigación y uso legítimo; si mira únicamente el volumen por API key, una red distribuida repartirá el trabajo y desaparecerá dentro del promedio. La unidad de detección no es el prompt aislado: es el patrón coordinado que emerge entre identidades, infraestructura, tiempo, tareas y salidas.

OpenAI publicó el 30 de septiembre de 2026 una investigación sobre una campaña de distilación adversarial. La divulgación apareció cuatro días calendario antes de este artículo en Lima y es la noticia central. OpenAI afirma que observó picos de 16.000 solicitudes con un patrón relevante desde más de 4.000 usuarios y luego relacionó actividad en un clúster superior a 15.000; su nota aclara que esas cifras describen intentos, no extracciones necesariamente exitosas. También reporta una ruta de replay de razonamiento cifrado y controles sobre salida en streaming. Son hallazgos y atribuciones del proveedor, no una auditoría independiente ni un benchmark transferible a cualquier producto.

La distilación es una técnica legítima: un modelo profesor produce señales para entrenar un modelo estudiante más pequeño o especializado. Se vuelve extracción ilícita cuando alguien obtiene esas capacidades de forma encubierta, a escala y sin autorización. La frontera no se define por una plantilla de prompt. Importan el consentimiento y las condiciones de uso, quién controla los datos, la procedencia de las entradas, el destino de las salidas y la conducta agregada. Un equipo que distila su propio modelo con un corpus autorizado no es equivalente a una red de cuentas fraudulentas que intenta reconstruir capacidades protegidas.

Anthropic describió en febrero campañas que, según su investigación, distribuían tráfico entre cuentas, medios de pago y rutas de acceso, concentrándose en razonamiento, código, tool use y tareas de evaluación. Su informe de septiembre añade otro riesgo: routers de terceros que conservan o retransmiten conversaciones pueden exponer datos de usuarios y convertir sesiones ordinarias en material de entrenamiento sin que el usuario lo sepa. Ambas fuentes son divulgaciones del propio laboratorio y deben leerse con ese límite, pero convergen en una decisión técnica útil: defender el modelo exige correlación entre capas; proteger al usuario exige además minimizar datos y gobernar cada intermediario.

Una API key larga no crea una identidad confiable. Emite credenciales por aplicación y entorno; vincúlalas a organización, tenant, plan, región y responsable; limita su alcance; rota secretos; y registra cambios de ownership. Para pruebas, educación o investigación, define flujos de verificación proporcionales al riesgo en vez de excepciones permanentes. Si un integrador revende acceso, exige que preserve identidad de cliente y señales de abuso, porque una cuenta agregadora sin atribución convierte miles de actores en un solo punto ciego.

La respuesta a una anomalía debe poder degradarse. En lugar de saltar de acceso total a bloqueo definitivo, prepara límites más estrechos, revisión adicional, cooldown, suspensión de una capacidad concreta y escalamiento humano. Conserva un camino de apelación y evidencia suficiente para explicarlo sin revelar reglas que faciliten evasión. El objetivo no es adivinar la intención moral de cada usuario, sino reducir la capacidad de coordinar abuso mientras se evita que una campaña distribuida renazca inmediatamente con otra clave.

Construye señales por solicitud y por cohorte: cadencia, similitud estructural, diversidad real de tareas, proporción entre entrada y salida, modelos elegidos, reintentos, errores, regiones, ASN, dispositivo, método de pago y sincronía entre cuentas. No necesitas guardar cada conversación completa para conservar todas esas señales. Deriva features con retención acotada, hashes resistentes a filtraciones triviales, ventanas temporales y acceso separado. Los umbrales deben aprender del tráfico legítimo de cada producto; un batch nocturno de evaluación puede parecer coordinado y ser completamente autorizado.

Correlaciona en varios horizontes. Una ráfaga de diez minutos revela automatización; una repetición semanal puede revelar reabastecimiento de cuentas; un cambio brusco después del lanzamiento de un modelo muestra adaptación. Aun así, una correlación es señal, no veredicto. Combina reglas deterministas para límites claros con modelos o análisis estadístico para clústeres, y registra qué evidencia activó cada acción. Si el detector solo funciona con la memoria de un analista, no puede evaluarse ni recuperarse cuando cambie el adversario.

No diseñes un contrato que dependa de revelar pensamiento interno. Pide salidas verificables: respuesta, citas, cálculos resumidos, tool calls, decisiones y evidencia necesaria para revisión. Trata cualquier estado opaco o cifrado que viaje entre turnos como un capability token: átalo a usuario, workspace, modelo, propósito y expiración; evita que otro tenant pueda reproducirlo; y no lo escribas en logs, analytics o herramientas de soporte como si fuera texto inocuo. La portabilidad sin contexto puede transformar una optimización de continuidad en una superficie de replay.

La salida en streaming también necesita un punto de control. Si envías cada token directamente al navegador, no puedes retener una secuencia detectada tarde sin aceptar que parte ya salió. Define buffers pequeños para clases de alto riesgo, límites de tamaño, detectores de fuga y una respuesta segura cuando el stream se interrumpe. No presentes este filtro como infalible: puede generar falsos positivos o degradar latencia. Mide ambos efectos y deja que el producto elija qué rutas requieren inspección reforzada.

Un límite de solicitudes por minuto es necesario, pero insuficiente. Presupuesta tokens, concurrencia, volumen de salida, costo, tareas de alta capacidad y expansión de cuentas por usuario, organización e infraestructura compartida. Añade límites dinámicos por riesgo y por novedad del modelo: una ruta de razonamiento valiosa puede merecer controles diferentes a una clasificación corta. Evita que el cliente multiplique cuota creando proyectos, invitaciones o claves; el cálculo debe remontar a una identidad y a un contrato, no quedarse en el identificador más fácil de reemplazar.

Mapea todos los caminos hacia el proveedor: backend propio, nube asociada, fallback, router, SDK, observabilidad y soporte. El mismo control debe seguir a la solicitud cuando cruza un partner, o el atacante elegirá la ruta con menor visibilidad. Exige en contrato propósito de procesamiento, retención, entrenamiento, subprocesadores, región, respuesta a incidentes y devolución de señales. Prueba esas promesas técnicamente. Un diagrama de arquitectura que omite al router comercial también omite quién puede leer la conversación y quién debe detectar abuso coordinado.

Define estados de incidente antes de necesitarlos: observar, limitar, retener salida, exigir reverificación, suspender, investigar y cerrar. Cada estado debe tener owner, evidencia mínima, SLA, alcance y criterio de salida. Preserva muestras y features con cadena de custodia y controles de privacidad; notifica a partners cuando su ruta esté involucrada; y mantén una lista de consumidores aguas abajo para retirar datos contaminados o credenciales comprometidas. La coordinación externa no reemplaza el control local, pero evita que el mismo clúster migre entre proveedores sin fricción.

El eval debe mezclar ataques sintéticos, replay de incidentes ya cerrados y tráfico legítimo difícil: equipos de evaluación, cargas batch, aulas, CI y clientes que usan plantillas repetidas. Mide recall por campaña, precisión por acción, tiempo hasta correlación, cuentas nuevas tras enforcement, fuga antes de bloqueo, latencia añadida y apelaciones revertidas. Separa detección de contención: un sistema puede alertar bien y bloquear tarde. Mantén un conjunto holdout, renueva casos cuando cambien modelos y rutas, y ejecuta ejercicios donde una señal crítica desaparece para comprobar que la defensa degrada de forma segura.

Este ejemplo es hipotético. Un copiloto de soporte permite resumir tickets, proponer respuestas y evaluar calidad. Durante una semana crece el tráfico desde cientos de cuentas nuevas. Cada cuenta respeta su cuota y sus prompts parecen normales, pero comparten infraestructura, alternan los mismos dominios técnicos, solicitan respuestas largas y ejecutan rúbricas casi idénticas en ventanas sincronizadas. El gateway agrupa las señales sin guardar adjuntos completos, reduce la cuota de tareas de evaluación y exige reverificación. El equipo revisa muestras autorizadas antes de suspender el clúster.

La investigación descubre que parte del tráfico pasó por un router que reemplazó identidades finales por una credencial común. El equipo no puede atribuir cada solicitud, así que desactiva temporalmente la ruta de alta capacidad, mantiene clasificación corta para clientes afectados y pide al partner señales por tenant. También rota claves filtradas y avisa a usuarios cuyos datos pudieron ser retransmitidos. La lección no es que el detector «encontró un prompt malo»: encontró una falla conjunta de identidad, observabilidad, contrato y presupuesto, y respondió sin apagar todo el producto.

Las divulgaciones recientes no demuestran que toda automatización masiva sea extracción ni que una defensa concreta generalice entre proveedores. Sí muestran por qué los controles aislados fallan: la identidad puede fragmentarse, el tráfico puede moverse por partners, una salida puede filtrar más de lo previsto y una campaña puede adaptarse después del enforcement. Empieza con seis controles verificables: identidad vinculada, grafo de comportamiento, separación de razonamiento, presupuestos compuestos, respuesta reversible y evaluación continua. Documenta además qué no puedes observar y qué riesgo residual aceptas.

Un gateway seguro no es un proxy con rate limiting. Es la capa que conserva contexto de identidad, aplica políticas, minimiza datos, observa patrones, gobierna proveedores y produce evidencia para actuar. Si necesitas diseñar esa capa dentro de un agente o copiloto B2B, el servicio de agentes a medida de Wasyra puede ayudar a convertir estos controles en contratos, trazas y evals. Es un servicio de implementación separado del producto agents.wasyra.com; el criterio sigue siendo el mismo: ninguna capacidad llega a producción sin una frontera que pueda medirse, explicarse y detenerse.