Auditar qué modelo sirve realmente su API — y por qué fallan las verificaciones de texto

¿De qué se trata?

Usted compra un modelo concreto. Recibe un endpoint HTTP. Nada entre ambos demuestra que coinciden.

Dos papers publicados este verano abordan esa brecha desde extremos opuestos. IRIS (arXiv, enviado el 23 de julio de 2026) audita pasarelas LLM comerciales usando únicamente el texto devuelto. AgentProv (arXiv, enviado el 30 de agosto de 2026, aceptado en EMNLP 2026) sostiene que, en las API agénticas, el canal de texto es el lugar equivocado donde mirar, y audita en su lugar el canal de llamadas a herramientas.

El vocabulario proviene de un trabajo anterior que formalizó el problema (arXiv, abril de 2025, revisado desde entonces). La sustitución es el reemplazo de todo el flujo: cada petición va a un backend más barato — un checkpoint más pequeño, una versión cuantizada o incluso otra familia de modelos. La dilución es fraccionaria: solo una porción ε de las peticiones se redirige, lo que resulta a la vez más barato para el proveedor y mucho más difícil de detectar. Ambas pueden originarse en un error de configuración, en control de costes o en una declaración falsa, y desde el lado del cliente se ven igual.

Cómo funciona

Ambas auditorías se apoyan en la misma observación: un modelo servido deja huellas estadísticas que sobreviven a la frontera de la API.

IRIS aprovecha que los modelos no saben ser aleatorios. Si se les pide un dígito o una cadena al azar, cada checkpoint devuelve un perfil de sesgo estable y propio; apilando esos sesgos sobre un puñado de sondas baratas se obtiene una huella. Lo que hace el método utilizable en operación es que dimensiona su propio presupuesto: un piloto barato ajusta la curva de decaimiento del error y congela el número de consultas antes de enviar tráfico sospechoso. Resultados reportados: 0,99 de AUROC verificando el backend en una escala intrafamiliar Qwen3; detección de dilución ε = 0,3 en pares cualificados con 0,85 de potencia media y una tasa de falsos positivos de 0,017; fracción de enrutamiento recuperada con un margen de 0,04 para sustitutos registrados. La asignación adaptativa eleva la tasa de acierto a presupuesto igual del 73 % al 87 %. En una auditoría real entre proveedores sobre una biblioteca de pasarela comercial, IRIS señaló 14 de 15 pares de proveedores que servían el mismo modelo, con las desviaciones atribuidas a diferencias genuinas de cuantización y de kernels, no a un engaño.

AgentProv parte de un problema estructural. Las pilas de servicio modernas descartan el texto cuando el modelo llama a una herramienta y solo exponen la acción estructurada, de modo que un auditor del canal de texto no tiene nada que medir precisamente en el tráfico que importa. Peor aún: los prompts de sistema inyectados por el proveedor distorsionan lo bastante las distribuciones textuales como para hacer parecer culpable a un proveedor honesto. AgentProv toma en cambio la huella de la distribución categórica de llamadas a herramientas — el post-entrenamiento agéntico reciente inscribe la política de uso de herramientas en los pesos — y decide la identidad con un test de permutación MMD. Reporta un 100 % de detección en 630 pares de checkpoints evaluados, manteniendo la tasa de falsos positivos bajo inyección de prompt de sistema en el 7 %, frente al 67 % y el 53 % de las dos referencias del canal de texto con las que se compara.

La formalización de 2025 es el contrapunto pesimista: la verificación puramente software es intensiva en consultas frente a sustituciones sutiles, y los métodos basados en log-probabilidades quedan derrotados por el no determinismo ordinario de la inferencia en producción. Su solución propuesta es de hardware: inferencia atestiguada dentro de un entorno de ejecución confiable (TEE).

Por qué importa

Sus evidencias de aseguramiento están ligadas a un modelo concreto. Resultados de red team, puntuaciones de evaluación, tasas de rechazo y medidas de resistencia a jailbreak se produjeron contra un checkpoint determinado. Si le sirven un backend cuantizado o sustituido, usted conserva el documento pero ya no la propiedad que describe.

La dilución está diseñada para ser negable. Una fracción de tráfico con comportamiento distinto se lee como varianza ordinaria. La verificación en el momento del alta — el único control que la mayoría de los procesos de compras ejecuta realmente — es justamente el que la dilución derrota.

Una desviación no es un fraude. La cifra de 14 sobre 15 es la advertencia honesta de esta literatura: los niveles de cuantización y las implementaciones de kernels difieren legítimamente entre proveedores que sirven los mismos pesos. Una señal de auditoría es una razón para hacer una pregunta, no una conclusión.

Los despliegues agénticos son el punto ciego. Esto se distingue de los proxies maliciosos, donde un intermediario hostil ataca al cliente. Aquí el proveedor puede ser enteramente de buena fe, y los elementos necesarios para comprobarlo simplemente los descartó la pila de servicio.

Defensas

Compras

• Nombre el artefacto en el contrato, no la gama comercial: modelo, versión, cuantización, pila de servicio. Exija notificación de cualquier cambio y derecho de auditoría.
• Pregunte si hay inferencia atestiguada disponible. Una atestación respaldada por TEE sustituye un argumento estadístico por una garantía criptográfica.
• Fije identificadores de modelo explícitos. Evite alias tipo latest y las conmutaciones automáticas silenciosas, que cambian el backend por diseño.

Ejecución

• Haga que el sondeo de conformidad sea continuo y presupuestado, no puntual en el alta. Fije el presupuesto a partir de un piloto antes de gastarlo, para que un resultado negativo signifique algo.
• En endpoints con llamadas a herramientas, audite sobre el canal de acción. Un auditor del canal de texto mide una señal que la pila de servicio ya eliminó.
• Controle el efecto de los prompts de sistema inyectados por el proveedor antes de concluir. Una distribución textual desplazada es un factor de confusión, no un veredicto.
• Registre un identificador o huella de modelo junto a cada llamada, para que un incidente posterior de calidad o seguridad sea imputable a un backend concreto.

Aseguramiento

• Reejecute periódicamente un subconjunto reducido de sus evaluaciones de seguridad y capacidad contra el endpoint de producción, no contra un despliegue de referencia. Trate una caída como un incidente de cadena de suministro y escálelo como tal.
• Cuando un proveedor no pueda atestiguar, cuantifique explícitamente el riesgo residual: asuma que el modelo servido puede ser más débil que el anunciado y compruebe si sus controles siguen sosteniéndose bajo esa hipótesis.

Estado

Elemento	Valor
IRIS	Preprint arXiv, enviado el 23 de julio de 2026
AgentProv	Preprint arXiv, enviado el 30 de agosto de 2026; aceptado en EMNLP 2026
Formalización del problema	arXiv, abril de 2025 (revisado)
Modos de fallo nombrados	Sustitución (flujo completo); dilución (fracción ε de peticiones)
Detección reportada por IRIS	0,99 AUROC intrafamiliar; ε = 0,3 con 0,85 de potencia media, 0,017 de FPR
Auditoría real de IRIS	14 de 15 pares de proveedores señalados, desviaciones atribuidas a cuantización y kernels
Detección reportada por AgentProv	100 % en 630 pares de checkpoints; 7 % de FPR bajo inyección de prompt de sistema
Referencias del canal de texto (FPR bajo inyección)	67 % y 53 %
Aviso de proveedor	Ninguno — es una cuestión de medición y de diseño de auditoría, no una vulnerabilidad de producto
Código	Publicado por IRIS y por la formalización de 2025