Evaluación de modelos de IA sin exponer prompts en 2026

Sí, ahora es posible realizar la evaluación de modelos de IA sin entregar prompts de prueba confidenciales al propietario del modelo ni transferir pesos propietarios al evaluador, al menos en un piloto real. Google DeepMind ejecutó Gemini 2.5 Flash Lite y prompts privados de benchmark dentro de un entorno GPU verificado criptográficamente, permitiendo que solo salieran los resultados autorizados. La línea de coste en cómputo seguro ronda los $7.08 por hora según las tarifas Spot actuales en Iowa. El coste significativo corresponde al personal: el informe técnico de DeepMind señala que la coordinación legal y la revisión de código, y no la sobrecarga del hardware, constituyen hoy el principal cuello de botella. Esto transforma la evaluación confidencial de un debate sobre confianza en un proyecto de aseguramiento con alcance y presupuesto definidos.

Sí, pero se trata de un piloto y no de un botón de producto

La respuesta práctica es afirmativa, aunque con límites claros. El piloto de Google DeepMind del 27 de agosto demuestra que una organización externa puede evaluar un modelo cerrado manteniendo dos activos críticos aislados:

• El evaluador mantiene en secreto frente al propietario del modelo los prompts del benchmark, las reglas de puntuación y los casos de fallo.
• El propietario del modelo preserva en secreto frente al evaluador los pesos del modelo y el código de inferencia, que constituyen su núcleo tecnológico.

Los pesos del modelo son los parámetros aprendidos que determinan su comportamiento. Un benchmark privado equivale al examen de evaluación. Ceder cualquiera de los dos destruye valor. Un benchmark filtrado puede incorporarse al entrenamiento, inflando puntuaciones posteriores sin que el modelo mejore realmente. Entregar los pesos expone propiedad intelectual y capacidades que el proveedor necesita proteger rigurosamente.

Imagine el piloto como una sala de exámenes sellada con dos puertas. El modelo entra por una puerta. La prueba entra por la otra. Antes de abrir cualquiera de ellas, ambas partes verifican un certificado firmado que valida la sala, sus cerraduras y sus normas operativas. La evaluación se ejecuta dentro. La sala entrega únicamente la tarjeta de puntuación acordada y luego desaparece.

El piloto utilizó Google Cloud Confidential Space, una Confidential VM a3-highgpu-1g, protección de memoria Intel TDX, una NVIDIA H100 80GB Confidential GPU y software PySyft de OpenMined. Un enclave seguro es precisamente esa sala sellada implementada en hardware: la memoria permanece cifrada durante la ejecución y una atestación firmada permite a ambas partes auditar el software interno antes de transferir datos.

No estamos ante una disponibilidad general. Tanto el anuncio como el informe técnico describen un primer piloto experimental, no un servicio de evaluación autoservicio con precios publicados o fecha de lanzamiento comercial.

Cómo funciona la evaluación de modelos de IA a doble ciego

La criptografía es fundamental, pero el flujo operativo se comprende mejor a través de cinco aprobaciones.

1. 1

   Acordar la interfaz

   El propietario del modelo publica una interfaz simulada (mock). El evaluador prepara su código de prueba contra esa estructura sin acceder al modelo real. Ambas partes definen qué cálculos se permiten y qué resultados específicos pueden salir.

2. 2

   Iniciar la sala sellada

   Una de las partes despliega un entorno GPU confidencial con el sistema operativo, el runtime y el contenedor PySyft aprobados. Alojar la máquina concede la facultad de apagarla, no de inspeccionar los secretos de la contraparte.

3. 3

   Verificar la sala

   Cada participante comprueba la atestación remota, una huella criptográfica firmada de la pila de hardware y software. Los datos solo se liberan si las mediciones coinciden con la configuración acordada y son recientes para esta ejecución concreta.

4. 4

   Cargar y autorizar

   El propietario del modelo transmite por streaming los pesos cifrados y el código de inferencia al enclave. El evaluador envía los prompts cifrados y el código de evaluación por un canal independiente. Ambas partes auditan las rutas de código autorizadas y aprueban la ejecución.

5. 5

   Ejecutar, publicar y borrar

   El enclave evalúa el modelo, emite únicamente el resultado autorizado por la política de salida y se desmantela. Las claves temporales de cifrado en memoria se eliminan en cuanto el entorno se detiene.

El piloto de DeepMind ejecutó dos evaluaciones privadas. Una empleó prompts de reserva del benchmark AILuminate de MLCommons sobre riesgos como ciberataques, contenido CBRNE, discurso de odio, autolesiones e inducción a delitos violentos. Otra utilizó un conjunto de datos sobre contenido dañino contextualizado para Singapur, provisto por Singapore AISI. AVERI gestionó el cifrado y descifrado de prompts y salidas, aportando personal para evaluar dichas respuestas.

Este último detalle es crítico. Doble ciego no implica que nadie vea nada. El evaluador conoce su propia prueba y puede recibir las salidas generadas. La garantía es más concreta: el propietario del modelo no accede a la prueba confidencial, el evaluador no obtiene los pesos y el entorno cloud queda restringido por hardware y políticas de seguridad.

La partida presupuestaria que cambia

La evaluación confidencial no debe contratarse como una licencia más de observabilidad de modelos. Corresponde a procesos de auditoría de proveedores, gestión de riesgos de modelos, aseguramiento de seguridad o compras en sectores regulados.

Las herramientas habituales de evaluación ilustran el presupuesto de software estándar. Braintrust ofrece Pro a $249 per month. LangSmith lista Plus a $39 per seat per month, lo que sitúa cinco usuarios en $195 per month antes de computar el uso. Son soluciones útiles para gestionar pruebas internas y flujos de trabajo cotidianos; actúan como anclas de precio, pero no sustituyen una auditoría a doble ciego.

La infraestructura segura presenta costes transparentes. Google Cloud indica que Confidential Space no aplica cargos adicionales independientes. En Iowa, el precio Spot consultado para el tipo a3-highgpu-1g es de $6.636703068 per hour, y el recargo por computación confidencial es de $0.4391592. En conjunto, suma unos $7.08 per hour, o $70.76 por una ventana de diez horas, antes de costes de almacenamiento y red.

El informe refleja una penalización de cómputo inferior al 5 percent para la arquitectura en enclave, señalando la sobrecarga procedimental y la coordinación humana como el obstáculo principal. Esta es la consecuencia operativa: el cómputo ya es lo bastante predecible para presupuestarlo; el diseño de la confianza, todavía no.

Un presupuesto realista contempla cinco partidas: honorarios del evaluador, integración con el propietario del modelo, infraestructura del enclave, acuerdos legales y auditoría del código junto con la política de salida. Si una propuesta solo desglosa horas de GPU, no es un plan de auditoría. Si únicamente presenta horas de consultoría, conviene exigir la capa de ejecución confidencial.

Siete casos de uso clasificados por retorno económico

1. Empresas reguladas que adquieren un modelo cerrado

Bancos, aseguradoras y entidades sanitarias tienen el caso de negocio más inmediato. Su equipo de compras puede aportar casos de fallo privados basados en políticas y operativas reales. El proveedor presenta su modelo cerrado. Un evaluador independiente ejecuta la prueba y devuelve un reporte acotado sin que ninguna parte ceda sus activos neurálgicos.

El beneficio radica en contar con evidencia objetiva antes de firmar contratos plurianuales. La empresa valida los escenarios críticos para su operativa en lugar de depender de benchmarks públicos. El proveedor evita entregar sus pesos o custodiar prompts sensibles que no desea almacenar.

2. Institutos nacionales de seguridad de IA

Un organismo público de evaluación puede mantener prompts sobre riesgos cibernéticos, biológicos, de desinformación o regulatorios fuera de la infraestructura del laboratorio, sin renunciar a evaluar modelos de frontera comerciales. Este escenario coincide con el piloto, donde Singapore AISI facilitó un corpus privado de contenido dañino.

El valor principal es prolongar la vida útil del benchmark y afianzar la supervisión. Al no filtrarse, la prueba privada sigue siendo válida frente a futuras versiones del modelo sin peligro de contaminación en el preentrenamiento.

3. Creadores independientes de benchmarks

Una entidad de benchmarks puede reservar sus casos más complejos, ofrecer solo una interfaz simulada y evaluar distintos proveedores dentro del mismo entorno atestado. Podrá publicar resultados agregados manteniendo los prompts individuales en secreto.

La ventaja es preservar la exclusividad del benchmark. La entidad puede auditar múltiples modelos cerrados sin regalar la propiedad intelectual que fundamenta su negocio. El desafío se traslada a la política de salida, ya que métricas excesivamente granulares podrían revelar los prompts de forma indirecta.

4. Laboratorios de IA que requieren aseguramiento externo fiable

Un desarrollador de modelos puede permitir que un evaluador de prestigio ponga a prueba un checkpoint privado sin necesidad de exportarlo. El evaluador aporta los casos de prueba, ambos aprueban el entorno y las evidencias resultantes respaldan auditorías corporativas o informes de seguridad.

Se logra credibilidad sin transferir los pesos en crudo. Resulta idóneo cuando la evaluación por API ordinaria expondría el dataset del evaluador a la telemetría del proveedor.

5. Equipos de ciberdefensa evaluando capacidades ofensivas

Un operador de infraestructuras críticas puede comprobar si un modelo es capaz de diseñar o ejecutar secuencias de ataque sensibles mediante prompts que jamás deberían alimentar la base de datos de un proveedor. El modelo permanece cerrado y la prueba se mantiene en el perímetro de seguridad del operador.

Permite tomar decisiones de despliegue basadas en datos reales con mínimo riesgo de fuga. Requiere un entorno sandbox aislado y una política de salida muy estricta, pues la ejecución confidencial no vuelve inofensivas las respuestas peligrosas.

6. Sistemas de salud que validan modelos clínicos especializados

Un departamento de investigación hospitalaria puede estructurar casos límite anonimizados y evaluar un modelo cerrado sin canalizar esa información por APIs comerciales estándar. La evaluación puede centrarse en protocolos de derivación, abstención y justificación clínica, evitando diagnósticos libres.

Genera evidencia adaptada a la normativa del hospital protegiendo tanto los historiales como el modelo. La gobernanza de datos y la regulación médica continúan vigentes: el enclave actúa como control técnico, no como exención legal.

7. Auditoría técnica en fusiones y adquisiciones

Un comprador en un proceso de M&A puede someter al modelo propietario de la empresa objetivo a casos de prueba reales procedentes de su due diligence. Un evaluador neutral ejecuta las pruebas acordadas y entrega métricas delimitadas a las partes autorizadas.

Reduce la exposición de secretos antes del cierre de la transacción y evita basar la decisión en demostraciones preparadas. Dado el coste de despliegue, encaja en operaciones corporativas relevantes y alianzas estratégicas, no en evaluaciones preliminares.

Tres productos viables para construir

1. Un laboratorio privado para la contratación de modelos (la mayor oportunidad)

Construir un servicio gestionado donde el comprador regulado aporte pruebas de aceptación confidenciales, el proveedor entregue el modelo cerrado y la plataforma devuelva un expediente de evidencias atestado. El cliente directo es el director de riesgos (CRO), los responsables de seguridad o los departamentos de compras técnicas.

Existe un interés de mercado demostrable: ai governance platform registra 1,600 búsquedas mensuales en EE. UU., con pujas superiores estimadas entre $27.92 y $71.51, y un crecimiento interanual del 307 percent en sugerencias. El mercado demanda herramientas de gobernanza; un laboratorio de evaluación convierte esa necesidad en una decisión de compra respaldada criptográficamente.

El producto mínimo viable consiste en: un modelo, una batería de pruebas privadas, un paquete de métricas autorizadas, una ejecución atestada y un informe ejecutivo auditable. Conviene iniciar como servicio especializado con software de soporte. El reto reside en la confianza: exige seguridad corporativa, evaluadores de prestigio, pericia en cloud, contratos marco y reputación técnica.

2. Un plano de control de atestación para evaluación de modelos de IA

Desarrollar software que traduzca hashes criptográficos, nonces, firmas de imágenes, políticas de seguridad y registros de ejecución en un panel de cumplimiento accesible. El cliente es el evaluador o proveedor que domina el cómputo seguro pero busca evitar que cada auditoría se convierta en un proyecto criptográfico a medida.

El término confidential computing suma 880 búsquedas mensuales en EE. UU. y un CPC de $30.80. Aunque el volumen es menor que en gobernanza general, el perfil del comprador es muy técnico y el problema implica presupuestos altos. La aspiración del informe de DeepMind es precisamente simplificar las pruebas de confianza sin lidiar manualmente con claves y dependencias.

El MVP valida el patrón de Google Cloud Confidential Space, registra las aprobaciones mutuas, las asocia a la imagen medida del software y emite un manifiesto firmado. La dificultad estriba en la dependencia del hardware y el cloud: incorporar otro entorno de enclaves modifica la raíz de confianza, el formato probatorio y los posibles modos de fallo.

3. Un mercado de intercambio de benchmarks sellados

Crear una plataforma donde los propietarios de benchmarks listen qué evalúan sin revelar las preguntas, y los creadores de modelos contraten ejecuciones atestadas que devuelvan únicamente métricas aprobadas. Quienes diseñan pruebas monetizan sus datasets sin difundirlos; quienes desarrollan modelos acceden a evaluación externa sin ceder sus pesos.

La consulta ai model evaluation tiene 140 búsquedas mensuales en EE. UU., KD 0 y un incremento interanual del 200 percent. Son cifras que justifican una solución B2B especializada, sobre todo al vender acceso seguro de alto valor en lugar de licencias estándar.

El MVP requiere un socio de benchmarks, un desarrollador de modelos, una imagen de enclave y una política de salida. El riesgo principal es la fuga por inferencia reiterada: con suficientes consultas o métricas desagregadas se puede reconstruir el benchmark. Los límites de tasa, la granularidad y la custodia de datos son funciones esenciales del producto.

El laboratorio de compras es el modelo de entrada más claro porque resuelve un dilema presupuestario existente: aprobar, rechazar o negociar la contratación de un modelo. Las otras dos opciones representan infraestructura valiosa, pero requieren un ecosistema más maduro.

Qué problemas no resuelve esta arquitectura

El piloto demuestra la viabilidad del secreto mutuo, pero no hace que la evaluación sea automática, globalmente barata o independiente de entidades de confianza.

• No es una plataforma autoservicio. DeepMind no ha facilitado fecha de salida al mercado ni tarifas para el piloto.
• Se demostró con un modelo cerrado en una sola H100. El documento prevé clusters confidenciales multirruta con H100 o B200 para modelos de mayor escala en trabajos futuros.
• No prescinde de la confianza en terceros. Se asume que el fabricante de hardware y el proveedor cloud no actúan de forma coordinada y maliciosa. El firmware propietario forma parte de la base de confianza.
• Google participa en la cadena de validación. El piloto dependió de los certificados y claves de verificación de Google; los entornos invitados no fueron reproducibles de forma independiente por el uso de claves privadas.
• Partes del código del modelo permanecieron opacas. No fue viable hacer auditables o incluir en listas blancas todos los métodos propietarios. AVERI asumió esa condición para este piloto.
• Un mal examen sellado sigue siendo un mal examen. El enclave garantiza el aislamiento de los prompts y la integridad del cómputo, pero no asegura que la métrica elegida sea predictiva del rendimiento real en producción.
• Las salidas requieren gobernanza específica. Un resultado excesivamente detallado puede desvelar el benchmark o secretos del modelo. Es obligatorio pactar la política de salida antes de iniciar el cómputo.
• El factor humano sigue pesando. Los acuerdos legales, las auditorías de código y la coordinación interinstitucional siguen acaparando la mayor parte del tiempo y los costes.

Para los equipos que seleccionan plataformas hoy en día, la guía de herramientas de auditoría de benchmarks aborda las opciones disponibles para evaluación rutinaria. La evaluación a doble ciego se reserva para escenarios donde el modelo, las pruebas o ambos son demasiado confidenciales para evaluarse vía API convencional.

Nuestra conclusión es clara: estamos ante un patrón de aseguramiento sólido y novedoso, no ante una categoría de producto empaquetada. Los primeros en adoptarlo serán organizaciones con decisiones críticas en juego, donde el valor de una certeza auditable compense con creces los costes de coordinación.

El plan para el lunes

Si lidera iniciativas de compras de IA, gestión de riesgos o seguridad, identifique una decisión contractual sobre modelos prevista para los próximos 30 días. Redacte un pliego de evaluación privada de una página que recoja: el modelo propuesto, una familia de fallos crítica, la entidad propietaria de las pruebas, la entidad titular de los pesos, la métrica autorizada para salir y la decisión de negocio que dependerá de ese dato.

Solicite a un evaluador externo y al proveedor del modelo presupuestos desglosados en cinco líneas: integración técnica, horas del evaluador, redacción de acuerdos legales, revisión de código y políticas de salida, e infraestructura confidencial. Tome los $7.08 por hora de GPU exclusivamente como referencia de cómputo base. El objetivo es visibilizar el coste íntegro de aseguramiento y evitar asumir que un gasto de $71 por diez horas de máquina cubre todo el proyecto.

Evite desarrollar una plataforma genérica desde el primer día. Demuestre primero que una evaluación sellada valida o descarta una adquisición, lanzamiento o integración concreta. Si lo consigue, tendrá el argumento operativo necesario para establecer un programa recurrente.

How to evaluate the performance of an AI model?

Comience por definir la decisión operativa que dependerá de la evaluación y elabore un conjunto de datos reservado que refleje fielmente la tarea real. Establezca las métricas clave y los límites de tolerancia a fallos antes de ejecutar el modelo, garantice una separación estricta entre los datos de entrenamiento y los de prueba, y documente con precisión la versión del modelo, el entorno, los prompts, el código de puntuación y la política de salida. Si exponer el examen o el modelo supone un riesgo estratégico para alguna de las partes, recurra a una arquitectura a doble ciego.

What is an AI model evaluator?

El término puede aludir a un especialista, una organización independiente o una solución técnica encargada de medir el comportamiento del modelo frente a baterías de prueba y reglas de validación predefinidas. En el piloto de DeepMind, entidades externas suministraron los datasets confidenciales y auditaron las salidas, mientras el modelo propietario permanecía blindado dentro del entorno verificado.

What does model evaluation measure in AI?

Permite cuantificar la precisión operativa, el cumplimiento de protocolos de seguridad, la robustez ante entradas adversarias, la calidad de las abstenciones, la veracidad factual, los sesgos algorítmicos, la latencia o los costes por inferencia, siempre en función del caso de uso. El uso de enclaves seguros protege el acceso a la prueba y al modelo; la validez y pertinencia de las métricas dependen del diseño técnico del evaluador.

What is a prompt for testing AI models?

Es una entrada formulada expresamente para poner a prueba una capacidad técnica o inducir un modo de fallo bajo parámetros controlados. Un prompt de prueba riguroso cuenta con un resultado esperado o una regla de evaluación objetiva, y forma parte de un conjunto de datos independiente con el que el modelo no ha sido entrenado. En auditorías críticas, puede incorporar directivas internas, vectores de amenaza o propiedad intelectual sensible que no debe trascender al desarrollador del modelo.

Si necesita diseñar un flujo de evaluación privada de modelos adaptado a sus decisiones corporativas, evidencias y requisitos de seguridad, consulte AI production systems.