Cómo Google DeepMind evaluó Gemini sin compartir el modelo ni las preguntas de prueba

Google DeepMind presentó un método para evaluar un modelo avanzado propietario sin entregar los prompts confidenciales a la empresa que lo desarrolló ni los pesos del modelo a los evaluadores externos. El piloto, anunciado el 27 de agosto de 2026, puso a prueba Gemini 2.5 Flash-Lite junto con el Instituto de Seguridad de la IA de Singapur, OpenMined, AVERI y MLCommons. Google lo describió como la primera evaluación doble ciega de un modelo de IA propietario de clase frontera. 1213

La idea es sencilla, aunque técnicamente exigente: cada parte conserva sus activos sensibles y ambos se reúnen únicamente dentro de un entorno protegido para ejecutar una evaluación autorizada. Esto busca resolver un problema habitual de las pruebas de seguridad. Si el desarrollador recibe las preguntas privadas, estas podrían quedar registradas, utilizarse de forma deliberada o accidental en entrenamientos posteriores o contaminar futuras evaluaciones. Si los evaluadores reciben los pesos del modelo, obtienen propiedad intelectual valiosa y acceso a una capacidad potencialmente sensible.

Qué se puso a prueba

El piloto utilizó una pequeña selección privada de la familia de benchmarks AILuminate, desarrollada por MLCommons. AVERI indicó que los prompts no habían sido expuestos previamente a Google DeepMind y que se emplearon para examinar el comportamiento de seguridad en ámbitos como la asistencia para ciberataques, los peligros químicos y biológicos, el discurso de odio, las autolesiones y la inducción a delitos violentos. 1

El material del benchmark permaneció confidencial durante toda la evaluación. AVERI cifró los prompts; el entorno protegido ejecutó el modelo y el proceso de evaluación; después, los resultados se descifraron y calificaron según los criterios acordados. El objetivo del piloto era demostrar el método, no publicar una clasificación convencional: no se divulgaron puntuaciones principales del modelo ni los prompts subyacentes. 1

Cómo funcionó la evaluación doble ciega

La prueba se ejecutó en Confidential Space, dentro de Google Cloud Confidential Computing, sobre una máquina virtual A3 Confidential VM. Según el informe técnico, Intel TDX cifró y aisló la memoria del equipo anfitrión, mientras que una GPU NVIDIA H100 Confidential protegió los pesos del modelo en la memoria de la GPU mediante cifrado basado en hardware. Las conexiones cifradas transportaron los prompts de los evaluadores y los activos de Google hasta el entorno protegido. 13

El diseño también incorporó controles para limitar las acciones del proceso y los datos que podía devolver. Entre ellos figuraban rutas de datos cifradas, cortafuegos de hardware, un ciclo de vida efímero del enclave y la capa de políticas PySyft de OpenMined. El modelo, el código de inferencia, los prompts y el código de evaluación solo se reunieron dentro del enclave aprobado, donde se ejecutó el cálculo acordado y se devolvieron resultados acotados. 13

Por qué fue importante la atestación remota

El cifrado, por sí solo, no permite saber qué software se está ejecutando. La atestación remota pretendía cubrir ese vacío. Antes de liberar sus activos protegidos, Google y los evaluadores podían inspeccionar la carga de trabajo declarada y verificar una prueba criptográfica —conocida como attestation quote— que identificaba el hardware y la configuración del enclave. Solo después de esa comprobación se pusieron a disposición del entorno los prompts y los activos cifrados. 13

Al terminar la ejecución, el enclave devolvió los resultados de evaluación permitidos y fue desmantelado. Según el modelo de confianza previsto, Google no podía leer los prompts dentro del enclave y los evaluadores externos no podían extraer los pesos del modelo. Es una protección más fuerte que una simple promesa contractual de no registrar ni reutilizar los datos, aunque no elimina todos los supuestos de confianza. 13

El problema que intenta resolver

La contaminación de benchmarks es un desafío persistente en la evaluación de sistemas de IA. Una prueba pierde valor si el modelo ya ha visto sus prompts durante el entrenamiento, el ajuste fino o evaluaciones anteriores. MLCommons sostiene que los benchmarks fiables necesitan datos limpios, procedencia documentada, un muestreo cuidadoso y suficiente transparencia para entender cómo se obtuvieron los resultados. 2024

La evaluación doble ciega ofrece una tercera vía entre dos arreglos imperfectos:

• Entregar los prompts al desarrollador: simplifica la ejecución, pero puede exponer material reservado y aumentar el riesgo de filtraciones.
• Entregar los pesos a los evaluadores: protege el benchmark frente a la exposición directa de las preguntas, pero suele ser inaceptable en modelos de frontera propietarios.
• Usar un enclave confidencial: el modelo y el benchmark se encuentran en un entorno protegido por hardware, sin que ninguna de las partes reciba en claro el activo secreto de la otra.

El piloto demuestra así un mecanismo plausible para preservar la confidencialidad en ambos lados y permitir, al mismo tiempo, una evaluación externa. Sin embargo, no demuestra por sí solo que las conclusiones sobre seguridad sean completas o definitivas.

Limitaciones importantes del piloto

La demostración tiene relevancia técnica, pero hay varios motivos para no interpretarla como una validación independiente y concluyente de la seguridad de Gemini.

En primer lugar, los evaluadores podían verificar la carga de trabajo declarada del enclave y la interfaz del modelo, pero no inspeccionar de forma independiente los pesos propietarios de Google ni su implementación de inferencia. Eso limita su capacidad para auditar si el entorno se comportó exactamente como estaba previsto en todos los aspectos. 13

En segundo lugar, el entorno operativo no era reproducible de principio a fin por una parte independiente. El despliegue y la infraestructura en la nube permanecieron bajo control de Google, en lugar de ser reconstruidos y ejecutados de nuevo por una organización no afiliada. Además, el proceso de atestación seguía dependiendo del hardware, el firmware, los sistemas de servicio y la infraestructura de atestación de Google Cloud. La verificación respaldada por hardware es más sólida que una promesa contractual de no registrar datos, pero no elimina la dependencia de esa cadena tecnológica más amplia. 13

En tercer lugar, el piloto no publicó los prompts privados ni los resultados numéricos. Mantener las preguntas en secreto ayuda a conservar su valor para futuras pruebas, pero también limita el escrutinio público, la comparación entre modelos y la validación independiente de los hallazgos sustantivos. AVERI describe el trabajo como una evaluación cualitativa y cuantitativa de pequeña escala, no como un resultado completo de clasificación pública. 1

Por qué todavía no es un estándar de la industria

El hardware seguro resuelve solo una parte del problema. Para que las evaluaciones doble ciegas se conviertan en una práctica duradera, también tendría que madurar el marco de gobernanza que las rodea.

Salvaguardas legales e institucionales. Deberían establecer cómo se manejan los datos, qué resultados pueden divulgarse, cuáles son las responsabilidades y quién puede acceder a la información, especialmente cuando las pruebas abordan capacidades peligrosas.

Custodia de los benchmarks. Es necesario documentar la procedencia, el muestreo, el etiquetado y las limitaciones de los prompts, además de contar con procedimientos de actualización y vigilancia de la contaminación. MLCommons ha subrayado que un benchmark no es fiable simplemente porque sus datos sean secretos: su construcción y mantenimiento también deben poder defenderse. 2025

Reproducibilidad independiente. Organizaciones ajenas al proveedor del modelo y al operador de la nube deberían poder validar, en un grado significativo, la compilación, la cadena de atestación, las políticas de ejecución y los resultados comunicados.

Escalabilidad. Un estándar útil tendría que funcionar con distintos desarrolladores, arquitecturas, nubes, evaluadores, tipos de benchmark y versiones sucesivas de los modelos, no solo en una colaboración diseñada a medida sobre una única plataforma de hardware.

El piloto de Google DeepMind se entiende mejor como una infraestructura para una forma más exigente de evaluar la IA que como la respuesta definitiva al problema de la confianza en los benchmarks. Muestra cómo la computación confidencial puede reducir el conflicto entre proteger los datos de prueba y proteger los modelos propietarios. Que llegue a producir evidencia creíble a escala industrial dependerá de la supervisión independiente, una gestión sólida de los benchmarks, protecciones legales, reproducibilidad y viabilidad operativa; no solo de la criptografía del enclave. 1320