Carril de lanzamiento con acceso restringido para IA con capacidades de seguridad: lanzar, demostrar, solicitar

Estás decidiendo quién puede ejecutar un modelo con capacidades de seguridad, qué pruebas necesita y cuándo los usuarios pueden cambiar su flujo de trabajo. Gemini 3.8 Flash Cyber no se ofrece a través de la API estándar de Gemini; el acceso está limitado a defensores verificados bajo el Programa Fairwind de Google, que incluye agencias públicas, operadores de infraestructura esencial y mantenedores de software. El rediseño es un carril: una línea base pública, una variante de defensor con acceso restringido y evidencia independiente antes de que cambien los flujos de trabajo. Haz del carril el producto, no la ficha del modelo.

La línea base pública debe ser inspeccionable

Define la línea base pública como la evidencia que cualquier equipo puede inspeccionar sin acceso especial. El estado final es un modelo con nombre, un límite de capacidad documentado y una evaluación pública que muestre dónde es fuerte y dónde no lo es.

Ejecuta la línea base contra un conjunto de tareas de seguridad compartido. Usa CWE-Bench, un benchmark de vulnerabilidades, cuando la tarea sea la detección de vulnerabilidades. Gemini 3.8 Flash Cyber logró un 47,2 por ciento de pass@1 en CWE-Bench, mientras que un modelo fronterizo líder logró un 47,8 por ciento. Mantén un registro fechado con la puntuación, el conjunto de tareas y los fallos.

Añade una puntuación de capacidad general para que la línea base no sea solo un número de seguridad. Gemini 3.8 Flash logró una puntuación del 54,9 por ciento en HLE-Verified. Un número público solo importa cuando el lector puede reproducir la tarea, la métrica y el modo de fallo.

Nombre el límite de capacidad en lenguaje claro. El límite debe indicar qué puede inspeccionar el modelo, qué puede modificar y qué no debe hacer. Debe ser una descripción breve que un ingeniero no especializado en seguridad pueda leer sin pedir un glosario.

Establece la cadencia de evaluación antes del lanzamiento. Ejecuta el mismo conjunto de tareas después de cada actualización del modelo, cada cambio de prompt y cada cambio de acceso. «Hecho» significa un registro fechado que muestre si la línea base sigue siendo válida.

La variante de defensor debe ser un contrato

Restringe la variante de defensor detrás de controles de acceso que se ajusten al riesgo. El control de acceso necesita un proceso de solicitud, un programa con nombre y una lista de quién puede usar la capacidad. El registro es una solicitud que no puede eludir el programa.

Exige evidencia independiente antes de que la variante restringida cambie un flujo de trabajo. El paquete de evidencia incluye evaluaciones de terceros, comprobaciones de corrección de parches y un modelo de coste que resista el volumen de producción.

Comprueba la evidencia contra el trabajo. En un benchmark interno que abarca 20 lenguajes de programación, el modelo superó una tasa de éxito del 70 por ciento para descubrir vulnerabilidades en bases de código complejas. El modelo generó 2,6 veces más parches correctos de vulnerabilidades de Chrome que los principales modelos comerciales mucho más grandes. En el benchmark interno de pruebas de penetración de Wiz, mostró una precisión (recall) 7,5 a 9,7 por ciento superior con un coste 2,3 a 5,2 veces menor que otros modelos fronterizos líderes. El entregable es una nota de decisión que nombra la brecha.

Redacta el contrato de acceso antes de cualquier solicitud. El contrato debe nombrar el uso permitido, el alcance de los datos, el límite de retención y la vía de salida. Es un documento al que ambas partes pueden señalar cuando una solicitud se sale del carril.

Pon a prueba el control de acceso bajo presión. Pide una capacidad que el carril no cubra y observa la negativa. La negativa es una denegación clara, una razón y una vía para solicitar el nivel adecuado.

Si un equipo puede decir «nivel de defensor» sin mostrar la evaluación, el carril ha fallado.

El coste y el acceso son señales de confianza

Fija el precio del carril para que el nivel sea visible. Las tarifas introductorias son de $0,75 por millón de tokens de entrada y $3,75 por millón de tokens de salida hasta el 31 de diciembre de 2026, subiendo a $1,50 y $7,50 por millón de tokens el 1 de enero de 2027. La tabla de precios es la primera señal de confianza que ve un comprador.

Un carril restringido que oculta precios, acceso o evaluaciones pide a los usuarios que infieran el límite. Un carril que muestra el límite les permite decidir.

Etiqueta el nivel activo en la interfaz. La etiqueta debe indicar qué variante está en ejecución, qué puede hacer y qué evidencia respalda la afirmación. Le da a un usuario nuevo una comprobación rápida de que el nivel es real.

Registra el límite. Anota quién solicitó acceso, qué datos puede ver el modelo y qué se le dijo al usuario. La pista de auditoría es el estado final.

Estima el volumen de producción antes de que el precio sea una sorpresa. Cuenta el número esperado de archivos de código, la longitud media de tokens y el número de reintentos. El rango de coste es un número mensual con un responsable, no una ejecución de demostración.

Asigna un responsable del presupuesto. Esa persona debe ver la tendencia de coste, la lista de acceso y los resultados de las evaluaciones en el mismo lugar. El responsable puede responder si el carril sigue valiendo el nivel.

Los comprobantes deben preceder a los cambios de flujo de trabajo

Termina el plan de lanzamiento con una lista de verificación que el equipo pueda firmar. Cada elemento necesita un responsable, una fecha y un comprobante.

• línea base pública
• variante de defensor con acceso restringido
• evaluaciones independientes
• corrección de parches
• coste
• controles de acceso
• señales de confianza para el usuario

Lanza solo cuando cada elemento tenga un comprobante.