¿Qué modelo te ha contestado? Ahora, con prueba

Hoy nadie puede saber qué modelo le ha contestado

Cuando se pregunta algo a un modelo de IA, la respuesta llega sin firma. Según Anthropic, un usuario no puede comprobar hoy que viene del modelo que el desarrollador dice que responde, y no de otro colado en secreto por un intermediario que reparte las peticiones entre modelos para ahorrar costes, ni de un atacante que haya manipulado la secuencia de tokens. Y juzgar por el texto no basta: según la empresa, es «poco fiable» aunque la respuesta sea de calidad.

Para el uso diario, en el que importa más la respuesta que el modelo que la escribe, la empresa reconoce que es una preocupación menor. Pero Anthropic cita casos en los que sí importa. Los evaluadores independientes que prueban modelos antes y después de su lanzamiento necesitan saber que examinan el mismo que luego se sirve. Los clientes que contratan a través de un intermediario quieren saber que los tokens salen del modelo que pagaron. Y un atacante que altere las respuestas no se detecta mirando solo el texto.

Anthropic piensa también en los reguladores: comprobar que un proveedor sirve solo modelos aprobados, o que su hardware se dedica a servir respuestas y no a entrenar otro modelo a escondidas. En este último caso, la propia empresa advierte de que demostrar que el hardware sirve respuestas no prueba que no esté, por ejemplo, entrenando otro modelo a la vez.

Comprobarlo sin el modelo parecía fuera de alcance

Comprobar una respuesta choca con dos obstáculos, según Anthropic. Los pesos de la mayoría de los modelos punteros son privados. Y aunque el usuario los tuviera, verificar que una respuesta sale de ellos obligaría a ejecutar el modelo, con unos recursos de cálculo muy por encima de lo que puede permitirse un usuario, o incluso un evaluador.

La salida que propone la empresa es una prueba criptográfica: el proveedor envía con cada respuesta un fichero de unos pocos megabytes que el usuario comprueba en segundos, sin ver los pesos. Si la respuesta no sale del modelo indicado, la comprobación falla.

El objetivo no es nuevo para Anthropic. En su hoja de ruta de seguridad, el Frontier Safety Roadmap, se fijó como meta un prototipo de inferencia verificable para el 30 de septiembre de 2026. Según la empresa, la cumplió con otro proyecto, que firma su tráfico y recalcula las respuestas en un servidor de confianza; FlashProve persigue lo mismo por un camino distinto.

FlashProve: compromiso, prueba y comprobación

FlashProve es el sistema que Anthropic presentó el 2 de noviembre de 2026. Lo firma el Frontier Red Team, el equipo de la empresa que somete los sistemas de IA a pruebas de estrés para entender hasta dónde llegan sus capacidades actuales y anticipar lo que viene.

Colaboran investigadores de la EPFL, la Escuela Politécnica Federal de Lausana, universidad técnica suiza; del Instituto Tecnológico de Massachusetts (MIT), universidad estadounidense; de StarkWare, una empresa de tecnología criptográfica que contribuye a Starknet, la red de cadena de bloques construida sobre su tecnología, y de Succinct, una empresa de criptografía aplicada, autora de SP1 y de una red para generar pruebas.

El sistema tiene dos partes: el proveedor del modelo, que demuestra, y el usuario, que comprueba. Y dos fases. En la previa, que se hace una vez por modelo, el proveedor publica un compromiso con los pesos. Según Anthropic, con Llama 4 Maverick tarda unos 39 minutos y sirve para unos 16 millones de peticiones; después hay que comprometerse de nuevo.

En la fase en línea, para cada petición, el proveedor genera un fichero que, según la empresa, prueba que «el modelo comprometido produce estos tokens de salida». Cualquiera que tenga el compromiso, el texto enviado y la respuesta puede comprobarlo sin los pesos y con poco cálculo.

Una prueba que no enseña nada más

Según Anthropic, la prueba de FlashProve cumple cuatro propiedades. Si es honesta, se acepta. No se puede falsificar salvo rompiendo supuestos criptográficos ampliamente aceptados. No revela nada de los pesos, ni de los cálculos intermedios, ni de qué partes del modelo se activaron. Y es pequeña y rápida de comprobar.

Lo que no oculta es la arquitectura: cómo está organizado el modelo por dentro, sin contar los pesos. La empresa lo deja para trabajos futuros.

La herramienta es un zkSNARK, el mismo tipo de prueba que usan redes de cadena de bloques como Starknet. Según Anthropic, su construcción se apoya en funciones hash y ofrece incluso seguridad poscuántica.

Claude puso la velocidad; Lean, las garantías

Según Anthropic, fue Claude, su modelo, quien introdujo mejoras en estos zkSNARKs y construyó un sistema «sustancialmente más rápido que los sistemas de código abierto anteriores». La misma empresa admite el riesgo: Claude «a menudo toma decisiones difíciles de evaluar». Para compensarlo, las garantías de seguridad se enunciaron y demostraron en Lean, un lenguaje de verificación formal.

Se publican cinco piezas, con el código, las demostraciones y la documentación bajo licencia Apache 2.0: el artículo, un informe técnico, la descripción del protocolo, el código ejecutable —un generador de pruebas y dos verificadores, uno rápido en C++ y otro en Lean demostrablemente correcto— y las demostraciones en Lean, con un visor interactivo para revisarlas. Según la empresa, es un avance intermedio, «no un programa de investigación terminado».

El verificador en C++ es el de uso diario, pero, según Anthropic, «no tiene ninguna garantía formal». En sus pruebas, coincide con el de Lean en todos los casos.

El banco de pruebas: Llama 4 Maverick

Para medir, Anthropic usó Llama 4 Maverick, un modelo de Meta de 400.000 millones de parámetros, de los que usa unos 17.000 millones por token. Es una mezcla de expertos, y FlashProve solo funciona con modelos de ese tipo: según la empresa, el trabajo de quien demuestra es proporcional a los expertos que se activaron, no al modelo entero, y la prueba sigue ocultando cuáles fueron.

Los pesos no van en la publicación. Quien quiera repetir el experimento los descarga aparte, en una conversión pública a 4 bits hecha por terceros, bajo la licencia Llama 4 de Meta.

Cuánto cuesta hoy demostrar una respuesta

Las cifras son de Anthropic, medidas con la versión a 4 bits del modelo, que ocupa unos 232 GB: cada petición es una ventana de 1.024 tokens leída de una pasada (prefill) y cada prueba comprueba un solo token. Quien demuestra trabaja en un servidor con una sola GPU H100 de Nvidia y 24 núcleos de procesador. Quien comprueba lo hace en el procesador del cliente, sin GPU: descarga una vez el compromiso y, después, una prueba por petición.

El precio está en el sobrecoste. Anthropic lo mide contra vLLM, un motor de código abierto muy usado para servir modelos, con la versión en 8 bits (FP8) del mismo modelo en ocho H100 y contando por GPU. Es la última línea de la tabla, y la que más pesa.

Frente a lo anterior, un salto de escala

Según Anthropic, la única prueba anterior de Llama 4 Maverick que conoce es la de VerInf, un trabajo de investigación previo. Cita también a Attestable, una empresa que ha publicado cifras con otro modelo, Gemma 4 31B, que es denso, y que no ha liberado una biblioteca de código abierto. La tabla pone las tres al lado.

La conclusión de la empresa es que demostrar una respuesta cuesta «aproximadamente 2 órdenes de magnitud» más que calcularla, «entre unas 70 y 95 veces en nuestras mediciones», y que eso es «mucho menos de lo que se esperaba». Anthropic cree que el avance debería trasladarse a más modelos y arquitecturas.

Lo que la prueba no dice

Una prueba aceptada no dice que la respuesta sea correcta, ni que el modelo sea bueno o seguro. Según la propia definición de Anthropic, certifica una sola cosa: que «el modelo comprometido produce estos tokens de salida». Es decir, qué pesos produjeron la respuesta, no si la respuesta es buena.

Y hay letra pequeña, declarada por la empresa. Lo que se demuestra es una versión exacta en números enteros de los pesos publicados, y que cada token comprobado es la elección voraz del modelo. Una respuesta calculada con decimales en coma flotante, o generada con muestreo, puede apartarse en algún punto y dejar de coincidir. Anthropic espera que la versión entera quede muy cerca de la real, pero eso no cubre las instrucciones preparadas por un adversario.

Es, además, un prototipo de investigación. El repositorio se presenta como «un artefacto de investigación: sin mantenimiento y sin aceptar contribuciones».

Pruébalo: cuatro rutas, de menos a más

El repositorio de FlashProve propone cuatro formas de probarlo, de menos a más exigente. Solo la primera es ligera: compila el verificador, cp_verify, y comprueba una prueba guardada. Las dos últimas piden una GPU H100 y, la cuarta, cientos de gigas de memoria y de disco.

Esa prueba guardada tiene truco, y el README lo dice: es un modelo sintético pequeño, de 8 capas, 4 expertos y un vocabulario de 512 piezas, así que «solo demuestra que el verificador funciona, no nada sobre un modelo en servicio».

El ejemplo, abierto sin ejecutar nada

El 3 de noviembre de 2026, hacia las 10:05, recorrimos la parte de la ruta 1 que no necesita ejecutar nada descargado: clonar el repositorio, comprobar que los ficheros del ejemplo llegaron íntegros y leer qué se está demostrando. Sin GPU y sin coste.

La suma de comprobación tiene un límite que conviene no olvidar: solo garantiza que la descarga está entera, no que la prueba sea válida. Eso lo decide el verificador.

Lo que se demuestra cabe en tres ficheros. La petición, example.req, son 64 tokens más dos valores, r y e; la respuesta, example.y, es el token siguiente, el 199. Según el README, la prueba afirma que los tokens 61, 62 y 63 y ese token siguiente son, cada uno, el que el modelo comprometido pone primero.

La comprobación completa exige compilar el verificador, y no lo compilamos ni lo ejecutamos. El README indica que, con este ejemplo, la última línea debe ser YES y el código de salida, 0.

Cómo se lee el veredicto

cp_verify da su veredicto con dos señales a la vez, el código de salida y la última línea, y el README pide leerlas juntas. Un código 0 con YES (o WITHIN LIMITS) es una prueba aceptada; un código 1 con NO, una rechazada o un fallo local, y el código 5, que no hay veredicto; otros códigos señalan llamadas o ficheros erróneos.

Un solo bit basta para que la rechace

El repositorio trae también el caso contrario. Según su README, un script altera los ficheros del ejemplo uno a uno y el verificador los rechaza todos con código 1: «10 conjuntos alterados: todos rechazados». La tabla recoge lo que documenta ese README; no es una ejecución propia.

Según ese mismo documento, cambiar un bit de la prueba, recortar su último byte o tocar un token del texto enviado o de la respuesta hace que la prueba se rechace. Usar otro identificador de compromiso, o alterar un bit de la clave, falla por otra vía, con su propio motivo.

Dos tareas que el verificador deja al usuario

En uso real, el README deja dos tareas en manos de quien comprueba. La primera, conseguir el identificador del compromiso «antes de enviar el prompt, de quien responde por el modelo, no a través del servidor que estás comprobando». Y añade: «Nunca lo tomes de los ficheros que acompañan a una prueba».

La segunda, construir uno mismo el fichero de la petición con el texto enviado y la respuesta recibida, porque, según el README, «nada comprueba que el fichero contenga tu prompt y tu respuesta». Una prueba impecable sobre una petición que no es la tuya no garantiza nada sobre tu respuesta.